The Website Redesign Checklist — Protect Rankings and Launch Safely

A website redesign is one of the highest-stakes projects a business can undertake online. Done well, it accelerates every commercial outcome the site touches — lead generation, conversions, brand credibility, and search rankings. Done carelessly, it can erase years of accumulated SEO equity in a weekend and generate technical problems that take months to diagnose and fix.

The difference between the two outcomes is almost always process. Businesses that treat redesigns as creative projects — focused primarily on aesthetics, new features, and launch date — tend to discover the hard way that a redesign is also a technical migration with significant risk to existing performance. Businesses that treat it as a structured project with clear phases and defined verification steps achieve both the creative goals and protect the performance they have built.

This is that structured process. Work through every phase before you launch.

Phase 1: Pre-Redesign Audit — Know What You Have Before You Change It

The single most important step in any redesign comes before a single mockup is created: a comprehensive audit of the existing site. You cannot protect what you have not documented.

Traffic and conversion baseline. Export twelve months of data from Google Analytics: your top-trafficked pages, their organic sessions, average session duration, conversion rates by page, and the traffic sources that drive your best conversions. This becomes your benchmark for post-launch comparison. If you cannot answer "what was the organic conversion rate of my top landing page in the six months before redesign?", you will not be able to determine whether the redesign improved or damaged it.

Search performance data. In Google Search Console, export the pages that generate the most organic impressions and clicks, the queries they rank for, and their average position. This is your SEO inventory — the rankings you have built over time that are at risk during migration.

Current URL structure. Export a complete list of all indexed URLs using Screaming Frog or Search Console's Coverage report. Every URL on this list must either be preserved (identical URL retained in the new site) or redirected (mapped to its closest equivalent in the new URL structure with a 301 redirect).

⚠ Gotcha: The most common cause of post-redesign organic traffic loss is broken URLs. When a new site is launched with a different URL structure — changing "/services/web-design" to "/web-design" or restructuring blog URLs — and no redirects are implemented, every incoming link and every saved bookmark points to a 404 page. Google interprets this as the content no longer existing and withdraws the rankings it had assigned to those URLs. A ranking that took eighteen months to build can be destroyed in a weekend launch. The redirect map must be built before development begins, not added as an afterthought after launch.

Phase 2: Define Goals and Success Metrics

A redesign without clear goals is a redesign that cannot succeed, because there is no agreed definition of success. Before any creative brief is written, establish:

What is the primary conversion goal of the site? (Lead form submission, online purchase, phone call, email subscription?)
Which pages or journeys are currently underperforming relative to their traffic? These are the priority redesign targets.
What specific metrics will define success? (e.g., "Increase lead form conversion rate from 2.1% to 3.5% within 90 days of launch")
What must not get worse? (Organic traffic, Core Web Vitals scores, email deliverability from the domain)

These goals should be documented and shared with every member of the redesign team — designers, developers, content creators, and any external agencies. Design decisions made without reference to conversion goals default to aesthetic preferences, which are a poor substitute for commercial outcomes.

Phase 3: Protect Your SEO Through Migration

SEO preservation during a redesign is the most technically complex phase and the one most commonly mishandled. It has four components:

URL mapping. For every URL in your current site inventory, define the destination URL in the new site. If the URL is identical, mark it as preserved. If it changes, write a 301 redirect rule. If the page is being removed entirely, redirect to the most relevant equivalent — not to the homepage. Redirecting everything to the homepage, a common shortcut, passes minimal link equity and sends incorrect signals about the destination content.

Content preservation. The unique content on each page — especially the pages that rank well organically — should be preserved in the new site, even if it is redesigned and reformatted. If a 1,500-word service page currently ranks on page one for a valuable keyword, the new design of that page must retain the substance of that content. Replacing it with a 200-word overview because it "looks cleaner" is a ranking risk.

On-page metadata. Title tags, meta descriptions, canonical tags, structured data markup, and Open Graph tags must be carried forward to the new site. These are not automatically transferred by most CMS migration tools. Verify every important page individually after launch using Screaming Frog or a site audit tool.

Internal links. The new site's internal linking structure should at minimum match the existing structure for all high-priority pages. Lost internal links mean lost PageRank flow to those pages, which can cause gradual ranking decline over the months following launch.

⚠ Gotcha: Redirect chains — where URL A redirects to URL B, which redirects to URL C — are worse than a single direct redirect. Each hop in a chain reduces the amount of link equity that passes through. Three-hop chains pass a fraction of what a direct redirect passes. Old CMS migrations that are redesigned again without cleaning up previous redirects often accumulate multi-hop chains across dozens or hundreds of URLs. Use a crawl tool to audit for chains after launch and replace them with single-hop redirects pointing directly to the final destination.

Phase 4: Performance Benchmarking and Targets

Record your existing Core Web Vitals scores from Google Search Console's CWV report before the redesign begins. These are your baseline. The redesign should be committed to matching or improving these scores, not degrading them in pursuit of visual richness.

Set explicit performance budgets for the new build:

Maximum page weight for key landing pages (a reasonable target is under 1MB total for the first load)
Target LCP under 2.5 seconds on mobile
CLS score under 0.1
Total blocking time under 200ms

These budgets should be written into the development brief, not assessed retrospectively after build. Retrofitting performance into a site built without performance constraints is significantly harder than building to those constraints from the start.

⚠ Gotcha: New website builds almost always include more third-party scripts than the previous site — analytics, marketing pixels, live chat widgets, cookie consent platforms, heat map tools, A/B testing frameworks. Each one adds to page weight, delays rendering, and potentially worsens Core Web Vitals. A launch that adds four new third-party scripts with no corresponding removal of old ones can turn a passing CWV score into a failing one overnight. Audit every third-party script before launch, remove any that are not actively used, and defer the loading of any that can run after the critical path.

Phase 5: Staging Environment Testing

A staging environment is a private, non-indexed copy of the new site where all testing happens before the public launch. Never build directly on the live site. Never launch from local development. Staging is the environment where problems are found and fixed.

The staging site must be blocked from search engine indexing (via robots.txt or a password gate) to prevent Google from indexing incomplete or duplicate content before launch. This sounds obvious but is a mistake made regularly.

Testing on staging must cover:

Every internal link (broken links should return zero)
Every form submission (does it arrive? Does the confirmation message display?)
Every redirect (does the 301 map resolve correctly?)
Core Web Vitals using PageSpeed Insights (test the staging URL directly)
Mobile display across at least two real devices (not just browser simulation)
Accessibility using a tool like axe or Lighthouse's accessibility audit
Structured data using Google's Rich Results Test
Analytics and conversion tracking (fire every event, check it arrives in GA4)

⚠ Gotcha: Analytics tracking gaps are common and consequential. When a new site launches and the GA4 tag is missing from key pages, or conversion events are not correctly configured, you lose data from the highest-intent moments in the customer journey. You also lose the ability to compare pre- and post-launch conversion rates accurately, which makes it impossible to know whether the redesign improved performance. Set up a systematic event-by-event test of your analytics implementation on staging before launch. Treat a missing conversion event with the same urgency you would treat a broken checkout form.

Phase 6: The Launch Protocol

The launch itself should be a managed, monitorable event — not an overnight deploy that you discover has problems the following morning.

Launch during low-traffic hours for your audience. For most UK B2B sites, this means midweek, mid-morning — not a Friday afternoon before a bank holiday weekend when your entire team will be unreachable.

Immediately post-launch, run a live crawl of the new site to confirm redirects are firing correctly. Submit your updated XML sitemap to Google Search Console. Monitor Search Console's URL Inspection tool for any crawling or indexing errors that emerge in the first 24 hours.

Set up a daily ranking check for your top twenty priority keywords for the first two weeks post-launch. Ranking fluctuations in the first few days are normal as Google recrawls the new site. Sustained ranking declines beyond two weeks warrant investigation — typically of the redirect implementation, content changes, or internal linking structure.

Phase 7: Post-Launch Validation

Thirty days after launch, run the full comparison:

Organic traffic vs. the same period in the prior year (accounting for seasonality)
Conversion rates on key landing pages vs. pre-launch baseline
Core Web Vitals field data (this takes 28 days of real-user data to update in Search Console)
Ranking positions for your priority keywords vs. pre-launch positions

Any metric that has materially worsened deserves investigation before the month is out. The earlier a post-launch SEO issue is identified, the faster and more completely it can be remediated. A ranking drop that goes uninvestigated for six months is one that has compounded into months of lost traffic that you will never recover.

A website redesign, executed with this level of discipline, is a genuine competitive advantage. Most of your competitors will launch theirs without a redirect audit, without a performance budget, without staging environment testing, and without post-launch measurement. You now know how to avoid every mistake they are making.