Why Did My New Website Kill My Google Rankings?
A while ago I was talking to the owner of a chain of bridal shops about her website.
The business had commissioned a complete rebuild. The old site needed replacing, and the new one looked better: more modern, more polished, much closer to what they wanted the brand to say online.
Then it launched.
Rankings dropped. Sales suffered. And the launch had landed in the middle of one of the most important trading periods of the year.
She hadn't known any of this was a risk. She'd commissioned a better website and been told it was ready. When the rankings fell, she was told this happens with a new site, and that Google would settle down in a few months.
There's some truth in that. Significant changes to a website can cause rankings to fluctuate while Google recrawls and reindexes it. Google says as much itself, and recommends timing a major site move for a quieter period where possible.
But that doesn't mean losing your search visibility is just the price of a new website. If Google is already sending customers your way, a rebuild shouldn't start from a blank canvas.
It should start with evidence.
The short answer: the rebuild probably changed something Google relied on
A website can look dramatically better after a rebuild and still perform worse in search, because Google isn't judging it the way you are.
Over time, Google builds up an understanding of a site: the pages it contains, what they're about, how they relate to each other, who links to them, and which searches they satisfy.
Some of that is obvious. Some of it isn't. An old website can be untidy, dated, badly designed even, and still contain pages doing useful work.
A rebuild can strip those signals out without anyone noticing. URLs change. Pages disappear. Several pages get condensed into one. Service descriptions shrink and go vague. Internal links vanish. Titles and headings change. Content that looked unimportant turns out to have been telling Google what the business actually does.
None of this means don't rebuild. A good rebuild makes a site clearer, faster, easier to use and stronger in search. But it should start by asking: what's already working, and what do we need to protect?
Common reasons rankings drop after a website rebuild
01 - URLs changed without proper redirects
The first thing I'd want to understand after a post-launch drop is the shape of it: what changed, when it changed, which pages were affected, and whether the fall is broad or concentrated.
From there, redirects are one of the first technical things I'd check.
Say your old site had a page at /wedding-dresses-brighton. It had existed for years, ranked in Google, and had links pointing to it.
The new site replaces it with /bridal-collections.
That's not automatically a problem. Websites evolve. But Google, and anyone following the old link, needs to be told where the page has gone. That's what a permanent redirect does: Google describes it as telling both visitors and Search that a page has a new home, and recommends permanent server-side redirects wherever a URL changes for good.
The destination matters too. Sending every deleted URL to the homepage isn't a migration strategy: Google specifically warns against redirecting a pile of old URLs to one irrelevant destination, since it confuses users and can get treated as a soft 404.
Old pages should map to their nearest equivalent on the new site.
02 - Useful content was removed
Rebuilds tend to trigger a tidy-up. Too much text, too many pages, sections that feel repetitive. Three short paragraphs instead of eight looks cleaner.
Sometimes that's the right call. But before deleting anything, it's worth knowing what that content is doing.
An old service page might hold useful detail about specific work. A project page might reinforce the areas you cover. FAQs might answer exactly what people are searching for. A page that looks redundant might still be pulling impressions and clicks.
The aim isn't to preserve every word forever. It's to avoid throwing away search relevance because nobody checked whether it mattered. That's what I mean by preserve before improve.
03 - Page titles, headings and focus changed
Titles and headings aren't magic switches. But they do a lot for a page's clarity.
A page that clearly explains one service can lose that clarity fast in a redesign. A page about a specific trade in a specific area gets replaced by something headed simply "What we do."
That might suit the design. It's much less useful at telling Google, or anyone else, what the page is actually for.
The same goes for the body copy. A rebuild can change what a page looks like without anyone noticing it's also changed what search need the page answers.
04 - Internal links were weakened
Internal linking isn't glamorous. It matters anyway.
Links inside a site help visitors move around, but they also help search engines find pages and understand how everything connects. Rebuilds quietly break these connections: a case study stops linking to the service it's about, supporting pages drop out of the footer, important pages end up three clicks deep, a useful link in the copy just doesn't make it into the new layout.
Each change looks small on its own. Together, they can leave your most important pages badly disconnected.
05 - The new page no longer serves the same purpose
This is a step further than deleting content. Keeping a page, or redirecting an old URL to a new one, doesn't mean you've kept what made it useful.
If the old page explained one service in detail and the new one is a broad overview of six, they aren't equivalent.
A migration shouldn't just ask where has this URL gone? It should ask: does the new page still answer the same need?
That takes judgement, not just a spreadsheet of redirects.
06 - Google can't properly crawl or index part of the new site
Sometimes the problem sits underneath the page entirely. A page can look fine to a visitor while something stops Google treating it as indexable: an accidental noindex, a crawling restriction, a canonicalisation problem, broken internal links, or a page Google simply hasn't found yet.
This is where Search Console earns its keep. The URL Inspection tool shows whether a page has been indexed, whether Google could crawl it, which version it's treating as canonical, and whether the live page looks indexable at all. Far more useful than refreshing Google every morning to see if the page has come back.
Some movement after a rebuild can be normal
The explanation given to that bridal business wasn't entirely wrong. Google says significant changes can cause temporary fluctuation while it recrawls and reindexes a site. For a medium-sized site, moving most pages through the index can take a few weeks. Larger sites, longer.
So some wobble after launch isn't automatically a disaster. But "give it a few months" isn't a diagnosis. If commercially important pages have vanished, redirects are missing, new URLs won't index, or content has disappeared, waiting doesn't fix any of that.
There's a commercial question too. If your business has a clear peak season, do you really want to launch a major website change right before it? Even a well-managed rebuild carries some short-term movement, and Google itself recommends scheduling big moves for quieter periods.
SEO planning is commercial planning.
What I would check if rankings dropped after a rebuild
You don't need an expensive toolset to start. You need to know what actually changed.
I'd want to know:
Which pages were getting impressions and clicks before the rebuild?
Do they still exist?
If URLs changed, where do the old ones redirect?
Are important service pages still as specific as they were?
Was valuable copy cut or thinned out?
Do titles and headings still describe the services clearly?
Are important pages still well linked internally?
Can Google actually crawl and index them?
Is Search Console reporting 404s or indexing issues?
Did the domain, platform, URLs, content and architecture all change at once?
Have rankings genuinely fallen, or has traffic shifted for another reason?
Search Console is usually where I start: it shows which queries and pages had visibility before and after the change. Analytics, where good history exists, adds another layer: which pages people actually visited, where the traffic came from, what happened around launch.
I'll also crawl the existing site with Screaming Frog before a rebuild starts, so I've got a clear picture of URLs, redirects, titles, headings and internal links before anything gets dismantled.
The tools aren't the strategy. They're the evidence for making better decisions.
A good rebuild starts before the new website is designed
I recently ran a migration review for a UK-wide training and consultancy organisation ahead of a major rebuild: a much bigger site than most of the small businesses I work with, with thousands of internal URLs, but the same underlying principle.
Before anything changed, we needed to understand what was already there. That meant crawling the site, reviewing its structure and search data, flagging migration risks and turning all of it into a clear brief for the agency doing the rebuild.
At a much smaller scale, I did the same thing rebuilding the Green Timber Tree Surgery website. Old site on Joomla, new one in Squarespace. Before touching anything, I crawled the existing site, went through Search Console and the available analytics, worked through the URLs, and planned where each old page should lead.
Different businesses, different websites, same principle:
A good rebuild doesn't start with a blank canvas. It starts with evidence.
That doesn't mean preserving a bad website. It means understanding what has value before deciding what to change.
From there you can restructure, rewrite the weak content, cut what's genuinely redundant, and build something better, without giving away the search visibility the business already earned.
How to rebuild without unnecessarily damaging your rankings
If your site hasn't launched yet, you're in the best possible position.
Before rebuilding, I'd normally want to:
crawl the existing website
review Google Search Console
check Google Analytics where useful data exists
identify the indexed, visible and commercially important pages
work out what content should be kept or improved
map old URLs to the right new destinations
preserve or improve internal links
avoid changing URLs just for the sake of it
check crawlability and indexing settings before launch
submit and check the new sitemap
monitor Search Console after launch
test redirects and key pages once the site is live
Google's own migration guidance says much the same: accurate URL mapping, proper redirects, checked canonical and robots settings, tested redirects, Search Console watched throughout.
For a small business website, this doesn't need to be a huge technical exercise. It needs to be proportionate.
A five-page site with almost no existing visibility is a different proposition to a fifteen-year-old site generating a serious share of a company's enquiries. The more value the current site is creating, the more it's worth understanding before you replace it.
Do you need specialist help?
Not every rebuild needs a full SEO migration project. But if your existing site already generates enquiries, ranks well for valuable searches, or has years of content and links behind it, I wouldn't rebuild it blind.
And if a new site has already launched and visibility has fallen sharply, I wouldn't assume it'll recover on its own.
Establish what changed first.
Sometimes the answer is straightforward. Sometimes several things happened at once and need untangling.
Either way, the principle holds:
Protect what's already working before trying to improve what isn't.
That's how I approach website refreshes and rebuilds: the design work sits alongside the search and structural evidence for the existing site, not bolted on afterwards.
I never did any SEO support for that bridal business. We just talked, once, after the damage had already been done. But what stayed with me is this: she wished someone had raised these questions before the new site went live.
That's really the point of this piece. Not that every rebuild needs a full migration audit, but that the conversation about what you might lose is worth having before you rebuild, not after.
Frequently asked questions
-
No. A well-planned rebuild can improve visibility considerably. The risk comes from changing URLs, content, structure and internal links without understanding what was working first.
-
There's no universal timeframe. Google says fluctuation is normal while it recrawls and reindexes, and that moving most pages through the index takes a few weeks for a medium site, longer for a larger one.
If the decline is severe or doesn't ease off, it's worth investigating rather than waiting it out.
-
No. Redirects matter, especially when URLs change, but the destination has to be relevant too. Content, internal linking, crawlability and what the new page is actually for all matter just as much.
-
Not necessarily. Preserving what works doesn't mean copying the old site word for word. It means knowing whether existing content has value before you cut or rewrite it. Good content can be reorganised and improved.
-
Yes. For most small business sites, Squarespace is perfectly capable. URLs, redirects, page settings, headings, internal linking and content all still need handling properly, but the platform is rarely the actual problem.
The real question is whether the rebuild was planned with the existing site's visibility in mind.
