Website Migration SEO Checklist: Move Your Site Without Losing Rankings

A redesign or replatform is the riskiest moment in a website's SEO life. Search engines have spent months or years learning your URLs, and a careless launch makes them forget it overnight. The good news is that nearly every traffic drop after a migration comes from a short list of preventable mistakes. This checklist walks through them in the order you should tackle them.

Benchmark and crawl the old site first

You cannot protect what you have not measured. Before any work on the new site, capture a baseline you can compare against later.

• Crawl the live site with a crawler and export every indexable URL with its title, description, headings, canonical and status code.
• Export top pages by clicks and impressions from Google Search Console, plus the queries behind them.
• List pages with external backlinks, because those URLs carry authority you must not break.
• Record organic sessions, conversions and Core Web Vitals so you can judge the result honestly.
• Save a copy of robots.txt, the XML sitemap and your structured data templates.

Build a one-to-one 301 redirect map

Every old URL that has traffic, links or rankings needs a permanent 301 redirect to its closest equivalent on the new site. Google's guidance on site moves with URL changes is explicit that redirects are the core signal.

1. Match old and new URLs in a spreadsheet, one row per URL, based on content rather than guesswork.
2. Point each URL to the most relevant page. Redirecting everything to the homepage is treated as a soft 404 and wastes the equity.
3. Avoid chains. A to B to C slows crawling, so redirect A straight to C.
4. Include URL variants: with and without trailing slash, http and https, www and non-www, and uppercase paths.
5. Retire pages with no equivalent by returning 404 or 410, not by redirecting them to unrelated content.
6. Test the whole map with a crawler in list mode before launch, then again after.

Keep redirects in place for at least a year, and longer for URLs with strong backlinks.

Preserve on-page signals and set canonicals

Rankings depend on what is on the page, so migrate content faithfully before improving it. Carry over titles, meta descriptions, heading structure, image alt text, internal links and structured data, and change one thing at a time so you can attribute any shift. Give every indexable page a self-referencing canonical tag with the absolute final URL, as described in Google's documentation on consolidating duplicate URLs.

The classic launch-day disaster is a staging site that was set to noindex or blocked in robots.txt and goes live that way. Make removing those blocks an explicit checklist item with a named owner.

Sitemap, robots.txt and Search Console

• Generate a new XML sitemap that lists only canonical, indexable, 200-status URLs, following the sitemap guidelines.
• Reference the sitemap in robots.txt and confirm that nothing important is disallowed.
• Verify the domain property in Search Console so you see every protocol and subdomain.
• Submit the sitemap at launch, then inspect key URLs and use the request indexing option for the most important ones.
• If the domain itself changes, use the Change of Address tool after redirects are live.

Requesting indexing is a nudge, not a command, and Google documents the limits in its page on asking Google to recrawl URLs. Redirects and a good sitemap do the real work.

Special case: migrating from WordPress to Next.js

Moving from WordPress to Next.js can improve speed and flexibility, but it changes how URLs, metadata and redirects are produced, so plan these items deliberately. Our comparison of Next.js vs WordPress explains when the move makes sense.

• Keep the URL structure identical wherever possible, including slugs, category paths and the trailing slash behaviour, so fewer redirects are needed.
• Declare redirects in configuration. Next.js supports permanent redirects in its config for hundreds of rules, and pattern-based rules for whole sections such as old category paths.
• Generate metadata in code. Titles, descriptions, canonicals and Open Graph tags must be produced for every route, since you lose the SEO plugin that did it for you.
• Rebuild the sitemap and feeds programmatically, and redirect the RSS feed if people subscribe to it.
• Handle media URLs. Old wp-content/uploads image URLs may have image-search traffic, so redirect or keep serving them.
• Recreate forms, comments and redirects for old shortlinks, which plugins used to handle silently.

Also check how the new pages are rendered. Content that appears only after client-side JavaScript runs is indexed later and less reliably, so prefer static generation or server rendering for anything you want to rank. Open the page source and confirm that headings, body text, canonical tags and structured data are present in the initial HTML, then use the live test in Search Console's URL Inspection to see what Google actually renders.

Finally, rehearse the launch on a staging copy that is protected with a password rather than only noindex. Run the redirect map against it, compare crawl exports between old and new, and fix every mismatch in titles, headings and canonicals while mistakes are still private.

Launch day and the first 90 days

Launch early in the week so problems can be fixed while the team is available. Immediately crawl the live site, confirm key redirects return a single 301, check that canonicals and the sitemap are correct, and watch the server logs and the Search Console crawl stats for spikes in errors.

Expect some fluctuation for several weeks as pages are recrawled. Compare clicks and impressions with your baseline weekly, review the Pages report for newly excluded URLs, and fix 404s that show up with inbound traffic. If rankings have not recovered after a couple of months, audit redirects and rendering first.

We handle redirects, indexing and monitoring as part of every relaunch, and our SEO service can audit a planned migration before you commit. To discuss yours, contact us.

Share:XLinkedInWhatsApp