Why did your Google rankings drop after the website redesign?
Most rankings lost after a redesign trace to three causes: old URLs that changed without permanent 301 redirects, pages whose content was cut or merged away, and a staging block (a noindex tag or robots.txt rule) left on the live site. Some movement in the first few weeks is normal while Google recrawls, and a drop can also be a tracking change rather than a ranking one. Search Console, GA4 and an archived copy of the old pages separate these without waiting on your vendor.
What it usually means
Start with the innocent explanation, because sometimes it's the whole story. Google's own site-move guidance says to expect ranking fluctuations while it recrawls and reindexes a changed site, and that on a medium-sized site it can take a few weeks or more before the new URLs replace the old ones in results. A dip in the first two or three weeks, with every old address still resolving to its new equivalent, is usually that. So is a drop that lines up with a seasonal lull you'd see in the same month last year, or with a Google ranking update that started the same week.
The second innocent explanation isn't a ranking problem at all. The analytics tag lives in the site template, and a redesign replaces the template. If the tag was left off a page type, swapped for a new property's ID, or now waits on a new consent banner, your analytics will report an organic collapse while Google is sending exactly as many clicks as before. That's why the first comparison below puts Search Console against GA4 before anything else: one of them measures Google, the other measures your tag.
If both agree the drop is real, the cause is usually one of three, and none of the three needs bad intent to happen. Someone mapped redirects for the pages in the navigation, and the deeper pages left off that list, the ones for a specific process, material or part family, started returning 404. Or the new template had room for less copy, or several pages were folded into one, so the specifics a page ranked for aren't on it any more. Or the block that kept the staging site out of Google shipped to production with everything else. Each is checkable today.
The risk follows the URLs, not the name of the project. A redesign that kept every address and every page's content carries its rankings over; a redesign that reorganized the navigation often changed addresses too, which makes it a website migration whatever the proposal called it. The shape of the drop points at the cause: pages gone from Google wholesale means an indexing block, specific pages gone means missing redirects, and pages still listed but ranking lower usually means the content changed, or the page lost the internal links that pointed at it when the navigation was reorganized. Google says it uses links to judge how relevant a page is, and that "every page you care about should have a link from at least one other page on your site."
What it costs while it stays this way
The evidence has an expiry date. Search Console keeps sixteen months of performance data, and that data is the most complete list you'll get of every old URL that earned impressions before launch, including the deep pages that have been forgotten. Once the launch date slides out of that window, the old URL list has to be rebuilt from GA4's Landing page report (if the old tag was sound), an old sitemap, or archive copies, and none of those records which pages were earning impressions in Google. A site that launched ten months ago has roughly six months left to pull it.
"We set up redirects" isn't the same as redirects that work, and Google's documentation spells out the gaps. Permanent redirects (301 and 308) tell Google the new address should replace the old one; temporary ones (302 and 307) may keep the old address, which no longer exists, in its results. Redirecting many old URLs to the homepage "might be treated as a soft 404 error", in Google's words, which passes the buyer nothing and, in our experience, carries very little of the old page's ranking over. And Google says to keep redirects for as long as possible, generally at least a year; the 301 redirect entry explains why we'd keep them indefinitely.
Every long-tail page that goes missing, whether it covered an alloy, a tolerance, a part family or an industry, was found by someone with a specific requirement, which is exactly the inquiry an established company wants, and none of those losses is visible on launch day. They surface a month or two later as fewer quote requests, and by then hardly anyone connects the dip to the launch.
Recovery isn't symmetrical with the damage. A missing redirect or an indexing block can be fixed the day it's found, but Google still has to recrawl and reassess, so a fix made in a day still takes months to show in full, and a few positions may never return.
How to confirm it yourself
- Get into Search Console under a company login. Sign in to Search Console with a company login first. If the site's property isn't there, that's the first finding, and the same ownership problem as analytics you can't see yourself, but fixing it doesn't need the vendor as long as someone at the company can add a DNS record. If only the vendor can, the domain itself isn't under the company's control, which is its own warning sign. Add a Domain property for the domain (and for the old domain too, if it changed) and verify it with the DNS record Search Console gives you, added at your domain name provider; Google says a manually added record can take up to two or three days to start working. Once it's verified, add a URL-prefix property for each version the site has loaded at (http and https, with and without www); Google verifies those automatically from the Domain property. Google's help says a property collects data from the day anyone first added it, so one the vendor set up before launch brings its history with it. A few days after verifying, check how far back Performance actually goes. If it starts after launch, step 2 has to lean on GA4 alone (if every channel fell at launch, not just Organic Search, suspect the tag), and the old page lists in steps 3 and 6 come from GA4's Landing page report and the Wayback Machine's list of captured URLs for the old site instead.
- Separate a ranking drop from a tracking drop. Open Performance, then Search results. Click the date filter, choose Compare, and set a custom range: the four weeks before launch against the most recent four weeks. Note clicks, impressions, and average position. If any of the before range falls before April 27, 2026, judge on clicks: Google's Data anomalies page for Search Console lists a logging error that affected impressions, CTR and average position, but not clicks, from May 13, 2025 until April 27, 2026. Then open GA4, Reports, then Acquisition, then Traffic acquisition, and compare the Organic Search row for the same two ranges. If Search Console clicks are flat and GA4 fell, the rankings are fine and the analytics tag is the problem. If only the protocol or the www changed, read a Domain property, which covers every protocol and subdomain of one domain, so both ranges sit in one report, provided it was added before launch; if it wasn't, add up the figures from the old and new URL-prefix properties. If the domain itself changed, no single property holds both ranges: read the before range in the old domain's property, and for the after range add the new domain's clicks to whatever the old property still shows, since Google keeps listing some old URLs while it recrawls. While you're in the old property, open Settings, then Change of address: Google shows a move-in-progress notice in both properties for 180 days after a move is submitted, so a launch less than 180 days ago with no notice means the move was never submitted.
- Find the pages that lost the most. Still in the Performance comparison, open the Pages tab. When two ranges are compared, the table adds a Difference column; sort by the clicks difference and read the top twenty losers. If the domain changed, there's no single comparison to sort: export the Pages tab from each property for its own range and line the rows up by path in a spreadsheet. Note whether each is an old address that no longer exists or a new page that ranks worse, because those two lists get different fixes. An old address shows a full loss even when its redirect works, since Google now credits the clicks to the new URL, so check whether its new equivalent gained about as much before counting it as a missing redirect.
- Check what Google says it can't index. Open the Page indexing report (Indexing, then Pages in the left menu) and read the reasons listed under why pages aren't indexed. A jump in "URL marked 'noindex'" or "URL blocked by robots.txt" after launch is the staging block; a robots.txt block can also show up in the Improve page experience table, where the report lists its warnings, as "Indexed, though blocked by robots.txt". A jump in "Not found (404)" or "Soft 404" is missing or lazy redirects. "Page with redirect" on old URLs is expected and fine.
- Inspect two live pages directly. Paste the homepage into the URL Inspection bar at the top of Search Console. In the indexed result, open Page indexing and compare the user-declared canonical with the Google-selected canonical; a canonical pointing at a staging hostname is its own launch-day accident. Then click Test live URL and read "Crawl allowed?" and "Indexing allowed?", which shows what Google would see on the page today. If "Crawl allowed?" says No, ignore the Yes under "Indexing allowed?": Google can't see a noindex on a page it isn't allowed to crawl. Repeat for one important capability page.
- Rebuild the old URL list and test the redirects. In Performance (in the old domain's property, if the domain changed), set the date range to the months before launch, open the Pages tab, and use Export. That's your list of old URLs that actually earned traffic, up to the 1,000 rows Search Console will export. If the export stops at exactly 1,000, the long tail was cut off; the Search Console connector in Looker Studio, or the Search Console API, returns up to 50,000 rows a day. Open the top twenty or thirty in a browser: each should land on its closest equivalent page, not the homepage and not a 404. To confirm the redirect is permanent, run the old URL through any online HTTP status checker (or curl -I) and look for 301 or 308.
- Compare a dropped page with its old version. For any page that still exists but slipped, look up its old URL on the Wayback Machine at web.archive.org and put the two side by side. Check the title tag, the main heading, the subheadings, roughly how much text there is, and whether the old menu linked to the page where the new one doesn't. A page that went from eight hundred words of specifics to a hero image and two paragraphs lost the thing it was ranking for.
- Rule out a coincidence before blaming the launch. Check Google's Search Status Dashboard at status.search.google.com for a ranking update that started the week of your drop, and check your main terms on Google Trends for a demand change. Open the Manual actions report in Search Console too; it should say no issues were detected.
What the vendor's answers actually mean
Raise a traffic drop after launch and the replies come in a few familiar shapes. Some of them are partly true, which is what makes them work. Here's what each one commits to, and what to ask next.
“It's normal for rankings to dip after a launch. Give it a few weeks.”
True for fluctuation, and Google says so. It isn't true for old URLs returning a 404, pages marked noindex, or a whole section gone from the index, none of which recover by waiting. Ask for the redirect map and a screenshot of the Page indexing report; if both are clean, waiting is reasonable.
“We set up all the redirects.”
Ask for the spreadsheet. "All" usually means every page in the navigation, and the losses are in the deep pages that weren't. Check whether the old URLs go to their equivalents or to the homepage, and whether they return 301 or 302.
“It's probably a Google algorithm update.”
Checkable in two minutes on the Search Status Dashboard. An update can move the ranking of a page that exists; it can't make an old address return a 404 or add a noindex tag. If the drop is concentrated in URLs that changed, the update isn't the cause.
“SEO wasn't part of the redesign scope.”
Possibly true of an ongoing SEO retainer, and not the same thing. Redirecting the addresses a site replaces is part of launching a site at new addresses, the way forwarding mail is part of moving. Read the contract, then ask for the redirect work as launch cleanup rather than as a new SEO project.
“We consolidated the old pages because they were outdated.”
Consolidation is often the right call. It works when every old URL redirects to the page that absorbed it and the useful specifics came across. It becomes content thinning when five detailed pages became one short one. The Wayback Machine comparison settles which.
What actually fixes it
Work in the order the causes do damage. Indexing blocks first: if the live site carries a noindex tag or a robots.txt block, that's a single configuration change, and Google's own migration guidance treats noindex rules and robots.txt blocks used during development as things to remove when the move starts. Then missing redirects, starting with the old URLs that earned the most clicks, each old address sent with a permanent 301 to its closest equivalent, no chains, and no bulk redirect to the homepage. If the domain changed and the move was never submitted, submit it with the Change of Address tool in the old domain's Search Console property, which needs Owner access to both properties under one Google account, the 301s already in place, and a separate submission for each version of the old domain, www and non-www. None of that needs a judgment call, so all of it belongs in the week it's found.
Content comes next, and it's slower. For each page that still exists but slipped, restore the specifics it lost: the headings, the technical detail, the title tag that named the thing buyers search for. Where several pages were merged, either bring back the ones that earned traffic or make sure the merged page genuinely covers what each of them said. Then resubmit the XML sitemap in the Search Console Sitemaps report (Indexing, then Sitemaps) and use Request indexing in URL Inspection on the most important fixed pages; there's a daily limit, so spend it on the pages that mattered most.
Set the right expectation for recovery. Redirect and indexing fixes tend to show within a few weeks as Google recrawls; content fixes take longer to register. Check weekly, judge at the 90-day mark as the website migration checklist recommends, and expect months rather than days, with no certainty that every position comes back. The risk in checking daily is reversing a fix before Google has had time to recrawl the pages it touched.
What good looks like next time is boring and written down: a full URL inventory before anything changes, a one-to-one redirect map covering every old address, a ranking baseline taken the week before launch, and an indexing check as the first thing done on launch day. The B2B website launch checklist covers the launch-week order, and the website RFP template asks for the redirect map and baseline in writing before anyone signs.
The message to send
If the checks above turned up old URLs that error or land on the homepage, send this. It asks for files and a date, not for reassurance, which keeps it a normal request instead of an argument.
Hi [name],
Our organic search traffic has dropped since the new site launched on [launch date], and I've traced part of it in Search Console to old URLs that now return errors or redirect to the homepage. I've attached the list.
Could you send the full redirect map as a spreadsheet (every old URL and where it points now), set each of the attached URLs to a permanent 301 to its closest equivalent page, and confirm the live site has no noindex tags, robots.txt blocks, or canonicals left over from staging?
Please also make sure [company email] is an Owner on our Search Console property, not just a user, so we can track the recovery ourselves.
Can we have the redirects and the confirmation by [date one week out]?
Common questions
How long does it take for rankings to recover after a website redesign?
It depends on the cause. Fluctuation from recrawling usually settles within a few weeks; Google says a medium site can take a few weeks or more for new URLs to replace old ones. Recovery from missing redirects or cut content takes months once fixed, and some of it may not return. Give it a full quarter before deciding whether the fixes worked.
Does a website redesign always hurt SEO?
No. If every old address still works and every page still says what it said, the rankings usually hold. The risk comes from changed addresses without redirects, content cut in the new template, and launch-day indexing mistakes. A redesign that reorganizes navigation often changes addresses, so it needs the same redirect map a rebuild does.
Can redirects still help if the site launched months ago?
Yes, and sooner is better. Old URLs are still in other companies' links, in PDFs and in bookmarks, and each one that now returns a 404 is a dead end today. How much ranking returns after a long gap can't be predicted, but a redirect costs minutes and a missing one keeps costing. Pull the pre-launch URL list from Search Console while its sixteen months of performance data still reach back before the launch.
Should we roll back to the old website?
Rarely. Missing redirects, cut content and a leftover staging block can all be fixed on the new site, and a rollback is a second URL change on top of the first. The exception is a new site so broken that the fixes would take longer than restoring the old one at its original addresses, which is uncommon and worth a second opinion before doing.
Why did rankings drop if the redirects are all in place?
If the redirects check out, look at content, internal links and indexing. Check Search Console's Page indexing report for noindex or canonical problems, and compare the pages that slipped with their archived versions for lost text, headings, title tags, or the menu and related-page links that used to point at them. Redirects move ranking signals to the new address; they can't restore what a page no longer says.