How to Find and Fix Orphan Pages

Published Read 6 min read

On this page

An orphan page is a page no internal link points to. Google can only reach it through your sitemap, which it treats as a weak discovery hint rather than a directive, so the page tends to land in “Discovered – currently not indexed” with zero internal PageRank flowing to it. Finding orphans is not something a single report hands you; it requires comparing a link-following crawl of your site against your full list of URLs from the sitemap, CMS, or logs, and treating anything in the list that the crawl never reached as orphaned. Fixing them means rebuilding real crawl paths (related-content modules, breadcrumbs, HTML hub pages, subcategories) for the pages that deserve to be found, while leaving alone the pages that are orphaned on purpose.

This is the discovery-gap case: valuable pages with no inbound internal links. It is the inverse of partial indexing as a value decision, where Google found the page, evaluated it, and chose not to index it on the merits. Here Google may never have had a path to the page at all. It is also the opposite of a crawl trap, where the site generates too many paths; an orphan has too few. And it is distinct from the per-page indexing diagnostic and from a full at-scale internal-linking audit. The defining condition is simply: the page has zero inbound internal links.

Google discovers pages primarily by following links. A page with zero internal links has no link path from anywhere on your site, which means the only way Google learns it exists is the sitemap. A sitemap is a hint that says “these URLs exist,” not a directive that says “crawl and index these,” and Google prioritizes it accordingly: low. Worse, a page nothing links to carries a quiet signal of its own. If not even the site’s owner linked to it from anywhere, why should Google treat it as important? That is exactly why orphans cluster in “Discovered – currently not indexed,” and why, even when an orphan does eventually get indexed, it receives essentially no internal PageRank and struggles to rank for anything competitive.

Detection is a comparison, not a lookup

No single tool simply lists your orphans, because finding one requires two datasets and a diff.

Start by crawling from the homepage with a crawler like Screaming Frog or Sitebulb. That crawl follows links and produces the set of URLs reachable through your internal linking. Then bring in a second list of URLs that should exist: your XML sitemap, a CMS export, and ideally your server logs. Diff the two. URLs that appear in the second list but were never reached by the link-following crawl are orphans. Most crawlers will do this directly: feed in the sitemap as an additional source and filter for URLs with zero inlinks, and the orphan set falls out.

Log files are the most accurate source of all, because they show which URLs Googlebot actually requested over time. A URL Googlebot has never requested, that also has no internal link path, is as orphaned as it gets. Where you have log access, use it to confirm.

The e-commerce archetype

Orphans concentrate predictably on large catalogs, in two distinct flavors. The first is depth-by-pagination: products buried so deep behind page after page of category pagination that they sit tens of clicks from the homepage. These are near-orphans by click-depth; technically reachable, practically ignored, because crawl priority falls off sharply with depth. The second is the true orphan, where a catalog or query bug drops products out of pagination entirely, so no path reaches them at all.

A platform migration is the single most common cause, and it is worth flagging because it’s silent. When templates, URL structures, or query logic shift during a re-platform, internal links that used to render simply stop rendering, and pages that were well-linked the day before become orphans overnight with no error to alert you. After any migration, the crawl-versus-list diff should be a standard check.

The JavaScript-filter trap

A common reason a “fix” doesn’t de-orphan anything: faceted navigation or filters that only change client-side state, or that use hash-fragment (#) URLs, create no crawlable paths. Google does not treat a hash fragment as a separate URL and does not get a real link to follow when state changes only in the browser. So if your related-products or category filtering is built that way, it looks like internal linking to a human but provides zero crawl paths to Googlebot. Only real, server-rendered URLs with actual href links de-orphan a page.

Prioritize before you fix

Not every orphan is a problem, so triage before you act. Fix the high-value orphans first: live products that should be selling, service pages, key content that should rank. Leave the intentional orphans alone; PPC landing pages and thank-you pages are deliberately kept out of the internal link graph, and that is correct. And for pages that are orphaned because they’re genuinely dead (no demand, no value), the answer is noindex or removal, not a new link. Spending effort linking a page that shouldn’t be indexed anyway is wasted work.

Fixes that don’t require a re-platform

Most orphan fixes are ordinary internal-linking work, not infrastructure projects. Populate related-products or related-posts modules so every page earns contextual inbound links from its neighbors. Add breadcrumb links so category and parent pages link down to children. Build crawlable HTML hub or category pages that link out to the orphaned set. Split oversized categories into subcategories so products sit at a reasonable click-depth instead of page twenty-eight of one giant listing.

On a large catalog, the highest-return quick win is almost always auto-populating related-products for the zero-inlink set. It removes the “no path” status programmatically across thousands of pages at once, which is the status that makes Google ignore a page outright. Note the boundary: removing the orphan status gets the page found and crawlable; whether it then clears the value bar and stays indexed is a separate question about the page’s own quality. De-orphaning is necessary, not sufficient.

Measure the fix by watching the numbers fall: “Discovered – currently not indexed” should shrink, and your count of pages with fewer than two internal links should drop on each subsequent crawl. A sitemap alone never fixes this; a page can be in the sitemap, submitted, and still invisible because nothing links to it. The link path is the fix.

Frequently Asked Questions

If a page is in my sitemap, isn’t it discoverable?

Discoverable, but not prioritized. A sitemap tells Google a URL exists; it is a hint, not a directive, and Google treats sitemap-only URLs as low priority. A page that lives only in the sitemap, with no internal link pointing to it, also carries the implicit signal that even the site owner didn’t think it worth linking. That’s why orphans cluster in “Discovered – currently not indexed” despite being submitted. The sitemap gets the URL known; an internal link path is what makes it matter.

Will adding the orphaned page to my navigation fix it?

It removes the orphan status, which is the immediate goal, but a single sitewide nav link is a weak signal. Contextual links from relevant pages (related-products modules, in-body editorial links, breadcrumbs) carry more weight than a boilerplate footer or menu link that appears on every page. For a large set of orphans, auto-populated related-content modules are usually the better fix than stuffing everything into the global navigation.

How is an orphan page different from a page Google chose not to index?

An orphan has no internal link path, so Google may barely reach it at all; the problem is discovery. A page Google “Crawled – currently not indexed” was found and evaluated, then declined on the merits; the problem is value. De-orphaning solves the first. It does not guarantee the second: once the page is reachable, it still has to clear the quality bar to stay indexed.

Sources

Related posts:

  1. Hiring SEO Talent: Interview Questions and Skill Assessment Methods SEO hiring is hard for a specific structural reason: the field has no reliable credential, and organic results are influenced by so many factors that a candidate can sincerely claim......
  2. How to Do SEO for Browser Extensions Browser-extension SEO is two channels, and most developers work only one. Store optimization (Chrome Web Store, Firefox Add-ons, Edge Add-ons) gets you found by people already browsing the store for......
  3. How to Build an SEO Moat Competitors Can’t Easily Copy Content is never a moat, because content is copyable. A rival with a budget can hire writers, study your top pages, and publish equal-or-better versions of anything you have written,......
  4. How to Do SEO for Comparison Pages (X vs Y) A comparison page earns its ranking by being credibly even-handed and factually defensible, not by declaring that you win everything. Readers and Google both discount a transparently self-serving "X vs......
  5. How to Do SEO for a Two-Sided Platform A two-sided platform needs two separate keyword strategies, one for supply and one for demand, and the SEO budget should concentrate on the constrained side: whichever side is harder to......
  6. How to Do SEO During a Website Redesign A redesign destroys organic traffic through a small set of preventable mistakes: changing URLs without one-to-one redirects, shipping a staging noindex to production, removing pages that hold backlinks, and bulk-redirecting......
  7. Your Pricing Page Is Invisible to Search Your pricing page ranks behind review aggregators for your own "your product pricing" query because that query carries three different intents and your page answers only one. Someone searching it......
  8. Why Your Staging Site Is Ranking Instead of Production Staging out-ranking production is a canonical signal inversion, not a simple case of an exposed test server, and treating it as the latter is why the usual fixes fail. Production,......
  9. How to Do SEO for Directory Websites A directory ranks only when its aggregation visibly adds something Google cannot get from its own index. Google already knows the local businesses in a category; if your listing pages......
  10. How to Build a Multilingual SEO Strategy The strategic decisions come before any hreflang tag, and getting them right is most of the work. Multilingual SEO is a sequence of investment choices: which languages to build for,......
  11. What Are Featured Snippets and How to Optimize for Them A featured snippet is an answer Google extracts from a top-ranking page and displays in a highlighted box above the regular results, the spot practitioners call "position zero." It is......
  12. How to Recover from a Google Manual Action Penalty A manual action is a human reviewer enforcing a named violation against your site, and recovery turns on two things this post treats in depth: knowing which violation type you......
  13. How to Do SEO for Programmatic Pages at Scale The line between legitimate programmatic SEO and doorway spam is one question: does each generated page carry genuinely unique data value, or is it a template with swapped variables? A......
  14. Edge SEO: Implementing Changes at the CDN Layer Edge SEO ships header, redirect, hreflang, schema, and meta changes in hours by running serverless workers at the CDN layer, instead of waiting weeks for an engineering backlog to clear.......
  15. Your CDN’s Edge Caching Is Breaking Hreflang for International Visitors When geo-IP detection or geo-redirects run at your origin behind a location-unaware CDN, two failures stack. The edge caches one country's response (or one geo-redirect outcome) under the URL alone......