The new site launched three weeks ago. It looks dramatically better, the team is pleased, and organic traffic has halved. Nobody wants to be the person who says the website redesign caused it, so the conversation drifts toward algorithm updates and seasonality while the number keeps falling.
It is almost never seasonality. A website redesign is a large simultaneous change to structure, content, and code, and that is exactly the kind of event that breaks things silently. A traffic drop that starts within days of a relaunch was caused by the relaunch, and the good news is that these failures are specific, findable, and usually fixable within a week or two if you look in the right order.
Check redirects before anything else in a website redesign
The overwhelming majority of website redesign traffic losses come down to URLs changing without proper redirects. It sounds basic and it is still the number one cause by a wide margin.
Every URL that had rankings and backlinks needs a 301 redirect to its closest equivalent on the new site. Miss those and you throw away years of accumulated authority, because the ranking signal attached to the old address has nowhere to go.
Three failure modes recur. Redirects were never created, usually because nobody exported the old URL list before launch. Redirects all point at the homepage, which search engines increasingly treat as a soft 404 rather than a genuine equivalence. Or redirects chain through several hops, diluting the signal and slowing crawling.
Get a list of every URL that had traffic in the twelve months before launch, request each one, and record what happens. Anything returning a 404, redirecting to the homepage, or chaining more than once goes on the fix list. This single exercise resolves most cases.
Check whether you blocked the site
Staging sites are routinely blocked from indexing, which is correct. The failure is forgetting to remove the block when it goes live, and it is far more common than anyone admits.
Look for a noindex meta tag on live pages, a robots.txt disallowing everything, and the WordPress discourage search engines setting if you use it. Any one of these will remove you from search results within days, and it produces the fastest and most dramatic version of this problem.
If this is the cause you are fortunate, because recovery is usually quick once the block is lifted and pages are recrawled. It looks catastrophic and it is the least damaging cause on this list.
Read More - The Minimum Viable Product Trap: Why Your First Build Is Probably Wrong
Compare the content, not just the design
A website redesign frequently reduces content substantially, and this is the cause people most resist accepting because the reduction was deliberate.
Modern designs favour shorter pages, more whitespace, and punchier copy. That is often better for conversion and it removes the text that was earning rankings. A service page that ran 1,200 words and now runs 300 has lost most of what made it relevant to a search engine.
Check whether pages were consolidated or removed entirely. Sites commonly merge several targeted pages into one during a redesign, so five pages each ranking for a specific term become one page ranking for none of them particularly well. Compare the old and new versions of your top twenty landing pages and look at what disappeared.
Check what the page looks like without JavaScript
Redesigns often move to a JavaScript framework, and that introduces a failure mode that is invisible in a browser.
If content only appears after JavaScript executes, search engines may not see it reliably. Rendering happens on a delay and is not guaranteed, so a page that looks complete to you can be largely empty to a crawler. Internal links inside JavaScript components may not be discovered at all, which quietly breaks how authority flows through the site.
View the page source rather than the inspector, and check whether your main content and navigation links exist in the HTML. If they do not, that is very likely your problem, and it is an architectural fix rather than a content one.
The technical details that get dropped
A handful of smaller items go missing during most rebuilds and collectively they matter:
- Title tags and meta descriptions. Frequently replaced with templated versions, losing carefully targeted titles.
- Canonical tags. Pointing at the wrong URL, at the staging domain, or missing entirely.
- Structured data. Schema markup that existed on the old site rarely survives, taking rich results with it.
- Internal linking. Contextual links inside body content often vanish when copy is rewritten, orphaning deeper pages.
- Image alt text. Lost during migration, removing image search traffic and accessibility.
- The XML sitemap. Still listing old URLs, or not regenerated at all.
Internal linking deserves attention because its effects are slow and easy to misattribute. Pages that lose their inbound internal links get crawled less and decline gradually over weeks, so the damage appears long after launch and looks like a separate problem.
Diagnose in the right order
The reason recoveries drag on for months is almost always that teams investigate in the wrong sequence, starting with the most interesting hypothesis rather than the most likely one. Work through it in order of probability and you will usually have an answer within a day.
Start with indexing, because it is the fastest to check and the most catastrophic. Confirm the site is not blocked and that pages are actually in the index. Then check redirects, which is the most common cause overall. Then compare content on your top landing pages. Then check rendering. Only after all four should you consider whether an algorithm update coincided with your launch.
That last point matters because algorithm updates are the most tempting explanation and the least actionable. If a core update genuinely landed the same week as your relaunch, you have two overlapping causes and the only way to separate them is to fix the technical faults first and see what remains. Blaming the update before checking your own redirects is how sites stay broken for a quarter.
It also helps to check whether competitors moved. If your rankings fell and nobody else gained, the cause is almost certainly technical and internal to your site. If a competitor rose into the positions you lost, you may be looking at a genuine relevance change rather than a website redesign fault, and the remedy is different.
Do not panic and revert
The pressure to roll back builds quickly, and it is usually the wrong move. A rollback means two site migrations in quick succession, which compounds the disruption rather than undoing it, and you lose whatever genuine improvements the new site brought.
Some fluctuation after any significant change is normal. Search engines need to recrawl and reassess, which takes weeks rather than days on most sites. A drop that stabilises and begins recovering after two or three weeks is the expected pattern for a well executed website redesign.
What is not normal is a sustained decline still deepening after a month, or an immediate drop close to total. Those indicate a specific technical fault from the list above rather than a settling period, and they need diagnosis rather than patience.
Read More - Six SaaS Tools, None That Talk: When to Build Custom
How to plan a website redesign without this happening
If you are planning a rebuild rather than recovering from one, the preventative work is straightforward and almost always skipped because it happens before anyone is excited about the project.
Export every URL with its traffic and backlink profile before you start. Build the redirect map as part of the design process rather than in the final week, because that is when it gets rushed. Keep the content on pages that already rank, and if the design cannot accommodate the text, change the design rather than deleting the content. Crawl the staging site with an SEO tool before launch, and compare titles, canonicals, and structured data against the live site systematically.
Then launch on a Tuesday morning with the whole team available, monitor Search Console daily for a fortnight, and fix issues immediately while the cause is still obvious. Almost every disaster in this category traces back to a launch that happened on a Friday afternoon with nobody watching.
If you are recovering from a rebuild or planning one, our Website Development team handles migrations with redirect mapping and technical continuity. Related reading: core update recovery, fixing INP, and rankings up with traffic down.
Frequently Asked Questions
How long should recovery take after a website redesign?
If the cause was redirects or an indexing block, expect improvement within two to four weeks of fixing it, since search engines need to recrawl and reassess. Content reductions take longer because you are rebuilding relevance rather than restoring a signal. A decline still deepening after a month means something remains unfixed.
Should I roll back to the old site?
Usually not. Rolling back means a second migration on top of the first, which compounds disruption and loses the improvements the new site brought. Diagnose and fix the specific fault instead. Reverting is only justified when the new site is fundamentally broken and cannot be repaired quickly.
How do I find which URLs lost traffic?
Compare Search Console performance data for the three months before launch against the period after, grouped by page. Pages that had traffic and now have none are your priority list, and checking what each one returns now, whether a 404, a redirect to the homepage, or a thinner page, usually identifies the cause immediately.
Is it normal to lose some traffic after a redesign?
A modest dip for a couple of weeks while search engines reassess is common even on well executed migrations. Losing a substantial share of organic traffic is not normal and always indicates a specific technical problem. The distinction is whether it stabilises and recovers or keeps falling.
Does redirecting everything to the homepage work?
No, and it actively harms you. Search engines treat mass redirects to the homepage as soft 404s, so you lose the ranking signal exactly as if the pages had been deleted, while also giving visitors a poor experience. Each URL needs redirecting to its closest genuine equivalent.
What if the old pages genuinely do not exist any more?
Redirect to the most relevant remaining page, such as a parent category or a related service. If nothing is genuinely equivalent, letting it return 404 is acceptable and honest. What matters is not defaulting everything to the homepage as a shortcut.
Can a redesign improve rankings?
Yes, when it improves performance, mobile experience, internal linking, and content depth while preserving URLs and existing signals. The rebuilds that gain traffic treat SEO continuity as a design requirement from the start rather than a checklist item handled the week before launch.
Talk to our team if your relaunch cost you rankings.