Your Redesign Tanked Your Google Rankings: The Recovery Playbook (2026)
Traffic fell off a cliff the week the new site went live. Here's how to find exactly which pages lost their rankings, why, and the redirect work that gets them back.
A redesign that tanks your rankings almost always has one of three causes: a broken or missing redirect map, content that got thinner or disappeared in the rewrite, or a chunk of the old site that Google simply hasn't found again yet. Two of those are fixable in days. One takes months and there's no shortcut. This post is how to tell which one you're looking at.
If you launched a new site two, four, or eight weeks ago and Search Console shows the click graph falling off a cliff around the launch date, you're not imagining it and it's not "normal settling in." Something specific broke. Below is the diagnostic, in the order that actually finds the fault fastest.
First: confirm the drop is real and get the shape of it
Open Google Search Console, go to the Performance report, and set the date range to cover 8 weeks either side of launch. Look at clicks and impressions on the same graph, not just clicks.
If impressions dropped alongside clicks, Google has stopped showing your pages at all — that's an indexing or redirect problem, not a content-quality one. If impressions held steady but clicks dropped, your pages are still appearing in results but ranking lower or the snippet got worse, which points more toward a content or relevance issue on individual pages.
Then go to the Pages report under Performance, sort by the old date range, and export your top 30–50 URLs by clicks before launch. This list is your recovery checklist. You're about to check every one of them against the new site.
Cause 1: the redirect map is broken or doesn't exist
This is the most common cause and the easiest to diagnose. If your URL structure changed during the redesign — new slugs, a new folder structure, a platform migration — every old URL needs a 301 redirect pointing to its new equivalent. Google's own guidance on site moves is explicit about this: without redirects, the old URL is treated as gone and the new URL is treated as brand new, with none of the ranking history carried across.
How to check it. Take your top 30–50 URLs from the export above and visit each one directly in your browser. For every one that changed, confirm it does one of two things: loads correctly at the same address, or 301-redirects straight to its new home in a single hop. Watch for these specific failures, because they're the ones that quietly wreck a migration:
A redirect that goes to the homepage instead of the equivalent new page. This is the single most common mistake in a rushed relaunch — the developer sets up a catch-all "redirect everything old to the new homepage" rule because it's fast, and it tells Google that every one of your old pages is now the same page. Rankings for all of them collapse into one URL that was never optimised for those terms.
A redirect chain — old URL to an intermediate URL to the final URL. Google follows chains, but each hop dilutes signal and slows discovery. Keep it to one hop.
A 302 (temporary) redirect where a 301 (permanent) was needed. Some CMS platforms default to 302s. A 302 tells Google "this might move back," so it's slower to transfer ranking authority and sometimes doesn't transfer it at all.
No redirect — the old URL now just 404s. This is the worst outcome. Every inbound link and every scrap of ranking history pointing at that URL goes into a wall.
The fix. Build (or rebuild) a proper redirect map: every old URL mapped one-to-one to its closest new equivalent, server-side 301s, no chains longer than one hop. If a page genuinely no longer exists and has no equivalent, redirect it to the most relevant parent category page — not the homepage — or let it 404 deliberately if it truly has nothing to serve, which is rare. Google recommends keeping the old redirects live for at least a year so ranking signals have time to fully transfer, even after you've updated your own internal links to point straight at the new URLs.
Cause 2: the content got thinner in the rewrite
This one hides well because the page usually still "exists" — it just says less than it used to, or answers a narrower question. Redesigns are often paired with a copy rewrite, and copy rewrites tend to trim word count in the name of a cleaner layout. That's a legitimate design goal and it can still cost you a ranking.
Compare the old page to the new one, side by side, for anything that ranked well before. Did the page lose a section that directly answered a specific question — pricing detail, a process breakdown, an FAQ block? Did headings that matched search terms get replaced with cleverer, less literal ones? Did the page get merged with another page, losing its own distinct focus?
None of this means you need walls of text back. It means the specific information that made the page useful for that specific search still needs to be there, even if the visual treatment is completely different. A shorter, better-designed page that still answers the question fully will hold its ranking. A shorter page that dropped the answer to save space won't.
Cause 3: Google hasn't recrawled everything yet
Sometimes nothing is actually broken — Google just hasn't caught up. This is the cause people panic about first and it's usually the least likely one if you're past the two-week mark, but it's real in the first stretch after launch.
Google's own documentation says a small-to-medium site can take a few weeks for most pages to move through reindexing after a migration, and larger sites take longer. During that window, Google states plainly that ranking fluctuation is normal while it recrawls and reindexes. If your redesign went live under three weeks ago and the redirects and content both check out, the honest answer is: wait, and keep watching Search Console rather than making more changes.
Check the Coverage (or Indexing) report in Search Console for anything marked "Discovered — currently not indexed" or "Crawled — currently not indexed" on URLs that used to rank. That's your signal Google knows the page exists but hasn't finished processing it, which is different from a problem you need to fix.
Submit your new XML sitemap in Search Console if you haven't — it doesn't force an immediate recrawl, but it tells Google where to look first, and on a fresh site that speeds up discovery meaningfully.
The order to actually do this in
Work through it in this sequence rather than jumping around, because each step rules things in or out for the next one.
Pull your pre-launch top-performing URLs from Search Console. Check each one for a working, single-hop 301. Fix any that redirect to the homepage, chain, use a 302, or 404. Give that fix 1–2 weeks to show in Search Console before doing anything else — redirect fixes are usually the fastest-recovering of the three causes.
For pages that redirect correctly but still aren't recovering, compare old versus new content directly. Restore anything specific and useful that got cut in the rewrite, without reverting the actual design.
For anything still unresolved after both of those, check the indexing status in Search Console. If it's a discovery issue rather than a redirect or content issue, that's a patience problem, not a work problem — keep monitoring rather than making further edits, since repeated changes during a recrawl window can reset the clock.
What this costs you if you don't fix it
The maths here isn't dramatic, it's just compounding. Every week a previously top-3 page sits at position 15 because of a homepage-catchall redirect is a week of organic enquiries that didn't happen and won't be recovered retroactively — Google doesn't backdate rankings once you fix the cause. For a service business where organic search drives even a handful of enquiries a month, a six-week unresolved redirect problem is measured in real missed leads, not just a Search Console graph looking sad.
This is also the exact failure mode that makes a DIY platform migration — Squarespace to Squarespace, WordPress theme swap, a rushed Webflow rebuild — riskier than it looks on the surface. The cost comparison between a template platform and a custom build usually focuses on subscription fees and ongoing flexibility, but the migration risk belongs in that maths too: a redesign done without a proper redirect map is often more expensive in lost organic traffic than the redesign itself cost to build.
If you're mid-recovery right now and unsure whether what you're looking at is a redirect fault, a content fault, or just Google catching up, that's worth separating from the general question of whether the ranking drop is a site problem or an SEO problem in the first place — we've written the full diagnostic for that split here.
What a clean migration actually looks like
Worth saying plainly, because most of the damage above is avoidable with an hour of planning before launch, not after. Before any redesign that touches URLs: export every URL that currently gets organic traffic from Search Console, build the one-to-one redirect map before the new site goes live (not after someone notices traffic dropped), test every redirect on staging, and keep the old sitemap active alongside the new one for the first month so Google has both trails to follow. Agencies who build custom sites for a living treat this as a standard line item in the migration scope, not an afterthought — it's genuinely one hour of unglamorous spreadsheet work that protects months of ranking history.
If your redesign already shipped and you're staring at a Search Console graph that fell off a cliff, run the diagnostic above before you touch anything else on the site. Most recovery timelines are shorter than owners expect once the actual cause — usually a homepage catchall redirect — gets found and fixed properly.
If you want a second set of eyes on the technical health of the current site, run the free audit. It checks Core Web Vitals, TLS and crawl readiness — robots.txt, sitemap presence — in under a minute, which is a useful sanity check on the platform itself while you work through the redirect map by hand.