SEO Migration Audit: What to Check Before, During and After a Redesign

Why migration audits matter

When a client tells me they are redesigning, my first question is not about colours or layout. It is "what is changing besides the design?" Google treats a move that keeps your URLs, such as a new host or CDN, differently from one that changes them, and its documentation covers each case separately. A visual redesign usually sits in between: URLs may stay, but templates, navigation, content blocks, internal links and scripts change underneath them.

That is why I treat every redesign as an SEO migration. The audit has one job: make sure nothing that earns visibility, links or leads is lost by accident. I run it in three phases, and the work done before launch decides most of the outcome.

Before launch: inventory and baseline

Build a complete URL inventory

Google's site-move guidance says to map the current URLs to their corresponding new ones, and to find old URLs from several sources: sitemaps, server logs, analytics, Search Console and the CMS itself. I add a crawl of the live site. Include images, videos, PDFs, scripts and stylesheets that have their own URLs and links. The Sitemap-to-URL List Converter turns a sitemap into a clean list in a moment.

Add value to every row

For each URL record the organic clicks from Search Console, the number of external links, the conversions or key events from GA4 and the template it uses. This turns a list of 3,000 URLs into a priority order: pages that earn traffic, links or leads need careful one-to-one handling; pages that earn nothing can often be merged or retired.

Capture a baseline you can compare against

• Organic clicks and impressions by page group from Search Console.
• The number of indexed pages and the main Page indexing statuses.
• Key events and conversions attributed to organic search in GA4.
• Core Web Vitals for the main templates.
• A full crawl export, saved with the date.

Without a baseline you cannot tell a real loss from a reporting change. This is the step clients are most tempted to skip, and the one I insist on.

Decide what to keep, merge or remove

A redesign is the natural moment to prune, but be careful. Content that ranks should keep its substance: the same topics, headings and answers, even if the layout changes. Where two pages overlap, merging them with a redirect is fine; Google accepts consolidating several old pages into one new relevant page. Where content is gone with no replacement, return a 404 or 410 rather than forcing a redirect.

The redirect map

If the redesign changes any URL, the redirect map is the most important document in the project. I build it as a spreadsheet with the old URL, the new URL, the redirect type and a note on why that destination was chosen. The Redirect Mapping Tool proposes matches with a confidence score, and I review every row by hand.

• Use server-side permanent redirects. Google recommends 301 or 308. Client-side redirects are a last resort.
• Redirect straight to the final URL. Google advises keeping chains short and follows up to 10 hops, so an old URL should not pass through two or three others on the way.
• Match intent, not just words. The destination should be the page a visitor looking for the old one would actually want.
• Do not redirect many unrelated URLs to one page, such as the homepage. Google warns that this can confuse users and may be treated as a soft 404.
• Use 404 or 410 for pages with no equivalent. Google advises this for permanently removed content.
• Update the links you control. Internal links, canonicals, hreflang annotations and sitemaps should point to the new URLs directly, not rely on redirects.

When the map is ready, generate server rules with the Redirect Rule Generator for your platform and test them in staging before they touch the live site.

Staging and technical QA

I crawl the staging site as if it were live. The goal is to catch every problem while it costs a developer an hour, not after launch when it costs traffic. Protect staging from search, but remember the protection must come off cleanly. Google recommends testing in a restricted environment, and I put staging behind a password, since that blocks visitors and crawlers alike. A robots.txt Disallow alone does not guarantee a page stays out of the index, because a URL that other pages link to can still be indexed.

The SEO Migration Redirect Checker tests hundreds of old URLs at once for 301s, chains, loops, wrong destinations, 404s and noindex, and the Canonical URL Checker covers the canonicals.

Launch day validation

1. Remove the staging controls. Take off noindex rules, robots.txt blocks and passwords. Google's guidance specifically says to remove migration-only noindex and robots.txt blocks, and to make sure production robots.txt reflects what should be blocked.
2. Run the full redirect list on the live site. Not a sample. Check the status codes, the destinations and the speed.
3. Inspect key pages with the URL Inspection live test to confirm Google can fetch and render them.
4. Submit the new sitemap in Search Console and remove the old one. Google notes you may see warnings about the old sitemap's redirecting URLs, and that these are normal and can be ignored.
5. Set up both properties. Verify the old and new sites in Search Console. For a move between domains or subdomains, use the Change of Address tool. Google says that tool is not needed for HTTP to HTTPS, for www versus non-www on the same domain, or for path changes within a domain.
6. Check tracking. Confirm analytics tags and key events work on the new pages.
7. Check capacity and access. Google may crawl the new site heavily after launch, so the server needs the capacity. Make sure firewalls and bot protection are not blocking Googlebot.
8. For hosting moves, lower the DNS TTL at least a week in advance, keep Search Console verification files in place and keep the old host running until its traffic reaches zero.

Small and medium sites are best moved all at once, according to Google; large sites can move in sections. Both approaches need the same checks.

After launch: monitoring

Review the same indicators weekly for the first month and compare them with the baseline. Expect movement: Google notes that rankings may fluctuate while pages are recrawled and reindexed, that for a medium-sized site it can take a few weeks or more for new URLs to appear, and that a temporary drop in Googlebot's crawl rate right after launch is normal.

Keep the redirects in place for as long as possible. Google's guidance is generally at least one year, and permanent redirects do not cause a loss of PageRank. If something is wrong, fix it quickly and record it. When post-launch problems look like a flood of errors, use the 12 audit errors that actually matter to sort them, and if key pages fall out of Google, the indexing diagnosis guide traces the cause.

The mistakes I see most often

• Launching with staging blocks still on. It happens even on well-run projects, because the setting lives in a place nobody thinks to check. The same risk applies to any template release after launch, and How a Single Deploy Can Wipe Out Your Organic Traffic covers the checks and rollback rules.
• Redirecting everything to the homepage because a proper map felt like too much work.
• Internal links still pointing at old URLs, so every click goes through a redirect.
• Removing content during the redesign that was the reason a page ranked.
• Forgetting non-page files, such as images and PDFs that earn links and traffic.
• Old URLs left in the sitemap or in canonical tags.
• No baseline, so nobody can say whether traffic really fell.
• Analytics broken at launch, which hides the damage until it is serious.

A project from my own work

On a redesign and international expansion project I delivered, the decisions that mattered most were made before any design existed. The old site served only one country and was hard to use, so I planned a new architecture of two dedicated websites for two markets, and worked with the design and development teams so search requirements were in the brief rather than a fix after launch. The new site reached over 4,500 monthly visitors in its first 50 days. You can read the details in the case study. It is one project, and a result like that depends on the brand, the market and the starting point, so it is not a promise for your site.

Frequently asked questions

Is a redesign the same as a migration?

Not always, but it carries the same risks. A redesign that keeps every URL is lower risk than one that changes them, yet templates, content and links still change. I audit both the same way and add the redirect work only when URLs change.

How long will traffic dip after a redesign?

There is no fixed answer. Google says rankings may fluctuate while it recrawls and reindexes, and that for a medium-sized site new URLs can take a few weeks or more to appear. A well-prepared move can show a small, short dip; a careless one can take much longer to recover.

Do I need the Change of Address tool?

Only for a move from one domain or subdomain to another. Google says it is not needed for HTTP to HTTPS, www versus non-www on the same domain, or for changes to paths within a domain.

How long should I keep the redirects?

As long as possible. Google's guidance is generally at least one year, and redirects can stay in place indefinitely.

Should I redirect all old pages to the homepage?

No. Redirect each old URL to its closest equivalent. Google warns that sending many old URLs to one irrelevant page may be treated as a soft 404. If a page has no equivalent, return a 404 or 410.

Can I migrate in phases?

Large sites can move in sections, according to Google, while small and medium sites are best moved all at once. A phased plan needs a clear rule for which URLs move when, and a tested redirect map for each phase.

Is this relevant if I am only moving to a new platform?

Yes. A platform change almost always changes URL patterns, templates and rendering. For online stores, the extra risks are covered in SEO for Nepali Ecommerce, and the audit-type comparison shows where a pre-launch audit fits among the others.

Sources and further reading

Technical statements about Google in this guide are based on the pages below, checked on 17 October 2026.

1. Site moves with URL changes: redirects, mapping, sitemaps, Change of Address tool, timing
2. Site moves without URL changes: testing, DNS TTL, removing blocks, monitoring
3. HTTP status codes, and network and DNS errors: how Google treats 301, 302, 404 and 5xx
4. Crawl budget management for large sites: 404 and 410 for removed pages, redirect chains
5. How to specify a canonical URL: canonical signals after a move
6. Build and submit a sitemap: new sitemap and lastmod
7. URL Inspection tool: live tests on key pages
8. Crawl Stats report: response codes and host status after launch
9. Core Web Vitals: LCP, INP and CLS targets