A website redesign is one of the few moments where a business can lose years of accumulated SEO value in a single afternoon. Not because redesigns are inherently risky, but because most teams treat SEO as an afterthought rather than a workstream that runs alongside design and development from day one.

The good news: migration-related traffic loss is almost entirely preventable. It happens because of a small, predictable set of mistakes — not bad luck or unavoidable algorithm sensitivity. This checklist covers what to do before, during, and after a redesign to come out the other side with your rankings intact.

What Counts as an "SEO Migration"?

Any of the following qualifies as a migration event and needs an SEO plan: a full website redesign, a platform change (e.g. moving from a custom build to Shopify or WordPress), a domain change, a URL structure change, or a move from HTTP to HTTPS. Each carries similar risk, and the same core checklist applies to all of them.

Key Principle

The redirect map is the single most important deliverable of any migration. Every other mistake on this list is recoverable with effort. A missing or incorrect redirect map is the one failure that directly and immediately breaks the connection between your old rankings and your new site.

Before Development Starts

Crawl and export the full existing site. Before a single line of new code is written, run a complete crawl of the current site (Screaming Frog or Sitebulb) and export every indexed URL, its title tag, meta description, H1, and current organic traffic and rankings. This becomes your baseline and your redirect source list.

Build the URL redirect map first, not last. Map every existing URL to its new equivalent before development begins. If a page is being removed with no direct replacement, decide now whether it redirects to the closest relevant category or is retired with a 410. Waiting until launch week to build this map is the most common cause of migration failures.

Document what content must be preserved. Identify which pages currently drive meaningful organic traffic and flag their core content (headings, body copy, structured data) as must-preserve, even if the visual design changes completely around it.

During Development

Build on a staging environment with noindex. Ensure the staging site is blocked from indexing (via noindex meta tag or password protection) so Google doesn't accidentally crawl and index a duplicate, incomplete version of your site before launch.

Preserve internal linking structure. If your new navigation or site architecture changes significantly, make sure high-value pages that previously received strong internal link equity continue to receive it in the new structure. A redesign that buries a previously prominent category three clicks deep will often see that category's rankings decline even with a perfect redirect.

Carry over structured data. Schema markup (Product, Article, FAQPage, Organization, etc.) is easy to lose entirely when a site is rebuilt on a new platform. Audit what schema currently exists and ensure equivalent markup is implemented on the new site before launch.

Launch Week Checklist

Check Why It Matters
All 301 redirects are live and tested Test a sample of at least 20-30% of redirects manually; don't assume a bulk redirect rule worked correctly for every edge case.
Robots.txt allows crawling A staging-environment robots.txt that blocks all crawlers is frequently pushed to production by accident, silently deindexing the entire site.
New sitemap.xml is submitted Submit the new sitemap in Google Search Console immediately at launch to accelerate re-crawling of the new URL structure.
Canonical tags point to the correct new URLs Leftover canonical tags pointing to old or staging URLs can prevent the new pages from being indexed correctly.

After Launch: Monitoring

Migration risk doesn't end at launch — the first 2-4 weeks require active monitoring. Watch Search Console's Coverage report daily for a spike in 404 errors or "Discovered — currently not indexed" pages, which signal redirect or crawlability problems. Track rankings for your top 20-30 previously-ranking keywords weekly, and compare organic traffic week-over-week against the pre-migration baseline you captured earlier.

If you see a sharp, unexpected drop, the fastest diagnostic step is almost always: pick 10 of your previously top-performing URLs, check whether they resolve correctly (200 status, correct content, correct canonical), and check whether they're indexed in Search Console. Most post-migration issues trace back to one of these two checks.

What Should You Never Do During a Migration?

  • Never change URLs and content and design all at once without a redirect map. Changing everything simultaneously with no mapping makes it nearly impossible to diagnose what caused any subsequent ranking change.
  • Never redirect everything to the homepage "to be safe." Google treats mass homepage redirects as soft 404s and passes minimal ranking value — redirect to the closest relevant content match instead.
  • Never skip testing redirects before launch. A redirect rule that works for 95% of URLs but breaks on trailing slashes, query parameters, or case sensitivity can silently 404 a meaningful chunk of your previously ranking pages.
Share this article:
D
Deepti SEO Consultant

Deepti has managed website migrations and redesigns across custom builds, WordPress, and ecommerce platforms, with a focus on zero-traffic-loss execution.

Frequently Asked Questions

Not inherently, but redesigns are one of the most common causes of sudden traffic loss because URLs, content, and internal linking often change without a documented SEO migration plan. A redesign that keeps URLs stable, or redirects changed URLs correctly, and preserves the content that was ranking, typically sees little to no negative impact.
Only if there's a clear reason to — a new URL structure, a change in domain, or fixing an existing problem. Every changed URL requires a 301 redirect to preserve rankings and backlink equity, and every redirect adds a small amount of risk if implemented incorrectly. If a URL doesn't need to change, leave it as is.
A well-executed migration with complete redirect mapping often shows minimal disruption, with rankings stabilising within 2-4 weeks as Google recrawls and re-indexes the new URLs. A poorly executed migration — missing redirects, changed content, broken internal links — can take 3-6 months or longer to recover, and some lost rankings never fully return.
Yes, wherever a genuinely equivalent page exists. Redirect each old URL to its closest content match on the new site — not to the homepage. Mass-redirecting everything to the homepage is treated similarly to a soft 404 by Google and passes very little ranking value forward.
It's a reasonable precaution but not a substitute for proper testing. Launching during a lower-traffic window gives you more room to catch and fix issues before they affect a large volume of visitors, but the real risk reduction comes from thorough pre-launch QA — crawling the staging site, verifying redirects, and checking indexation settings — not from the day of the week.
Not creating a URL-to-URL redirect map before development starts. Teams frequently build the new site first and only think about redirects the week of launch, by which point old URLs and their exact mapping to new pages have often been forgotten or lost. The redirect map should be one of the first documents created in any redesign project, not the last.