Short answer
An orphan page is a page on your site with no internal links pointing to it. You can open it by typing the URL or find it listed in the sitemap, but neither a visitor moving through the site nor a crawler following links will ever get there.
The danger is not a penalty — there is none. The danger is that such a page receives no internal link equity, gets crawled rarely, and any change you make on it is noticed weeks late. And you cannot find orphans with a crawler alone: you have to diff the link crawl against URL lists from your sitemap, Search Console, server logs and analytics.
How an orphan differs from other problem pages
These terms get mixed up constantly, and the fixes are not the same.
| Page type | What is wrong | Status code |
|---|---|---|
| Orphan page | No inbound internal links at all | 200 |
| Broken page | Does not exist, links point nowhere | 404 / 410 |
| Deep page | Links exist, but it sits 5+ clicks from home | 200 |
| De-indexed page | Links exist, but noindex or a canonical removes it | 200 |
| Dead-end page | Pages link to it, but it links to nothing | 200 |
The practical difference: a broken page shows up in every error report, while an orphan looks perfectly healthy. It returns 200, it has a decent title, it may even bring traffic — just a fraction of what it could. That is exactly why orphans survive on sites for years.
It is also worth separating a true orphan from a page with a single footer link. Technically the latter is not an orphan, but in terms of the equity it receives the difference is small — I covered that in detail in the article on internal linking for SEO.
Why orphan pages are a problem
Three effects, of very different sizes.
The page gets almost no internal equity. Equity arrives through external links and spreads through internal ones. A page with no inbound links sits outside that flow: all it has is whatever it earns directly from outside, and a typical service page or product card has no external links at all.
The crawler rarely visits. Googlebot walks the site through links and treats the sitemap as a list of candidates. In my experience, pages without inbound links are re-crawled noticeably less often: Google notices edits after weeks rather than days. On a small site that is tolerable; on a catalogue with tens of thousands of URLs it becomes a crawl budget and technical SEO question.
Junk slips into the index unnoticed. The flip side: orphans are not only useful pages. Test copies, old landing page versions, WordPress attachment pages, tag archives — these usually exist precisely as orphans. Nobody sees them in the structure, so nobody notices they are being indexed.
There is a fourth, organisational effect that stings the most. An orphan page usually means somebody spent time building it and then it fell out of the structure. That is work you already paid for that returns nothing.
How to find orphan pages: five sources
The key point: a crawler alone will not do it. Screaming Frog, Sitebulb or my own crawler all follow links — a page with no inbound links simply does not exist for them. You need a diff across several URL lists.
- A link crawl of the site. Start at the homepage and let the crawler collect everything it can reach. This is your "connected pages" list — the baseline for comparison.
- Sitemap.xml. Load it separately and compare with the crawl. Anything in the sitemap that the crawler never reached is a direct candidate. Fastest method, but it only sees what the CMS put in the sitemap.
- The Page indexing report in Search Console. Export the URLs Google knows about. This surfaces pages neither the sitemap nor the crawler knows — old URLs that still have external links pointing at them, for instance.
- Server logs. The most complete source: every URL Googlebot actually requested. On large sites this is the only way to see the full picture, but it is also the most work.
- GA4 landing pages report. Shows URLs people actually arrived on. If a page brings traffic but the crawler never found it, that is a valuable orphan.
From there the whole job is list subtraction: URLs from sources 2–5 minus URLs from the crawl = candidates. Candidates, not a verdict — some will drop out on inspection.
What to discard immediately so you do not waste time:
- parameterised URLs (
?utm_source=,?sort=) if they are consolidated with canonicals; - pages blocked in robots.txt — the crawler skipped them for a different reason;
- pagination and filters generated by scripts, if the crawler did not execute JavaScript;
- pages whose links live in JS-rendered blocks. This one is common: the link exists in the markup, but a crawler without rendering never sees it, so the page looks like an orphan without being one.
Always check that last point before fixing anything: on sites with a heavy front end, half of the "orphans" are false positives from a crawler that did not run JavaScript.
Where orphan pages come from
| Source | What it looks like | Usual fix |
|---|---|---|
| Site migration | URLs moved, links to them never restored | Return to structure or consolidate with 301 |
| Catalogue cleanup | Category dropped from the menu, product pages stayed | Decide the fate of the product pages |
| Paid-ad landing pages | Deliberately kept out of navigation | Keep them, but remove from the index |
| CMS auto-generation | Date, tag and author archives, attachment pages | Noindex, drop from sitemap |
| Old campaign pages | Campaign ended, links removed, page remained | 410 or redirect to the current section |
| Product imports | Products loaded into the database but never assigned a category | Assign a category |
| Manual template edits | A link was removed from a block during a redesign | Put the link back |
A word on Google Ads landing pages. Keeping them out of navigation is deliberate and fine — as long as they are excluded from the index. The trouble starts when an ad landing page gets indexed and starts competing with your main service page for the same query. Then orphaning is joined by keyword cannibalization, and you are untangling two problems at once.
What to do with the orphans you find
Order matters: decide the page's fate first, add links second. The reverse order means you carefully link up pages that should not be on the site at all.
- Rank candidates by value. Does the page have impressions in Search Console, did it receive traffic, does it have external links? A page with impressions is definitely not junk.
- Answer one question: does this page have its own keyword cluster? If yes, it is needed. If it answers the same intent as another page, it is a duplicate.
- Weave the needed pages back in. A slot in the right category, contextual links from two or three relevant pieces, a menu entry if it earns one. Depth target: no more than three clicks from the homepage.
- Consolidate duplicates. A 301 to the main page if the content really is the same; a canonical if both versions must stay live.
- Remove the junk. Pages that should not be indexed get
noindexand leave the sitemap; pages that should not exist get 410. Do not setnoindexwhile keeping the URL in the sitemap — that sends Google contradictory signals. - Check whether it will happen again. If the orphans came from a template or an import, fixing them individually solves nothing; fix the source.
Step 3 is best done in batches: if 40 product pages of one category fell out of the structure, that is one change to the category template, not forty manual edits.
What I see on my own projects
I will not quote a "fixing orphans gives +N% traffic" figure — no such number exists, and any specific one here would be invented. But the patterns repeat.
Orphans almost always appear in batches, never one at a time. Find one and go looking for the rest of its batch: they usually share a source, whether a migration or an import. Fixing them individually is the worst possible use of your time.
On a typical site, more than half of the orphans you find turn out to be junk. Tag archives, attachment pages, test copies. That is not a disappointment but a normal outcome: cleaning them out of the index is worth more than linking up a couple of forgotten posts.
The valuable orphans are usually hiding in old content. An article that was in the blog three redesigns ago still collects impressions — nobody links to it any more. Those pages give the fastest payoff from being reconnected, because they already have history in the index.
On limits. For a 20-page site this whole method is overkill: reading the sitemap with your eyes is enough. It starts paying off at around a hundred URLs and becomes a mandatory recurring routine on catalogues in the tens of thousands. And one more thing: reconnecting an orphan will not make it relevant if it never matched the intent. If the site structure was not built around real demand, that is where you start instead.
The most honest orphan test: try reaching the page from the homepage using links only. If you cannot do it in five minutes, neither can Google.
Checklist: clear your orphans in one pass
- Crawl the site from the homepage, with JavaScript rendering if your front end needs it.
- Export sitemap.xml and compare it with the crawled URLs.
- Export the Page indexing report from Search Console and add it to the comparison.
- Pull landing pages from GA4 for the last 12 months — those reveal the valuable orphans.
- Subtract everything the crawler found through links from the combined list.
- Filter out false positives: robots.txt, parameters, links inside JS blocks.
- Split what is left into needed and junk, based on whether the page owns a keyword cluster.
- Reconnect the needed ones — category, menu, contextual links.
- Kill the junk with noindex or 410 and remove it from the sitemap.
- Find the shared source of the batch and fix that, not just the symptoms.
- Repeat the check next quarter — and always after a migration or a redesign.
If it turns out orphans reappear after every catalogue update, the problem is no longer SEO but how page generation is built: that is web development, and it is solved at the template level rather than by manual linking.
