Identify the kind of move before making a checklist
Changing hosting while keeping every URL is different from changing a domain or rewriting the entire path structure. If addresses change, old bookmarks, internal links and search results must lead somewhere appropriate. In a fictional example, a company changes “/services/advice.html” to “/advice/”, while an older brochure retains its address. List that distinction before launch. Testing only the new home page misses the routes that real visitors might have saved or followed from another website.
Inventory the important old URLs. Use an existing sitemap, a crawl of the current site, navigation and available traffic records, without guessing visitor numbers. Mark pages associated with requests, downloads, useful external links or other business value. Record a proposed new destination and a reason for each. If a service has ended, a closely related overview might help visitors, but sending every old URL to the home page often does not. Google Search Central explicitly advises against redirecting many old URLs to one irrelevant destination.
Make the content decision before the redirect rule
For each page, decide whether its content remains, merges with another page, is replaced or disappears. Check whether the target meets the expectation created by the old address. Similar topics do not automatically make two pages interchangeable. If pages merge, record which information survives and which is intentionally retired. This is an editorial choice before it becomes a server instruction. Technical SEO cannot make an unrelated destination meaningful merely by adding a redirect.
A useful worksheet has six columns: old URL, new URL, content decision, redirect behavior, owner and test result. Add an open status for cases still being discussed. In the fictional company, the old advice page receives a permanent redirect to “/advice/”. A past event page has no invented current replacement. The team can keep it as an archive or remove it deliberately. The worksheet also supports recovery: when a route behaves incorrectly, people can see what was intended and which mapping changed.
Test privately, then switch the public route
Build and review the new output before making it public. Compare navigation, forms, files, languages and mobile behavior with the agreed requirements. Development copies are sometimes blocked from crawling or marked “noindex”; Google warns that these settings must be checked when the replacement becomes public. A successful request to the home page does not show whether a particular article, document or language page is available. Test both actual old URLs and the proposed new destination pages.
Prepare a recovery path. Save the previous site version, redirect configuration and any data needed to restore service, and name the person who can decide to roll back. Recovery is not always a single click, especially if forms, databases or domain settings change at the same time. Reduce simultaneous changes where possible. If a migration also rewrites every article, diagnosing an unexpected drop becomes harder because content and address changes are mixed together.
Check signals after the switch
For a lasting address change, use appropriate permanent HTTP redirects such as 301 or 308. Update internal links so they point straight to the new pages. Inspect the canonical URL and language alternatives of important destinations. The new sitemap should contain the intended canonical URLs and agree with navigation. Google documents these as signals and discovery aids. None is a promise of a particular position in search results, and a sitemap submission does not make every URL indexed immediately.
Use real HTTP requests to check the mapping. Does an old page reach the intended new page? Are there needless redirect chains? Does the destination return the expected content? Focus first on pages that previously supplied useful entrances or requests. After launch, inspect error pages, server logs and available indexing reports. Compare them with a recorded baseline, while noting other changes such as seasons or campaigns. A short term movement in a chart alone cannot prove that the migration succeeded or failed.
Separate expected processing time from fixable errors
Google explains that crawling and processing a large site move takes time and that search rankings may fluctuate temporarily. This is not a reason to wait through a known broken redirect, blocked target or missing document. Distinguish concrete technical failures from shifts whose cause has not yet been established. Keep a dated record of what was changed and when. It will make later investigation more reliable than a story reconstructed from memory after the results are known.
For a practical first pass, select ten important old URLs. Open each one, choose the closest meaningful new destination and note what a visitor expects there. Repeat those ten journeys after launch, then expand the check to the rest of the inventory. If there is no useful new destination, do not fabricate one just to fill the worksheet. A careful migration helps visitors reach appropriate content and gives the team a way to detect and repair mismatches. Whether and when search systems process the full move remains a separate observation.
Common questions
Is a new sitemap enough for a move?
No. Test relevant redirects, direct internal links, reachable destination pages and their canonical URLs. A sitemap assists discovery; it cannot replace the mapping or a functional check.
Does a traffic drop prove a migration error?
Not by itself. First look for specific failures such as blocked pages or wrong destinations. Then compare the timeline with the baseline and other changes before attributing a cause.