Site Migration SEO Checklist: Redirect and Validate URLs

A safe site migration is an inventory and validation job, not just a redesign launch. Keep URLs when there is no good reason to change them. When a URL must move, send it through one direct permanent redirect to the closest useful replacement, update every internal signal, and verify the result at scale.

Google warns that ranking fluctuations can happen while it recrawls and reindexes changed URLs. Good preparation reduces avoidable losses, but it cannot promise a flat traffic line or a fixed recovery date.

Choose the checklist that matches the move

Before launch: preserve a usable baseline

1. Crawl and export the old site

Save a crawl before development replaces the current version. At minimum, export each indexable URL, HTTP status, canonical, title, meta description, H1, robots directives, internal inlinks, depth, and structured-data status. Also retain:

• XML sitemap URLs;
• Search Console landing pages and queries;
• analytics landing pages and conversions;
• pages with external links;
• images, PDFs, and other files that receive traffic or links;
• robots.txt, redirects, and important response headers.

This baseline lets you distinguish a new launch defect from an old issue that already existed.

2. Decide which URLs actually need to change

A new CMS does not require new public URLs. Preserve a clean, useful URL when its page still solves the same task. Changing it creates redirect work, link updates, recrawling, and another failure point without creating value for the visitor.

If old content is being consolidated, use the update, merge, redirect, or delete framework before filling the map. Do not redirect every retired page to the homepage.

3. Build an old-to-new URL map

Use one row per old URL. A practical sheet includes:

old_url,new_url,decision,expected_status,owner,test_result,notes
https://example.com/old-chair,https://example.com/chairs/oak,redirect,301,developer,pending,closest replacement
https://example.com/expired-offer,,remove,410,developer,pending,no replacement

Every redirect destination should answer the same or a closely related need. A discontinued product may have a real successor. An unrelated article does not become relevant because both URLs are in the same spreadsheet.

4. Make the staging site testable but not indexable

Protect staging with authentication or another access control when possible. A temporary noindex rule can be useful on a public test host, but it must be removed from the production release. Do not block crawling with robots.txt and then assume a crawler has validated the pages behind the block.

Test pages, forms, images, downloads, navigation, mobile layouts, analytics, consent controls, and critical transactions. Confirm that the production host will have enough capacity. Google notes that crawl activity can increase after a move because both old and new URLs may be requested.

5. Align the new site's signals

Each new indexable page should return 200, have a self-referencing canonical, remain crawlable and indexable, and appear in the new sitemap. Update internal links, hreflang annotations where used, structured data, Open Graph URLs, and asset paths to the new public URLs.

Use the Article schema guide for article-level entity and date checks. Use the sitemap cleanup workflow to keep redirect sources and noncanonical variants out of the final sitemap.

Launch: turn on direct permanent redirects

Use server-side 301 or 308 redirects for permanent moves when your platform supports them. Point each old URL directly to its final destination. Google can follow redirect chains, but chains add latency and create more places to fail.

old URL --301--> final new URL --200--> self-canonical

Avoid:
old URL --301--> interim URL --301--> another URL --200--> final page

Test the first response, the final status, the final URL, and the destination canonical. A browser reaching a page is not enough. It may have followed a chain, landed on an error template returning 200, or reached a page canonicalized elsewhere.

Use Change of Address only for the right move

Search Console's Change of Address tool is for a move from one domain or subdomain to another. Use it after redirects are working and both properties are verified. Do not use it for HTTP-to-HTTPS changes or for moving a few paths within the same site. Those moves rely on redirects and updated sitemaps.

For a domain move, verify all relevant variants and follow Google's property requirements. The tool supports the migration process, but it does not repair a broken redirect map.

Post-launch: run a crawl diff immediately

Crawl the public site and test the old URL list against production. Compare the results with the saved baseline.

Monitor recovery without inventing an SLA

Track both old and new properties where relevant. Watch server logs, Page indexing, crawl errors, impressions, clicks, and key landing pages. Old URLs should lose activity as new URLs are crawled and shown. Investigate a persistent mismatch, such as old URLs still receiving internal links or new URLs returning unexpected statuses.

Google says a medium-sized site move can take a few weeks to be noticed, while larger sites can take longer. That is a general observation, not a deadline. Keep redirects for as long as possible, generally at least one year according to Google's current site-move guidance. For users and old external links, keeping useful redirects indefinitely is often sensible.

Compare equivalent weekly or monthly periods instead of reacting to one day. Separate migration effects from seasonality, campaigns, tracking changes, and wider search updates.

Common migration failures

Redirecting everything to the homepage

This removes the page-level relationship and can be treated as a soft 404. Redirect only to a useful replacement.

Launching production with staging noindex rules

Check the rendered HTML and HTTP headers, not only the CMS setting. Sample templates and crawl the full site.

Leaving old URLs in navigation and sitemaps

Redirects are a safety net for old requests. The new site should link directly to its final canonical URLs.

Judging success only by total sessions

Analytics can break during the same release. Validate tracking independently, then review Search Console and server evidence alongside business conversions.

Sources checked

Google's site-move, redirect, hosting, Search Console, and traffic-drop guidance was verified from official sources on July 26, 2026.

• Google Search Central: site moves with URL changes
• Google Search Central: redirects and Google Search
• Google Search Central: changing hosting without URL changes
• Search Console Help: Change of Address tool
• Google Search Central: debugging search traffic drops