How to Find Orphan Pages and Restore Internal Linking

Orphan pages cannot be reliably found with a single standard site crawl: if a URL has no internal links pointing to it, a crawler starting from the homepage may never discover it. A practical method is to collect URLs from several independent sources, compare them with the list of pages found through internal crawling, then verify each candidate and restore useful pages to the site structure.

What Counts as an Orphan Page

For a practical SEO audit, an orphan page can be defined as an indexable or potentially useful URL that exists on the site but receives no regular internal HTML links from other accessible pages.

It is important not to confuse orphan pages with other issues. A page that can be reached through a chain of internal links is not an orphan, even if the path is too deep. A URL protected by authentication, a service endpoint, an internal search result, or an intentionally isolated landing page is also not necessarily an SEO problem.

The main check is this: the URL appears in the sitemap, analytics, server logs, CMS, or search engine data, but is absent among the destination pages of internal links in a complete site crawl. Such a URL should be reviewed manually rather than automatically classified as an error.

Step 1. Get a List of URLs Accessible Through Internal Links

First, perform a standard crawl of the site starting from the homepage. Any crawler that can follow HTML links and export discovered URLs and inbound links will work.

Before crawling, define consistent rules; otherwise, duplicate URL variants will contaminate the comparison:

• choose the primary protocol, usually HTTPS;
• include only the required hostname;
• normalize trailing slashes according to the site architecture;
• do not mix parameterized URLs with their canonical versions unless necessary;
• do not treat fragments such as #section as separate pages.

After the crawl, export at least two fields:

• page URL;
• number of incoming internal links or a list of the pages containing those links.

We will call this export Crawl. It represents the pages that the crawler was actually able to discover through the site structure.

Do not limit crawl depth to two or three levels when the goal is to find orphan pages. Artificially limiting depth creates false positives: a normal fourth-level page will appear to be missing.

Step 2. Export the XML Sitemap

The next source is the XML Sitemap. Collect all URLs from the sitemap and from all nested sitemap files if a sitemap index is used.

We will call this list Sitemap.

The mere presence of a URL in a sitemap does not prove that the page should be indexed or that it is an orphan. A sitemap is only a source of known URLs. It may still contain deleted, redirected, non-canonical, or technical pages.

For each URL from the Sitemap, you will later need to check at least the HTTP response, indexability, and canonical.

Step 3. Add URLs from Analytics

If the site uses web analytics, export the page addresses that received views over a sufficiently long period. In practice, it is useful to choose a period that includes seasonal pages and infrequent visits rather than only the last few days.

We will call this list Analytics.

It is especially useful for old publications and landing pages: users may continue reaching them from bookmarks, search engines, advertising, or external links even after all internal links have been removed.

Before comparison, remove service parameters if the analytics system records a single document as multiple URLs, for example variants containing campaign tracking parameters. Do this only for parameters whose purpose is known. Do not automatically remove all query parameters: on some sites they define separate content.

Step 4. Use Server Logs

Web server logs can reveal URLs that are absent from both the sitemap and the current internal linking structure. Select requests to HTML pages on your site and exclude obvious static resources such as images, CSS, JavaScript, fonts, and other files that are not documents.

This list can be called Logs.

Logs are especially useful after migrations and redesigns. They may contain old URLs that search engine crawlers or users continue to request.

However, not every URL found in logs should be treated as an existing page. Logs may contain:

• requests to URLs deleted long ago;
• invalid URLs;
• bots scanning random paths;
• redirects;
• 404 and other responses.

Therefore, the HTTP status must be checked separately.

Step 5. Add URLs from the CMS and Content Database

For a large site, it is useful to obtain a list of published entities directly from the CMS: articles, products, categories, reference pages, and other content types.

This source often reveals real orphan pages earlier than SEO tools do. For example, an article may have a Published status and a valid URL but have been removed from its category and all navigation blocks.

Do not export drafts, preview URLs, service records, or administrative pages without filtering them first.

Step 6. Compare the Lists

After normalizing the URLs, create a combined table. The following columns are sufficient for each address:

The main orphan-page candidates are identified using this condition:

Crawl = no
AND
(Sitemap = yes OR Analytics = yes OR Logs = yes OR CMS = yes)

If your crawler separately exports the number of incoming links, a second check is also useful:

Internal inlinks = 0

Do not combine the two criteria blindly. Some tools may add a URL to the crawl from a sitemap, API, or another supplemental source. In that case, the page will appear in the overall export even though it actually has no internal HTML links pointing to it. For final classification, rely specifically on incoming internal links.

Step 7. Verify Every Discovered URL

Automated comparison produces candidates, not a final list of errors. For each candidate, check the following in order:

1. HTTP response. A useful page should normally return a final successful response. Redirects, 404s, and other states require separate handling.
2. Page type. Make sure it is a real HTML document rather than a file, API endpoint, or technical route.
3. Indexability. Check the robots meta directives and any other indexing controls used by the site.
4. Canonical. If the page points to another URL through canonical, first determine whether the current address is an independent document or a duplicate.
5. Link presence. Look for the page in the source HTML of other documents. Links generated only through non-standard scripts may be handled differently by SEO tools.
6. Page value. Decide whether the page should remain accessible and indexable at all.

Step 8. Group Orphan Pages by Cause

The appropriate fix depends on the cause. In practice, it is useful to divide the discovered URLs into at least four groups.

A Useful Page Accidentally Dropped Out of the Site Structure

Add contextual links to it from topically related documents. If the page belongs to a category or section, restore its presence in the appropriate listing, category archive, or navigation block.

Do not rely on a sitemap link alone: an XML Sitemap does not replace internal navigation.

The Page Is Needed Only for a Narrow Campaign

If the URL is intentionally used as a standalone advertising or service landing page, the absence of internal links may be acceptable. The decision depends on whether the page should participate in organic search and the site's information architecture.

The Page Is Outdated

If the content is no longer needed, do not artificially restore it to the menu merely to eliminate its orphan status. Choose the appropriate action based on the page's purpose: delete it, merge it with current content, or configure a redirect if a genuinely relevant replacement exists.

The URL Is a Duplicate

First eliminate the cause of the duplicate: parameters, alternative paths, incorrect CMS links, or other URL-generation mechanisms. Creating additional links to a duplicate usually only makes the problem worse.

How to Properly Restore a Page to the Internal Linking Structure

For a useful page, choose link placements based on relevance rather than at random. The most useful locations include:

• the parent category or section;
• a product, article, or document listing page;
• related content;
• a contextual paragraph on another page where the link is logically useful to the user;
• breadcrumbs, if they reflect the actual site hierarchy.

The anchor text should describe the destination of the link. There is no need to insert the same keyword phrase into every link.

Do not try to fix hundreds of orphan pages by adding a single global block of links in the footer. This may technically create incoming links, but it does not restore a proper site structure or topical relationships between documents.

Step 9. Recheck the Site

After making changes, run a new crawl using the same settings as in the initial audit.

For a corrected page, the following verifiable conditions should be met:

• the crawler discovers the URL when starting from a normal site entry point;
• the URL has at least one expected internal HTML link;
• the link points directly to the intended address unless an intermediate redirect is part of the site architecture;
• the page returns the expected HTTP response;
• the canonical and indexing rules match the intended decision;
• the sitemap does not contain URLs that the site no longer considers current canonical pages.

After that, compare Crawl again with all sources external to the internal link graph. The difference should contain only intentionally isolated, technical, or already handled URLs.

Common Causes of False Results

The first source of errors is inconsistent formatting of the same URL. For example, HTTP/HTTPS variants, versions with and without www, and versions with and without a trailing slash may appear in the table as separate records.

The second source is JavaScript navigation. The JavaScript rendering capabilities of specific SEO crawlers vary by product and version. Without checking the documentation for the tool being used, you cannot assume that it will detect the same links that a browser sees after scripts execute.

The third source is pages that become accessible only after submitting a form, signing in, or performing a user action. A standard crawler may not discover them, and that does not necessarily indicate an internal linking problem.

You also cannot consider a page properly linked simply because it appears in an XML Sitemap. A sitemap is used as a URL discovery mechanism, but it does not create HTML relationships between documents.

Limitation Regarding Search Console and Other Cloud Services

Search engine data can serve as an additional source of URLs: it can help identify pages known to the search engine but absent from the current crawl. However, report names, available fields, export methods, and service interfaces change over time. The current official documentation for these services was not checked for this article, so specific interface labels and version-dependent instructions are not provided.

Final Checklist

• Run a complete crawl of the site from the primary entry point.
• Export URLs from the XML Sitemap.
• Collect page addresses from analytics.
• If access is available, add URLs from server logs.
• For large sites, export published pages from the CMS.
• Normalize URL formatting across all datasets.
• Find addresses that are absent among the destinations of internal links.
• Check the HTTP response, indexability, canonical, and purpose of each candidate.
• Restore useful pages to relevant sections and contextual internal linking.
• Do not create links to duplicates or pages that should be removed.
• Repeat the crawl and confirm that corrected URLs are discoverable through internal HTML links.