A documentation redirect map pairs every old public URL with an approved target or retirement action, then tests the deployed response, final canonical URL, anchor behavior, and absence of redirect chains.
Start from observed old URLs, not the new navigation
The old sitemap is only one source. A useful inventory combines the current crawl, analytics landing pages, search-console data, repository routes, inbound links, support macros, release notes, and generated API paths. Those sources reveal pages that users and external sites still request even when the current navigation no longer links to them.
Each old URL receives one approved outcome. A page that keeps the same subject maps to its closest new equivalent, several overlapping pages may converge on one merged guide, and genuinely obsolete material receives an intentional retirement response. Redirecting every missing page to the homepage hides mistakes and gives readers no relevant continuation.
Preserve the parts of a URL readers depend on
Documentation links often include anchors, versions, locales, trailing-slash variants, file extensions, and query parameters. The route record states how each pattern behaves and whether the target contains the referenced section. A path-level redirect that drops a widely linked anchor can look correct in an automated status check while still failing the reader's task.
Google recommends permanent server-side redirects when a page has moved. The deployed rule should return the intended permanent status and land directly on the canonical target without an intermediate chain. Canonicals, sitemaps, navigation, and internal links should point to the final URL rather than rely on the redirect forever.
Test the manifest against production behavior
The acceptance crawl requests every old route, records the status and full redirect path, confirms the final canonical, and flags loops, chains, cross-domain errors, and unexpected 404 responses. High-traffic and externally linked pages receive a manual reader check. The manifest remains versioned after launch so new route changes extend one known record instead of starting another spreadsheet.
Where the service stops
Reality Contact, LLC migrates and validates the agreed documentation corpus, but does not decide product policy, invent missing API behavior, approve legal or security content, publish private documentation publicly, or switch the production domain without buyer authorization. The buyer approves keep, merge, retire, route, component, and access decisions, supplies content owners, and switches or authorizes the production domain after build, redirect, accessibility, and parity checks pass. The work is documentation implementation and document preparation, and it does not replace legal, security, accessibility, compliance, or product advice. The buyer owns every content, access, route, retirement, component, claim, and production-domain decision.
Sources: Google Search redirect guidance; GitBook migration documentation.