You export a list of every published URL from your CMS, then crawl the site with a tool that follows links from page to page. The two lists disagree. The crawler reaches 1,840 pages. The CMS reports 2,190. Somewhere in that gap of roughly 350 URLs sit pages that load fine, return a 200, and have nothing on the rest of the site pointing to them. Those are orphan pages, and the reason a normal crawl missed them is the same reason they can quietly cost you traffic.
What an orphan page actually is #
An orphan page is a live URL that no other page on the same site links to. Nothing internal points in. A visitor can still land on it from a search result, an ad, or a link someone posted elsewhere, but they cannot reach it by clicking around your own site.
Here is the part that trips people up. You cannot find orphan pages by crawling your site, because a crawler works the way a search engine bot does: it starts on a page, follows the links it finds, follows the links on those pages, and keeps going. A page with zero inbound internal links is a page the crawler has no path to. The tool reports every URL it can reach and stays silent about the ones it cannot, which are the exact ones you went looking for. The method that maps your whole site is blind to the pages most cut off from it.
Why sites grow orphans in the first place #
Orphans are rarely created on purpose. They accumulate, one small change at a time. A few of the usual sources:
- A redesign or migration drops pages out of the navigation while the old URLs stay live.
- A category or tag page is removed from the menu, but the individual posts under it remain published.
- A CMS or plugin auto-generates URLs (author archives, date archives, paginated feeds, faceted filter combinations) that nothing links to on purpose.
- Old campaign and seasonal landing pages outlive the emails and ads that used to point at them.
- A product is pulled from a collection page, but its URL is never redirected or removed.
The common thread is time. Sites change faster than anyone updates the links between their pages, and each change can strand a URL that used to be connected. On a small brochure site this rarely amounts to more than a handful. On a large ecommerce catalog or a publisher with years of archives and faceted navigation, the stranded URLs can run into the thousands.
Do orphan pages actually hurt you? #
This is where honesty matters more than alarm. There is no documented “orphan page penalty.” Google does not hand out a demerit because a page has no internal links. What happens is quieter, and it works through signals rather than punishment.
Internal links do two jobs. They help search engines discover a page, and they pass context to it: the anchor text describes what the page covers, and the surrounding content and link equity tell Google how the page fits into the rest of the site. An orphan gets neither. If the URL sits in your XML sitemap or carries an external backlink, Google can generally still find and index it, so discovery is often survivable. What the page loses is the relevance and priority its connected neighbors receive, which tends to leave it ranking weaker than its content deserves.
Discovery through a sitemap alone is also thinner than it looks. A sitemap is a suggestion, not a guarantee of crawling, and a page whose only path to Google is one line in an XML file has no backup. If a sitemap regeneration bug drops that line, the page can slip out of the index with nothing else pointing to it.
And some orphans are perfectly fine. A page you deliberately keep out of your link graph, a pay-per-click landing page tuned for one ad, a checkout confirmation, a gated download, is orphaned by design. The goal is not zero orphans. The goal is to know which ones are accidents and which ones are choices.
How to find them: cross-reference, do not just crawl #
Since a crawl alone cannot reach orphans, the technique is to build two lists and compare them. The first list is every URL that is internally linked, which a standard site crawl gives you. The second list is every URL known to exist through some source that does not depend on internal links at all. The URLs in the second list but missing from the first are your orphan candidates.
The sources that surface URLs a crawler cannot reach:
- Your XML sitemap. Pages listed here but never reached in the crawl are strong suspects.
- Google Search Console. The Pages report and the Performance report show URLs that earned impressions or clicks, which is proof the page exists and gets seen whether or not you link to it.
- Analytics. Any URL that recorded a pageview is a URL that exists, linked or not.
- Server log files. These show every URL Googlebot actually requested, including ones it reached through old links or its own memory of the site.
- Backlink tools. A page can be cut off internally while still holding links from other websites, and those are the orphans most worth rescuing.
A worked version looks like this. Your sitemap lists 2,190 URLs. The link-following crawl reaches 1,840. Search Console shows 2,050 URLs with impressions in the last three months. Line the three sources up, and the URLs that appear in the sitemap or Search Console but never in the crawl are the gap you care about. In practice, tools such as Screaming Frog and Sitebulb automate the comparison: connect the Search Console, Analytics, and XML sitemap feeds to the crawl, and the tool flags URLs it found in those feeds but never encountered by following a link. Screaming Frog reports them under Orphan URLs. Treat that output as candidates, not a verdict, because a sitemap can list a redirected or dead URL and a backlink report can surface a page you retired on purpose.
Deciding what to do with each one #
Once you have a real list, the work is not one problem with one fix. Each URL falls into a bucket, and the right move depends on which bucket. A short map:
| The orphan is… | What to do |
|---|---|
| A useful page that should rank | Add contextual internal links from relevant pages, and return it to the navigation or a hub page if it belongs there. |
| Outdated or thin, with nothing worth keeping | Redirect it with a 301 to the closest relevant page, or remove it and return a 410 if there is no good target. |
| A near-duplicate of a stronger page | Consolidate: point a canonical or a 301 at the version you want to keep. |
| Orphaned on purpose (PPC, thank-you, gated) | Leave it, and consider noindex if it should stay out of search entirely. |
| Cut off internally but holding external backlinks | Reconnect it first, because link equity is arriving with nowhere on your site to flow. |
The most valuable case is that last row. A page with real backlinks and no internal links is earning authority that has nowhere to go, and one well-placed contextual link from a relevant page can put that authority back to work across your site. The cheapest win in the whole exercise is usually a reconnection, not a rewrite.
Turning it into a habit #
This is never a one-time cleanup. Stranded URLs return after the next redesign, the next plugin, the next round of pruning. The realistic discipline is to run the cross-reference check on a schedule, quarterly for most sites and again after any migration or large content change, and to reconnect or redirect a URL the moment you strand it rather than rediscovering it a year later in a sitemap you barely remember exporting. Finding orphans is a mechanical exercise. Deciding which ones deserve a way back is the judgment that earns the traffic.