You published the article. It is live, it is in your sitemap, and nothing on your site points to it. Those are orphan pages, and you probably have more of them than you think.
Here is the good news: this is a plumbing problem, not a writing problem. This guide walks you through how to find orphan pages on your own site, then what to do with each one. By the end you will have a reconciled list of every page with zero incoming internal links, a keep-or-remove decision for each, a real home in the right cluster for the keepers, and a validation pass that proves the fix landed.
What you need: a site crawler, a URL export from your CMS, your XML sitemaps, analytics, Search Console, and edit access to the pages where links will go.
Step 1: Define what counts as a page and what counts as an orphan
Before you crawl anything, write down the rule. A page is an orphan when your audit finds zero incoming internal links from any other page in the same site graph. That is it. No traffic test, no quality test.
Then decide what is in scope. Normally that means public, published, canonical HTML pages: articles, docs, product and service pages you want found in search. Record your start URL, the folders or subdomains you are including, your canonical policy, and the date range you will pull analytics and Search Console from.
Now open a spreadsheet and give it real columns. Normalized URL. Original URL and the system it came from. Title. Content type. HTTP status. Canonical target. Indexable or noindex. In a sitemap, yes or no. Which sources found it: crawl, analytics, Search Console, logs, backlinks, CMS, or a plain URL list. Incoming internal link count. The source URLs of those links. Crawl depth. Topic or cluster. Disposition. The source page you picked for the fix. Validation date and result.
Feels like a lot of columns? It is, and you will be glad for every one of them at step 4, when you are deciding whether a page lives or dies.
How you know this step is done. Your team agrees on what counts as a page, which properties are in scope, how duplicate and redirected URLs get mapped, and what zero incoming internal links means in your setup. Your page set is not just your current sitemap.
Where people go wrong. Calling every URL missing from a crawl an orphan. A crawl only reports what it could reach from where it started. A URL can be missing because of crawl scope, a robots rule, JavaScript rendering, a broken link, a redirect, or a whole section nothing connects to. It is a candidate, not a verdict.
Step 2: Crawl your site from its real front door
Run a crawl starting at your home page or the correct property root. Capture internal inlinks, the source pages those links sit on, crawl depth, status code, canonical, indexability, and the final URL after redirects.
If your templates build links with JavaScript, use a rendering mode that inspects the rendered page. Then go check that those links also exist in the delivered HTML. Google generally treats a link as crawlable when it is an anchor element with an href that resolves to a real address. A click handler on a div is not a dependable path. Put the routes that matter in ordinary anchors and stop worrying about it.
One rule to hold: do not build an artificial crawl path just for the audit. You are trying to measure the graph you actually have, not the one you wish you had. A page that only shows up because a sitemap named it should stay clearly marked as source-only.
How you know this step is done. The crawl finished at the scope you intended, and your export has the target URL, a source page or a confirmed zero-inlink state, crawl depth, status, canonical, and indexability. Check that your license or configuration did not quietly cap the crawl at a sample.
Pro tip. Save your crawl configuration. A re-crawl at step 7 only means something if the start URL, included areas, rendering mode, exclusions, and URL rules are the same both times.
Step 3: Add every other place your URLs live
Here is the part most people skip, and it is the part that makes the whole thing work. A crawl that starts at your home page and follows links can never reach a true orphan. That is the definition. So the crawler has to be told those URLs exist. This is the real answer to how to find orphan pages: you do not find them by crawling harder, you find them by comparing lists.
Feed it everything you have:
- Your CMS export of all published public URLs. This is the closest thing to a complete inventory, because it includes pages that have never had a single visit or impression.
- Every XML sitemap and sitemap index, including separate blog, docs, product, image, video, or regional ones.
- Analytics landing pages for a defined period. The documented Screaming Frog workflow suggests at least a month of data, with organic traffic as the default segment.
- Search Console page data for a defined period. Treat this as proof that Google has seen a URL, not as your master inventory.
- Server access logs if you have them. Logs record real server-side requests, including ones analytics never sees.
- A backlink list if external discovery matters to you. An external link explains how an isolated page gets found. It does not make the page internally linked.
- Known isolated areas: documentation systems, legacy folders, faceted sections, product directories. Add them as seed URLs rather than hoping the home-page crawl finds them.
Then reconcile. The model is simple: pages with no internal links are all discovered URLs minus the URLs that have at least one valid observed internal-link edge. The subtraction has to use the crawler's link edges, not a page's presence in a sitemap.
Normalize before you compare, or your numbers will lie to you. Resolve relative links. Drop fragments, because they point inside a page, not to a different one. Keep meaningful query parameters, strip your known tracking ones. Be consistent about protocol, host, path, trailing slash, and case, and do not assume paths are case-insensitive. Follow redirects to the final destination for the decision, but keep the original URL in the file as an alias. These are bookkeeping rules, not ranking rules. They exist so you do not count one page three times or miss an inlink because two systems spelled the URL differently.
In Screaming Frog specifically, the path runs like this. Under Configuration, Spider, Crawl, turn on Crawl Linked XML Sitemaps. Under Configuration, API Access, connect Google Analytics and Google Search Console and pick your property and date range. Run the crawl to 100 percent, then run Crawl Analysis and make sure the Sitemaps, Analytics, and Search Console analyses are all selected. The Orphan URLs filter appears under each of those three tabs, and Reports, Orphan Pages gives you one combined export with a Source column. As a cross-check, open the Internal tab and filter for a blank crawl depth. A URL with no crawl depth was never reached through internal links. The free version caps a crawl at 500 URLs, so a real site audit needs the paid license, listed at $279 per license per year.
Once you have the inventory, DeepSmith's Content Map is useful for the next question, which is where each page belongs. It crawls, enriches, and classifies every page on your site onto a shared topic and funnel-stage taxonomy, and it rechecks your sitemaps every 24 hours. That tells you the topic and stage of an orphan and which existing page is its likely pillar. It is not a zero-inlink detector. Your crawler and your reconciled source list are still what prove the orphan condition.
How you know this step is done. Every candidate row carries source labels, and you can tell apart "not found by this crawl," "found by sitemap," "found by analytics," "found by Search Console," "found in the CMS," and "found in logs."
Where people go wrong. Using one source to find pages with no internal links. A sitemap alone finds declared URLs, not missing relationships. Analytics or Search Console alone misses every page that never got a visit or an impression. The union is the whole trick.
Step 4: Qualify every zero-link candidate before you change anything
You now have a list. Do not start adding links. Open each candidate row next to the live page and work down five questions.
- Is it a real public content page? Pull out feeds, files, tracking URLs, test pages, login-only URLs, and faceted duplicates. Keep them in a separate technical list, because a pile of them usually means a template problem.
- Does the URL resolve? Map redirects to their final destination. A broken or removed URL needs a depublication or redirect decision, not a new link.
- Is it canonical and indexable on purpose? Check the canonical target, robots rules, and noindex state. A noindex directive does nothing if crawlers are blocked from fetching the page and reading it.
- Is it a duplicate? If another page should own the topic, move the useful material there and redirect. Google does not recommend using noindex just to pick a canonical page inside one site, because noindex takes the page out of Search entirely.
- Does it have a real audience or business purpose? Look at the content, the CMS owner, analytics, Search Console, logs, external links, and any campaign use.
Every candidate then gets one of four dispositions:
- Keep and link. Useful, unique, meant to be found. It moves to step 5.
- Keep but deliberately outside organic search. A paid campaign landing page can stay isolated. Its search treatment just has to be an explicit decision, not an accident.
- Merge and redirect. Two pages fighting over one topic. Consolidate into the stronger one, redirect the other, update the references that pointed at it.
- Remove or deprecate. No visitor value, no business purpose, nothing worth preserving. If it has good external links pointing at it, redirect it somewhere relevant instead of dropping it cold.
How you know this step is done. Every candidate has a written disposition and a named owner. "Add a link" is not the default answer.
Where people go wrong. Deleting all the orphaned content in one satisfying sweep, on the theory that orphan pages are junk pages. Orphan status is a graph problem, not a quality verdict. Some of your best pages get orphaned during a migration or a navigation redesign, and some isolated pages are isolated on purpose.
Step 5: Map each keeper into the right cluster
For every page marked keep and link, answer these in order.
What is this page's search intent, and what question does it actually answer? What topic does it belong to, and what stage is it, awareness, consideration, or decision? Which existing pillar, category, or hub page should introduce that topic? Which existing pages are places where this page is a genuinely useful next click for the reader?
Pick source pages with a real topical relationship. Not your highest-traffic post because it is your highest-traffic post. Then decide whether the page also belongs in a navigation or category path, because an important page should not depend on one obscure route when your site has a clear parent category for it. On the orphan page itself, give the reader a way back up to the hub when that helps them.
The structural bar is one valid incoming internal link from a crawlable page. Everything past that is a relevance and usability call, not a quota. Google says plainly there is no magical ideal number of links per page, so do not invent one.
This is another spot where the Content Map earns its keep. Its shared taxonomy shows each page's topic, its funnel stage, and how deep your coverage runs per topic, which makes the pillar-and-related-pages decision an informed editorial call instead of a memory exercise. You still make the call.
How you know this step is done. Every valuable orphan has a named parent or pillar, a chosen source page for the new link, a one-line reason the relationship helps the reader, and a target URL that resolves to the intended canonical page.
Where people go wrong. Dumping the page into a footer, a giant archive, or an unrelated article just to make the count nonzero. That is a cosmetic inlink. You wanted a path.
Step 6: Publish the link, or apply the other decision
For a keeper, add the link on the chosen pillar, category, or related-article page. Make it a normal HTML anchor with an href that resolves to the canonical destination. If that template is JavaScript-driven, confirm the anchor is in the delivered markup and not something that only appears after a user event a crawler may never trigger.
Update your sitemap only when the page is canonical, indexable, and something you want in search. A sitemap entry supports discovery. It does not replace the internal link, and it never has.
For the other three dispositions: keep an intentional campaign page's search treatment explicit, consolidate and redirect your duplicates, remove what has no value. Never use a robots block as a stand-in for a noindex instruction, because a crawler that cannot fetch the page cannot read the instruction.
Most fix orphan pages SEO advice stops right about here, at "add a link and move on." That is the step where it usually breaks, because a link that exists in staging is not a link. Good fix orphan pages SEO work is mostly this unglamorous part: the anchor, the template, the production check.
There is a prevention angle worth knowing too. For articles you have not written yet, DeepSmith's Writer scans your enriched sitemap and inserts up to five strategically placed internal links while the article is being generated. That stops new orphans from appearing. It does not go back and repair the ones already sitting in your CMS. Those still need this audit, a decision, a published link, and the validation below.
How you know this step is done. Every valuable target has at least one incoming link live in production. Intentional pages have an explicit search treatment. Merged pages resolve to their new owner. Removed pages are out of the active queue. The change and its release date are recorded.
Where people go wrong. Stopping after the staging edit. The audit is not fixed until the production page shows the link and the destination can be fetched.
Step 7: Re-crawl, validate, and watch what happens next
Take a breath. The hard part is behind you. This last step is just proving the work.
Re-run the same crawl with the same source imports. Confirm each former candidate now has at least one incoming internal link, a named source page, a crawl depth that is no longer blank, the status you expect, and the canonical and indexability state you expect.
Then open the source page and check the link in the delivered page, not only in a browser inspector that is showing you the rendered result. Make sure the destination is not blocked, unexpectedly redirected, or pointing at a different canonical URL than you thought.
Use Search Console's URL Inspection when you want Google's view of a specific page. The live test tells you whether Google's inspection system can access the page for indexing. It does not tell you the page will be indexed. For a single changed URL, an owner or full user of the property can request indexing. For a lot of URLs, submit or update the sitemap instead. Google is clear that crawling can take anywhere from a few days to a few weeks, that individual requests have a quota, that asking twice does not make it happen faster, and that a request is not a promise of inclusion.
After the crawl and indexing systems have had time to refresh, look at what changed. DeepSmith's AI Visibility Pages view shows which of your pages AI engines cite, each page's share of your total citations, and the prompts driving them. Use it as a before-and-after observation layer. Citation movement can have plenty of other causes, so read it as an observation, not as proof that one internal link did it.
How you know this step is done. The re-crawl puts the page inside your internal graph, the source URL is recorded, the technical checks pass, and there is no unresolved zero-inlink page left without a disposition.
Where people go wrong. Treating a sitemap entry, a live-test pass, or "URL is on Google" as a citation guarantee. Discovery, crawling, indexing, retrieval, ranking, and citation are six separate events, and clearing the first one does not clear the rest.
Keep them from coming back
You just cleaned the house. Now put in the smoke detector, because orphaned content comes back every time someone ships a redesign.
Add a required "incoming source page" field to your content brief or CMS publishing checklist. Before anything publishes, assign it to a cluster and name its parent. Publish the incoming link at the same time as the article, or make the source-page update the very next release task instead of a someday task.
Keep only intended, canonical, indexable pages in your sitemaps. Re-run the multi-source check after migrations, redesigns, navigation-template changes, CMS moves, big URL deletions, and any change to client-side rendering. Pick a cadence that matches how much you publish and ship. There is no universal right answer here, so do not let anyone sell you one.
Keep the last audit file too. The candidate list, the dispositions, the source-page changes, the validation results. Next time, that file is what lets you tell a brand-new orphan from a page you already decided to leave isolated on purpose.
What to do this week
Start small. Pull the CMS export and one crawl, and see how big the gap is. That single comparison usually surfaces the worst offenders in an afternoon, and it tells you whether this is a ten-page cleanup or a two-week project.
Then fix the top five pages you would be embarrassed to lose, and add the incoming-link check to your publishing checklist so the number stops growing while you work.
If you would rather have the map and the linking handled while you focus on the editorial calls, DeepSmith puts the topic map, the internal linking, and the AI citation tracking in one place. You can start a free trial and see your own site in it before you commit to anything.
