Every business with an ageing website eventually has the same thought: this needs a redesign. And almost every business that's been burned before has the same fear immediately after: what if we lose all our rankings when we do it.
That fear is well-founded.
Website redesigns are one of the most common ways businesses accidentally torch years of organic traffic overnight, and it's almost always avoidable with the right process.
This is the checklist we'd want you to have read before you sign off any redesign budget, whether you're working with us or anyone else.
Google ranks specific URLs, not just domains or brands.
When a redesign changes URL structures, deletes pages that were quietly ranking well, strips out metadata, or restructures navigation in a way that breaks internal linking, Google has to work out what happened to all the pages it previously understood and trusted.
Sometimes it figures it out cleanly. Often, particularly with a rushed or badly planned migration, it doesn't, and rankings that took years to earn can drop sharply within weeks.
The specific failure points are consistent across almost every bad migration we've seen.
None of this is inevitable. It happens because redesigns get treated as a design and development project, with SEO considered, if at all, as an afterthought right before launch.
The fix is to treat SEO as part of the project plan from day one, not a check to run the week before going live.
Before a single design decision gets made, you need a complete record of what currently exists and how it's performing.
This means exporting every live URL on the site, along with its current title tag, meta description, and a note of its current organic traffic and keyword rankings from Google Search Console and Analytics.
You need to know which pages are actually earning their keep before anyone decides to cut, merge, or redesign them.
This audit should also flag your current top-performing pages specifically. These are the pages that need the most careful handling during the migration, because they have the most to lose.
A page generating a handful of visits a month can afford some rough handling during a redesign. A page driving a meaningful share of your organic leads cannot.
If you haven't had a proper technical SEO audit done recently, this is the point to get one, not after the redesign is finished. Our SEO service can help with exactly that.
Google ranks specific URLs, not domains, so a redesign that changes URLs, deletes ranking pages, or breaks internal linking without warning can undo years of rankings within weeks. The fix starts before any design work: export every live URL with its title tag, meta description and current performance.
This is the single most important technical step in the entire process, and the one most commonly done badly. A redirect map is a one-to-one list: every old URL, mapped to the specific new URL that replaces it.
Not a blanket redirect of everything to the homepage, which is one of the most damaging shortcuts a lazy migration can take, and one we still see agencies do more often than you'd hope.
Every old URL needs a genuine new home, even if the content has been merged, restructured, or renamed.
If a page truly no longer has an equivalent on the new site, it should redirect to the most closely related page that does exist, not just default to the homepage. Google reads a one-to-one, topically relevant redirect as continuity.
It reads a mass redirect to the homepage as a strong signal that the specific content is simply gone, which is exactly the read you don't want for a page that was ranking well.
These should all be 301 (permanent) redirects, implemented at the server or CMS level before the new site goes live, tested thoroughly, and left in place for the long term, not removed a few months later once "the migration is done."
Search engines and any external sites still linking to the old URLs need that redirect to keep working indefinitely.
It's tempting, when redesigning a site, to treat it as a clean slate and rewrite everything from scratch. Resist this for any page that's currently performing well.
If a page ranks for a valuable keyword with its current title tag, meta description, and core content, that's evidence the page is doing something right, and a full rewrite risks losing whatever that is.
The sensible approach is to carry over what's working, and only rewrite what genuinely needs improving, ideally informed by exactly the kind of title tag and meta description review we did for your existing 116 pages.
New design, same underlying SEO-proven content and metadata where it's already earning its place, updated content and structure where the audit showed real gaps or cannibalisation.
A redesign is actually the ideal moment to fix cannibalisation issues between near-duplicate pages, since you're already restructuring the site, but that's a deliberate content decision made with the audit data in hand, not a side effect of a design refresh.
The single most important technical step is a genuine one-to-one redirect map for every old URL, never a blanket redirect to the homepage. For any page already ranking well, resist the urge to rewrite it from scratch - migrate its metadata and content deliberately instead.
If your site currently has schema markup, structured data that helps Google understand and richly display things like reviews, FAQs, or business information, make sure your new developer knows it exists and migrates it properly.
This is one of the most commonly lost elements in a redesign simply because it's invisible in a normal browser and easy for a new development team to overlook if nobody flags it explicitly.
Confirm this is on the project plan, and check it's actually present on the new site before launch, not after.
A redesign often changes navigation, footer links, and the general structure of how pages connect to each other. Every internal link across the whole site needs auditing against the new URL structure.
A page that used to receive strong internal linking support, and therefore ranked well partly because of it, can quietly lose that support in a redesign if nobody checks that the links pointing to it still exist and still use the correct new URL.
This is tedious, unglamorous work, and it's exactly the kind of thing that gets skipped under launch deadline pressure. It shouldn't be.
A site with broken or missing internal links doesn't just look unpolished, it actively signals to Google that those pages are less important than they used to be.
Structured data is invisible in a normal browser and easy for a new dev team to overlook, so confirm it's on the project plan and check it's live before launch. Internal linking needs the same scrutiny - a page can quietly lose the ranking support it had if navigation and footer links aren't rebuilt against the new URL structure.
On launch day, submit the new sitemap to Google Search Console immediately, and use the URL inspection tool to request indexing for your highest-priority pages rather than waiting for Google to discover them naturally.
Google's own site move documentation is worth reading in full alongside this guide, since it covers the platform-specific technical detail we don't repeat here.
Check that your robots.txt file hasn't accidentally blocked crawlers from the new site, which happens more often than you'd think when a staging site's restrictive robots.txt gets carried over to production by mistake.
For the first thirty days after launch, check Search Console weekly, not just at the end of the month. Watch for a spike in 404 errors, which usually means a gap in your redirect map.
Watch for sudden drops in impressions or clicks on pages that were previously performing well, which is your earliest warning sign of a ranking problem while there's still time to fix it quickly.
And watch your indexed page count, a sudden drop usually means Google is struggling to crawl or understand part of the new site structure.
Some fluctuation in the first couple of weeks is completely normal as Google reprocesses the site.
A sustained decline past that point, particularly on your previously top-performing pages, means something in the migration needs urgent attention, and it's much easier to fix in week two than to discover in month three after the damage has compounded.
| Step | What it covers |
|---|---|
| 1. Audit everything first | Export every live URL, title tag, meta description, and current traffic/rankings before touching anything |
| 2. Build a proper redirect map | A 1:1 redirect for every old URL to its new equivalent, so nothing is left orphaned |
| 3. Migrate metadata and content deliberately | Carry over what's already working rather than starting from a blank slate |
| 4. Don't lose your structured data | Carry existing schema markup across to the new build, don't let it quietly drop |
| 5. Rebuild internal linking properly | Fix the whole linking structure, not just page-by-page as issues turn up |
| 6. Launch on staging, then monitor closely | Test with a noindex tag, confirm it's removed at launch, then watch rankings and traffic closely afterwards |
Every proper redesign gets built and tested on a staging environment before it goes live, which is the right approach, but it introduces its own well-known risk: staging sites need a noindex tag so Google doesn't accidentally crawl and index an unfinished, duplicate version of your site.
The mistake that catches out a surprising number of otherwise well-run projects is forgetting to remove that noindex tag when the finished site goes live, which quietly tells Google not to index any of it.
Make this an explicit, checked item on your launch-day list, not an assumption. It takes thirty seconds to verify and can otherwise cause weeks of confusion about why a perfectly good new site isn't appearing in search at all.
Check your page source directly for a noindex meta tag, or check the indexing settings in your CMS, rather than just assuming whoever flipped the switch remembered.
On launch day, submit the new sitemap and request indexing for priority pages straight away, and double-check robots.txt hasn't carried over a staging site's crawler block. Staging environments need their own noindex tag - and the single most common cause of a redesign tanking rankings overnight is forgetting to remove it before going live.
A good agency should have ready answers to these. If they don’t, that’s worth noticing before you sign anything:
The single most damaging shortcut we see, more than any other mistake on this list, is a new design agency being brought in specifically for the visual and development work, with no one on the project explicitly responsible for the SEO side of the migration.
Everyone assumes someone else is handling redirects and metadata, and the gap only becomes visible weeks after launch when traffic has already dropped and the cause has to be reverse-engineered from Search Console data instead of prevented in the first place.
If you're working with a web design agency for the redesign itself, ask directly, in writing, whose job the redirect map and metadata migration is.
If the honest answer is "we assumed you'd sort that" or "we assumed we'd sort that," you've just found the gap before it became a problem, which is exactly the point of asking.
A good agency should have a ready rollback plan, a pre-launch redirect map, and someone actively watching Search Console for the first two weeks - if they don't, notice before you sign. The single most damaging mistake is nobody being explicitly responsible for SEO during the migration, so redirects and metadata fall through the gap between design and development.
To make this concrete: a well-run redesign for a business with, say, sixty existing pages starts with a full export of those sixty URLs and their current performance data, roughly two to three weeks before any design work begins.
The redirect map gets built and reviewed alongside the new site's proposed structure, not after it's finalised, so anyone can catch pages that would otherwise be orphaned.
Metadata gets migrated page by page as part of the build, not left as a placeholder to fill in later.
The new site launches on a Tuesday or Wednesday, deliberately avoiding a Friday launch that leaves nobody available to fix an urgent issue over the weekend.
And someone is explicitly assigned to check Search Console daily for the first week, then weekly for the following month.
None of this is complicated. It's a checklist, followed properly, by someone whose job it is to follow it.
The businesses that lose rankings in a redesign are almost never the ones who lacked the technical knowledge to avoid it, they're the ones where nobody was explicitly accountable for doing it.
A website redesign done properly should be, at worst, SEO-neutral, and often becomes an opportunity to actually improve rankings by fixing the technical debt and content issues an older site inevitably accumulates.
A website redesign done carelessly can undo years of organic growth in a matter of weeks.
The difference between the two outcomes isn't luck, it's whether SEO was built into the project plan from the very first conversation about the new design, or bolted on as an afterthought once the visuals were already signed off.
This is exactly the process we run as part of our website design and development service whenever a redesign involves an existing site with rankings worth protecting.
If you're planning a redesign and want it handled by people who treat this as a genuine migration project rather than just a design refresh, we'd be glad to talk it through.
Get in touch through our contact page for a free discovery call, we'll look at what you've got now, what's actually working that needs protecting, and how to plan the move so you come out the other side with a better site and the rankings intact.
A well-run migration exports every URL and its performance two to three weeks before design starts, builds the redirect map alongside the new structure rather than after, and avoids a Friday launch. Done properly, a redesign should be SEO-neutral at worst and often an improvement; done carelessly, it can undo years of organic growth.
