Website redesign SEO migration checklist: protect visibility while the site changes

Before changing templates or URLs, capture the existing state. Export the current crawl, XML sitemap, Search Console landing pages and queries, analytics landing-page conversions, backlink targets and all known redirects. Record pages that receive qualified enquiries even if they are not the highest-traffic pages.

Classify each existing URL: keep unchanged, improve in place, consolidate into another page, replace with a new URL, or remove without replacement. This decision should be based on intent and value rather than design preference. A page may look dated and still carry search signals that should be preserved.

Take a baseline of important metrics before launch: organic clicks, impressions, top landing pages, conversions, index coverage, Core Web Vitals and important ranking groups. The purpose is not to promise that every metric stays flat; it is to make unexpected losses visible and diagnosable.

A redesign is an opportunity to simplify duplicate or confusing pages, but consolidation should be deliberate. Map each important search intent to one canonical destination. If two old pages answer the same decision, a stronger combined page may be appropriate. If they serve different stages or services, merging them can damage relevance.

Keep navigation and internal links aligned with the new hierarchy. High-value service pages should not become buried several clicks deeper because the new menu is visually cleaner. Breadcrumbs, service hubs, related resources and contextual links all help users and crawlers understand relationships.

Do not create large batches of near-identical city or sector pages to make the new site feel bigger. New URLs should exist because they solve a distinct user need and can contain distinct information, proof or local relevance.

Compare old and new pages for title, meta description, H1, main copy, images and alt text, internal links, canonical, robots directives and structured data. The new copy does not have to be identical, but important relevance and proof should not disappear accidentally.

Check that CMS defaults are not overwriting page-specific metadata. Validate that only one canonical is present. If schema is generated both globally and on individual pages, confirm entity IDs are consistent and that the markup reflects visible facts.

For JavaScript builds, inspect the rendered output and network behaviour. Lazy loading should not prevent meaningful content from being available. Forms, CTAs and navigation must function with real production APIs. A migration can preserve rankings and still fail commercially if enquiry tracking or lead routing breaks.

Immediately after launch, crawl the production site and test a sample of every redirect pattern. Verify the sitemap, robots.txt, canonical host and index directives. Inspect the highest-value URLs in Search Console and compare the rendered page with what users see.

Over the following weeks, watch organic clicks and impressions at page and query level, not only site-wide totals. A site can look stable overall while a commercial service cluster falls sharply. Check crawl errors, excluded URLs, soft 404s, duplicate canonicals, structured-data errors and Core Web Vitals.

Expect some recrawling and reassessment after substantial changes. Avoid reacting to one day of volatility by reversing the architecture. Prioritise clear technical defects first, then investigate whether important content, internal links or intent changed. Keep the pre-launch baseline and migration inventory until performance has stabilised.