Guide

Orphan pages in SEO: what they are and how to fix them

What an orphan page is, how sitemap.digital finds one from real crawl data, and the fastest way to fix it before your next scan.

By Sunny Patel · Updated 2026-07-15

An orphan page has no internal link pointing to it anywhere on your site. It can still exist. It can still return a normal 200 response. It can even sit inside an old sitemap.xml file. Nothing crawling your site the normal way will ever land on it. Normal crawling means following links from page to page. sitemap.digital flags this as the orphan issue. An orphan page has zero inbound links from any other page found during the crawl. The crawl root is the one exception. It never counts as its own orphan. The problem is structural. It is not a ranking penalty by itself. A page can pass every on-page check and still sit unreachable the moment its last remaining link disappears.

Why orphan pages happen

Orphans usually appear after a redesign drops a navigation section. A content migration that forgets to relink old articles produces the same result. A template change can quietly remove a related posts block. That block was sometimes the only internal link a whole category of pages depended on. Removing it orphans every page in that category at once. Deliberately unlinking a temporary page creates the same problem. A campaign landing page is a common example. The page becomes an orphan once nobody deletes or retires it properly. Large sites add a fifth cause. Pagination and filter logic often link only to the first page or two of a series. Everything past that point becomes reachable only through a sitemap entry. A locale or language variant of a page can become orphaned too. The hreflang set can point to it while no visible navigation does. AI crawlers generally ignore hreflang and rely on real anchors instead. Every cause produces the same outcome. The page floats outside the site's link graph. It stays discoverable only by direct URL, an old bookmark, or a stale backlink. A search engine that indexed the page in the past may still serve it for a while.

Why AI crawlers never reach them

Search engines like Google can sometimes find an orphan page through an old link elsewhere on the web. A submitted sitemap can also surface it. AI crawlers such as GPTBot, ClaudeBot, and PerplexityBot work differently. They crawl by following links from a starting point. A visitor clicking through your site works the same way. An AI crawler following your link graph never arrives at a page with no path leading to it. That page might hold the best content on the whole site. It still will not get read. It will not get cited in an answer either. Crawl budget makes the gap worse. An AI crawler samples a limited slice of any one domain per visit. It spends that budget on the pages your own navigation points to. A page with zero internal signal pointing at it never enters that sample. Strong content and strong external backlinks do not change that outcome.

Google Search Central's guidance on crawlable link formats confirms the mechanism. Search engines only follow a real <a href> element with an href attribute. The same rule applies with even more force once no link exists at all.

Find your orphan pages step by step

You do not need to guess which pages lost their links. A crawl-based tool builds the actual graph and shows you directly. Follow these steps inside sitemap.digital.

1. Paste your homepage or a section root into sitemap.digital and run a scan. The crawler follows every <a href> it finds and records who links to whom.
2. Open the finished scan and check the Scorecard. The orphan count sits alongside broken links and average click depth as a headline structure stat.
3. Switch the list view to sort by inbound links. Every page sitting at zero is either a genuine orphan or a page you left unlinked on purpose. Check each one by hand either way.
4. Open the interactive tree view and turn on the links overlay. Orphan pages carry a distinct badge. The badge sits on the same graph. You can see exactly which section of the site lost the connection. That location matters more than the raw count once a site runs past a few hundred pages.
5. Cross-check each flagged URL against its own traffic history before you act. A page with real search visits or an existing backlink is worth relinking straight away. A page with neither is a candidate for retirement instead.
6. Click into any flagged page's detail drawer to confirm its inbound and outbound counts. Decide which fix applies from the table below. Rescan once the fix is live to confirm the orphan flag cleared.

Orphan vs noindex vs 301: choosing the right fix

Not every orphan page should simply get a link back. Some should never have been crawlable in the first place. A few are better retired outright. Match the page to the scenario below before you touch anything.

Screaming Frog's guide to finding orphan pages recommends this same match-and-fix approach before any bulk changes. Confirm the fix worked with a fresh crawl rather than assuming it did.

Worked example: turning an orphan into a linked page

The example below is simplified to show the mechanics. It is not a real aggregate result pulled from live scans.

Say a site publishes /guides/backup-strategy as part of a content push. A redesign of the resources hub happens two months later. The new hub template only links to the five newest guides. The backup strategy page quietly drops out of every internal link path. A scan run after the redesign flags it. inDegree sits at zero. The orphan badge shows in the tree view. The page still returns 200. It still holds a handful of external backlinks from its original launch. Traffic to the page has already started sliding month over month. That slide is the usual first symptom before an orphan disappears from the index entirely.

The fix is one link. The site adds a reference to the guide from a related disaster-recovery article already sitting at click depth two. It also adds a line in the resources hub's category footer. A rescan afterwards shows the change directly. inDegree moves from zero to two. The orphan flag clears. Click depth for the page settles at three. The content, the URL, and the external backlinks stay identical throughout. The only variable was whether the site's own link graph acknowledged the page existed.

How to fix an orphan page

Add one real link to the page from content already reachable in your site structure. A relevant blog post works. A listing page works. A footer section works. A related guides block like the one at the bottom of this page works too. Redirect the page instead if it should not exist as a standalone URL any more. Follow the 301 row in the table above for that case. Do not leave a valuable page with no links and no purpose. Give every page you care about at least one path in from the rest of the site. Confirmation matters as much as the fix. Rescan once the link is live to confirm the orphan flag cleared.

Choose the linking page with care. A link buried inside a rarely visited page barely helps. Pick a page that already sits at a shallow click depth and already receives a healthy share of internal links itself. That page passes real crawl priority down to the orphan instead of just technically satisfying the inDegree count. Batch several orphan fixes into one release where you can. A single rescan then confirms every fix at once instead of spreading verification across separate small deploys.

Ahrefs' guide to orphan pages notes that they accumulate naturally as sites grow through redesigns, migrations, and abandoned campaigns. That pattern shows up on sites of every size.

sitemap.digital's own scan history is still small. Most of it comes from self-testing during early development. We are not publishing a hard percentage of affected sites until a much larger sample can back one honestly. What we do publish precisely is the rule this tool applies. We also show you your own site's real graph. That is the part that actually fixes the problem.

Frequently asked questions