Guides9 min read

The Website Redesign Checklist: How to Rebuild Your Site Without Losing Your Google Rankings

A website redesign tanks rankings when the new site quietly breaks what the old one was ranking for — pages moved without 301 redirects, internal links pointing at URLs that no longer exist, indexed content deleted instead of merged, and metadata that never made it into the rebuild. None of this is inevitable. It's a sequencing problem, not a redesign problem, and every part of it is preventable if you map it before you touch a single page.

If you're staring at an outdated, slow, embarrassing site and still delaying the rebuild because you're afraid of what happens to your traffic, that fear is reasonable — redesigns lose rankings constantly, and it's rarely because the new design was worse. It's because nobody carried the SEO equity from the old site to the new one on the way through. This is the checklist that carries it through.

Why redesigns lose Google rankings in the first place

Google doesn't rank your homepage or your brand — it ranks individual URLs, each with its own accumulated signals: backlinks pointing at it, internal links reinforcing it, click history, indexing age, and content that matched a specific search intent. A redesign that changes the URL structure, deletes a page, or replaces ranking copy with something thinner is effectively asking Google to start that page over from zero. The design can be objectively better and the traffic can still drop, because rankings aren't attached to how a page looks. They're attached to a URL and everything pointing at it.

The five ways a redesign quietly breaks SEO

URLs change without 301 redirects, so every backlink and bookmark now hits a 404.
Internal links get rebuilt pointing to the new navigation, leaving old ranking pages with zero internal links pointing at them.
Content that ranked for long-tail queries gets deleted or folded into a generic page during a copy rewrite.
Page speed regresses because the new design ships heavier images, fonts, or scripts than the old one.
Metadata — title tags, meta descriptions, schema markup, canonical tags — gets lost in the migration instead of carried over deliberately.

Any one of these alone can cost you meaningful traffic. In most redesigns we've seen go wrong, it's three or four of them happening at once, which is why the drop looks catastrophic instead of minor.

What to export and document before you touch the old site

Before a single old page comes down, you need a record of what it was doing for you. Once the old site is gone, you're reconstructing this from memory, and memory is not a migration plan.

01
Export your top-performing pages from analytics
Pull the last 12 months of traffic by URL from Google Analytics or your analytics tool, ranked by sessions. Anything getting meaningful organic traffic is a page you need to account for in the new site, not just leave behind.
02
Export your indexed URLs from Search Console
Search Console's Pages report and the URL Inspection tool show you exactly what Google has indexed. Cross-reference this against your analytics export — some pages rank for queries that drive almost no clicks but still hold link equity worth preserving.
03
Pull your current backlink profile
Use Search Console's Links report, or an SEO tool if you have one, to see which external sites link to which of your URLs. Those backlinks are worth real money in ranking terms, and they become worthless the moment the URL they point to starts 404ing.
04
Screenshot or archive your metadata
Title tags, meta descriptions, and structured data (schema markup) rarely get ported over deliberately during a rebuild — they get forgotten because they're invisible on the page itself. Record what exists now so it can be rebuilt intentionally, not recreated from scratch by whoever writes the new copy.
05
Save your current XML sitemap
Your existing sitemap is effectively a manifest of every URL Google considers part of your site. It's the fastest way to build a complete redirect map, because it's the closest thing you have to a full site inventory.

How to build a 301 redirect map so nothing gets lost

A 301 redirect tells browsers and search engines that a page has permanently moved, and it passes along the vast majority of that page's ranking signals to its new location. Skipping this step is the single most common reason redesigns lose traffic — not because redirects are hard to set up, but because nobody built the map before launch.

Take the full list of old URLs from your sitemap and analytics export, and match each one to its new equivalent on the rebuilt site — old-blog-post-slug to new-blog-post-slug, not just old-blog-post-slug to the new blog homepage. Redirecting everything to your homepage "to be safe" is barely better than a 404: it tells Google the specific page is gone, and a generic redirect target signals a much weaker relevance match than a real one-to-one redirect. Every URL on the old site needs a decision — redirect to its direct replacement, redirect to the closest merged page, or, if a page truly has no reason to exist anymore, a deliberate decision to let it go rather than an oversight.

Should your new site keep the same URL structure?

If your current URL structure is reasonably clean, keeping it unchanged is the single easiest way to avoid an SEO risk during a redesign, because unchanged URLs need no redirects at all — the ranking signals simply stay attached to the same address while the design around them changes. Redesigning the visual layer of a site doesn't require touching the URL layer, and treating them as separate decisions removes most of the risk before it exists.

Where a URL restructure is genuinely warranted — folding a messy blog taxonomy into something coherent, fixing URLs that never matched what the page is actually about — do it as a deliberate, mapped decision with a 301 for every affected URL, not as a side effect of a template migration. And where a page's underlying content is changing meaningfully, keep the canonical tag pointed at the version you want indexed, so Google doesn't end up confused about which URL is the authoritative one during the transition.

Sequencing the redesign so you can catch problems before they cost you

The riskiest way to redesign a site is to build it in isolation for months and flip a switch on launch day. If something breaks, you find out from a traffic graph, days after it happened, with no clean way to isolate the cause.

A safer rollout looks like this

Build and QA the new site on a staging environment, blocked from indexing with a noindex tag or password protection so Google never crawls an unfinished version.
Record baseline rankings and organic traffic for your top pages before launch, so you have a real before to compare against.
Launch during a low-traffic window, not the week of a product launch or a paid campaign push.
Push the redirect map live at the same moment as the new site — never after, and ideally verified in staging first.
Resubmit your XML sitemap in Search Console immediately after launch, so Google recrawls the new structure instead of waiting to discover it on its own schedule.
Monitor Search Console daily for the first two weeks, watching for a spike in 404s or a sudden drop in indexed pages.

For larger sites, a phased rollout — migrating one section at a time instead of the whole domain at once — gives you a much smaller blast radius if something in the redirect map was wrong. It's slower, but it turns a potential site-wide traffic drop into a contained, fixable issue on one section.

What to watch in the first 30 days after launch

Rankings don't move instantly, so the absence of a drop in week one doesn't mean you're clear, and a temporary dip in week one doesn't necessarily mean something's wrong either — Google needs time to recrawl and reprocess a changed site. What matters is what you track and how fast you catch a real problem versus normal churn.

Check Search Console's Coverage report for a sudden rise in "Not Found (404)" errors — that's usually a missed redirect. Check the Performance report, filtered by your top pages from before launch, to see whether impressions and clicks are holding steady or falling off a cliff. And check whether your indexed page count has dropped sharply, which usually means large sections of the new site aren't being recognized as equivalent to what was there before, and Google is treating them as new, unranked pages instead.

A redesign doesn't lose rankings because the new site is worse. It loses rankings because nobody told Google where everything went.

A short pre-launch gut-check

Do I have a 301 redirect mapped for every URL on the old site that gets any traffic or backlinks?
Is my new site's URL structure the same, or is every structural change intentional and redirected?
Have I exported my analytics, Search Console data, and backlink profile before the old site comes down?
Is the new site staged and blocked from indexing until it's actually ready to launch?
Do I know exactly what I'll check in Search Console on day one, day seven, and day thirty?

If you can answer yes to all five, a redesign is a low-risk upgrade, not a gamble on your search traffic. Most of the horror stories founders hear about redesigns killing rankings trace back to one missing step on this list, not to some unavoidable SEO penalty for changing a site's design. This is exactly the part of a rebuild we handle by default, not as an afterthought bolted on after launch — if you'd rather have someone map the redirects and watch Search Console while you focus on the business, that's what we do.