How to Audit Orphan Pages on a Large Blog

What is an orphan page and why does it matter on a large blog?

An orphan page is a page on your site that no other page on your site links to. It can still exist, still be in your sitemap, and still be indexed. What it has lost is the ordinary route by which both people and crawlers arrive, which is a link from somewhere else on the site.

This matters because of how discovery works. Google states that it uses links as a signal when determining the relevancy of pages and to find new pages to crawl. A page with no internal links is missing from that system entirely, so whatever it might be worth, it is competing without the support every other page on your site gets by default.

Orphans are a large blog problem specifically. At forty posts you would notice. Past a few hundred, they accumulate quietly, usually from campaign pages, old category experiments, posts published outside the normal workflow, and anything created during a migration. This walkthrough finds them and decides what to do with each.

How do you build the list of pages that should exist?

Start from your CMS rather than a crawler. Export every published item, because that list is authoritative about what exists. A crawler can only find what is reachable, which means by definition it cannot find your orphans, and starting with a crawl is the most common way this audit fails before it begins.

Then pull your sitemap as a second list. In most setups the sitemap is generated from the CMS, so it should match, and when it does not match that discrepancy is itself a finding worth chasing. Pages missing from the sitemap are often excluded deliberately by a setting nobody remembers changing.

Add a third list from Search Console covering pages that have received impressions. This is the one that finds pages your CMS export missed, typically anything created outside the normal collection, and it also tells you which orphans are already earning something despite the handicap. Those are the ones to fix first.

How do you find which of those pages nothing links to?

Crawl the site, extract every internal link target, and subtract that set from your CMS list. What remains is your orphan candidate list. This is a straightforward set operation and it is the entire mechanical core of the audit, which is why it is worth doing in a script rather than by hand.

Crawl from the homepage and follow only internal links, exactly as a crawler would. Do not seed the crawl with your sitemap, because seeding defeats the purpose. You are trying to discover what is reachable by navigation, and adding the full URL list as starting points makes everything reachable by definition.

Expect the first result to be wrong in a specific way. Your crawl will report far more orphans than you have, because paginated archives, filtered views, and search pages hide a lot of legitimate links behind interactions a simple crawler does not perform. Check a handful by hand before you trust the number, and adjust the crawl to follow pagination properly.

Why might a link exist and still not count?

Because of how it is built. Google is explicit that generally it can only crawl a link if it is an anchor element with an href attribute, and that most links in other formats will not be parsed by its crawlers. Something that behaves like a link in a browser is not necessarily a link to a crawler.

Google lists the specific patterns it does not recommend, including an anchor element carrying a framework specific routing attribute rather than href, a span element with an href on it, and an anchor whose destination lives only in an onclick handler. It also flags href values that contain JavaScript expressions rather than an address. Each of these can look and behave correctly to a visitor.

The good news is that dynamic insertion is fine. Google states that links are also crawlable when you use JavaScript to insert them into a page dynamically, as long as the markup is a proper anchor element with an href. So the question is never whether JavaScript was involved, it is whether what ends up in the page is a real link.

What does anchor text have to do with this?

A link with no visible text passes almost no information about the destination. Google describes anchor text as the visible text of a link that tells people and Google something about the page being linked to, and explicitly labels an anchor element containing only whitespace as bad, empty link text.

There are documented fallbacks and they are worth knowing rather than relying on. Google says that as a fallback it can use the title attribute as anchor text if the anchor element is for some reason empty, and that for images used as links it uses the alt attribute of the image element as anchor text.

That second one matters on blogs specifically. Related post modules are very often an image wrapped in a link with no text at all. Those links count for discovery, so they do solve the orphan problem, but if the image has no alt text they carry nothing about what is on the other end. Fixing alt text on those modules is a quiet improvement most sites have available.

What does Search Console tell you and what does it not?

It tells you what is indexed and why some things are not, with real limits on completeness. Google notes that the Page indexing report's list of example URLs is limited to 1,000 items and is not guaranteed to show all URLs in a given status, even when there are fewer than 1,000. It is a sample, not a register.

Google also directs you elsewhere for single pages. The documentation states that the Page indexing report is not used to investigate the index status of specific pages and that you should use the URL Inspection tool for that. So the report shapes your understanding of patterns, and inspection answers questions about individual URLs.

One more caution from the same documentation, aimed at exactly the audience most likely to run this audit. Google says that if your site has fewer than 500 pages you probably do not need this report, and suggests site searches instead. If you are under that threshold, this whole audit is likely simpler than the tooling suggests, and you can do most of it by reading your own archive.

How do you decide what to do with each orphan?

Sort them into three piles. Pages that should be linked, pages that should be merged into something better, and pages that should stop existing. Most teams only consider the first pile, which is how an orphan audit turns into an exercise in linking to content nobody should be reading.

Link it when the page is genuinely useful and simply lost. Merge it when it overlaps something stronger, in which case the content moves and the old URL redirects. Retire it when it covers something you no longer do or believe, and be willing to do this, because a blog that only ever grows accumulates material that works against you.

Google is reassuring about the third pile. Its documentation says it is fine for a URL not to be indexed for the right reasons, naming an expected robots.txt rule, a noindex tag, a duplicate URL, or a 404 for a page you have removed and have no replacement for. Not every page needs to be saved.

Where should the new links actually go?

Into the body text of closely related posts, not into a related posts widget. A link inside a sentence carries context about why the reader should follow it, and it sits inside the content rather than in a module that readers and systems both learn to skip.

Find the targets by searching your own archive for the orphan's main topic, then read the two or three best matches and place a link where it genuinely helps. This is slower than automating it and it is the difference between a link that does something and a link that exists. There is a systematic version of this in building an internal linking system on Webflow CMS.

One link is usually enough to solve the discovery problem. Two or three is better for the page's prospects. Twelve forced mentions across unrelated posts is worse than one, because you have damaged several good pages to help one weak one. If an orphan cannot attract even one natural link from your own archive, that is information about whether it belongs in pile one.

How do you stop orphans from coming back?

Make linking part of publishing rather than a periodic cleanup. The rule I use is that no post ships without at least one inbound link from an existing post, added at publication. That single habit prevents almost every orphan that would otherwise be created going forward.

Then re-run the audit on a schedule, quarterly is plenty, because the exceptions will still slip through. Campaign pages, anything built by someone outside the usual workflow, and anything created during a platform change are the reliable sources. Knowing that lets you check those categories specifically rather than crawling everything in a panic.

On a large blog it is also worth checking that your on-site search and archive navigation genuinely surface old content, since those are what readers use when your linking misses something. I wrote about tuning that in tuning native search on a large Webflow blog.

What should you do next?

Export your CMS list and crawl your site from the homepage this week, then subtract one from the other. Even a rough version of that comparison will surface pages you had forgotten existed, and the first run is always the one that finds the most.

Check five of the resulting orphans by hand before you act on any of them, to calibrate how much your crawl is missing. Then sort the confirmed list into link, merge, and retire rather than defaulting everything into link.

If several of the orphans turn out to be worth keeping but out of date, that is a refresh queue rather than a linking job, and I covered how I run that in building a content refresh workflow for old posts. If your archive has grown past the point where you can hold it in your head and you want help getting a map of it, reach out and let's chat.