I redesigned my website and my traffic dropped: what went wrong and how to recover

7 min read

Three months ago you launched the new site. Clean design, faster loading, updated copy. The whole team was happy. And then came the part nobody expected: organic visits dropped 40%. Enquiries through the site, which weren’t many to begin with, almost disappeared. Google Analytics shows a sustained decline from exactly the day of launch.

This isn’t a rare case. It’s one of the most common — and most expensive — mistakes B2B companies make when they redesign their digital presence without clear technical judgement. The problem wasn’t the design. It was what nobody checked before publishing.


Why a redesign can destroy rankings that took years to build

Google doesn’t evaluate websites the way a user does. While a visitor notices whether the design looks professional, Google is reading something else: URL structure, metadata, headings, internal link text, load speed and — above all — whether the pages it indexed over months or years still exist at the same addresses.

When you redesign without respecting that architecture, Google comes looking for pages that ranked well and finds 404 errors. It arrives at a URL it knew and finds it changed. Or worse: it finds the same content duplicated across three different paths because nobody configured the redirects. In every one of those cases Google’s response is the same: drop the site in the results until it understands what’s going on.

This has a technical name: loss of domain authority through a badly executed migration. And the damage isn’t cosmetic. Depending on the scale of the redesign, it can take three to twelve months to recover the rankings you lost, and only if someone actively works on it. If nothing is done, the traffic simply doesn’t come back.

The most frequent error: changing URLs without redirecting them

If your old site had the services page at /servicios.html and the new one has it at /services/, Google treats them as two different pages. All the ranking history of the old URL — the external links pointing to it, the time it had been indexed, the user interactions — is orphaned. The new URL starts from zero.

A concrete case: an industrial services company launched a full redesign in mid-2023. They had 18 indexed pages with stable rankings for their key commercial terms. In redesigning, they changed the folder structure and didn’t implement 301 redirects. In 45 days they lost 60% of their organic traffic. The new site was technically better. The rankings took eight months to partially recover.


The specific causes of a traffic drop after a redesign

Not every drop has the same cause. Before acting, diagnose. The most frequent — and verifiable — reasons the PTW team identifies in post-redesign audits are these:

Missing or badly implemented redirects. Changing a page’s URL without redirecting the old one to the new is, in SEO terms, equivalent to closing a branch without telling the customers who already knew it. Google loses the trail, and the new page has no history to inherit.

Loss of indexable content. Many redesigns simplify page text in the name of “visual cleanliness”. The result is that pages which previously had 600 words containing relevant terms now have 80 words and a large image. Google has fewer signals to work out what the page is about.

Underlying technical problems. Sites launched without checking robots.txt, with noindex tags left active from the development environment, with load speed degraded by unoptimised images, or with an out-of-date sitemap Google can’t read.

Changed heading structure. If your previous H1s and H2s contained the terms you ranked for, and the redesign replaced them with generic phrases or removed the hierarchy to prioritise the design, Google loses the signals it used to classify your content.

A badly executed HTTP to HTTPS migration. If the old site was HTTP and the new one is HTTPS, but permanent redirects weren’t configured for every variant (with and without www, with and without a trailing slash), Google may be splitting authority across duplicate versions of the same site.

A second concrete case: a B2B logistics company redesigned its site and moved to a new CMS. The development team left the staging configuration active, which blocked search robots. The site stayed in that condition for three weeks before anyone noticed. In that time Google deindexed 23 pages. Restoring the indexing took a further two months.


How to assess the damage and what to do first

If you’ve already launched and traffic dropped, the order matters. This isn’t about undoing the work — it’s about repairing the technical base that was compromised.

Post-redesign diagnostic checklist

Anyone responsible for the site can do this with access to Google Search Console and browser inspection tools:

  • Check coverage in Google Search Console. Go to Coverage and compare how many pages are indexed now versus before launch. If the number dropped significantly, pages were lost.

  • Review 404 errors. In Search Console, under “Pages”, filter by “Not indexed” > “Not found (404)”. Every one of those URLs is a page Google knew and can no longer find.

  • Check the robots.txt file. Go directly to yourdomain.com.au/robots.txt in a browser. If you see Disallow: / or blocks on main folders, the site is preventing Google from indexing it.

  • Verify the redirects. Use a tool like Screaming Frog, or the browser’s network inspector, to confirm that your most important old URLs redirect with a 301 (permanent) to the new ones. A 302 (temporary) doesn’t transfer authority effectively.

  • Review metadata on key pages. Check that the <title> and meta descriptions of the home and service pages contain the terms you wanted to rank for. If the redesign deleted them or made them generic, they need rewriting.

  • Measure load speed. Use Google PageSpeed Insights on the mobile version. If the score dropped compared with the old site, the redesign degraded the technical base. Uncompressed images and unoptimised scripts are the most common causes.

  • Check the XML sitemap. Confirm it exists, that it’s updated with the new URLs, and that it’s registered in Search Console.

What to do with the errors you find

The priority order is this:

  1. First, indexing blocks. If robots.txt or noindex tags are preventing Google from accessing the site, that comes before everything else.

  2. Second, missing 301 redirects. Identify the 10 to 20 most important old URLs — those with the most traffic or the most external links pointing at them — and implement permanent redirects for them.

  3. Third, recoverable content. If pages lost relevant text during the redesign, restore that content or rewrite it. This isn’t about returning to the old design — it’s about the page having enough substance for Google to understand its purpose.

  4. Fourth, metadata and heading structure. Check that each service page has a clear H1, descriptive H2s, and a page title containing the main term it should rank for.

  5. Fifth, speed. Compress images, review unnecessary third-party scripts, and verify the hosting responds in reasonable time (under 200 ms to first byte).


What separates a redesign that adds from one that subtracts

The underlying problem isn’t that redesigns are inherently risky. It’s that in most cases they’re treated as graphic design projects when they’re actually migrations of digital assets. A site with three years of accumulated ranking has technical value that can be destroyed in a weekend if nobody actively protects it.

The difference between a redesign that holds or improves traffic and one that destroys it isn’t the budget or the platform. It’s whether someone with technical judgement reviewed the URL architecture before launch, validated the redirects, and verified Google could still read the site after the change.

That isn’t last-minute work. It’s part of the process from the start.


If you launched a redesign and traffic dropped, the first step is understanding exactly where the chain broke. PTW’s digital diagnostic is designed to identify those break points precisely: what was lost, why, and what to do first to recover it. No assumptions, no generic checklists — only what applies to your site’s specific situation.