How to find orphan pages on your site

Orphan pages are pages on your site that no other page on your site links to. Google can still reach them through a sitemap or an external link, so being orphaned is not the same as being invisible. What they lose is context: no anchor text describing them, no position in your structure, and no path for a reader who is already on your site. Finding them is one subtraction, and the whole method fits in this chapter.

What you need before this chapter

You need a working internal link structure to compare against, and a view on what your site is supposed to be shaped like. Both are covered in internal linking strategy. This chapter is the audit that runs after that structure exists, because an orphan is defined entirely by what the structure fails to touch.

What counts as an orphan page

One condition, and two things people wrongly add to it.

The fourth row is the one that costs teams a week. An unindexed page and an orphan page look identical in a report and have nothing to do with each other. A page can be orphaned and indexed, or well-linked and unindexed, and the diagnosis for each starts somewhere else.

Why a sitemap does not fix an orphan page

Google lists three ways it finds URLs: "Some pages are known because Google has already visited them. Other pages are discovered when Google extracts a link from a known page to a new page: for example, a hub page, such as a category page, links to a new blog post. Still other pages are discovered when you submit a list of pages (a sitemap) for Google to crawl" (How Google Search works, read 2026-09-03).

A sitemap covers discovery, and only discovery. It carries a URL and nothing else — no anchor text, no surrounding sentence, no indication of which section of your site the page belongs to. The link in Google's own example does carry those things, which is why the same page discovered two ways arrives with two different amounts of information attached.

A sitemap tells a crawler that a page exists. A link tells it what the page is for.

The reader side is simpler and harsher. Nobody browsing your site can reach an orphan page at all. It exists for people who arrive from a search result, and for nobody else.

How to find orphan pages in five steps

The method is a set difference. Everything you intend to publish, minus everything your own links reach. The work is in building the two lists honestly.

1. Build list A: every URL you intend to have. The sitemap is the fastest source; a CMS export is the more complete one, because it includes pages the sitemap generator skipped.
2. Build list B: every URL reachable by following internal links from the homepage. Use whatever crawler you already have, and make sure it renders JavaScript if your navigation is built that way.
3. Subtract B from A. What remains is a candidate list, not a verdict.
4. Triage every candidate into link, merge or remove. The table below is the whole decision.
5. Verify the ones you kept. After adding links, confirm the page is actually indexed with the inspection tool, covered in how to read the URL inspection tool.

# List A: every URL the sitemap claims
curl -s https://example.com/sitemap.xml \
  | grep -oE '<loc>[^<]+' | sed 's/<loc>//' | sort -u > all-urls.txt

# List B: export from your crawler, one URL per line
sort -u crawled-urls.txt > reached.txt

# A minus B: the orphan candidates
comm -23 all-urls.txt reached.txt

If the two files use different trailing-slash or protocol conventions, this subtraction will report your entire site as orphaned. Normalise both lists before you run it, and sanity-check the count before you believe it.

Run the subtraction twice before acting on it: once against the sitemap and once against a CMS export, if you have both. Where the two candidate lists disagree, the disagreement itself is the finding — a URL that appears in the CMS but not in the sitemap is a page your build pipeline has quietly stopped publishing, which is a different bug with a different owner.

The triage table

Every candidate lands in one of four rows. Deciding takes about thirty seconds per page once you have the table in front of you.

The last row is the one worth slowing down for. Before removing anything, check whether the page has links from other sites. An orphan internally can still be the most-linked page you own externally, and deleting it throws away the one signal it accumulated.

Three ways this measurement lies to you

All three produce a candidate list that looks convincing and is wrong.

1. Your crawler could not render the navigation. If links are built by script and the crawl did not execute it, list B is short and half your site looks orphaned. The shape of that failure is measured in what counts as a crawlable link.
2. List A came only from the sitemap. Pages the sitemap generator skipped never enter the comparison, so the pages most likely to be orphaned are exactly the ones missing from the input.
3. Pagination and filters inflate both lists. Faceted URLs generate thousands of candidates that are not pages anyone intended to publish. Exclude them by pattern before triage rather than deciding on each one.

What being orphaned does not mean

It is not a penalty. Nothing in Google's documentation describes orphaned pages as a negative signal, and we have no measurement suggesting otherwise. It does not mean the page cannot rank, because discovery through a sitemap is a documented path. And we cannot tell you how much traffic a given orphan is losing — that would need a before-and-after on the same page with links added and nothing else changed, and we have not run that test.

What we will say plainly: a page nobody on your site links to is a page nobody on your team decided was worth pointing at. That is usually the more useful finding. To check what a fetch of one of those pages actually returns before you decide its fate, see how QueryWin reads a page.

Common questions

Are orphan pages bad for SEO?

Not directly, and no documentation says they are. The cost is indirect: no anchor text describing the page, no internal link equity reaching it, and no path for a human already on your site. Those are three real losses that add up without ever being a penalty.

How do I find orphan pages without a crawler?

Compare your sitemap against your server access log for the last month, keeping URLs that received no visits with an internal referrer. It is a rougher method and it misses pages nobody has visited for other reasons, but it needs no tooling beyond files you already have.

Does a footer link stop a page being an orphan?

Yes, by the definition used here — it is linked. Whether a link in a footer that appears on every page describes the target usefully is a separate question, and one this audit does not answer.

Should I put orphan pages in the sitemap?

Only if you also link them. A sitemap-only page is discoverable and contextless, which is the condition you set out to fix. Adding it to the sitemap and stopping there resolves the report without resolving the problem.

How often should I run this?

After each migration, each redesign of the navigation, and once a quarter otherwise. Orphans arrive in batches — a template change or a CMS move creates dozens at once — rather than one at a time.