A safe migration begins with a URL map, not a launch-day rewrite
For a domain, platform, or URL-structure change, make an explicit old-to-new URL map before release. Google’s site move guidance recommends permanent server-side redirects for URL changes and staged verification. The most useful minimum deliverable is a reviewed table: old URL, intended new URL or retirement status, content owner, redirect status, final status, canonical, and test result.
Export current sitemap URLs, important internal destinations, top landing pages, locale variants, PDFs, and legacy routes still receiving links. Decide whether each page has a close replacement, should remain at its address, or should return a truthful missing/removed response. Do not substitute a homepage redirect for a decision. Preserve analytics and ownership verification separately from crawler controls; a migration is not the time to fold unrelated redesign changes into routing.
Rehearse a practical move
Suppose docs.example.com/getting-started becomes www.example.com/guides/getting-started/. In staging, request the old HTTPS URL and ensure it performs one server-side redirect to the exact new page. Verify the destination returns 200, self-canonicals, appears in the new sitemap, and has internal links. Check that assets, PDF downloads, language alternatives, and the old robots file do not introduce a second hop or blocked destination. Launch the same mapping without exposing staging to the public; see staging site indexing prevention.
After release, test samples from every URL class and crawl the whole map with a bounded tool appropriate to your scale. Compare old and new hostname responses, redirects, canonicals, robots policy, sitemap, noindex headers, and error routes. Submit updated signals through the search engine tools you use, then monitor real server logs and search diagnostics. Do not call a successful deploy proof that every crawler has recrawled or retained every result.
Keep the launch small and reversible
Do not simultaneously change domain, information architecture, content, CMS, and international targeting unless the business need requires it. Do not leave staging noindex headers or authentication rules on production. Do not break an old URL’s query handling without deciding whether parameters matter. Do not remove redirect rules immediately after launch; retain them according to your reviewed migration policy.
Use redirect chains and crawler access, canonical URL audit, and the AI search readiness checker to gather evidence. The checker is a raw response assessment, not migration monitoring or a ranking guarantee.
Capture a launch baseline
Before switching traffic, save a small set of representative old URLs, headers, sitemap entries, and canonical pages. Repeat the same checks immediately after launch and again after cache expiry. A stable baseline makes a real regression visible without claiming that crawler recrawls or search-result changes follow a fixed timetable.
FAQ
Name a single owner for the migration map through the post-launch period. That prevents urgent fixes from changing routes without recording the intended destination or verifying the final response.
Should every old page redirect?
Redirect pages with a close replacement. Return an appropriate missing or removed status when no useful replacement exists.
How long until search results update?
There is no fixed guarantee. Keep redirects and consistent signals available while crawlers revisit the URLs.