Orphan Pages: The Posts Nothing Links To

Open your sitemap and pick a post from the middle of it. Now try to reach that post from your homepage using only links, the way a reader would. On most business blogs past a few hundred posts, you cannot. The page exists, it is in the sitemap, it is indexed — and nothing on the site points at it. That is an orphan page, and once you start looking you usually find you have a lot of them.

Why an orphan is weaker than it looks

Internal links do two separate jobs, and an orphan fails both.

The first is discovery. A crawler arrives at your homepage and follows links. Anything it can only find through the sitemap is being discovered by the least informative route available — you have told it the URL exists, but nothing about where the page sits, what it relates to, or whether the rest of the site considers it important.

The second job is the interesting one: internal links are how a site states its own priorities. When six pages link to one guide, the site is saying that guide matters. When nothing links to it, the site is saying nothing at all. You cannot make up for that with external authority you do not have — for most small business sites, internal linking is the only ranking lever that is entirely under their own control.

How a site ends up with hundreds of them

Orphans are almost never created deliberately. They accumulate through a few very ordinary mechanisms.

• Volume publishing. A generator writes posts one at a time with no knowledge of the corpus, so nothing it writes ever links to anything it wrote last week.
• Chronological blog indexes. Your blog page lists the newest posts. A post is linked for as long as it is on page one, then it silently falls off and nothing points at it again.
• Deleted or restructured hubs. A category page gets removed in a redesign, and every post that was only reachable through it becomes unreachable in the same commit.
• Tag pages that are noindexed. Very common, and it quietly means the only thing linking to a post is a page you have told search engines to ignore.

The pattern underneath all four: linking is treated as something you do to a page when you publish it, rather than something the whole corpus does continuously. New posts get links. Old posts stop getting them.

Finding your orphans

You need two lists and a subtraction. The first list is every URL that exists — take it from your sitemap, or from the filesystem if the site is static. The second is every URL that is linked to from somewhere on the site — crawl your own homepage and follow internal links until you stop finding new ones.

Anything in the first list and not the second is an orphan. Any free crawler will do this; so will a short script if your site is static. The number is usually higher than people expect, and the useful part is not the total but the shape: if your orphans cluster in one date range or one category, you have found the exact moment your process broke.

The fix that does not work

The obvious move is to pick your best pages and link to them from everywhere. Resist it. That is how a link graph collapses into a star: a handful of pillar pages accumulate every internal link on the site, and the long tail — which is most of your corpus — goes on earning nothing. You have not fixed the orphan problem, you have concentrated it.

The same trap appears in automated related-posts blocks that simply pick the highest-scoring matches. Relevance alone is not enough, because relevance is not evenly distributed. A few broad posts are plausible neighbours for everything, so they win every slot, and the specific posts that most need a link get none.

What actually works: weight the graph, not just the relevance

If you generate related links automatically, score candidates for relevance and then divide by how many inbound links each candidate has already received in this run. A page that has been chosen five times becomes a less attractive choice the sixth time. Relevance still decides the shortlist; distribution decides the pick.

Then add a rescue pass. After everything is assigned, find any page with zero inbound links and force it into its nearest neighbour's list. It is a blunt instrument and it is the difference between every page having at least one way in and a permanent orphan tail. This is worth doing even manually if your corpus is small enough.

Two other things earn their keep. Topic hubs — real pages, per subject, that link out to everything in that subject — give the long tail a structural home rather than a lucky adjacency. And when you publish something new, the run should relink the corpus around it, not only add links to the new page. A new post should earn inbound links on the day it ships, not just outbound ones.

Do not confuse this with a reason to publish more

There is a version of this advice that ends with more content, and it is wrong. Orphan pages are a symptom of a corpus that grew faster than its structure. Adding pages to a site whose link graph is already broken produces more orphans, not fewer, and if the new pages overlap the old ones you have added a second problem on top of the first.

The order matters: fix the graph over what you already have, remove what should not exist, and only then think about volume. A smaller corpus where every page has a way in will outperform a larger one where most pages are islands.

A short checklist

• Subtract linked-URLs from all-URLs; look at where the orphans cluster, not just how many.
• Never fix orphans by linking everything to a few pillars.
• Weight automated related-links by inbound count, not relevance alone.
• Add a rescue pass so nothing finishes with zero inbound links.
• Build real topic hubs; do not rely on chronological indexes or noindexed tag pages.
• Relink the corpus when you publish, so new posts earn inbound links too.

A page nothing links to is a page your own site declines to vouch for. Search engines notice that before they notice your keywords.

← Back to all articles