Traffic dropped after a website redesign? How to recover

If your traffic dropped after a website redesign, the cause is usually technical, and you can usually fix it. The usual suspects are old URLs that no longer 301 redirect, a staging noindex or robots.txt block that went live with the site, and page titles, schema and internal links that didn't survive the rebuild. Check them in that order over the next 48 hours. Start with redirects, because every day they stay broken Google drops more of your old pages. A small dip for a few weeks is normal. A steep drop that doesn't come back almost always has a cause you can find in Google Search Console.

I've been on the build side of this more than once. I rebuilt procol.ai on Next.js, and I moved the Aura Clips agency site from Framer to WordPress on Bricks Builder. In both, URLs, templates, metadata and tracking had to be carried across on purpose. None of it moves over by itself. Here's the order I'd check things in if a launch like either of those went wrong.

Is a traffic drop after a website redesign normal?

A small, temporary dip is normal. A sharp drop that lasts isn't. Google's own site move guidance says to expect ranking changes while Googlebot recrawls your site, and that a medium-sized site can take a few weeks before Google shows the new URLs instead of the old ones. A cliff is a different story: whole sections disappearing, or clicks halving and staying there.

Before you change anything, make sure the drop is real. Compare clicks in the Search Console Performance report with sessions in GA4. If Search Console looks fine and only GA4 fell, the redesign broke your tracking, not your rankings. A missing Google Tag Manager container or GA4 tag is common after a platform switch. On the Aura Clips rebuild I had to set GA4 and Tag Manager up again on the new WordPress site. Changing platform doesn't bring your tracking with it.

What should you check first in the first 48 hours?

Redirects first, then noindex and robots.txt rules, then on-page SEO, then Core Web Vitals, and finish in Search Console. That order gets the most damaging problems out of the way before you spend time on the slower ones:

1. 1

   Confirm the drop

   Compare Search Console clicks with GA4 so you know it's rankings, not broken tracking.

2. 2

   Check redirects (hours 0 to 6)

   Test every old URL with traffic or backlinks. Each should 301 once to the right new page.

3. 3

   Check noindex and robots.txt (hours 6 to 12)

   Look for staging rules in robots.txt, robots meta tags and X-Robots-Tag headers.

4. 4

   Compare on-page SEO (hours 12 to 24)

   Crawl old and new pages for lost titles, headings, schema, canonicals and internal links.

5. 5

   Measure Core Web Vitals (hours 24 to 36)

   Run your key templates through PageSpeed Insights and note where LCP, INP or CLS got worse.

6. 6

   Read Search Console (hours 36 to 48)

   Check the Page indexing report, resubmit your sitemap and request indexing for your top pages.

Are your old URLs returning 404s instead of 301s?

This is the most common cause of a post-redesign drop, and the most expensive one. Every old URL that had rankings or backlinks needs a permanent server-side redirect (301 or 308) to its closest new equivalent. Google's migration troubleshooting table says it frequently sees sites redirecting to wrong or non-existent URLs.

How to check it today:

1. Export your old URLs. Good sources are the Search Console Performance report (Pages tab, with a date range before launch), your old XML sitemap and your backlink report.
2. Test each URL with a status checker or curl -I https://yoursite.com/old-page. You want one 301 that lands on a live 200 page.
3. Flag anything that returns a 404, lands on the homepage or bounces through more than one hop.

Sending everything to the homepage is a tempting shortcut, and it doesn't work. Google says redirecting many old URLs to one irrelevant page may be treated as a soft 404. Chains matter too. Googlebot can follow up to 10 hops, but Google advises redirecting straight to the final destination.

If your new site runs on Next.js, my free Redirect Map Builder turns a list of old WordPress URLs, or old and new pairs, into a redirects() array for next.config.js. Before you deploy, it flags chains, loops, duplicates, trailing-slash mismatches and query strings, and it suggests pattern rules for WordPress archives, feeds and dated permalinks. On WordPress, the same map goes into a redirect plugin or your server config.

Once the redirects are live, leave them alone. Google recommends keeping site-move redirects for at least a year, and for users, indefinitely. I'd just keep them forever. They cost nothing.

Did a staging noindex or robots.txt rule go live?

If pages vanished from Google within days of launch, look for a leftover staging noindex tag or robots.txt block next. Developers hide staging sites from Google, and sometimes the hiding rule ships with the launch. Google's site move documentation lists leftover noindex and robots.txt blocks as a common mistake. Check three places:

• robots.txt: open yoursite.com/robots.txt. A Disallow: / under User-agent: * blocks every crawler.
• Robots meta tag: view the source of a key page and search for noindex. On WordPress, check that "Discourage search engines from indexing this site" under Settings → Reading is unticked. On Next.js, check that the robots field in your metadata isn't still being set by a staging environment variable.
• X-Robots-Tag header: a server or CDN rule can send noindex with nothing visible in the HTML. Running curl -I shows it.

My free AI Crawler Checker reads your live robots.txt and shows, for 14 AI crawlers, whether each one can fetch your home page and which rule decides it. If they're all blocked by the same catch-all User-agent: * rule, Googlebot is blocked too, unless it has its own group. The tool also lists the sitemaps your robots.txt declares, which is a common place for a staging sitemap URL to hide.

The fix takes a minute. Recovery takes longer, because Google has to recrawl each page to see the block has gone. Request indexing for your top pages in the Search Console URL Inspection tool and resubmit your sitemap.

Did the redesign lose your titles, schema and internal links?

If redirects and indexing rules are clean, the redesign probably stripped on-page SEO. Compare what Google sees on the old pages with the new ones. These are the things that tend to go missing without anyone noticing:

• Titles and meta descriptions, which reset to template defaults like "Services | Brand" and lose the keywords that ranked.
• Headings, which get restyled into plain divs or merged, so the H1 disappears or shows up twice.
• Body copy, trimmed so the design looks cleaner. Pages that ranked for detailed answers lose those rankings.
• Structured data. Organization, Product, FAQ or Article JSON-LD often came from an old plugin that nobody reinstalled. Test pages with Google's Rich Results Test.
• Internal links. The new navigation drops deep pages, footers shrink, and links in the content still point at old URLs that now redirect. Google advises updating internal links to the new URLs instead of relying on redirects.
• Canonicals that point to the staging domain or the old URL.

Crawl the old URL list and the new site with a tool like Screaming Frog and you'll see most of this within an hour. To rebuild what's missing, the free Meta Tag Generator and Schema Markup Generator on this site give you a quick first draft of titles, descriptions and JSON-LD.

Did Core Web Vitals get worse after the redesign?

Often, yes. New designs tend to ship heavier: autoplay video heroes, sliders, extra fonts, animation libraries, or a page builder where there used to be hand-written templates. But slower speed rarely causes a sharp traffic drop by itself. Google's Core Web Vitals guidance defines a good experience with these thresholds, measured at the 75th percentile of page loads:

Speed comes after redirects and indexing, not before. Run your main templates through PageSpeed Insights, then paste the report into my free Page Speed Fix Planner for a ranked list of fixes. For WordPress sites, my Core Web Vitals guide covers the usual culprits. Keeping procol.ai's marketing site and landing pages fast on every device is an ongoing part of my job at Procol, and that's taught me to test every template, not just the homepage. The homepage is rarely where the problem is.

What does the Search Console Page indexing report tell you?

It tells you why pages aren't indexed, and after a redesign each status points to a specific fix. This is where the 48 hours end, and you'll keep coming back to it for weeks. Open Indexing → Pages:

Then go to the Performance report and compare the 28 days before launch with the 28 days after, broken down by page. The URLs that lost the most clicks will point you to the template or section that broke. Also check Google's list of ranking updates. If a core update rolled out the same week, part of the drop may have nothing to do with your redesign. Google's guide to debugging traffic drops explains how to read the pattern.

How long does it take to recover traffic after a redesign?

Usually a few weeks once the cause is fixed, but there's no fixed timeline. Google says a small to medium site can take a few weeks for most pages to move, and it handles the move one URL at a time, so a lot depends on how quickly Googlebot gets back to your pages. Fix the cause, resubmit the sitemap, request indexing for your top pages, then check Search Console week by week. If indexed pages and impressions are climbing, you're on track. If nothing has moved after a few weeks and the redirects and indexing rules are clean, the problem is probably content or links lost in the redesign, and that needs a proper audit.

Should you fix it yourself or pay for a technical SEO audit?

If you found one obvious cause, like a robots.txt Disallow: /, fix it yourself. If you found several causes, or none, pay for an audit. Market prices vary a lot:

Those bands come from Refact's 2026 technical SEO audit price guide. SeoProfy puts a typical audit at $500 to $5,000, and RankAI quotes $100 to $300 an hour for experienced SEOs in North America. Site size and platform move the price most, along with whether the fixes are included or you only get a report. A report on its own is less useful than it sounds if nobody on your side can act on it.

What should you ask whoever fixes it?

You want to know how much they'll actually check, whether they'll make the fixes, and how they'll track recovery. These questions cover it:

• Will you check every old URL with traffic or backlinks, or just a sample?
• Will you make the fixes, or hand over a report for someone else to act on?
• Can you show me what Google sees: rendered HTML, headers and canonicals?
• How will you track recovery, and for how long?
• Will I keep full access to hosting, DNS and Search Console?

If your rebuild hasn't launched yet, read how to move from WordPress to Next.js without losing SEO first. It's much cheaper to stop these problems before launch than to chase them afterwards.

Your next step

Check a handful of your old URLs with curl -I to confirm each one returns a single 301 to the right page, and run the free AI Crawler Checker on your robots.txt. If redirects are missing, the Redirect Map Builder builds the map for you. If all of that looks right and traffic is still down, I run paid technical SEO and Core Web Vitals audits for Next.js and WordPress sites. I check redirects, indexing, metadata, schema and speed, rank the problems and fix them. Book a 20-minute call and send me your domain and launch date.