Skip to content
NessFlow
Menu

Orphan pages: zero inbound links is the wrong test

Across seven sites, 49 of the 50 orphan pages had inbound links. An inbound link count saw exactly one. Here is the definition that holds up, how to find orphans by hand, and what the fix costs.

The NessFlow team (Product engineering, NessFlow) · · 8 min read

Screenshot of the Reachable and orphan pages in the internal linking screen in NessFlow, on a demo dataset.

A real product screen, rendered on a fictional demo dataset: the figures shown belong to no client.

We audited seven sites belonging to the same Paris hotel group and found 50 orphan pages. 49 of them had inbound links. Usually three each, all followable, all working.

A tool that defines an orphan as "a page nothing links to" would have found one. On six of the seven sites, it would have reported none.

This piece explains why that test fails, what replaces it, and how to run the replacement by hand on your own site.

The data

The seven sites were crawled on 9 October 2026 with JavaScript rendering, no crawl limit reached, and the results were re-read on 8 November. Five of them are built on the same site template; the other two were built independently.

Site Pages measured Orphans Orphans with zero inbound links
A 105 12 0
B 95 8 0
C 92 8 0
D 85 8 0
E 70 8 0
F 33 2 1
G 30 4 0
Total 510 50 1

A measured page is an internal page that answered 200. An orphan is a measured page that no path of followable links connects to the home page. Both definitions matter, and the second one is the whole point.

What an orphan actually is

An inbound link count is a local property. It looks at one page and nothing else. Being an orphan is a global property. It depends on the site's entire link graph.

The question is not "does anything point to this page?". It is "starting from the home page and clicking, can you get there?".

The two questions agree as long as forgotten pages are forgotten one at a time. They part ways as soon as forgotten pages link to each other. Every one of them receives links, none of them can be reached, and the local count sees nothing wrong.

That is exactly what we found.

Islands

The 50 orphans receive 139 inbound links between them. All 139 come from other orphans. Not one starts from a reachable page.

137 of those links sit in the navigation, and they share one family of anchors: FR, EN, ES, BR. It is the language switcher.

The five sites built on the shared template show the identical pattern. The Press page exists in four languages, and so does the Reviews page. No menu, no footer and no body copy leads to any of them. But every language version carries, like every other page on the site, a switcher pointing to its three translations.

/press/       ──FR──▶  /fr/presse/
/press/       ──ES──▶  /es/prensa/
/press/       ──BR──▶  /br/imprensa/
/fr/presse/   ──EN──▶  /press/
...

Four pages, twelve links, a closed island. Each page gets three links. None of them is reachable. Site A has a third island of the same shape around a contact form, which is where its twelve orphans come from.

The other two sites show the same thing at a smaller scale. On site F, a concierge page exists only in its French version and nothing links to it at all: the one orphan in this data set that a link count would catch. Its English translation is linked from that page and nowhere else. Site G has two islands of two pages each: a general information page, and the HTML sitemap page, each in two languages. The sitemap page carries thirteen links into the rest of the site, and nothing leads to it.

A translation link is horizontal. It connects a page to its equivalents, never to the rest of the site. A page reachable only through its translations is reachable only if one of those translations is. When none is, the language switcher builds an island.

How the crawler found them

If no link leads to these pages from the home page, how does a crawler find them at all?

Through the XML sitemap. 49 of the 50 orphans were discovered because they were listed in the site's sitemap file, not because any link led to them. The fiftieth was reached through a link from another orphan.

That has two consequences.

First, a crawl that only follows links cannot find orphans, by construction. It only sees what is reachable. To find what is not, you need a second list of URLs that does not depend on links: the sitemap, the URLs that earn impressions in Search Console, the URLs bots request in your server logs.

Second, the sitemap makes these pages discoverable to a search engine. An orphan is not an invisible page. It is a page the site declares in one file and connects to nothing in its own structure. The sitemap says "this page exists"; the internal linking says "it matters to no one". The two messages contradict each other, and only the second one is repeated on every page of the site.

What it does to those pages

The internal link score ranks, on a 0 to 100 scale, how much of the site's internal popularity a page receives from the rest of the site. All 50 orphans fall in the lowest band, 0 to 24, and most of them sit at 0. They link to one another, but a page that receives nothing from outside its island has nothing to pass on.

We make no claim about the effect on rankings. What can be measured is what the site says about these pages through its own structure, and on that point the answer is unambiguous.

The choice of pages makes this worse than it looks. Press and Reviews pages are exactly the pages that show a third party talking about the hotel. They are trust signals, the first thing an E-E-A-T checklist looks for, and the site wrote them, translated them, declared them in its sitemap, and then put them where nobody walks.

The method, by hand

It takes four steps, and any crawler that can export its links will do.

1. List the pages that should exist. Start with the sitemap. Add every URL from the Search Console Performance report with at least one impression over the last three months, and, if you have them, the URLs Googlebot requests in your logs. Keep the ones that answer 200.

2. Crawl from the home page, following links only. Turn sitemap discovery off for this pass: you want to know what links reach, and nothing else. Do not follow nofollow links. Keep the list of pages reached.

3. Take the difference. Pages in list 1 that are missing from list 2 are your orphans. It is the only definition that holds up.

4. For each orphan, look at what links to it. Export the inbound links of those pages from the crawl in step 1, the one that found them. If their sources are orphans too, you have an island, and the anchor text will almost always tell you where it comes from: a language switcher, pagination, a "related pages" block that only renders inside a dead section.

Step 4 is not a refinement. It is what tells you what to fix. A lone orphan is fixed by adding a link. An island is fixed by adding one link to one of its pages: the language switcher does the rest, since it already connects every version to the others.

What fixing it costs

For the five sites on the shared template, the fix is a single line: a "Press" link and a "Reviews" link in the shared footer. Forty pages become reachable at once, in four languages, across five sites.

The real cost is not technical, it is editorial. For each island, someone has to decide whether its pages deserve to exist.

  • They do: link to them from a reachable page, ideally from body copy that discusses them rather than from the footer. A footer link makes a page reachable; an editorial link gives it context.
  • They do not: remove them from the sitemap, then delete or redirect them. A page you do not want to link to has no business in the file that asks search engines to visit it.

What cannot be defended is the current state: pages declared to search engines, translated into four languages, and connected to nothing.

Limits of this data

Seven sites, five of them on a shared template: this is field data, not a sample. It shows that the case exists, that it repeats from site to site as soon as a template carries it, and that a local link count misses it completely. It does not say what share of the web is affected.

The figures hold for the crawl date. A site fixed since then would no longer show these islands.

And the definition depends on what you call the home page. We start from the page actually served at the root of the domain. If your home page redirects to a language version, start from where the redirect lands, or the whole site will look orphaned.

Next

For the third list of URLs, the one in your server logs, see our guide to log file analysis. For what happens when an orphan carries a canonical or a redirect, see which URL actually gets indexed.

Orphans, their inbound links and the click depth of every page are measured on every crawl by our technical SEO audit, which tells a measured orphan apart from a page whose linking could not be computed.

Screenshot of the Trust baseline and the axes the business model calls for screen in NessFlow, on a demo dataset.

tutorial

E-E-A-T: your checklist depends on your business model

A hotel was losing ten trust points over a return policy it cannot have. Here are the fifteen checks that can actually be verified, which of them apply to your business, and the four traps that corrupt the reading.

The NessFlow team · · 11 min read

Screenshot of the Keyword opportunities mined from Search Console screen in NessFlow, on a demo dataset.

tutorial

Keyword cannibalization: proving a conflict without counting pages

Two pages on one query prove nothing. Across 49 published detection methods, not one separates an engine that is hesitating from an engine that has decided. Here is the protocol that does, by hand, and what our own thresholds are worth.

The NessFlow team · · 14 min read

Diagram: A claim, checked, in the NessFlow architecture.

engineering

Measuring the agentic web without trusting the user agent

A user agent string is a claim, not an identity. We built forward confirmed reverse DNS and published range checking, ran it over 39,319,497 requests on three production sites, and counted two things separately: which machine readable paths agents actually ask for, and which of the agents asking are who they say they are.

Tarek Morgene · · 18 min read

Start with a measurement, not a promise

Run an audit on your own site and read what the engine finds. If you would rather be walked through it, book a demo: we run it on your site, with your own URLs on screen.

Access opens in waves: we email you when yours is ready.