If your traffic dropped after a redesign, I’d start by looking at what changed on the site before blaming Google.
That sounds obvious, but redesigns often change far more than the design.
URLs move. Pages disappear. Content gets cut down. Titles reset. Navigation changes. Staging settings accidentally make it onto the live site. Sometimes the Analytics setup breaks and the “traffic drop” isn’t actually a search drop at all.
The useful part is that most of those things can be checked.
This is the order I’d normally work through them.
First, make sure the drop is real
A bit of movement after a redesign isn’t unusual, especially if URLs have changed.
Google has to recrawl and reprocess the site, so I wouldn’t panic over a small wobble in the first week or two. Google’s own guide to debugging drops in search traffic says a medium-sized site can take a few weeks to settle after URLs change.
What would concern me more is a sharp drop that stays down, or a clear loss on particular pages or sections.
The first thing I’d do is compare Search Console with Analytics.
If Analytics fell off a cliff on launch day but Search Console didn’t, I’d check whether the tracking code made it onto the new site before doing anything else.
Then I’d look at Search Console over a longer period, ideally 16 months, so I can compare the post-launch period with the same time the previous year.
That helps separate a redesign problem from normal seasonality.
Check where the old URLs went
This is usually one of the first places I look.
Take the pages that had the most organic traffic before the redesign and test the old URLs.
You want each one to end up on the closest equivalent new page.
What I often find instead is:
- a 404
- a redirect to the homepage
- several redirects chained together
- a redirect to something only vaguely related
- the old URL still loading alongside the new one
Any of those can cause problems.
If a page had ranked for years and the redesign simply removed it without a proper replacement, that history doesn’t magically transfer to the homepage.
If there was no redirect map before launch, I’d build one now using whatever historical data is available: Search Console, old sitemaps, Analytics, backlinks and, if necessary, an archive of the old site.
Then I’d get the important redirects live first.
Check whether Google can actually access the new site
A site can look completely normal in a browser and still be making life difficult for Google.
I’d check robots.txt first.
It’s surprisingly easy for a staging rule such as Disallow: / to make it onto the live site.
Then I’d check key pages for noindex, look through the Page indexing report in Search Console, and test a few important URLs with URL Inspection.
I’d also request a made-up URL.
If /this-page-definitely-does-not-exist/ returns a normal-looking page with a 200 status, that needs fixing. A missing page should behave like a missing page.
That sort of issue is easy to miss because, from a visitor’s point of view, the site may still look fine.
Compare the old content with the new
Redesigns usually come with a tidy-up.
Long pages get shortened. Sections get merged. Copy is rewritten to fit a cleaner layout. Old pages are removed because nobody is sure what they were for.
Sometimes that improves things.
Sometimes the awkward old page was the one bringing in most of the traffic.
I’d compare the old and new versions of the pages that lost the most visibility.
I’m not just looking at word count. I’d look at:
- which topics disappeared
- whether useful headings were removed
- whether important questions are still answered
- whether internal links changed
- whether the page now serves a different intent
- whether the useful content has been pushed behind tabs, interactions or scripts
If a page lost most of its useful content at roughly the same time it lost most of its search visibility, that’s obviously worth investigating.
It doesn’t prove causation by itself, but it gives you somewhere sensible to look.
Check what happened to page titles
This is another easy one to miss.
New themes and templates often reset titles and descriptions to something automatic.
A page that previously had a carefully written title can suddenly become:
Services | Company Name
or just the page name.
That can affect both relevance and click-through rate.
After the Kwiat migration, for example, I found collection pages where titles and descriptions were often being generated from the collection name rather than properly written.
I’d take a sample of the pages that lost visibility and compare the old and new titles.
If they’ve become generic, restore the stronger versions where they still make sense.
Check whether old and new URLs are competing
Sometimes a redesign doesn’t actually remove the old pages.
The new URL launches, but the old one still returns a 200.
Now Google has two similar pages to choose between.
Canonical tags can make that worse if they’re pointing in the wrong direction or changing between the raw and rendered page.
On Kwiat, old category URLs were still resolving after the platform move, and on some searches both the old and new versions were appearing.
That’s not ideal.
Search a few important terms and look at which URL Google is actually showing.
If it’s the old one, or both versions are appearing, I’d check redirects and canonicals before doing anything more complicated.
Look at the navigation as well
Redesigns often change the internal linking structure without anyone really thinking of it as an SEO change.
A page that used to be linked from the main navigation might now sit three levels deep.
Another might lose links from several high-value pages because the new design is cleaner.
That changes how users and crawlers move through the site, and it can reduce the internal importance of pages that previously performed well.
I’d compare the old and new crawl depth and look at which pages lost internal links.
Sometimes the page itself hasn’t changed much at all. Its place in the site has.
What else changed on launch day?
This is the question I’d keep coming back to.
A redesign might also involve:
- a new CMS
- a new JavaScript framework
- a different hosting setup
- changed mobile behaviour
- new cookie consent
- a new analytics configuration
- image-heavy templates
- rewritten internal links
- different schema
- a new domain or URL structure
The more things that changed at once, the harder it is to blame one factor.
That’s why I’d work from evidence rather than assumptions.
The order I’d fix things
If I found several issues, I’d usually prioritise them roughly like this:
- Confirm whether the drop exists in Search Console as well as Analytics.
- Fix missing or incorrect redirects from old high-value URLs.
- Remove anything blocking crawling or indexing.
- Fix duplicate or conflicting old and new URLs.
- Restore important content, titles or internal links where the evidence supports it.
- Submit the correct sitemap and keep an eye on indexing and visibility.
Then give Google time to recrawl and reassess the site.
I wouldn’t promise recovery by a particular date.
Some fixes are picked up quickly. Others take longer, especially on larger sites or where the migration changed a lot at once.
A real example from a redesign project
I don’t have a neat before-and-after redesign graph I can publish, so I’m not going to pretend I do.
What I can show is the kind of problem that gets caught before launch.
On Evewell, a London fertility clinic rebuilding its WordPress site, I reviewed the existing site before the new one went live.
One page sat outside the main structure but was still generating 5,145 clicks a year.
It would have been very easy for someone tidying the site up to remove it because it didn’t look important from the navigation.
I also found an old redirect that already ended in a 404.
Both went into the migration briefs before development moved on.
That site is due to launch in late 2026, so I can’t claim the outcome yet. But that’s exactly why I like doing this work before launch rather than after the traffic disappears.
The Evewell case study and Kwiat migration case study show more of the work.
The short version
If traffic drops after a redesign, I’d check the boring things first.
Did the URLs change?
Did the redirects work?
Can Google still access the important pages?
Did useful content disappear?
Did the titles reset?
Are old and new versions both live?
Did the navigation make important pages harder to reach?
And is the drop actually in Search Console, or only in Analytics?
Most redesign-related traffic problems are easier to understand once you line up what changed with when the drop happened.
If you’ve already launched and traffic has fallen, my traffic decline investigation works through the evidence and tells you which issues I think are actually contributing.
If you haven’t launched yet, the site migration checklist and my redesign support are aimed at catching this stuff before it becomes a recovery job.
You can also request a free assessment if you want me to take a first look.
FAQ
How long does it take traffic to recover after a redesign?
It depends on how much changed and how big the site is. A medium-sized site can take a few weeks to settle after URL changes, and larger ones longer. If there’s no sign of recovery after six weeks or so, I’d start looking for a fault.
Will changing my website design hurt SEO?
It can, mostly because of what changes underneath the design. New URLs without redirects, removed pages, thinner content and reset titles all cost visibility. A new look on the same URLs and content usually carries much less risk.
Should I undo the redesign if my traffic drops?
Usually not. Rolling back is another big change on a site Google is still working through. I’d find the specific cause first, which is often redirects, an indexing block or lost content, and fix that on the new site.
How do I find out which pages lost traffic after a redesign?
In Search Console, set the date range to 16 months and compare the weeks after launch with the same weeks a year earlier. Sort the Pages tab by the change in clicks. The biggest losses are where I’d start looking.
Do I need redirects if I’m only changing the design?
Only if URLs change. If every page keeps the same address, those pages don’t need redirects. If any address changes, even a folder name or a trailing slash, each old address should redirect to its new one.
Sources
- Debugging drops in Google Search traffic, Google Search Central, accessed 21 October 2026. Supports: the few-weeks guidance for medium sites after URL changes and the 16-month view.
- Paul Myers, Evewell pre-migration audit, 2026 (published case study). Supports: the page outside the main structure and the broken redirect.
- Paul Myers, Kwiat headless Shopify migration, 2026 (published case study). Supports: the reset titles and the old category URLs still resolving.
