Follow this order and you will come through a redesign with your rankings intact: audit, map, redirect, test, monitor. Before anything else touches your live site, export your crawl data and analytics snapshots so you have a baseline to measure against. Every step after that exists to protect what's already working while you build something better.
TL;DR:
- Export Search Console and GA4 data per indexed URL, crawl URLs and metadata, save sitemaps and robots.txt, and record valuable backlinks before design begins.
- Map every old URL to a destination, use 301 or 308 server side redirects without chains, and keep them active for at least a year.
- Test LCP below 2.5 seconds, INP below 200 milliseconds, and CLS below 0.1 across major page templates, not just the homepage.
- Check coverage, crawl errors, status codes, and top page traffic daily in week one; compare results with baseline and audit at 30 and 90 days.
Table of Contents
- Pre-redesign audit: what to export and save before you touch anything
- Crawl, URL mapping and redirect planning: matching old URLs to new ones
- On-page content, metadata and structured data: what moves and what improves
- Core Web Vitals and performance: the benchmarks worth hitting
- Staging site QA: the checks that catch mistakes before launch
- Launch-day checklist: the tasks that catch regressions fast
- Post-launch monitoring: the 30 to 90 day plan
- What running redesigns teaches you about where they go wrong
- How we support businesses through a website redesign
- FAQ
- Sources
Pre-redesign audit: what to export and save before you touch anything
Think of this stage like taking photographs of a garden before you dig it up. You need a clear record of what's growing well so nothing gets lost by accident.
Start with your performance data. Pull Search Console data per URL, including queries, clicks, impressions, click-through rate and average position, alongside GA4 landing page metrics. These numbers become your "before" picture, and without them you won't know if the redesign helped or hurt.
Next, run a full crawl of your current site. You want every URL, its status code, title tag, meta description, canonical tag and hreflang markup if you use multiple languages. Google's own guidance recommends exactly this: crawl the current site, export all URLs and metadata, and save your sitemaps and robots.txt file before any migration begins.
While you're gathering data, pull a backlink export for your highest-value pages. Mark each page as keep, consolidate, remove or redirect, so there's no ambiguity later about what happens to it.
- Export Search Console and GA4 data for every indexed URL
- Run a full site crawl and save status codes, titles, metas and canonicals
- Pull backlinks for pages with strong link equity
- Save current sitemaps, robots.txt and a full site backup
Pro Tip: Store every export in a dated folder before work begins; you'll want to compare against this exact snapshot at 30 and 90 days post-launch.
Crawl, URL mapping and redirect planning: matching old URLs to new ones
Once you know what you have, the next job is deciding where it goes. This is where a mapping spreadsheet earns its keep. Build one with columns for the old URL, the new URL, the redirect type, the reason for the change and any backlink notes worth flagging.
- List every URL from your crawl export alongside its intended new destination
- Choose 301 or 308 server-side redirects wherever a permanent move is needed
- Avoid chaining redirects (old URL to redirect to another redirect to final page)
- If you're moving domains, set up redirects first, then use Search Console's Change of Address tool
- Verify every site variant, including http, https, www and non-www versions
- Keep redirects live for at least a year and note any intentional 302s separately
- Test with live HTTP checks, then run a follow-up crawl to confirm nothing breaks
Google Search Central is clear on the mechanics here: server-side permanent redirects should be used wherever possible, chains should be avoided, and redirects should stay in place for at least a year to preserve ranking signals. For domain-level moves specifically, Google's site-move documentation recommends configuring redirects before using Change of Address, and checking that all variants of your site are verified in Search Console.
One year is the minimum redirect lifespan Google recommends for preserving signal equity after a URL change.
For large or complex sites, it's often worth testing redirects on a representative subset of pages before rolling the full plan out, though a small sample won't catch every edge case on a genuinely large site.
On-page content, metadata and structured data: what moves and what improves
Your titles, meta descriptions and H1s are doing real work for you right now, so treat them with care during the move. For top-performing pages, migrate the existing metadata directly rather than rewriting from scratch, and keep your keyword targeting consistent unless you have a specific reason to shift it.
Structured data needs the same attention. Carry across your schema markup and rel=canonical tags, then revalidate everything on staging before launch, since a redesign can easily strip schema out without anyone noticing until traffic drops.
- Migrate or carefully rewrite titles, metas and H1s for your top pages
- Carry across canonical tags and schema, then revalidate on staging
- Preserve image URLs where possible and carry alt text across
- Build a content map: page, target keyword, and action (keep, merge or redirect)
- Confirm staging metadata matches your pre-redesign crawl export line for line
Images deserve a second look too. Large, unoptimised media is one of the quickest ways to undo good SEO work, so check load times for your heaviest pages on the new site before launch. A content map keeps this whole process honest: when pages get merged or restructured, it's easy to lose a keyword's home entirely unless you've written down where each one is supposed to live.
Core Web Vitals and performance: the benchmarks worth hitting
Page experience is part of the ranking picture now, and it's one of the easier things to get wrong during a redesign if nobody's watching. The current targets are LCP under 2.5 seconds, INP under 200 milliseconds and CLS under 0.1, according to Core Web Vitals guidance.
Measure these on your representative page templates, not just your homepage, since a product page or blog template often behaves very differently under load. PageSpeed Insights and the Core Web Vitals report inside Search Console both track these metrics over time, which makes them useful for spotting regressions early.
- Benchmark LCP, INP and CLS on each major template before and after launch
- Run PageSpeed Insights checks and watch the Core Web Vitals report in Search Console
- Confirm server capacity, CDN configuration and mobile rendering under load
- Check that robots.txt isn't accidentally blocking CSS, JavaScript or other critical resources
Pro Tip: Fixing one slow template often lifts site-wide Core Web Vitals more than chasing small wins across dozens of individual pages.
Staging site QA: the checks that catch mistakes before launch
Staging is where mistakes are cheap. Before anyone outside your team sees it, confirm the staging environment is noindexed and password protected, since robots.txt alone won't stop pages being indexed; you need noindex tags or password protection for that.
- Confirm meta robots tags are set correctly before you unblock anything
- Crawl and render staging pages to check Googlebot can see JavaScript-driven content
- Verify status codes, canonical tags, hreflang and structured data all look right
- Check internal links point straight to final URLs rather than through a redirect
- Test analytics tracking, event tags, consent banners and every form
- Keep a rollback plan and an offline backup ready before you flip the switch
A staging environment that passes every one of these checks gives you genuine confidence on launch day, rather than a hopeful guess.
Launch-day checklist: the tasks that catch regressions fast
Launch day moves quickly, so keep this list short and work through it methodically rather than trying to check everything at once.
- Confirm redirects are live and test a sample of your highest-value old URLs
- Remove the staging noindex, check robots.txt, and submit your updated XML sitemap to Search Console and Bing
- Verify Search Console is still correctly verified and add an analytics annotation marking the launch
- Smoke-test critical journeys: checkout, contact forms, account logins
- Crawl the live site and compare the results against your pre-launch snapshot
None of these take long individually, but skipping one is how small issues turn into missed revenue a week later.
Post-launch monitoring: the 30 to 90 day plan
The first week deserves daily attention. Check index coverage, crawl errors, any spike in 4xx or 5xx status codes, and traffic on your top pages every single day.
- Run daily checks for the first week: coverage, crawl errors, status code spikes, top-page traffic
- Move to weekly reports, then monthly, comparing clicks, impressions and position against your baseline
- Fix redirect chains and critical errors as soon as they appear, and start outreach to recover lost backlinks
- Schedule a full audit at 30 days and another at 90 days
- Set clear thresholds in advance for when a problem triggers a targeted fix versus a partial rollback
Industry migration guidance notes that temporary ranking fluctuations are normal after a redesign, and recommends exactly this rhythm: structured audits at 30 and 90 days rather than panic at day three.
Pro Tip: Decide your rollback thresholds before launch, not during a traffic dip; a calm decision made in advance beats a rushed one made under pressure.
What running redesigns teaches you about where they go wrong
The most common failure we see isn't a dramatic technical error. It's simpler than that: a missing redirect for a page nobody remembered was still getting traffic, or a staging checklist that got skipped because launch day felt rushed. Continuity is the whole game.
Teams that treat redirects, backups and monitoring as somebody's ongoing job, rather than a one-off task before launch, tend to come through a redesign with far fewer surprises. That consistency is harder to maintain without dedicated support watching for it.
— Will
How we support businesses through a website redesign
A redesign touches hosting, staging, backups, redirects and ongoing monitoring all at once, which is exactly where things slip when IT support isn't built into the plan from day one. We handle Web Domains, Hosting & SSL alongside Remote Monitoring & Management, so staging environments, backups and post-launch performance checks sit with one team rather than being split across several suppliers.
For businesses that want design and SEO handled directly, our Managed IT Support covers the technical side of a migration, and where a project needs dedicated design input we work alongside partners like TK Marketing for build and branding work. If you're planning a redesign and want a second pair of eyes on your migration plan before launch, get in touch and we'll talk through what a managed migration review would look like for your site.
If you're on WordPress specifically, our guide to choosing the right WordPress maintenance plan covers the staging and backup groundwork a redesign depends on.
FAQ
How long should redirects stay active after a redesign?
Keep redirects live for at least a year after launch to preserve ranking signals, as Google's own redirect guidance recommends. Shorter windows risk losing the link equity and ranking history tied to your old URLs.
What's the first thing to do before starting a website redesign?
Export your current Search Console performance data, a full site crawl, and your sitemaps and robots.txt before any design work begins. This baseline, recommended in Google's migration guidance, is what lets you spot and fix regressions after launch.
How soon will I know if the redesign hurt my rankings?
Watch index coverage, crawl errors and top-page traffic daily in the first week, then compare weekly and monthly reports against your pre-launch baseline. Industry migration guidance notes that some ranking fluctuation is normal, with clearer answers emerging by the 30 and 90 day audit points.
Do I need to resubmit my sitemap after a redesign?
Yes, submit your updated XML sitemap to Search Console and Bing as part of your launch-day tasks, alongside confirming your site verification is still intact. This helps search engines discover your new URL structure faster.
What causes most SEO losses during a redesign?
Broken continuity, usually missing or chained redirects that sever the link between old and new URLs, is a frequent cause of ranking loss highlighted in Google's own advice on site moves. A clear URL mapping spreadsheet and permanent redirects are the most effective safeguards.