A Website Migration SEO Checklist With a URL-Level Rollback Plan

TL;DR

• Build a URL-level inventory and destination map before changing domains, paths or platforms.
• Test content, redirects, canonical URLs, links and media on representative pages before the release.
• Define who can pause or roll back the migration and which failures justify that decision.
• Verify the public site after deployment and monitor old and new URLs rather than judging the move from the homepage alone.

Define what is actually changing

A migration can change the domain, URL paths, hosting, CMS, design or several of those at once. Write down the intended changes and the parts that should remain stable. This gives the team a concrete scope to test.

For example, moving articles from /blog/ to /blogs/ is a URL change even if the domain and design remain the same. Replacing a CMS while preserving every public URL creates a different set of risks.

Avoid bundling unrelated content rewrites into the same release unless they are necessary. A narrower change is easier to compare with the previous site and easier to recover if something fails.

Create the URL mapping before implementation

Inventory the current public pages using the site, sitemap and available traffic or link evidence. Record each old URL, its intended new URL and the reason for the mapping.

Use an explicit outcome for every important page: preserved, moved, merged or intentionally removed. Do not map unrelated pages to the homepage merely to avoid an error response. The destination should make sense to a person following the old link.

Add an owner and verification status to the mapping. A spreadsheet with unresolved destinations is a planning document, not a release-ready redirect specification.

Preserve the content that matters

Check titles, body sections, tables, images, captions, metadata and structured content. A successful import can still lose material when the new renderer does not support the old document format.

Choose representative pages that exercise the site's features: a long article, a table, a list, an image-heavy page, an older post and any special landing-page template. Compare them with the old site before approving the migration.

Keep a recoverable export or backup of the source content. If the import changes identifiers or slugs, preserve the mapping so an editor can trace an old page to its new record.

Test redirects and canonical destinations

Google's site-move guidance recommends a URL mapping, permanent redirects for moved pages, updated internal links and a new sitemap. It advises keeping redirects for at least a year in general and notes that search visibility can fluctuate during a move.

Turn that guidance into checks for your own mapping. Request each important old URL, follow the redirect and confirm that the final page is the intended replacement. Look for loops, chains, missing routes and destinations that still reference the old address.

Use the canonical-versus-redirect guide when the implementation mixes duplicate handling with actual moves. These mechanisms should reflect the page's intended behavior.

Define release and rollback criteria

Agree in advance on failures that should stop the release. Examples include widespread missing articles, inaccessible images, broken authentication for required public content, or incorrect redirects on important landing pages.

Assign someone who can make the decision and someone who can execute the recovery. Record which deployment, database snapshot and routing configuration would be restored. A rollback plan that says only “revert the code” may be incomplete if content or DNS changed too.

Also decide what does not automatically justify rollback. A brief reporting delay or an expected period of search volatility should be evaluated differently from a public site that returns errors.

Use a release checklist with evidence

Keep the evidence near the release record so the team can distinguish an assumed pass from an observed one.

Verify after deployment, not only in preview

Open the production hostname and repeat the critical checks. Preview success does not establish that production DNS, caching, environment configuration and content delivery behave the same way.

Check more than the homepage. Visit old deep links, newly moved articles and later archive pages. Confirm that public assets do not depend on an authenticated preview session.

Review pagination and the sitemap together so the full library remains discoverable after the move.

Monitor and close the migration deliberately

Track public errors, redirect failures and unexpected changes in important page groups. Compare old and new URLs using a consistent reporting scope, and record subsequent fixes with their dates.

Keep the migration open until the agreed technical checks pass and ownership of ongoing monitoring is clear. Search performance may require longer observation than the deployment itself.

When moving a RankWin-connected blog, preserve the configured public path and verify the site's renderer against the published content. The custom integration guide is a useful starting point, but the final evidence must come from the actual production URLs.