Website Migration SEO Checklist: Redesign Without Losing Traffic

Ofcom’s Online Nation 2025 report found that Google Search is used by 82 per cent of UK adults, which shows what is at stake if a migration costs you search visibility.

A redesign or domain move does not have to cost you search traffic, but it will if URLs change without a plan. This checklist splits the work into before, during and after launch, with the redirect mapping, staging rules and monitoring routine that protect your rankings. Follow it in order and you will also have a rollback plan if something goes wrong.

Why migrations lose traffic

Google ranks URLs, not brands. Each URL has built up its own history: links pointing at it, internal links, how searchers respond to it and what it is understood to be about. When you change a URL, that history only carries over if you tell Google, clearly and permanently, where the page has gone and the new page is a genuine equivalent.

Most traffic drops after a migration come from a short list of causes:

• Old URLs returning 404 because nobody mapped them.
• Everything redirected to the homepage instead of matching pages.
• The staging site’s noindex tag or robots.txt block copied to the live site.
• Content cut, merged or rewritten during the redesign, so the new page no longer matches what ranked.
• Internal links, canonicals and sitemaps still pointing at old URLs.
• Several big changes at once (domain, structure, content, platform), making it impossible to tell which one caused a problem.

Every step below exists to prevent one of those.

Know which kind of migration you are doing

If you can, avoid combining types. A redesign and a domain move launched together makes diagnosis much harder. Where business reasons force a combined move, the checklist still applies, but expect to spend longer checking afterwards.

Before launch: the preparation checklist

Build a complete URL inventory

Collect every URL that currently exists or has value. Combine these sources into one spreadsheet and remove duplicates:

1. A full crawl of the current live site.
2. Your current XML sitemaps.
3. Pages with clicks or impressions in Search Console over a long date range.
4. Landing pages from your analytics.
5. URLs with external links, from any backlink tool you use.
6. Existing redirect rules, so old redirects are not broken by new ones.

The crawl alone is never enough. Orphan pages with no internal links still get traffic and links, and a crawler will not find them.

Record a performance baseline

Export clicks, impressions and positions per page from Search Console, and save key ranking queries. Without this, you will not be able to prove what changed after launch.

Map every redirect

Add a column to your inventory for the new URL. Each old URL should point to the single most relevant new page. Use these rules:

• One to one wherever a matching page exists.
• Where pages are merged, redirect all of them to the merged page.
• Where a page is retired with no equivalent, redirect to the closest relevant category only if it genuinely serves the visitor. Otherwise let it return 404 or 410.
• Never redirect in bulk to the homepage.
• All redirects should be permanent (301 or 308) and go straight to the final URL, with no chains.

Lock down staging

The new site will sit on a staging server while you build it. Protect it with a password at the server level so that nothing gets indexed. A noindex tag alone is weaker because staging URLs can still be discovered and crawled. Make a written note that the staging protection, any noindex settings and any robots.txt blocks must be removed at launch. On WordPress, that includes the search engine visibility setting covered in the WordPress technical SEO checklist.

Check content parity

Compare important old pages with their new versions. Titles, main headings, body copy, structured data, internal links and images should all have a home on the new page. Redesigns often trim copy for visual reasons; if that copy was why the page ranked, you will feel it. Check that schema markup survived the template change too, as it is frequently lost.

Write the rollback plan

Decide in advance what would make you roll back and how you would do it. Keep the old site and its server config intact for a while after launch. Know who has the access to switch DNS or restore the previous build. A rollback plan you never use costs little; one you need and do not have costs a lot.

During launch: the day-of checklist

1. Remove staging password protection, noindex tags and robots.txt blocks from the live site.
2. Deploy redirects and test a sample from each section of your map, plus your highest-traffic URLs individually.
3. Confirm every redirect is permanent and lands on a page returning 200.
4. Check canonical tags point to the new URLs, not old ones or staging addresses.
5. If you use hreflang, update all alternate URLs to the new addresses and confirm return tags still match.
6. Update internal links in menus, footers and body content so they point directly at new URLs instead of relying on redirects.
7. Publish a fresh XML sitemap of the new URLs and submit it in Search Console.
8. For a domain move, verify the new domain in Search Console and use the change of address tool from the old property. Google documents this process on its Search Central developer site.
9. Update analytics, tag manager and any tracking so you do not lose measurement.
10. Crawl the new site end to end and look for 404s, redirect chains and noindex tags.

Launch at a time when your developer is available for the following days. A Friday evening launch with nobody around on the weekend is a common way to turn a small fault into a large one.

After launch: monitoring for 4 to 8 weeks

Ranking fluctuation after a migration is normal while Google recrawls and reprocesses URLs. What you are looking for is signs that something is broken, not every daily wobble. Plan to monitor closely for 4 to 8 weeks.

First week

• Check the page indexing report daily for new 404s, server errors and pages blocked or excluded unexpectedly.
• Re-crawl the old URL list and confirm every one redirects correctly.
• Watch server logs or crawl stats to confirm Google is fetching the new URLs.

Weeks two onwards

• Compare clicks and impressions by page against your baseline. Investigate any page that has dropped sharply rather than looking only at the site total.
• Check that the new URLs, not the old ones, are appearing in search results.
• Look for pages where Google chose a different canonical from the one you set.
• Keep redirects in place long term. Removing them after a few months throws away the signals they carry.

A migration often surfaces old leftovers too: parameter URLs and thin archives that move across with everything else. If the new site’s indexed count balloons, read the guide to index bloat and how to remove it.

Mistakes I see repeatedly

• Treating the redirect map as a developer task only. Developers know the new structure; whoever owns SEO knows which old pages matter. Both need to sign it off.
• Changing the theme without checking output. Page builders change markup, headings and speed. On Elementor sites, review the points in Elementor SEO technical fixes before launch.
• Forgetting JavaScript rendering. If the new platform renders content with JavaScript, check that Google can see it. The guide to implementing JavaScript SEO explains how.
• Letting the old domain expire. After a domain move, keep the old domain registered and redirecting indefinitely.

If you would rather have someone plan the mapping, test staging and watch the launch with you, migration support is part of my technical SEO consulting.

Questions people ask about website migrations

Planning a redesign or a move and want a second pair of eyes on the redirect map before it goes live? Get in touch for a free audit and I will point out the risks while they are still cheap to fix.