A classic car marketplace had 9,220 pages indexed in Google.
8,317 of them had nothing on the site linking to them.
That’s ninety per cent. Nine pages in every ten existed, were indexed, and could not be reached by clicking. No menu, no category, no related-items block, no link from anywhere. If you didn’t already know the URL, the page was not findable by a person, and it was only findable by Google because the sitemap had handed it over.
The site was live. It was taking traffic, about 8,000 visits a month. Nothing looked wrong. Nobody had noticed, because there is nothing to notice.
What an orphan page actually is
A page nothing links to.
That’s the whole definition, and it’s why the problem hides so well. An orphan page isn’t broken. It returns a 200. It renders. It converts if somebody lands on it. Every tool that checks for errors will tell you it’s fine, because by every measure a tool checks, it is fine.
It’s simply not part of the site any more. It’s a file on a server that happens to be in Google’s index.
The reason that matters isn’t philosophical. Internal links are how importance moves around a website. A page with no internal links receives none of it. It sits at the bottom of the pile regardless of how good it is, and on a large site it’s competing with thousands of siblings in exactly the same position.
They are almost never written by hand
Here’s the thing I’d want you to take from this post, because it changes what you do about it.
Orphan pages are not pages somebody wrote and then forgot to link. That happens, but it’s a handful of pages and it’s not why anybody’s number is in the thousands.
Orphans at scale come out of a database.
The car marketplace was a listings site. Every vehicle got a page. Vehicles came and went, which is the business, and the pages stayed. Nothing in the template linked to a listing once it dropped off the current inventory. The sitemap kept feeding them to Google. Google kept them.
Nobody made a decision. Nobody wrote 8,317 pages. A system generated them, one at a time, over years.
The same pattern turns up on ecommerce catalogues with discontinued products, job boards with expired postings, event sites, property portals, anything with a feed. If your site has a database behind it, this is your default state unless somebody has designed against it.
The tell: the same number three times
Something in that audit gave the cause away before I’d looked at a single URL.
- 8,317 pages with no internal links
- 8,317 pages with a missing canonical, or a canonical still pointing at
http - 7,353 pages under 500 words
Three findings. Two of them the same number, the third close behind.
That is not three problems. It’s one page-set, generated by one template, carrying every fault of that template. Which is useful, because it means there is one fix, not three, and it means you should stop counting and go and find the template.
I now check for this deliberately. When two numbers in a crawl report match exactly, they are describing the same pages. Chasing them as separate line items is how a technical audit turns into a 400-row spreadsheet that nobody ever implements.
The canonical half of that is not exotic either. HTTP Archive’s 2025 Web Almanac found a canonical tag on only 67% of mobile pages — a third of the web has none. What made the car marketplace unusual was not that a template omitted the tag. It was that one template was responsible for nine tenths of the site, so a single omission printed itself 8,317 times.
It happens on small sites too
The scale makes the car marketplace memorable, but the proportion is what matters, and the proportion doesn’t need a big site.
Here’s a crawl of a small manufacturer’s ecommerce site, 174 URLs in total.
164 internal HTML pages. 60 orphaned. Thirty-seven per cent, on a site small enough that one person could have clicked every page in an afternoon.
And a car parts retailer, in between the two: 1,630 pages indexed, 1,277 orphans. Seventy-eight per cent. That one also had 1,344 pages under 500 words and no robots.txt file at all, which tells you roughly how much attention the technical layer had been getting.
Three sites, three sizes, same shape.
On the robots.txt point, before anyone assumes that was freakish: the Web Almanac found 13% of sites return a 404 for robots.txt. One in eight. Which is not itself a crisis — no robots.txt means no restrictions, and plenty of small sites need none. The tell is not the missing file. It is a 1,630-page ecommerce catalogue where nobody had ever had cause to open one.
How to find yours
Two minutes of work, and the reason more people don’t do it is that the check has to be run deliberately. Nothing surfaces it on its own.
Crawl the site, then feed the crawler your sitemap as well. This is the step people miss. A crawler starting from your home page follows links. By definition it will never reach a page that has no links pointing at it, so a plain crawl reports zero orphans on a site with eight thousand of them.
You have to give the crawler a second source of URLs: the XML sitemap, a Search Console export, an analytics export, a database dump. Then let it compare the two lists. Anything in the second list that the crawl never reached is an orphan.
In Sitebulb it’s under Internal → Orphaned. In Screaming Frog you enable list mode alongside the crawl and use the Orphan URLs report. Both need the sitemap connected first or the number comes back empty and falsely reassuring.
Then sort by whether you care. This is the same question as any other indexing problem: is there anything in that list that was meant to earn something? A thousand expired listings is a maintenance issue. Your third-best service page is an emergency.
What to do with them
There are only three answers, and the first one is the most common.
Let them go. Expired listings, discontinued products, last year’s events. These pages have done their job. Remove them from the sitemap, return a 410 or redirect to the nearest sensible category, and stop generating the URL when the item goes. This is the correct outcome for the large majority of orphans on a database-driven site, and treating it as a loss is why these numbers grow.
Link to them properly. For pages that should exist, a product still on sale, a service page, a location page, the fix is to put them back into the site. Not by adding them to the footer. From the category or hub page they belong under, in the body, with anchor text that describes them. If you can’t work out where a page belongs, that’s an architecture answer, not a linking one.
Consolidate. If forty orphans are forty near-identical thin pages, one good page and forty redirects is better than forty linked thin pages. Linking to something that shouldn’t exist just moves the problem.
What I would not do is add a sitewide “all listings” page with eight thousand links on it. It technically removes the orphan status and it achieves nothing else.
What happened next: nothing
I should be straight about the ending, because it isn’t a success story.
They never did it.
Not because they disagreed with the diagnosis. The site was built on TotalWebManager, a dealer platform old enough and tangled enough that changing how those listing URLs were generated risked breaking things nobody could confidently map. No one could tell me what else depended on that template. The cost of finding out the hard way, on a live site taking real orders, was higher than the cost of leaving 8,317 pages sitting there doing nothing.
I think that was the right call, and I’d rather say so than sulk about it.
An orphan page set is not an emergency. It’s dead weight. It isn’t actively removing you from search the way a stray noindex tag or a robots.txt block does. Orphans just quietly fail to help. On a legacy platform where you can’t predict what a template change touches, “leave it alone and don’t make it worse” is a defensible answer. I’ve seen far more damage done by confident fixes to systems nobody understood than by leaving a known problem in place.
What I’d do differently now, on any site like that one: stop the bleeding instead of cleaning up the spill.
Don’t retro-fix eight thousand pages. Change what happens to the next listing when it expires: one rule, one place, testable before it ships. The backlog stays where it is, but it stops growing, and in a year the shape of the site is meaningfully better without anybody having touched the risky part.
That’s the version of this recommendation I now give whenever the platform is old enough that nobody wants to be the person who broke it.
The honest caveat
Removing orphan pages is a cleanup, not a growth lever. I have never seen a site’s traffic jump because orphans were dealt with in isolation, and I would be suspicious of anyone who told you otherwise.
What it does is stop you wasting effort. On the car marketplace, ninety per cent of the indexed pages were carrying nothing and going nowhere, and every piece of work anybody did on that site, content, links and speed, was being spread across ten times more pages than needed to exist. The value of fixing it is that everything you do afterwards lands somewhere.
It’s also the fastest way to find out that your real problem is architectural. A site with a 90% orphan rate does not have an internal linking problem. It has a site that was never designed to have a shape.
The short version
- An orphan page is a page nothing links to. It isn’t broken, which is why nothing flags it.
- At scale they come from a database, not a writer. Listings, expired products, feeds.
- Matching numbers in a crawl report mean one page-set, not several problems. 8,317 orphans and 8,317 bad canonicals were the same pages.
- A plain crawl will report zero. You must give the crawler the sitemap as a second URL source.
- Ask what you actually care about before you touch anything.
- Most of them should be removed, not linked. Some should be linked properly. Some should be consolidated.
- It’s a cleanup, not a growth lever, but it’s what makes the growth work land.
- On an old platform, fixing the flow beats fixing the backlog. Stop generating new orphans; leave the existing ones if touching them is risky.
If a site should be ranking and it isn’t, that’s the work I do. Technical SEO covers the crawling, indexing and architecture layer. If you’re not sure which of several plausible problems is costing you, that’s what an SEO audit is for.
