You launched the new website. It looks good. Then you opened Google Analytics a few weeks later and see the traffic line has fallen off a cliff.
This is one of the most common situations I see with B2B businesses. A handful of technical mistakes during the migration told Google to start treating the site as if it had never existed - even though the rankings, content, and domain authority were all there before the rebuild.
If your website gets no traffic after a redesign, here's exactly what typically went wrong.
Missing redirects wiped out years of link equity
When a site is rebuilt, URLs change. The old page at /our-services/industrial-automation becomes /services/industrial-automation in the new CMS. To a human reading the address, it's the same page. Google sees a dead page and a new page with no ranking history.
Every page that had rankings or backlinks attached to it needs a 301 redirect from the old URL to the new one. Without it, Google discards that page's history entirely. One missing redirect is a minor problem. Twenty missing redirects across core service and product pages is a traffic catastrophe.
The most common scenario: a developer runs a broken-link check after launch, finds no internal 404s, and considers the job done. That check only tests links within the new site. It won't catch old URLs that Google still has indexed, or backlinks pointing to pages that no longer exist at their previous address.
Title tags and meta descriptions were reset to CMS defaults
Most website platforms auto-generate title tags from the page heading. When your developer rebuilds the site, unless someone has specifically migrated the SEO metadata from the old site, every page goes live with a generic or auto-generated title.
A page that previously ranked for "industrial metal sheds Brisbane" might now carry a title tag that reads "Services - [Company Name]." Google re-reads that page, sees a weaker relevance signal, and adjusts rankings accordingly.
This is easy to miss because the site looks fine in a browser. Title tags and meta descriptions are invisible unless you're looking at the page source or running a crawl with a tool like Screaming Frog. Without that check at launch, you won't catch the problem until the rankings data tells you - weeks later.
A no-index tag was left on from the staging environment
This one is surprisingly common and it's brutal when it happens.
During development, sites are configured to block search engines from crawling them. You don't want a half-built site showing up in Google results before it's ready. The problem is when that block doesn't come off at launch.
Developers move fast. The staging environment's no-index setting - or a disallow: / rule in the robots.txt file - sometimes carries over to the production site. Google crawls the new site, reads the "don't index this" instruction, and stops indexing the pages. Google was told to leave. So it left.
Checking this takes 30 seconds. Search site:yourdomain.com.au in Google after launch. If a site with 50 pages is returning 2 or 3 results, something is blocking indexation. That's your first call to make.
Internal linking was restructured without considering how Google crawls the site
Search engines discover pages by following links. If your homepage links to your main service pages, and those pages link to case studies and location pages, Google has a clear path to find and evaluate everything on the site.
A site rebuild often reorganises navigation. Menus get consolidated, footer links change, and pages that were one click from the homepage end up three levels deep - or orphaned entirely, with no internal links pointing to them. An orphaned page rarely ranks well because Google has no contextual signals about what it covers or how it fits the rest of the site.
If your new site structure buries your industrial safety training pages five levels deep in a dropdown, Google has less reason to treat that content as central to your business.
A post-migration traffic drop is normal - a 90-day cliff is not
Google doesn't penalise new websites. But it treats them with caution until it has enough evidence to trust them again.
A site migration done without proper SEO handover looks to Google like a new site on a familiar domain. The rankings you had before the rebuild were earned through content relevance and backlinks built up over time - and Google needs to revalidate all of that before it'll restore what you had.
Some traffic dip after a rebuild is expected. A drop of 20-30% that recovers over 60-90 days is within normal range. A drop of 70-100% that doesn't recover after three months means something in the migration itself needs diagnosing.
How to protect your rankings through a site rebuild
The work happens before and after launch, not just on the go-live day.
Before you launch, crawl the existing site and export every URL that's currently indexed. Map old URLs to new URLs. Every page that's changing address needs a redirect destination documented before the developer touches the CMS. Export your existing title tags and meta descriptions - these need to be carried across, not regenerated.
At launch, confirm the robots.txt file isn't blocking Googlebot and that no pages have a no-index tag that shouldn't be there. Submit the new sitemap to Google Search Console immediately.
In the first two weeks after launch, run a fresh crawl using an SEO tool within 48 hours and look for 404 errors, redirect chains, and missing metadata. A redirect chain - where the old URL redirects to a second URL before reaching the final destination - loses ranking value at each hop. Fix them to single-step redirects.
Then watch Google Search Console weekly for the first eight weeks. Track impressions (what Google is seeing), not just clicks. If impressions hold but clicks drop, the issue is likely title tag relevance. If impressions collapse, it's indexation or redirects.
If your website gets no traffic after a rebuild and you're not sure where the problem sits, an SEO audit will surface it quickly. Get in touch if you'd like me to take a look.
