What to do when a website relaunch loses rankings & traffic
- A drop in traffic after a website relaunch is almost never one cause on its own, it is usually three or four separate problems stacked on top of each other and it happens because the initial scope of work wasn’t well defined & the right success measurements weren’t put in place.
- Before you spend a dollar on recovery you need to establish the actual date the traffic stopped & be very specific about it to then measure from. Changes in traffic or visitor behaviour can be seen within a day or so while ranking changes can take weeks.
- Some of this damage is recoverable within a few weeks, some of it takes months of work and some of it is gone permanently so knowing which category you are in changes what you should do next
- The single biggest predictor of how much you get back is how long the problem stayed in place before anybody looked at it properly
- Most recovery plans fail because they are ordered by the size of the traffic drop rather than by what the lost pages were actually worth to the business
- As a marketing consultant I have been engaged to fix this specific situation across trades, professional services, retail, automotive, publishing and B2B so the patterns I see repeated are remarkable consistent.
The problem I see many business owners go through
There is a particular type of enquiry I have taken more times than any other over the years, and it always arrives with the same tone of controlled panic in it.
A business has just spent somewhere between five and fifty thousand dollars on a new website, everybody involved is pleased with how it looks from a visual perspective but then somewhere between two weeks and three months after launch the enquiries stop coming in like they were before.
When the owner finally goes looking at the data (or asks their agency/contractor or marketing manager to) one of the obvious things they see is that organic search traffic that used to bring in enquiries has decreased so rapidly there is little to no traffic at all. The common excuse that I hear for this is “that this is normal and that it will settle down.”
Only a small portion of that is true because if the right pre-work was done it should have remained fairly steady.
Google’s own documentation on moving or changing a site with URL changes is explicit that you should expect temporary fluctuation in site ranking during the move, and that for a small to medium sized website it can take a few weeks for most pages to move across properly.
What is not normal, and what I see constantly, is a decline will persist for months, or one that stabilises at a level well below where the old site sat, or one where the pages that used to bring in paying customers simply no longer exist, not in Google’s index at all or were changed so dramatically they don’t convert visitors into leads anymore.
This guide is the process I actually work through when somebody puts that problem in front of me as a marketing consultant.
It is written so that you can run the first half of it yourself without paying anybody anything, because a surprising number of these situations turn out to have one obvious cause that anyone can find in twenty minutes if they know where to look. The second half is harder, and I am going to be honest with you about why.
One thing worth saying before we start
You will find articles online claiming that some specific percentage of website redesigns lose search traffic, and you should ignore every one of them. That number does not exist and cannot exist, because there is no central registry of website relaunches anywhere in the world, no master record of which sites were rebuilt and when, and no mechanism by which anybody could sample the whole population of businesses that have relaunched a site and measure what happened afterwards.
Anyone quoting you a figure has either invented it or is repeating somebody else’s invention, which is a useful early signal about how much of the rest of their advice you should trust.
What I can tell you is what I have seen directly, which is that I have personally been brought in to diagnose and repair this exact situation on at least 10 occasions for separate businesses and that in most cases the owner had no idea anything was wrong until well after the damage was done.
The reading of that is not that the problem is rare, it is that there are almost certainly thousands of businesses with this situation right now who have never connected their low enquiry levels directly to changes made to the website they paid for months ago,.
Plus, nobody will tell or show them because nothing in the process is there for that, the developer or agency got their money probably.
First, work out whether the relaunch actually caused it
This is the step that almost nobody takes and it is the one that saves the most money, because there are at least three completely different things that produce a chart shaped like the one you are looking at in the screenshot above from one of my clients and the remedy for each of them is different.
- The first possibility is that the relaunch broke something, which is what you are assuming and what is most often true. Meaning the page content, headings, URL structure or something else had significant changes and without old pages redirecting to new ones.
- The second is that one of Google’s ranking updates rolled out near your launch date and did the damage independently of anything your web developer touched.
- The third, which sounds too simple to be worth checking until you have watched a business spend fifteen thousand dollars not check it, is that demand for what you sell has genuinely shifted, either seasonally or structurally, and the website is performing exactly as it always did against a smaller market or during a low demand period which is normal. So any measurements have to be looked at year on year as well as period vs period.
The way you separate these is to stop looking at the launch date and go and find the date the traffic actually started slowing down.
- Open Google Search Console, set the performance report to the longest range you have available, and look at where the line changes direction. In my experience the break date and the launch date are rarely the same day, and the gap between them is diagnostic in itself.
- A break that lands within a few days of launch usually means redirects or indexing. A break that begins two or three weeks after launch and then continues downward for a month is much more likely to be the slower process of Google recrawling the site, finding thinner pages than it had before, and reassessing them.
- A break that has no relationship to your launch date at all is telling you something important, and you need to hear it before you start blaming people.
- Then take that break date and check it against Google’s own published record of ranking updates, which lives on the Google Search status dashboard and lists every Core update, Spam update and Discover update with its start date and duration.
- If you relaunched in the second half of May 2026, for example, you are going to want to know that the May 2026 core update began rolling out on 21 May and ran for close to twelve days, and that the March 2026 core update started on 27 March and ran for over twelve days, because a rebuild that went live inside either of those windows has two candidate explanations rather than one.
- I have sat in meetings where a developer was being blamed for a core update, and I have sat in others where a core update was being used as cover for a genuinely broken migration, and the only way to tell the difference is to look at the dates properly.
- The other trap in this step is misreading the chart itself, which is easier to do than most people expect, particularly when the reporting was reinstalled during the rebuild and the before and after periods are not measuring the same thing. I have written separately about how website data without context can present a false positive, and the same logic runs in reverse here, because a false negative is just as expensive.
- If you relaunched in the second half of May 2026, for example, you are going to want to know that the May 2026 core update began rolling out on 21 May and ran for close to twelve days, and that the March 2026 core update started on 27 March and ran for over twelve days, because a rebuild that went live inside either of those windows has two candidate explanations rather than one.
- If your analytics property was recreated at launch, if the tracking code sat broken for the first three weeks, or if the old site was counting sessions differently, then part of the drop you are looking at is measurement rather than reality, and you need to know how much before you start commissioning work.
If it turns out that a ranking update is genuinely part of what happened to you, that is a different piece of work with a different shape to it, and I have covered what that means and what to do about it in what a Google core update actually means for your business.
If any of the above explanation seems confusing or is too hard to figure out that is when you get me to do a digital marketing audit. In a scenario like this I look at what was happening before, what was created for the new website, how the migration was handled and what the data is showing now.
You get a summary that is clear, actionable and with screenshots to argue your position with the people responsible.
The five hours after launch that decide most of it
Assuming you have established that the relaunch is implicated, the next step is the one that most often produces an immediate answer, because a large proportion of catastrophic post relaunch drops come down to a small number of technical failures that are trivially easy to check and, once you find them, embarrassingly easy to fix.
Google publishes a list of the mistakes it sees most frequently during site moves, and it is worth reading in full, but the ones I find on live client sites over and over again are these.
- The old URLs are not redirecting to the right places. If your rebuild changed any URLs, and almost every rebuild does, then every single old address needs to point at its closest equivalent on the new site using a permanent server side redirect. Google’s guidance is specific that redirecting a large number of old URLs to one irrelevant destination such as the homepage can be treated as a soft 404, which means those pages are not just failing to pass their value across, they are being actively discounted.
I have opened up more than one rebuild where the entire old site had been swept into a single homepage redirect because it was faster to configure that way, and the person who did it either did not know it was harmful or was just being lazy.
- The staging site is still live and indexable. When a site is built on a temporary subdomain and that subdomain is never taken down or blocked, you end up with two copies of your content competing with each other, and Google gets to choose which one it prefers.
I have found live, crawlable staging environments sitting on client domains months after launch, and I have found them on my own site too, which is why I now check for it as a matter of routine rather than assuming that the person who built it remembered.
- A noindex rule or a blocked robots.txt survived the push to production. Development sites are commonly blocked from crawling while they are being built, which is sensible, and the block is then supposed to be removed at launch, which it frequently is not.
This is the single most brutal version of the problem because the site looks perfect to every human who visits it while being entirely invisible to search, and it can run for months without anybody noticing.
- The sitemap was never resubmitted. The new sitemap needs to be submitted in Search Console so that Google can discover the new URLs efficiently, and the old one can then be removed. I have audited sites where no sitemap had ever been submitted at all, including one renovation builder whose historical search performance made a great deal more sense once I found that out, and I documented that work in the renovation builder local marketing case study.
- Nobody kept the redirects in place long enough. This one catches people who did everything right at launch and then undid it six months later during a tidy up. Google’s documentation asks you to keep redirects for as long as possible and generally for at least a year, because that timeframe is what allows all the accumulated signals to transfer across, including the links other websites are still pointing at your old addresses.
From a user’s point of view the advice is to consider keeping them indefinitely. Ripping them out at the three month mark because the redirect file looked messy is a decision I have had to explain the consequences of more than once.
- The new website was designed on a large screen & nobody checked if the site worked on tablet or mobile phone. I have seen this happen, in fact I just completed a website content update for one client where the VA updated their money making tour page but didn’t check if it worked on mobile phone.
More than 80% of their traffic arrived on mobile for a tour worth $8,000 per person but engagement time dropped from around 2 minutes to under 30 seconds, that is how poor the update was.This has cost them enquiries no doubt but the owner nor the VA had any idea until I pointed out the discrepency in the data.
If you want to work through your own site’s indexation status properly, I recorded a full session on what you can use Google Search Console for which covers the specific reports that answer these questions.
There is one more item on this list that is not technical at all.
Google’s site move guidance includes a recommendation to change only one thing at a time, and to sequence a domain change, a platform change and a design change rather than doing them together. Almost nobody does this, because it is slower and more expensive and the whole point of a rebuild is that everything gets fixed at once.
The consequence of ignoring it is not that the rebuild fails, it is that when something does go wrong you have no way of isolating which of the four simultaneous changes caused it, and the diagnosis becomes guesswork.
What the relaunch removed that you did not notice
If the technical checks come back clean, or if you fix everything you find and the traffic still does not come back, then you are dealing with the more interesting version of this problem, which is that the new site is technically healthy and simply contains less of what was working.
This is the category of loss that is genuinely invisible if you compare the old site to the new one visually, because the new one almost always looks better. It is also the category that produces the enquiries I find most satisfying to work on, because the fix is real marketing work rather than a configuration change.
- Content volume gets cut because thin pages look untidy. Somewhere in most rebuild processes there is a conversation about consolidating pages, and it is usually framed as improving the user experience by reducing clutter. The pages being consolidated are frequently older, plainer, less designed pages that happened to be the only thing on the site ranking for a long tail phrase that a real customer types.
Nobody checks that before deleting them, because checking requires pulling the query data first, and the rebuild brief did not include that.
- Internal linking gets stripped by a cleaner navigation. A new template with a tighter menu structure removes the contextual links that used to sit inside body copy and point at service pages. Those links were doing work. Removing them does not just reduce the paths a visitor can take, it changes how authority moves around inside your own site, and service pages that used to be well supported end up isolated.
- Body copy gets replaced by design. This is the most common single cause I encounter in the non technical category. A page that used to carry nine hundred words explaining a service in specific, useful detail becomes a hero image, three icons with four words underneath each, and a button.
It looks considerably more professional and it now says almost nothing that a search engine can retrieve or that a customer can use to decide whether you are the right choice.
- Title tags and headings get regenerated by the theme. New build, new SEO plugin, default templates applied site wide, and the specific phrasing that had been matching real queries for years is replaced by a pattern. I check for title tag and H1 mismatches on every site I audit now because I find them so reliably.
- Structured data disappears with the old theme. Schema markup that was baked into the previous build is rarely carried across deliberately, and its absence is silent.
- Speed regresses because the new site does more. New page builder, more plugins, uncompressed hero video, a booking widget, a chat tool, a review carousel. I have documented exactly how this accumulates in how this business owner made their website slower, where a series of individually reasonable additions produced a genuinely poor result, and in how this business owner crashed their WordPress website, where the attempt to fix speed with a plugin created a worse problem than the one it solved.
- Everything a real human wrote gets treated as clutter. Case studies, project pages, testimonials with names attached, the detailed version of the about page, photographs of actual work rather than stock imagery. This material is the hardest thing on your website for a competitor to copy and the easiest thing for a designer to characterise as legacy content.
It is also, increasingly, the material that gets surfaced and cited when somebody asks an AI assistant for a recommendation rather than typing a query into a search box, which I have gone into properly in how AI search is changing how customers find your business.
I am about to start a consultation with a business in New Zealand that produces site measured building plans for commercial property, and their situation is a textbook version of this whole section.
- Their previous marketing team rewrote all of their materials to suit generic search optimisation, removed the physical sample plans from the website entirely, and changed the site’s format so substantially that existing clients could no longer find their way around it when they went looking for something themselves.
- Those physical samples were the single most persuasive asset the business had, because the entire differentiator in that market is the level of detail in the drawings and the fact that every plan is measured on site to a recognised method of measurement rather than estimated. Removing the samples removed the argument.
- The site now generates no leads at all, in a business where roughly sixty percent of revenue comes from one specific product line that has genuine search demand behind it, and the owner is still getting referrals from clients he worked with under a previous business entity because the relationships are strong and the product is good.
That is a business with everything it needs to succeed online and a website that has been actively stripped of the ability to demonstrate it.
The reason I include that example rather than a cleaner one is that it shows the shape of the real problem.
Nothing was technically broken. The redirects were not the issue. Somebody made a series of decisions that each sounded defensible in a meeting and collectively removed the reason a customer would choose this business over the four competitors named in the same conversation.
The mistakes that make the damage permanent rather than temporary
Here is the part you actually came for, which is what can still be salvaged. The honest answer is that it depends almost entirely on which of three categories your particular problem falls into, and that the variable which decides the category is not the severity of the mistake but how long it has been running.
- Recoverable, usually within weeks. Redirect errors, noindex rules, blocked crawling, sitemap problems and regenerated title tags all sit here. These are configuration failures rather than content failures, the fix is definitive rather than gradual, and once Google recrawls the affected pages the recovery tends to be fast and close to complete.
If you find one of these and it has only been running for a matter of weeks, you have been lucky, and you should go and fix it today rather than reading the rest of this.
- Recoverable, but slowly and only with real work. Lost content depth, stripped internal linking, missing structured data and speed regressions all sit here. Nothing about these is unfixable, but the fix is to rebuild the substance that was removed, which takes months rather than days, and it only works if it is done properly rather than partially.
I have watched the partial version fail often enough to have written a separate piece about it, because fixing half a website problem fixes nothing in a way that surprises people who expected to get half the result back for half the effort.
- Often not recoverable at all. Pages deleted with no equivalent and no redirect, where the content itself is gone and nobody kept a copy. A domain change stacked on top of a redesign stacked on top of a platform migration, where the compounding makes the individual causes impossible to isolate.
Months or years of drift before anybody looked, during which competitors moved into the positions you vacated and built up their own history there.
The hardest one, which is a rebuild that changed what the business appears to be about, because you are no longer trying to recover rankings for the thing you used to rank for, you are trying to establish new ones for something different.
The reason time matters more than severity is straightforward when you see it laid out.
A redirect error caught in week one costs you almost nothing, because the old positions are still warm and the pages come straight back. The identical error found in month nine has cost you nine months of accumulated signal, and in the meantime somebody else has been sitting in your search results collecting your customers and building their own track record in that position.
You are not restoring something now, you are competing for it against an incumbent who was not there before your relaunch.
This is also where I have to be direct – if a redesign wiped out a technical and content foundation that took a year to build, getting back to where you were is frequently a bigger job than the original work was, and the business has already spent its budget on the rebuild that caused the problem.
I have had that conversation with clients whose earlier work with me was undone by a later redesign somebody else delivered, and it is genuinely painful for everyone in the room. The published version of that story is in how an agency new website design lost traffic and rankings, and the most expensive version I have documented is how a news website lost twenty five thousand dollars in ad revenue after a redesign, where the loss was measurable directly in money rather than in traffic.
How to decide what to chase first
If you take one thing away from this guide, make it this section, because it is where most recovery attempts go wrong even when everything else has been done competently.
- The instinctive way to build a recovery plan is to sort the lost pages by how much traffic they lost and start at the top. This is almost always the wrong order.
- A blog post that lost four thousand sessions of informational traffic may be worth considerably less to your business than a single service page that lost thirty, because the thirty were people actively looking to buy the thing you sell and the four thousand were people reading something interesting on their lunch break.
- If you spend your first two months rebuilding the blog post because the number was bigger, you have spent your recovery time on the wrong asset.
- A blog post that lost four thousand sessions of informational traffic may be worth considerably less to your business than a single service page that lost thirty, because the thirty were people actively looking to buy the thing you sell and the four thousand were people reading something interesting on their lunch break.
- The correct order is by commercial value of the lost query, which means you need to know what the old site was ranking for, which pages served those queries, what those queries were worth, and which of them are still worth having given whatever has changed in your market since. That is four separate pieces of analysis and each of them requires judgement rather than a tool.
It is also worth being realistic about what a restored ranking gives you, because getting a page back into position is not the same as getting the work back. I have seen recovered rankings that produced no clicks at all, either because the search result was now sitting underneath an AI overview that answered the question outright, or because the title and description that had been regenerated during the rebuild were no longer giving anybody a reason to click.
I went into that specific gap in what happens when good rankings stop getting clicks, and the related trap of treating position as a proxy for value in why number one on Google does not always mean anything.
What to ask the people who built it
At some point in the next few days (I’ll assume this has just happened to you) you are going to have a conversation with your developer or your agency or website designer about this, and if you go into it without specifics you won’t get anywhere. Worse still they may not even know what is happening..
Here is what to ask.
- Ask them to send you the redirect map as a file, not to describe it or to reassure you that it was handled. A real redirect map is a two column list of every old URL and its new destination, and if one does not exist then the redirects were done by pattern or by guesswork, which is worth knowing.
- Ask them which URLs from the old site have no destination on the new one, and what those pages used to be. This is the question that surfaces deleted content, and it is the one most likely to produce a long pause.
- Ask them what the indexed page count was before the relaunch and what it is now. If they cannot tell you, they were not watching, and Google’s own guidance on monitoring a site move is specific that you should be tracking exactly this on both the old and new properties as the move progresses.
- Ask who owns fixing whatever turns up, and at whose cost. Ask it early and get the answer in writing, because the moment a diagnosis exists the conversation about responsibility becomes considerably harder to have calmly.
The reason I am giving you those four questions rather than a longer list is that they are the four that cannot be answered with reassurance.
Everything else in this conversation can be met with a version of it takes time for Google to catch up, which is true enough in general to be hard to argue with and useless in your specific case.
I have watched a lot of business owners lose this conversation, and I have written about the broader version of the problem in why a developer alone cannot fix your SEO problem, where a technically competent developer was working conscientiously on exactly the things that were not causing the decline.
If the conversation goes badly, or if the answers you get do not match what you can see in your own data, that is worth taking seriously rather than talking yourself out of. I have collected enough examples of how that plays out to have written how marketing agencies bait and switch clients, and I would rather you read it before the next invoice than after it.
What a relaunch done properly looks like instead
None of this is an argument against rebuilding a website, and I should be clear about that because I build them. It is an argument that a rebuild which keeps what was already working does not produce any of the problems in this guide.
When I migrated a commercial property surveying business from Silverstripe to WordPress, the search performance did not dip and then recover, it grew, because the migration was planned around the content and the queries rather than around the design, and the full detail of that work is in the Realserve website migration case study.
The same was true of a Joomla website migration for a motorsport business, where the platform changed completely and the search visibility came through it intact.
The difference in both cases was not technical sophistication.
It was that I pulled the query data before deciding which pages mattered, mapped every old URL to a destination before anything went live, and treated the existing content as an asset with a measurable value rather than as legacy material to be tidied up. That is the whole method together with ensuring the new page content is an improvement on what was there before.
It is not complicated and it is not expensive relative to the cost of the rebuild itself, it is just work that nobody has an incentive to do unless it is explicitly somebody’s job.
Where this guide stops being enough
You can run everything in the first half of this on your own, and if you do, there is a reasonable chance you find something in the technical checks that explains most of what happened. If you do find it, fix it and get on with your life, and I am glad this was useful. Although maybe it isn’t clear cut so you are unsure and that is pretty normal from what I have seen.
What you cannot easily do alone is the part in the middle, which is deciding what order to attack the recovery in when the technical checks come back clean. That requires reconstructing what your old site was ranking for, working out which of those queries still have commercial value in your market as it exists now rather than as it existed when the old site was built, and being honest about which losses are worth chasing and which ones you should write off and replace with something better.
Getting that order wrong does not just waste money, it wastes the window in which recovery is still cheap, and the window closes.
That is the digital marketing audit work that I do.
If you want somebody to look at what actually happened to your site, tell you which category your problem falls into, and give you a ranked plan of what to fix in what order, a one hour marketing consultation is $195 and is usually enough to tell you whether you have a configuration problem or a content problem.
If it turns out you need the full picture, including the query reconstruction and the commercial ranking of what to recover, that is a digital marketing audit at $695, and you get a written report you can hand to whoever is doing the implementation, including the people who built the site in the first place.
You will be dealing with me directly either way.
Frequently asked questions
How long after a relaunch should rankings recover on their own? Google’s guidance is that a small to medium sized site can take a few weeks for most pages to move across, and that some fluctuation during that period is normal. If you are past six to eight weeks and the trend is still downward rather than flattening or recovering, that is no longer settling down, that is a problem, and waiting longer makes it more expensive rather than less.
Can we just put the old website back? Occasionally, and it is worth asking about, but it is rarely as clean as people hope. If the old site still exists as a complete backup and the relaunch was very recent, restoring it can be the fastest route to stopping the bleeding while you work out what went wrong. If several months have passed, or if the domain or platform changed, you now have to migrate a second time to get back, which means running the same risk again with a business that has already been damaged once.
Is it too late if the relaunch was a year ago? It is not too late to improve things, but you are in a different situation to somebody who caught it in week two. The technical failures are still worth finding and fixing because they are absolute. The positions themselves are harder, because competitors have had a year in the results you vacated and have built up their own history there, so you are competing rather than restoring.
Does changing the domain name at the same time make it worse? Yes, and Google’s own advice is to change one thing at a time rather than sequencing a domain change, a platform change and a redesign together. The problem is not that a domain change is inherently dangerous, it is that when three changes go live simultaneously and the traffic falls, there is no way to isolate which one caused it, and the diagnosis turns into an argument between the people responsible for each change.
Why did rankings drop when the new site is faster and looks better? Because neither speed nor visual quality is what was earning those positions. If the rebuild reduced the amount of specific, useful, retrievable content on the page while improving how it looks, then it has made the site better for a visitor who is already there and worse at the job of getting that visitor in the first place. Those are two different problems and a design brief usually only addresses one of them.
Should the agency fix this for free? That depends on what your contract said and how the problem is characterised, which is exactly why the four questions earlier in this guide matter. If the redirect map does not exist, or old URLs have no destination, or the staging site is still indexable, those are execution failures rather than judgement calls but it depends what was in the scope of work you agreed to. If the argument is about content that was removed for design reasons with the client’s approval, that is a harder conversation, and getting the diagnosis documented independently before you have it puts you in a considerably stronger position.
