The SEO Checklist for Website Redesigns and Migrations

Why migrations are the riskiest thing you can do to a ranking site

A working site accumulates thousands of small ranking signals over years: indexed URLs, earned backlinks, title tags Google already trusts, structured data it has already parsed. A redesign or platform migration touches all of it at once. Get the technical handover wrong and you are not risking a slow decline, you are risking losing most of that accumulated trust within days of launch.

Before launch: map every URL

Export every indexed URL from Search Console and your analytics, and build a spreadsheet mapping each old URL to its exact new equivalent before a single redirect gets written. This is the single step most redesigns skip, usually because it is tedious rather than difficult, and it is the direct cause of most post-launch traffic collapses.

301 redirects, done properly

• Every old URL that ever earned traffic or backlinks gets a 301, not a 302, redirect to its nearest live equivalent.
• Redirect to the actual matching page, never a blanket redirect of every old URL to the homepage, which destroys the relevance signal the redirect is supposed to preserve.
• Avoid redirect chains. A URL that hops through three redirects before landing dilutes authority and slows every crawl.
• Keep the redirect map live indefinitely, not for a token few weeks, since old backlinks and bookmarks keep arriving for years.

What to preserve exactly

Title tags and meta descriptions that already rank well should migrate unchanged unless there is a specific, tested reason to rewrite them. The same applies to structured data: if the old site had a working Organization graph and article markup, the new site needs the identical entities, not a redesigned version that happens to look different to a crawler. This is squarely technical SEO territory, and it is worth treating as a formal handover item in the project plan rather than an assumption the developer will "keep it the same."

Internal linking patterns matter too. If your highest-authority pages currently link heavily to a specific service page, the redesign needs to preserve that pattern, not reorganise navigation in a way that quietly cuts off the internal links a page was depending on.

Testing on staging before launch

Never validate a migration for the first time on the live domain. Build the new site on a staging URL, blocked from indexing with a site-wide noindex tag and password protection so it cannot leak into Google's index by accident, and test the entire redirect map against it before the switch. Click through a meaningful sample of old URLs, not just the handful someone remembers, and confirm each one lands on the intended page rather than a near-miss.

This single step catches the majority of migration disasters before they become public. A broken redirect discovered on staging costs nothing. The same broken redirect discovered a week after launch has already cost rankings, and the fix arrives too late to prevent the dip that already happened.

Launch day and the first two weeks

Submit the new sitemap to Search Console the moment the site goes live, and check the Coverage report daily for the first two weeks. Watch specifically for a spike in 404s, which usually means a gap in the redirect map, and for a sudden drop in indexed page count, which usually means a robots.txt or noindex tag shipped by accident. Both are common, both are fixable within hours if caught early, and both are effectively unrecoverable in the short term if left for a month.

The honest summary

Nothing here is complicated. What it requires is treating the migration as an SEO project with its own checklist, not a design project that SEO gets bolted onto afterward. Every well-known migration disaster traces back to skipping the URL map, the redirects, or the first two weeks of monitoring, in that order.