Website migration SEO: protect URLs, crawl access, and measurement

Website migration SEO starts with one question: will the public URLs change? Moving the same site to another host is different from changing its domain, paths, or content structure. The first task is service continuity; the second also requires a reliable map from old pages to their replacements.

No migration checklist can guarantee unchanged rankings. It can reduce avoidable problems such as missing pages, broken redirects, blocked crawling, and inconsistent canonical URLs. Preserve evidence from the old site so a later traffic change can be investigated rather than guessed at.

Classify the move

Google publishes separate guidance for hosting changes without URL changes and moves that change URLs. Choose the checklist that matches the change, rather than adding redirects to a host-only move that keeps every address intact.

Save a baseline you can compare later

Collect the current URL inventory, sitemap, important search landing pages, analytics configuration, and recent search performance. Include pages receiving referrals or conversions even if they have little search traffic. Save current titles, canonical destinations, indexing directives, and status codes for representative templates.

Then label each URL: keep, move, combine, or remove. Assign an owner to unresolved destinations. A migration spreadsheet containing hundreds of blank new-URL cells is not ready to launch, even if the new home page looks finished.

Separate measurement changes from site changes. If the analytics property, consent behavior, or conversion event changes on launch day, document it. A sudden analytics drop can be a tracking failure; search impressions, server logs, and actual enquiries help distinguish the possibilities.

Map changed URLs to relevant destinations

Google’s redirect documentation recommends permanent server-side redirects when content permanently moves; 301 and 308 are the relevant permanent HTTP statuses. Point directly to the final destination where practical, rather than creating a chain through several historical addresses.

For an old service page, use the corresponding new service page. If two genuinely overlapping articles are combined, the consolidated article can be an appropriate destination. If content is removed with no relevant replacement, plan the correct missing-page response instead of redirecting every request to the home page.

Google’s site-move guidance warns that irrelevant mass redirects can be treated as soft 404s and recommends keeping redirects for at least a year. Budget for continued control of the old domain and whatever serves those redirects. An expired old domain cannot reliably help returning visitors find the new site.

Review launch settings as a separate task

A staging site may intentionally block indexing, use a temporary domain, or contain placeholder links. Before launch, check the final hostnames in canonical tags, internal links, structured data, image URLs, and the sitemap. Review both robots.txt and page-level indexing directives.

Protect private staging environments with appropriate access controls. A robots.txt rule is a crawler instruction, not access control. Keep a short list of staging-only settings so removing a password does not leave a forgotten noindex on the production pages.

1. 01 Before Inventory URLs, record a baseline, and review the destination.
2. 02 Launch Connect traffic, activate required redirects, and check crawl settings.
3. 03 After Inspect failures and search data, then fix the specific cause.

Check the public site immediately after cutover

• Open important old URLs and verify their final destinations and status codes.
• Check a sample of new pages from each template and content type.
• Confirm images, downloads, navigation, forms, and checkout still work.
• Verify the public sitemap contains intended canonical URLs.
• Review server errors, unexpected missing pages, and redirect loops.
• Confirm search-console access and submit the appropriate sitemap; use any move-specific tools only where their requirements apply.

For a host-only move, keep the old environment available while the DNS transition settles and check logs on both sides. For sites that accept orders or submissions, reconcile data written during that overlap.

Investigate changes without undoing everything

Compare affected pages and queries with the baseline. A whole-site crawl block, a broken directory of redirects, and a normal change in demand produce different evidence. Fix the identified cause and record the date. Repeated broad changes make it harder to determine what helped.

Google notes that search visibility can fluctuate as a move is processed. Avoid promising a fixed recovery day or attributing every change to the new host. A controlled migration gives you a clearer path to diagnosis, with fewer unrelated changes competing for an explanation.