Compare independent URL inventories and check crawl coverage before calling a page an orphan.
An orphan page is a page with no incoming internal links from the rest of a website. Finding one is harder than sorting a crawl by zero links: a crawler can only report what it discovered and inspected. A page absent from the crawl might be disconnected, hidden behind JavaScript navigation, outside the crawl boundary or simply beyond the run's limits.
This guide explains how to find potential orphan pages using a sitemap and a crawl, then verify them against a broader inventory. Start with the website link analyzer, keep its coverage notes and treat zero-inlink findings as candidates. The workflow below is designed to produce defensible decisions rather than an exaggerated count of supposedly invisible pages.
1. Build a list outside the crawl
Export your published URLs from your CMS when possible. Also collect the sitemap URLs and any important landing pages known to the content owner. These independent sources matter because a link-following crawl cannot discover a completely disconnected page unless another input reveals it. Save the source of each inventory entry so you can investigate disagreements later.
A sitemap is useful for discovery, but it is not a substitute for navigation or proof of indexing. Google's sitemap overview explains its role and limitations. Your CMS inventory may contain drafts, archived records or intentionally excluded pages, so do not assume every exported address belongs in search. Begin by marking which URLs represent current, public content that you actually want visitors to reach.
2. Compare matching URL versions carefully
Normalize the comparison consistently, but do not erase meaningful differences. HTTP versus HTTPS, a www hostname and trailing slashes can create mismatches in a spreadsheet. Inspect redirects and canonical information before deciding that two entries represent the same content. Query strings can also identify a real page variation, so deleting every parameter is not a safe general rule.
For example, a sitemap may list a current guide while an old internal link points to its previous slug and redirects. A simple exact-match comparison would miss the relationship. Keep both the requested address and the resolved destination in your notes. If many candidates are just older addresses, work through the internal redirect guide first. You may have a consistency problem rather than a collection of genuinely disconnected resources.
3. Find sitemap-only candidates
Run a crawl and look for pages discovered through a sitemap without observed incoming internal links. Compare that list with your independent inventory. Separate pages the crawler actually fetched from pages merely listed or skipped. A URL that was never inspected cannot support the same conclusions as a successfully crawled page whose links were analyzed.
FreeSiteExplorer uses conservative orphan-candidate language because its crawl is bounded. Read the coverage explanation before acting on the results. A partial run might miss the very category page that links to a candidate. In your review sheet, use statuses such as “needs wider coverage,” “linked in rendered navigation” and “confirmed by inventory review.” This preserves uncertainty while still giving each candidate a clear next investigative step.
4. Check the most likely parent pages manually
Open the category, documentation index, service hub or article collection where the candidate should appear. Search those pages for its title and inspect the actual link destination. A label may be present but point somewhere else. Conversely, the destination may be linked under a shortened title that a text search for the full heading misses.
Consider an illustrative gardening site with a detailed guide to pruning young apple trees. The guide exists in the sitemap, but the fruit-tree hub lists only older tutorials. If no other suitable parent references it, that is a plausible navigation gap. Before adding it, read the guide and confirm that it remains current. Repairing discoverability for outdated or redundant content can create more confusion rather than solving the visitor's problem.
5. Account for JavaScript and crawl boundaries
A menu or related-content widget may add links after the initial HTML response. This analyzer does not execute JavaScript, so its view can differ from an interactive browser. Google's JavaScript SEO documentation describes rendering considerations; do not assume every crawler sees identical content. Inspect how the website actually exposes the candidate link.
Also review hostname boundaries, robots restrictions, pagination and the configured depth and page limits. A separate help subdomain is outside a same-host crawl even if the business considers it part of one website. An archive page beyond the crawl limit can contain valid incoming links. Write down which explanation you ruled out. If you cannot inspect enough of the site, keep the candidate unconfirmed and ask the appropriate site owner for the missing inventory or access context.
6. Decide whether the page deserves a place
Not every disconnected URL needs more links. Evaluate its purpose, accuracy and overlap with other pages. An active, useful tutorial may need a contextual route from a relevant hub. A duplicate campaign page might need consolidation. An expired operational page may belong in an archive or be retired according to the site's content policy.
Make this an editorial decision before implementing a technical change. For the apple-tree guide, the likely repair could be a link from the fruit-tree hub and a relevant seasonal checklist. For a duplicate guide, merging unique useful information into the better maintained resource may be more appropriate. Document who approved the decision and why. Avoid adding a giant footer list of every candidate just to remove zeroes from a report; it can bury useful navigation in noise.
7. Add links where readers need the next step
Choose source pages whose readers would benefit from the destination. Write a short explanation around the link and use wording that accurately describes the next page. The anchor text audit workflow can help if your new links otherwise become repetitive “read more” labels. A relevant connection should make sense even without an SEO objective.
After publishing, start from the source page and follow the new route on desktop and mobile. Confirm that a real anchor points to the intended public URL and that the destination is usable. Run another comparable crawl to check whether the incoming relationship is now observed. Keep the content decision and the technical validation separate in your log: one records why the page belongs, the other proves that the chosen route exists.
8. Maintain an inventory as content changes
Orphan candidates often arise when a category is redesigned, an article listing changes or a campaign ends. Add an incoming-link check to publication and retirement workflows. When publishing a new resource, identify its parent and any relevant contextual sources. When removing a hub, review the destinations that depended on it before the new navigation goes live.
Store a lightweight inventory with URL, owner, purpose, parent page and last review date. Reconcile it with crawl evidence periodically, especially after structural releases. If the site is large, review one meaningful section at a time and state the boundary clearly. A broader free internal link audit ties these decisions to broken links, depth and anchors. The goal is a maintained content system where important pages have sensible routes, not a one-time declaration that no orphans can possibly exist.
Frequently asked questions
Does a sitemap link mean a page is not orphaned?
A sitemap can reveal a URL to a crawler, but it does not create a normal contextual route for visitors from other content pages. Keep sitemap discovery separate from incoming HTML links when investigating whether a page is connected to the website.
Can a single crawl prove that a page is an orphan?
Usually a bounded crawl cannot prove that no incoming link exists anywhere. It may miss restricted, rendered or unvisited pages. Combine crawl findings with a CMS inventory and manual checks before calling a candidate a confirmed navigation gap.
Should I delete all pages with zero observed inlinks?
No. First evaluate their value and investigate coverage. Some useful pages need relevant connections; others may be intentionally isolated or redundant. Deletion should follow a content decision and a review of existing visitors, external references and replacement options.
Why is an important page missing from the report entirely?
It may be absent from both discovered links and sitemaps, outside the hostname boundary, restricted or beyond crawl limits. Compare it against your independent inventory and review the run's warnings. Missing from the report is not equivalent to missing from Google.