An orphan page exists and may return 200, but it cannot be reached through internal links from other accessible pages on the site. It may remain in the sitemap, receive external traffic, or be stored in the CMS, so a standard crawl starting from the homepage will not find it.
A single crawler cannot detect orphan pages: finding them requires comparing independent URL sources.
Agree on an exact definition
Not every page with one link is an orphan, and not every URL without a link needs one. Set a rule: an internal HTML link with href must come from an indexable page that the crawler can load. A link from a closed personal account, an internal search result, or a block that appears only after a user action does not provide a reliable crawl path.
Track crawl depth separately. A URL six clicks deep is technically not an orphan, but it is harder to discover and recrawl. It is therefore useful to include two statuses in the report: “no incoming links” and “has a link, but the page is too deep.”
Before collecting data, define the scope: primary protocol and host, language versions, subdomains, parameters, and pagination. Otherwise, service URLs, slash duplicates, and old HTTP versions will be mixed in with real documents.
Build a set of URLs discoverable through links
Start a crawler from the homepage and, if necessary, from the root pages of individual sections or languages. Allow JavaScript execution if the navigation is built client-side, but save a separate result without rendering: the difference will show which links depend on scripts.
For each URL, collect the response code, final URL after redirects, canonical, depth, number of incoming links, and source page. Exclude form destinations, mailto, external domains, and fragments from the set. Normalize URLs carefully: parameters may be either technical duplicates or standalone landing pages.
The crawl result is not a list of every page on the site, but a set of Crawl that the crawler discovers through the current link structure. The principles of building a connected architecture are covered in detail in the internal linking guide.
Add independent URL sources
Collect separate sets:
Sitemap— all URLs from current XML sitemaps and their indexes;Analytics— landing pages with visits during the selected period;Search— pages with impressions, clicks, or a known status in search consoles;Logs— URLs requested by search crawlers and users;CMS— published entities from the database or CMS export;Backlinks— destination URLs of external links, if such an export is available.
Each source has its own margin of error. A sitemap may contain outdated URLs, analytics does not show pages without traffic, logs are limited by their retention period, and a CMS may export drafts and system entities. The sources therefore do not replace one another; their value comes from comparing them.
If the XML sitemap contains redirects, 404 and non-canonical versions, flag this as a separate issue first. Recommendations for cleaning up a sitemap are in the article on sitemap errors.
Combine the lists and calculate candidates
Bring the URLs into a consistent format: remove fragments and normalize the host and protocol according to the site’s rules, but preserve the original value in a separate column. Do not remove parameters mechanically. Then, for each URL, record whether it appears in each source and in the crawl result.
The basic candidate formula is:
Orphan candidates = (Sitemap ∪ Analytics ∪ Search ∪ Logs ∪ CMS ∪ Backlinks) − CrawlThis produces candidates, not confirmed orphans. A URL may be missing from Crawl because of noindex, a redirect, authentication, a server error, or a crawler configuration limit. Add the response code, canonical, and entity type before labeling a page an orphan.
A useful table includes these columns: URL, discovery source, HTTP status, indexability, canonical, traffic, impressions, update date, page purpose, and decision. First sort by working, indexable URLs with traffic or impressions: they are more likely to need their crawl path restored quickly.
Check each class of candidate
A working URL with 200, its own canonical, and useful content is the main candidate for returning to the site structure. Find a logical place to link to it from: a category, hub, breadcrumbs, related article, or parent entity page. The link should help visitors; merely closing an item in the report is not enough.
There is no need to “rescue” a redirect with a link: update the sources to point to the final URL. For 404, find out why the URL remains in the sitemap, analytics, or database; then restore the page, set up a relevant redirect, or remove the outdated reference. Replace non-canonical versions with the canonical URL in links and the sitemap.
Pages with noindex may intentionally be outside the site structure: search results, service filters, or pages displayed after form submission. Do not automatically add them to the navigation. Just check that the restrictions are consistent with their purpose. The SEO audit fix plan describes how to choose an action for different errors.
Fix the cause of orphan pages
The list of fixed URLs will quickly become outdated unless you address the underlying mechanism. Common causes include a migration that changed category URLs; importing content without assigning it to a category; removing a “Related” block; a menu error; filtering entries by a new status; broken language navigation; and publishing through an API that bypasses the standard CMS process.
Group findings by template and date. If all the orphan pages belong to one page type and appeared after a release, check the code that generates links. If they are a few old, individual articles, the issue is more likely editorial. Comparing published CMS entities with URLs in the navigation can be turned into an automated test.
A good publishing process does not allow a page to be “published but not linked to anything.” Required fields might include a category, parent object, or at least a place in a topical hub. After a programmatic import, run a separate page-discovery check: a sitemap alone is not enough for verification.
Restore links based on priority
Do not add every discovered page to the menu or footer. First determine its role. A commercial landing page should get a link from the relevant service or category; an informational article from a topical overview; an archival document may remain accessible by direct URL but be excluded from the index; a useless duplicate should be consolidated.
Choose descriptive anchor text that matches the destination. Check that the link is present in the source or reliably rendered HTML, is not blocked by nofollow without a reason, and leads there without an intermediate redirect. After deployment, run another crawl from the homepage. The fixed URL should appear in Crawl, have at least one relevant source, and retain the correct canonical.
The full reChecker website audit collects pages from sitemaps and internal links and records their discovery source. For the set Crawl, use only URLs found by link crawling (crawl or both); URLs found only in the sitemap should remain orphan candidates. Then add exports from the CMS, analytics, logs, search consoles, and external links.
Check regularly
The right frequency depends on how quickly the site changes: a marketplace needs frequent checks, while a small corporate site can be checked after releases and bulk publishing. Keep the previous result. A newly orphaned page is more important than an old URL already classified as archival.
You can build the check into the release process: compare an export of published URLs with a crawl of the test or closed pre-production version; separately check that the sitemap contains no URLs without incoming links, if that is prohibited for the project. Run a short production crawl after release.
The final table should include a decision for every candidate: link to it, update the link, redirect it, remove it from the sitemap, leave it as a service page, or restore it. Add an owner and the date for the next crawl. After deployment, useful URLs appear in Crawl, while service and removed URLs retain their pre-agreed status.