If a website redesign hurt your search rankings, the drop almost always lands seven to twenty-one days after launch, not on launch day. That lag is Google recrawling the site and discovering missing redirects, thinner pages, and leftover staging directives. The cause is nearly always mechanical. Mechanical problems are diagnosable, and they are recoverable.
That matters because the instinct is to blame the designer, the copy, or the new layout. Usually none of those moved. Something specific broke during the migration, and it is almost always sitting somewhere you can check this afternoon. This is the order we work in when a client calls us mid-crisis: start at the top, stop when you find the bleed.
The Pattern: Traffic Falls Off a Cliff Seven to Twenty-One Days After Launch
The tell is the lag. Traffic does not fall the day the new site goes live, it falls a week to three weeks later, because Google reacts to recrawling your site, not to your site changing. Top service pages get recrawled within days; town pages and older posts might not be looked at for two or three weeks. So the decline arrives in waves. Around day seven you lose the pages that earn the most, which is why revenue-relevant traffic drops first. By day twenty-one the long tail catches up and the chart looks like a cliff.
If traffic dropped the same day you launched, that is not a ranking problem, it is a broken analytics tag. The second tell is which pages fell. Pull Search Console, compare the twenty-eight days after launch against the twenty-eight before, and sort by lost clicks. Losses clustered on pages whose URLs changed mean a redirect problem. Losses spread evenly across URLs that did not change mean a content or sitewide problem. That one sort tells you which half of this article to read first.
Missing 301s: The Single Most Common Cause, and How to Find Them in an Afternoon
Missing 301 redirects cause more post-redesign ranking loss than everything else combined, and finding them takes an afternoon, not a retainer. Here is the diagnostic order we use. It works because it does not depend on anyone remembering what the old site had.
Pull the old URL set from two independent sources. Export the Pages report from Search Console covering the sixteen months before launch: every URL that earned impressions, the set carrying real ranking equity. Then run a Wayback Machine CDX query against your domain for the archived URL list, which catches pages that never ranked but still hold links from a supplier directory or an old chamber listing. Search Console misses pages with links but no impressions; Wayback misses pages never archived. Together they are close enough.
Diff the old set against your new sitemap. Normalize both lists to the same host and trailing-slash convention, dedupe, subtract. What is left is every old URL with no counterpart on the new site.
Request each one and record the status code. Not in a browser, where a service worker or a cache can lie to you. Use curl or a crawler and read the raw response. Sort into three buckets: URLs that 301 somewhere sensible, URLs that 404, and URLs that 301 to the homepage.
Test the URL, not the config. This is the step almost everyone skips, and the one that hardened into a rule for us. A redirect in a config file proves nothing about whether it runs: it can be written perfectly and never execute, because the route matcher or rewrite order excludes that URL pattern before the rule is consulted. We shipped exactly this fix on a client site where the middleware matcher excluded every URL containing a dot. A whole set of legacy .asp and .htm redirects had been written correctly, reviewed, and deployed, and not one had ever fired. The map looked complete; as far as any crawler was concerned, the redirects did not exist. So "we have a redirect file" is not an answer to "are the redirects working."
On that third bucket: redirecting a dead URL to your homepage is a soft 404 with extra steps. Google reads it as confirmation the old page is gone, and the equity does not transfer. Point every old URL at its closest real equivalent, and if there is none, let it 404 honestly.
Content That Quietly Got Shorter, and Why the New Design Ate the Copy
The second most common cause is that the new site says less than the old one, and nobody noticed because nobody measured it.
This is a side effect of how redesigns get built. A designer lays out a page with a hero, three service cards, a testimonial strip, and a CTA band. The old page had eleven hundred words about the service, the process, the materials, the neighborhoods served, and the common questions. The new layout has room for three hundred, so the copy gets cut to fit, and a page that answered a query in depth now answers it in a sentence. Google ranked the old page because it was the most useful result. It stops ranking the new one for the same reason.
This hits hardest on the pages quietly doing the most work: service pages, town pages, and older posts that accumulated depth over years. Exactly the pages a designer looks at and thinks "wall of text."
Confirm it in fifteen minutes. Open the Wayback copy of your three biggest losers, count the words against the live version, then compare specifics rather than volume. Did the FAQ block survive? The process steps? The named service areas? The brand and material names? Those specifics matched long-tail searches, and a page can hold its word count while losing rankings if the words went generic.
The fix is not pasting the old copy into the new design. It is giving the new design somewhere to put depth: an accordion, a details section below the fold, a real FAQ block. Same failure as the five signs your business website is losing you customers, triggered by a rebuild instead of by neglect.
Noindex Left On From Staging, and the Other Four One-Line Disasters
A single leftover line from staging can deindex an entire site, and each of these takes under a minute to check.
noindexleft on from staging. The staging build carried<meta name="robots" content="noindex, nofollow">so the half-built site would not get crawled, and it shipped to production. View source on your homepage and search for "noindex". Fastest total wipeout available, so check it first.robots.txtwithDisallow: /. Same origin story. Openyourdomain.com/robots.txt. While you are there, confirm the AI crawlers are not blocked either, a separate lever covered in our guide to whether your site is blocking ChatGPT and other AI crawlers.- Canonicals still pointing at the staging host. The page loads on your real domain but tells Google the real version lives at
staging.agency.comor a.vercel.appsubdomain. Google obeys the canonical, so your live pages become duplicates of a host it cannot index. - A sitemap listing the old URLs, or listing nothing. One submitting URLs that now 404 is asking Google to crawl dead pages; one listing only the homepage is asking Google to find everything else alone. Fetch it and count.
- Password protection or an access wall left on. Deployment protection, basic auth, a "coming soon" plugin. The site works for you because you are logged in. Test in a private window, or with curl and no cookies.
Every one of these is a one-line problem with a sitewide blast radius. Check all five before touching anything harder, because if one is live, nothing else you fix will matter.
Schema, Titles, and Internal Links That Did Not Survive the Rebuild
The third tier of damage is everything that was never visible on the page, which is exactly why nobody notices it is gone.
Title tags. Old sites usually built titles from a template: service, town, business name. New builds frequently ship the same title on every page, or one that is only the business name, or one so long Google rewrites it. Crawl the site, export the titles, look for duplicates and anything past roughly sixty characters. A page that lost its keyword-bearing title slides even when nothing else changed.
Structured data. LocalBusiness, Service, FAQPage, Review, and BreadcrumbList markup lives in code, not in the CMS, so it is the first thing lost in a platform change. You will not see it on the page. You will see rich results vanish from the SERP: no star ratings, no FAQ dropdowns, no breadcrumbs. Run the affected URLs through the Rich Results Test against an archived copy of the old markup.
Internal links. The old site probably linked every service and town page from the footer. Redesigns love a clean footer, and a clean footer often means those links are gone. Pages that were one click from everywhere are now three deep or orphaned, orphaned pages get crawled less, and crawled less means ranked lower. List every sitemap URL with zero internal links pointing at it.
None of this is visible when you look at the new site and think it looks great. It shows up only in a crawl and a diff, which is why "the new site looks better" and "the new site ranks worse" are perfectly compatible statements, and why the post-launch checklist matters more than the launch.
The Recovery Order: What to Fix First When a Website Redesign Hurt Your Search Rankings
Fix in order of blast radius, largest first, because a sitewide directive masks every other problem you are trying to diagnose.
| Symptom | Likely cause | How to confirm |
| --- | --- | --- |
| All pages gone from Google within days | noindex shipped from staging | View source, search for "noindex" |
| Site not crawled at all since launch | robots.txt has Disallow: / | Open /robots.txt in a browser |
| Pages indexed but showing a staging URL | Canonical points at the staging host | View source, check rel="canonical" |
| Only the URLs that changed lost traffic | Missing or non-firing 301 redirects | curl the old URL, read the status code |
| Redirects exist in config but URLs still 404 | Route matcher excludes the pattern | curl the URL itself, never trust the config |
| Same URLs, lower positions, no errors | Content got shorter or more generic | Word-count and specifics diff vs Wayback |
| Rich results vanished from the SERP | Schema lost in the platform change | Rich Results Test vs archived markup |
| Deep pages fading slowly over weeks | Internal links removed from footer or nav | Crawl, list URLs with zero inbound links |
| Traffic dropped on launch day exactly | Analytics tag not migrated | Real-time report, view source for the tag |
The sequence:
- Check the five one-line disasters. Fifteen minutes. If one is live, fix it and request indexing on your top pages. Recovery is often visible in seven to fourteen days, because Google recrawls fast once allowed back in.
- Build the real old URL list. Search Console export plus a Wayback CDX crawl. Half a day. Nothing downstream is trustworthy without it: you cannot redirect URLs you cannot remember.
- Diff, redirect, then test every redirect against the live server. A day. Prioritize by lost clicks, not URL count. Expect movement in two to four weeks.
- Restore lost depth on your top losers. The slowest to pay off, four to eight weeks, because you are re-earning a position rather than restoring a signal. Do the five biggest pages, not all of them.
- Rebuild titles, schema, and internal links. A few days. The compounding tier, and most of the difference between recovering to eighty percent of your old baseline and passing it.
- Resubmit the sitemap, request indexing, then stop touching things. Changing the site daily during recovery makes it impossible to tell which fix worked.
FAQ
How long after a redesign do rankings usually drop?
Seven to twenty-one days. Google reacts when it recrawls, not when you deploy, and top pages get recrawled first, so the decline starts small around day seven and looks like a cliff by day twenty-one. Traffic that fell on launch day itself is almost always a broken analytics tag.
How do I find the URLs my old site had?
Two sources together. The Search Console Pages export for the sixteen months before launch gives you every URL that earned impressions. A Wayback CDX query gives you the archived set, including pages that never ranked but still hold links. Combine, dedupe, diff against the new sitemap.
I have a redirect file. Why are the old URLs still 404ing?
Because a redirect in a config proves nothing about whether it runs. The rule can be perfect and never execute if the route matcher or rewrite order excludes that URL pattern. We shipped exactly this fix on a client site where the matcher excluded every URL containing a dot, so a set of legacy .asp and .htm redirects had never fired once. Test the URL with curl, not the config.
Should I roll back to the old site?
Almost never. A rollback is a second migration stacked on the first and doubles the URL churn Google has to absorb. The exception is a site that is fully deindexed or genuinely broken. Otherwise, patch forward.
Can I prevent this on the next rebuild?
Yes. Freeze the old URL set before launch, build the redirect map from it, and test every redirect against staging instead of reading the config. Capture the old titles, word counts, and schema so you can diff them after cutover. If you are still choosing who does the rebuild, the migration plan is something a real website proposal should spell out.
The Bottom Line
A redesign that tanked your rankings is a migration problem, not a design problem. The site did not get worse at selling, it got worse at being found, and every cause above is mechanical, visible in an afternoon, and recoverable in weeks. The one rule worth carrying out of this: test the URL, never the config. Every redirect map we have been handed looked complete on paper. The ones that actually worked were the ones somebody had requested, one URL at a time, and watched return a 301.
If your traffic is down after a rebuild, book a migration audit. We will pull the old URL set, diff it against the live site, test every redirect against the server, and hand you the fix list in priority order. If the site is converting badly on top of ranking badly, that side is covered in why your contractor website is not getting leads.