Internal linking and useful reader routes
Reconnect useful pages through meaningful reading paths.
Orphan recovery compares the pages that exist with the pages reachable through internal links, then restores useful routes to pages that deserve a distinct role. A missing crawl result is a lead to investigate, not proof that a page has no incoming links.
Free learning from Semantec SEO.

Define the missing path and the evidence boundary.
A structural orphan has no incoming internal link in the graph being examined. A weakly supported page has links, but those routes may be hard to find, irrelevant to its task or dependent on a fragile component. Keep these classifications separate. One irrelevant footer link can change a link count without solving the learning gap.
Define the graph before claiming an orphan. Record the crawl’s start URLs, date, included hosts, excluded parameters, authentication state, rendering method and followed link types. A crawl that never entered a branch cannot prove that every absent page is isolated. Similarly, a CMS export can show that a URL exists without showing a useful path to it.
Combine URL sources where available: the CMS inventory, sitemap, internal crawl and historical records can reveal different candidates. Search or analytics exports may add known URLs, but absence from those exports does not prove irrelevance. Record which sources were available and which were not.
Inspect incoming links directly for each candidate. Separate body links, menus, cards, breadcrumbs and links from pages outside the crawl’s scope. Identify redirected targets and duplicate URL forms so one page is not mistaken for more than one independent resource.
Confirm that the page deserves recovery.

Recovery is a content decision as well as a graph repair. Check that the page answers a distinct question, preserves useful evidence and has a maintained owner. If another page already answers the same task better, consider an approved merge rather than creating a token inbound link to keep both alive.
Check the destination’s technical state before recommending a route. A missing page, a login requirement, a redirect, a canonical preference for another resource or a deliberate exclusion can change the decision. These signals need interpretation together. A canonical annotation is not a redirect, and a robots restriction does not establish a page’s usefulness to a person.
Some utility or private process pages intentionally sit outside public learning paths. Do not expose them solely to reduce an orphan count. A page with unresolved ownership or outdated instructions should be held for review instead of being recommended to readers.
The working decision can be recover, strengthen, merge, redirect, remove or hold. Record the reason and dependency. A redirect or removal requires its own approved action; finding a weak path does not authorize deleting the page.
Design entry points and useful depth.

Start from where the reader encounters the need. A branch hub can introduce the recovered page, while a closely related explanation can connect the specific prerequisite. Add an outbound route from the recovered page when readers need to return to the main task or continue to the next decision.
Depth is useful only in relation to a task and starting point. A specialist reference may reasonably sit behind an introduction; a necessary prerequisite should not be hidden behind unrelated steps. Compare the observed route and its labels rather than applying a universal number of clicks.
Google recommends an internal link from another site page for each page you care about. This is a discoverability baseline, not a guarantee of indexing or a sufficient learning design. The proposed recovery should explain why the chosen source page introduces the destination need.
Count incoming pages separately from repeated links in one template. Ten copies of a repeated navigation link are different from ten relevant explanations. Neither count alone establishes that readers can find the answer at the right moment.
Worked example: trace a missing supporting explanation.
Consider a fictional learning collection with a planning hub, a “Compare two room layouts” task and a separate explanation of usable occupancy. The comparison asks the reader to compare occupancy figures but never defines how arrangement affects them. The supporting explanation exists in the fictional CMS and sitemap.
A crawl starting at the planning hub reaches the comparison but misses the occupancy explanation. The audit then checks the complete included URL list and inspects internal incoming links. In this example, no included public page links to the explanation. The absence is supported within that recorded scope; it is not inferred from the crawl alone.
The explanation is kept because it resolves a prerequisite that the comparison needs and does not duplicate another owner. Add a contextual route from the comparison’s first occupancy discussion, with the planned anchor “how arrangement changes usable occupancy.” Add a hub entry that describes the explanation’s role. The recovered page should point back to the layout task after explaining the distinction.
Do not add a generic link from an unrelated news article merely to change zero to one. Do not claim the page is recovered until those routes exist and have been followed. The table describes the fictional investigation and acceptance conditions; it does not report a live crawl of this website.
| Evidence or step | Finding | Action or acceptance |
|---|---|---|
| CMS and sitemap | Occupancy explanation exists | Candidate only; does not establish reachability |
| Scoped hub crawl | Comparison reached; explanation absent | Inspect scope and incoming sources |
| Included source inspection | No incoming public route found | Structural orphan within recorded scope |
| Content review | Distinct prerequisite for layout comparison | Recover rather than merge |
| Comparison passage | Needs arrangement distinction | Add accurate contextual route |
| Hub and destination | Need entry and return path | Verify both plus final technical state |
Verify the route rather than the count alone.

Recheck each changed source and the final destination. Confirm that the source contains a real navigable anchor, its wording matches the explanation and the destination is available in the intended access state. Test any fragment and the route back to the task. Review the page’s owner, overlap and technical signals after the change.
Repeat the scoped crawl or graph inspection using the same assumptions so the before and after comparison is meaningful. If rendering, crawl exclusions or URL normalization changed, record that difference rather than presenting the new count as a pure effect of the added links.
Recovery can improve the available route without proving increased engagement, traffic or indexing. Keep proposed routes, implemented links, observed reachability and measured behavior as separate records. Review again when content moves, menus change or a supporting page is consolidated.
Sources and further reading.
The platform documents explain technical link handling. The decision records and fictional examples on this page are editorial methods; they do not report a live audit or guarantee a search outcome.
Continue learning
Choose the next related task.
Use the internal linking learning hub for related route decisions, or return to the semantic SEO learning overview to choose another subject.
