Something about the new site is probably making it harder for search engines to reach, index or understand your pages than the old one did. The three things I’d check first are a development setting that’s still telling search engines to stay away, page addresses that changed without proper redirects, and content that got cut or rewritten in the redesign. A big relaunch can cause temporary ups and downs, especially when page addresses change, but don’t assume that’s what you’re seeing until you’ve ruled out the fixable causes. And before you react to the percentage, check whether the loss is on the pages that bring in customers. Start by making sure the drop is real and not a broken tracking code.
The agency I run builds websites, but none of the checks below needs us. Hand them to whoever built yours.
The redesign that went almost invisible
I once got to watch a site’s search traffic fall almost all the way to nothing over the two to three months after it was redesigned. My team didn’t build it, but we had access to the data and could watch it happen in real time.
It was a WordPress site, and the cause turned out to be one setting. The box labelled “Discourage search engines from indexing this site” was still ticked. Whoever handled the launch had missed it, and the new site was telling search engines to stay away.
It’s an easy mistake, because keeping search engines out is the right thing to do while a site is being built. Nobody wants a half-finished site showing up in Google. The trouble starts when that setting survives the launch.
First, make sure the drop is real
A redesign often comes with a new analytics setup, and if the tracking code is missing from some pages or configured differently, traffic can look like it collapsed when it didn’t. Compare your analytics with Google Search Console, which reports clicks from Google directly and doesn’t depend on your tracking code. If Search Console shows clicks holding steady while organic visits in analytics fall off a cliff, suspect tracking first. The two tools measure different things, so they’ll never match exactly, but they shouldn’t move in opposite directions.
If Search Console shows the drop too, look at which pages and searches lost the most, compared with the same period before launch. The shape of the drop points to where to look first:
| What you see | Where I’d look first |
|---|---|
| Clicks from Google fall to almost nothing | Indexing or access: the site is blocked, noindexed or unreachable |
| Only certain pages lose traffic | Those pages: their redirects, canonical tags or the content that changed |
| A gradual slide over several weeks | Content and internal links that changed, or Google still processing the move |
| Analytics drops but Search Console doesn’t | Tracking and reporting |
| Rankings fall with no obvious technical or content change | A Google update, competitors or a change in what people search for |
These are directions to investigate, not diagnoses.
Check that Google can reach and index the site
This is the fastest check and the most damaging problem when it’s there. Ask whoever built the site to confirm:
- The site-wide visibility setting is off. In WordPress it’s a box under Settings, Reading labelled “Discourage search engines from indexing this site.” Other platforms have their own versions. Unticking it doesn’t rule out the rest of this list, because an SEO plugin or template can still add restrictions.
- Important pages aren’t marked noindex, whether in the page’s code or in the server’s response. Noindex tells Google to leave a page out of its results.
- Robots.txt isn’t blocking important pages. It’s a small file at yourdomain.com/robots.txt that controls which pages crawlers can visit. That’s different from noindex: robots.txt controls crawling, noindex controls whether a page appears in results.
- Canonical tags point to the right pages. A canonical tag signals which version of a page you’d like Google to treat as the main one. A launch that leaves them pointing at the staging site, the old domain or the wrong page can send Google elsewhere.
- Pages load properly for Google, without server errors, login walls or a firewall blocking crawlers. New hosting or new security settings can cause this.
- The new XML sitemap is submitted in Search Console, and the Page indexing report shows your important pages indexed. Where they aren’t, the report shows the status Google gives, which tells you where to start looking.
Search Console’s URL Inspection tool checks a single page. Use its live test to see the page as it is now, not just how Google recorded it on an earlier visit.
While someone is in robots.txt, have them check what it says about AI crawlers. OpenAI, for example, runs one crawler for ChatGPT’s search results and a separate one for training its models, and a site can allow one and block the other. Some companies block AI crawlers on purpose, which is a legitimate choice. It won’t explain a drop in Google traffic, but you should know what your new site allows and whether anyone decided it.
Check what happened to your URLs
If Google can reach the site, look at whether page addresses changed.
Search engines rank individual pages, not whole websites. Each URL builds up history: the searches it shows up for, the links pointing at it, how well it has answered people. When a page moves to a new address, a permanent server-side redirect (a 301 or 308) tells Google that the new page replaces the old one, so it can carry those signals across and send visitors to the right place. Without one, old links and old search results can lead to dead pages, and the replacement may have to win back its rankings largely on its own.
Ask for:
- A list of every old URL. Search Console, an old sitemap or your analytics can reconstruct it if nobody kept one.
- Each old page with a real replacement redirected to its closest match, the page that answers the same question. Not the homepage, which doesn’t answer what anyone came for.
- Pages that were deliberately retired returning a proper “not found” rather than redirecting somewhere unrelated.
- No redirect chains or loops, where one redirect points to another.
Start with the pages that brought in the most search traffic and leads before launch. Test the redirects themselves, not just the list, and keep them in place for at least a year.
Check what changed on the pages themselves
When owners hear “redesign,” they think about how it looks. But a redesign often changes what’s on the page, and that alone can cost rankings even when every technical check passes. Detailed service descriptions get replaced with short headlines. FAQs, case studies and technical explanations get cut. Several focused pages get merged into one general page. The wording that matched what people searched for gets rewritten. That’s no reason to be afraid of editing a page that ranks. A change that makes the page more useful is worth making. What tends to cost rankings is losing the content people were searching for, changing what the page is about or folding several pages into one.
Internal links change too. A page can keep its URL and still lose the links from the homepage, menus and related pages that told Google it mattered.
Ask whoever built the site to compare your ten or twenty most valuable pages before and after launch: what content disappeared, what got merged, and which pages lost links from the rest of the site.
If all of that checks out, it’s probably volatility
I’ve been involved in hundreds of website redesigns, and even when everything is done right, a substantial change to the code and content brings a period of volatility. The new site can be faster and better on every count and still wobble while Google works out what each page, and the site as a whole, is now about. Google’s own guidance on site moves says to “expect temporary fluctuation in site ranking during the move,” and that a small or medium site can take a few weeks or more for most pages to move over.
When the technical setup and the content are sound, in most cases you’ll recover. “Sound” should mean someone has shown you the evidence, not just told you: the pages and searches that lost the most, what changed on them, what was fixed and whether they’re improving. I wouldn’t promise you’ll come out ahead, or put a date on it. Track clicks, impressions and the searches your key pages show up for against a comparable period before launch. If they’re climbing back, it’s settling. If they keep sliding, something on this list was missed.
What to hand whoever built the site
If you want one list to send:
- Confirm analytics is on every page and matches Search Console.
- Confirm the visibility setting is off, important pages aren’t noindexed or blocked in robots.txt, canonicals point to the right pages, and pages load for Google without errors. Tell me what robots.txt says about AI crawlers.
- Show me the Page indexing report and confirm the new sitemap is submitted.
- Send me the list of old URLs and where each one goes now.
- Show me how the top 20 pages from before launch changed: their content, their internal links, and their clicks and impressions since.
If you haven’t launched yet, preventing all this is far easier than fixing it. I wrote about protecting your search traffic in a redesign, and whether you need one at all.
Diagnosing a drop after launch is a common starting point for my SEO consulting. If your traffic fell, get in touch before you spend more fixing the wrong thing.
