Lost Rankings After a Website Redesign? What Went Wrong

The call I take most often after a relaunch starts the same way. Someone exported their old sitemap two days before launch, the new site went live over a weekend, and by the following Thursday their best pages were gone from search. Not down a few spots. Gone. The contact form went quiet. Somebody on the team Slacked "is it just me or did we fall off Google," and that's usually the message that ends up forwarded to me.

So let's diagnose it. A redesign is supposed to be a good thing, and most of the time the design itself isn't the problem. The problem is what happened to the plumbing underneath while everyone was looking at the new homepage. I'll walk through the real causes, how to tell which one hit you, and the honest part nobody likes hearing: most of this should have been handled before the site ever went live.

One caveat up front. I can't tell you from here exactly which cause is yours. What I can do is give you the short list of suspects in the order I'd actually check them, all grounded in what Google documents, so you can run the checks yourself or hand them to whoever's helping you.

Why does a redesign tank your rankings?

The single most common cause is broken or missing 301 redirects. When a redesign changes your URLs, every old address needs a permanent redirect to its new equivalent. Without that, Google sees the old URLs returning errors and the new URLs as pages it has never met. All the ranking history, backlinks, and trust that lived on the old addresses don't transfer. They evaporate.

Google is direct about this in its site-moves documentation, updated in March 2026. It tells you to "keep the redirects for as long as possible, generally at least 1 year," because the redirect is how signals move from the old URL to the new one. And here's the part people get backwards: redirects don't dilute your rankings. Google states plainly that "permanent redirects don't result in a loss of PageRank," and that "the indexing pipeline uses the redirect as a signal that the redirect target should be canonical." The danger isn't redirecting. The danger is not redirecting, or redirecting to the wrong place.

The classic wrong place is the homepage. When a team is in a hurry, they'll sometimes point every retired URL at the homepage to "catch" the traffic. Google can treat that as a soft 404, which means the authority you're trying to preserve gets thrown out instead of forwarded. A redirect only helps when it points to the page that actually replaced the old one.

What are the most common causes of lost rankings after a redesign?

Redirects are the headline, but they aren't the only way a relaunch goes sideways. Here are the causes I check, what each one does, and the signal that tells you it's your problem. Most of these are documented by Google. A couple are my own judgment from doing this work, and I'll flag those as judgment rather than dress them up as cited fact.

What broke	Why it costs you rankings	How to tell if this is you
Missing or wrong 301 redirects	Old URLs 404 and lose their history; homepage redirects can read as soft 404s (Google-documented)	Old URLs return 404s or all land on the homepage; Search Console shows a Not Found spike at launch
noindex or robots.txt left from staging	Tells Google to stop indexing or stop crawling the whole site (Google-documented)	View Source shows a robots noindex meta tag; the live robots.txt has Disallow: / ; indexed pages drop sharply
Content removed or thinned	Pages lose the depth and helpfulness that earned their rankings (aligns with Google's helpful-content guidance)	Compare archived versions of top pages against new ones; word count, headings, or FAQs got cut
URL structure changed without a map	Every rewritten URL starts as a new, unrecognized page (Google-documented)	Spot-check old URLs from a pre-launch export against the live site for 404s
Lost titles, metadata, and headings	Google has fewer relevance signals; title tags feed both ranking display and click-through (Google-documented)	Crawl the new site for missing or duplicate titles, blank descriptions, and missing H1s
Lost structured data / schema	Removes rich-result eligibility and machine-readable entity clarity (Google-documented)	Run Google's Rich Results Test before and after; check Search Console Enhancements for new errors
JavaScript-rendered content not crawlable	Content sits in a render queue or stays hidden; JS-set canonicals and noindex may be ignored (Google-documented)	Use the URL Inspection live test to see what Googlebot renders vs. the raw HTML
Duplicate URLs and canonical errors	Signals split across HTTP/HTTPS, www/non-www, and slash variants instead of consolidating (Google-documented)	Search Console flags "Duplicate without user-selected canonical"; test the URL variants by hand
Lost internal linking and architecture	Googlebot loses crawl paths and the link flow that signaled which pages matter (Google-documented for crawlability)	Crawl for orphan pages with no inbound internal links; compare the old nav and in-content links
Core Web Vitals regression	A real tiebreaker in close calls, though Google weighs relevance first (Google-documented)	Run PageSpeed Insights before and after; check the Core Web Vitals report in Search Console

A few of these deserve more than a table row.

The staging block that rides to production

This is the most insidious one, because the site looks fine. Staging environments are usually protected with a noindex meta tag or a robots.txt that says Disallow: / so Google never indexes the work-in-progress. If that protection ships to production, you've quietly told Google to stop indexing or crawling your live site. Google's documentation on blocking indexing adds a nasty wrinkle: "If a page is blocked by a robots.txt file or the crawler can't access the page, the crawler will never see the noindex rule." So a robots block and a noindex tag can interact in ways that don't behave the way anyone intended. Either way, pages start falling out of the index within days to weeks, by which point the launch team has moved on to other work.

Content that got "simplified"

Redesigns love a clean look, and a clean look often means cutting copy. The FAQ gets removed. The long explainer gets trimmed to a paragraph. Old blog posts get dropped instead of migrated. Here's my honest take, and I'll mark it as judgment rather than a Google citation: thinning content during a redesign is one of the most underestimated causes of a quiet ranking slide, because nobody connects "we made it prettier" with "we deleted the substance that ranked." The pages that earned their position earned it partly on depth. Strip the depth and you strip the signal. Compare your old top pages against the new ones in an archive and you'll usually see it.

JavaScript that hides your content

Migrating to a heavier JavaScript framework can tuck your real content behind a rendering step. Google's JavaScript SEO documentation, updated in March 2026, describes the render queue and warns that "the page may stay on this queue for a few seconds, but it can take longer than that." It also says, plainly, that "server-side or pre-rendering is still a great idea," and that canonical or noindex tags set by JavaScript may not be processed reliably. If your headings, body copy, and links only appear after scripts run, use the URL Inspection live test to confirm Googlebot actually sees them.

Does a botched migration hurt your AI search visibility too?

This part gets missed, and it shouldn't, because it's the same problem with a second consequence. The work of showing up in Google and the work of showing up in AI answers are not two tracks. They're one. When a migration blocks crawling or drops pages from the index, it pulls you out of AI Overviews, AI Mode, and the AI assistants people increasingly ask first, at the exact same moment it pulls you out of classic search results.

Google says so directly. Its AI optimization guide, published in June 2026, tells you to "ensure your content is crawlable, as Google Search generative AI models use publicly accessible, crawlable content to learn patterns." Google's documentation on AI features adds that pages must be "indexed and eligible to be shown in Google Search with a snippet" to appear in those features at all. So the staging robots.txt block that hides you from organic search hides you from AI answers too. Same root cause. Double the damage.

Schema is part of this picture. Google's guide is honest that structured data isn't required for generative AI features, so I won't overstate it. But the entity clarity that schema provides is exactly the machine-readable signal that helps engines understand what your pages are about, and a redesign that strips it removes a layer of that clarity right when you can least afford to look unfamiliar to the systems deciding whether to cite you. For the work I do, protecting search visibility and AI visibility through a migration isn't two jobs. It's one.

How do you prevent ranking loss during a redesign, and what should you do if it already happened?

Here's the uncomfortable truth. Almost everything above is a pre-launch problem, not a post-launch one. The redirect map, the metadata migration, the schema carry-over, the crawl check on the staging build, verifying both old and new sites in Search Console before you start: all of it is cheaper, faster, and more complete when it happens before the site goes live. Recovering rankings after the fact is the hard version of the same work, and sometimes you don't get all of it back.

If you're planning a redesign and haven't launched yet, this is the moment to get it right. The fuller version lives in my walk-through on how to migrate a website without losing search rankings, but the short version is a real URL map, server-side 301s for every changed address, titles and descriptions and headings carried over, schema preserved, internal linking kept intact, and a crawl of the staging build to confirm nothing important is blocked or missing. Google's site-moves guidance also recommends changing one thing at a time where you can, rather than stacking a CMS change, a domain change, and a redesign into one weekend.

If you've already launched and you're reading this in a panic, start with the diagnosis order above: redirects first, then the staging block, then content, metadata, and schema. Fix what you find, then give it time, honestly. Google's site-moves documentation says "a medium-sized website can take a few weeks for most pages to move in our index; larger sites can take longer," and it tells you to "expect temporary fluctuation in site ranking during the move." I won't hand you a recovery date, because Google doesn't publish one and anyone who quotes you an exact number of days is guessing. What's true is this: some wobble right after launch is normal. A sustained, multi-week decline is a signal that something is actually broken and waiting won't fix it.

This is the kind of problem a migration-and-launch engagement is built to catch before it ever costs you traffic, across both search and AI visibility, because for the work I do those are the same job. If a redesign is on your calendar, or one already cost you rankings, that's worth a conversation. If you're still deciding whether an independent SEO consultant is the right fit for the work, that question has its own breakdown at Do You Need an SEO Consultant?. You can also see how I approach launches, migrations, and technical SEO if you want the shape of the engagement first.

The design isn't usually what tanked your rankings. It's what happened to the plumbing underneath while everyone admired the design.