Finding Orphan Pages: What Nothing Links To Internally

What makes a page an orphan

Orphaned does not mean broken. The page responds, the content is complete, the layout is fine. The defect does not sit in the page but in the website's link graph: there is no path leading from the home page to this address through clickable links. That is exactly why the condition goes unnoticed in a normal visual check - anyone who knows the address and opens it sees a page in good order. Only tracing the graph from the outside reveals the gap.

In practice you meet three degrees of it. A page is fully orphaned when none of your own content links to it in the delivered HTML. It is effectively orphaned when its only incoming link comes from a page that is itself not indexable or is not reached either - the feeder then hangs on the same island. And it is practically orphaned when its only access route runs through a form, a parameter or a script action that fires only after a click: a crawler reading nothing but the delivered markup will not arrive there.

The distinction is not hair-splitting, it decides the remedy. A fully orphaned page needs a link from the overview that fits its topic. An effectively orphaned page needs its feeder repaired first, otherwise you merely move the problem up one level. And a practically orphaned page usually needs no link at all but a decision: should this state have an address of its own in the first place?

How an address gets discovered at all

Search engines work through discovery in stages, and not every address survives every stage (Google Search Central). At the beginning stands the question of how an address becomes known. The regular route is the link: a crawler follows addresses it has found on pages it already fetched - if no such link exists, the page may go undiscovered (Google Search Central). An overview page pointing at a new article is therefore not a convenience but the transport route.

The second route is the XML sitemap. It announces addresses without any context - no anchor text, no position in the document, no surroundings. That makes it a hint rather than an assurance: it helps with discovery but does not assure that all entries it contains will be crawled and indexed (Google Search Central). On large websites in particular it is harder to make sure every page is linked from at least one other page, which is why new pages are more likely to be overlooked there (Google Search Central). The sitemap cushions that case but does not replace the linking.

The sitemap itself has hard limits too. Each file may hold at most 50,000 addresses and 50 MB; larger inventories have to be split across an index file (sitemaps.org). Exceeding that limit or shipping a broken index file loses you precisely the fallback route you were counting on. How to keep the sitemap under continuous review is covered in the article on sitemap monitoring.

How orphan pages typically come about

Orphan pages are rarely a single mistake. They are the residue of ordinary work on a website: something gets rebuilt, the content stays behind, and nobody checks the graph afterwards. These patterns show up most often in practice.

1. Menu rebuild without follow-up. An item drops out of the navigation while the pages behind it stay online. If the navigation was the only feeder, they are orphaned from that deploy onwards.
2. Campaign pages from outside channels. Landing pages that only appeared in ads, in a newsletter or on a trade fair handout show up nowhere in your own inventory.
3. Pagination switched off. Archive and category pages from page three onwards disappear as soon as a rebuild replaces the pager with an infinite-scroll loader.
4. Filter and facet pages. Addresses that arise only from form parameters do not exist as a link in the markup - and are indexable all the same.
5. Relaunch without carrying the link structure across. The content moves, the cross-references from the body copy do not. That is the largest single item in almost every migration.
6. Links inserted only by a script. Whatever loads after a click or on scroll is not in the delivered HTML and does not count towards discovery.
7. Downloads and fact sheets. PDF overview pages that were only reached from an email sit there without a feeder once the mailing is done.
8. Language versions without a switcher throughout. If the language switch sits only on the home page, half the translation cannot be reached from within.

The timing is striking: most of these cases arise on one specific day, namely the deploy of a rebuild, rather than gradually. Running the comparison once a year shows you the result but not the trigger. Migrations in particular deserve a separate look at website migration monitoring, because several of these patterns occur there at the same time.

Orphan page and broken link point in opposite directions

Both findings are defects in the same graph, but they point in opposite directions. A broken link is an edge without a target: the link exists, the address behind it no longer answers. An orphan page is a target without an edge: the address answers perfectly well, only nothing points at it. The body of guidance out there deals almost exclusively with the first direction, which is understandable - it is cheaper to measure.

That is where the asymmetry lies. A broken link falls out of the crawl by itself: the crawler follows the edge and gets an error status back. The guide on monitoring broken links describes that route in detail. An orphan page precisely does not fall out of the crawl, because the crawler does not pass by there at all. It only becomes visible when the crawl is set against a second, independently produced list. A crawl on its own fundamentally cannot answer this question.

On top of that comes the special case of pages that respond but are empty in substance while still reporting status 200. They appear in the crawl as valid nodes and obscure the view of the actual structure; how to detect that is covered in the article on wrong status codes. For the comparison this means: sort the status codes first, then compare the sets.

A third point concerns the quality of the edges you do have. On inner pages, 92.42 percent of desktop sites carry descriptive link text, on home pages the figure is 84.64 percent (Web Almanac). A link with a vague anchor text still counts towards discovery but contributes little to classification. When tidying up an orphan page, both steps are worth it: set the edge and give it a text that names the target.

Four lists and their differences

Searching for orphan pages is at heart a set-theory exercise. You need at least two lists, preferably four, and the finding does not sit in any one list but in the difference between them. Each of the four sources knows addresses the others do not - and that surplus is exactly the yield.

The first difference matters most: everything that is in the sitemap and missing from the crawl. Because the sitemap is usually generated straight from the content management system's database, it knows the target state; the crawl knows the actual state. Watch the format limits while doing this - beyond 50,000 addresses per file the inventory is split up (sitemaps.org), and reading only the first file manufactures a difference of your own making.

The second difference comes from the server log and is the most honest one: whatever was fetched exists. Addresses that turn up there and are missing from the crawl are either orphaned or targeted from outside. The third difference comes from pageview data and is commercially the most interesting, because it shows which orphan pages have an audience regardless. How to evaluate transitions between pages for this is described in the article on user paths and page transitions - orphan pages stand out there by appearing as entry points while showing up in no path as an intermediate step.

A fourth and often overlooked source is your own site search. Search terms without results, and searches that end in a page view, show which content people expect and cannot find through the navigation. The article on evaluating internal site search covers the analysis; for our topic the second case is the more revealing one, because it flags orphan pages with real demand. How broadly an inventory is monitored overall is covered in the article on monitoring coverage of the URL inventory.

Setting up the crawl so it measures the truth

The crawl supplies the reference quantity for everything else. Set too narrowly it reports orphan pages that are none; set too widely the finding disappears into the noise. These points decide how much the result can carry.

• Only delivered markup counts. An edge is a link present in the HTML the server outputs. Anything a user action inserts has no effect on discovery (Google Search Central).
• Resolve redirects, do not count them. A chain of several hops produces intermediate nodes that are not real pages; the article on redirect chains shows why they belong apart.
• Separate noindex cleanly. The directive is found on 3.5 percent of desktop sites and 2.4 percent of mobile ones (Web Almanac). Such a page may pass edges on but does not work as the sole feeder - the target then effectively hangs on an island.
• Read meta robots on both routes. Meta robots directives occur on 47.0 percent of desktop sites and 47.9 percent of mobile ones (Web Almanac); evaluating only the meta element and not the HTTP header misses a share of them.
• Record the canonical. 68 percent of desktop pages carry a canonical element, on mobile it is 67 percent (Web Almanac). If it points elsewhere, the address is not a target in its own right and does not belong on the candidate list.
• Check the document head. On 10.1 percent of desktop sites and 10.3 percent of mobile ones there are invalid elements in the head section (Web Almanac) - which can truncate subsequent directives and distort your crawl result.
• Sort status codes beforehand. On 13.3 percent of desktop sites and 13.2 percent of mobile ones at least one checked resource answers with 404 (Web Almanac); such addresses do not belong in the set comparison.
• Take the exclusion file seriously. Parsing at least 500 kibibytes of robots.txt is required (IETF); anything beyond that a client may ignore. An overlong file can therefore contain rules that remain effectively without consequence.

A pitfall of its own is the accidental block. If a deploy puts a noindex directive on pages that should not have one, those pages drop out of the index and later look like orphan pages even though the graph is sound. The article on the noindex leak after a deploy describes the sequence; for the comparison this means indexability belongs in the report as a column of its own, not in the filter.

From finding to decision

An orphan page you have found is not yet a task. The most common mistake after the first comparison is to link every address from the list somewhere - the result is a footer with thirty links that helps nobody and blurs the structure of the website. Three outcomes make sense, and the finding itself supplies the basis for deciding: views, age, topic and status code.

Scale determines the order. The guidance on crawl budget is aimed explicitly at large sites with more than a million addresses and moderately frequent changes, as well as at medium or larger sites from 10,000 addresses upwards with very rapidly changing content (Google Search Central). Below those orders of magnitude, the argument against orphan pages is not crawl budget but plain findability for people. And even above them it holds that not every crawled page will necessarily be indexed (Google Search Central).

A useful intermediate step is sorting by requests from the server log. Pages with regular access and no internal feeder are the most rewarding candidates, because demand is already demonstrable there. Pages with neither access nor links, by contrast, are the actual ballast - they cost maintenance and return nothing. How to automate such checks on a permanent footing is described in the article on technical SEO monitoring.

Findability is an accessibility requirement too

The look at orphan pages is usually framed purely as an SEO question. That falls short. The Web Content Accessibility Guidelines require, in success criterion 2.4.5 at level AA, more than one way to locate a page within a set of pages - the only exception being pages that are the result of, or a step in, a process (W3C). An orphan page is not one way short, it has none.

On the legal side, the German Accessibility Strengthening Act draws the same line. Products and services count as accessible there when they are findable, reachable and usable in the customary manner, without particular difficulty and in principle without outside help (BFSG). The word findable comes before reachable and usable - an order that fits the matter: what nobody finds does not need to be reachable.

In practice this means the second route to a page should not be a makeshift. Alongside the main navigation, a maintained overview page, thematic links in the body copy and a working site search all qualify. Anyone wanting to see the requirements in context will find the classification under accessibility under the BFSG.

Keeping orphan pages in view permanently

A one-off comparison clears the old stock and is worthless afterwards, because the next rebuild produces new cases. The comparison therefore belongs in the same rhythm as the deploy: produce, compare, report. What matters is not the frequency as such but the link to the moment when changes go live.

• Produce crawl and sitemap in the same run, so the two lists reflect the same state and the difference does not consist of a time lag.
• Normalise addresses consistently: protocol, domain with and without www, trailing slash, upper and lower case, ordering of parameters.
• Filter the report down to new entries. What is interesting is what has been added since the last run - otherwise the old stock sits in every report and dulls attention.
• A threshold instead of single alerts. An alarm from a certain number of new cases per run catches the deploy outliers without firing on every editorial change.
• Check the sitemap separately, because it carries the fallback route; a quick look works with the sitemap validation tool.
• Deliver the finding to the editorial team, not only to the technical side - the decision between linking, merging and retiring is an editorial one.
• Keep the history. Only the time series shows which rebuild produced which spike; a report with a status page records that without further effort.

That turns a clean-up campaign into a control loop. The effort after the first pass is small, because only the differences to the previous week come up - typically a handful of addresses rather than a long list. Which check intervals and which scope suit an inventory is shown by the pricing overview.