A new website launches.
It looks better.
The technology is newer.
The navigation is cleaner.
Everyone involved breathes a sigh of relief.
Then traffic starts falling.
Pages that previously generated consistent search visits disappear from Google.
Enquiries decline.
Rankings that took years to build suddenly become difficult to find.
And somebody asks:
What happened?
Website migrations and rebuilds are one of the easiest ways for a business to accidentally damage its search visibility.
The frustrating part is that many of the causes are entirely preventable.
A new website is not a new start for Google
Businesses understandably approach a website project as an opportunity to start again.
- New design.
- New technology.
- New navigation.
- New content.
- New URLs.
But Google already has a relationship with the existing website.
It understands individual pages.
It has indexed them.
Other websites may link to them.
Those pages may have accumulated authority over many years.
Google has learned which searches they are relevant for.
When a rebuild changes everything at once without carefully mapping the old website to the new one, much of that accumulated value can be disrupted.
The website may be new.
The search equity behind it isn't.
URLs matter more than they look
Imagine an existing page has ranked for years at:
/services/commercial-drainage/
The new website launches and the equivalent page becomes:
/what-we-do/drainage-solutions/
There is nothing inherently wrong with the new URL.
But Google needs to understand that the old page has permanently moved to the new one.
That is what a proper redirect helps communicate.
Now multiply that across hundreds or thousands of pages.
If old URLs simply disappear, redirect to irrelevant destinations or all get pushed back to the homepage, search engines lose important signals.
Users following old links also arrive at dead ends.
A redirect plan is not glamorous.
But it can be one of the most commercially important documents in a website migration.
Content often disappears during redesign
Another common problem is simplification.
The old website has grown organically over many years.
There are service pages, guides, articles, FAQs, category pages and historical content.
During the redesign, someone understandably says:
"There's far too much content. Let's clean it up."
And sometimes they should.
But deleting a page because it looks old is very different from establishing whether that page generates meaningful organic traffic, links or enquiries.
Before removing content, understand its value.
Ask:
- Does the page receive organic traffic?
- What searches does it appear for?
- Does it have external links?
- Does it contribute to conversions?
- Is there a better page it should be consolidated into?
- Does it need improving rather than deleting?
Content decisions should be based on evidence rather than aesthetics alone.
Technical changes can have commercial consequences
A migration can introduce issues that are almost invisible to someone browsing the website normally.
- Pages may accidentally become non-indexable.
- Canonical tags can point to the wrong URLs.
- Internal links can break.
- Sitemaps can contain incorrect pages.
- JavaScript changes can affect how content is rendered.
- Page speed can deteriorate.
- Mobile behaviour can change.
- Structured data can disappear.
- Duplicate content can be created.
None of these necessarily stop the website from looking good.
That is why a visual sign-off is not enough.
The search implications need their own checks.
Benchmark before you move anything
One of the most valuable things a business can do happens before the new site launches.
Create a baseline.
Understand:
- Organic traffic
- Search visibility
- Important rankings
- Top landing pages
- Conversions from organic search
- Indexed pages
- Backlinks
- High-value content
- Branded versus non-branded traffic
Then you have something meaningful to compare against after launch.
Without a baseline, a business can know traffic has fallen without understanding precisely where the loss occurred.
That makes recovery slower and more expensive.
Search should be involved before launch, not after it
Too often, search specialists are brought into a website project when something has already gone wrong.
The new website launches.
Traffic falls.
Then somebody asks an SEO specialist to investigate.
That is backwards.
Search should be considered while decisions are being made about:
- Site architecture
- URLs
- Content
- Navigation
- Templates
- Redirects
- Internal linking
- Page performance
- Tracking
Protecting existing visibility is usually much easier than recovering it afterwards.
What should happen before launch?
At a minimum, I would want to see:
A complete crawl of the existing website
Know what currently exists before replacing it.
Search performance benchmark
Understand which pages and searches currently create value.
URL mapping
Decide where every important existing URL will go.
Redirect plan
Implement permanent redirects from old pages to their most relevant new equivalents.
Content assessment
Know which content should be retained, improved, consolidated or removed.
Analytics and tracking plan
Ensure measurement survives the migration.
Technical review
Check indexation, canonicalisation, sitemaps, robots directives, structured data and other important search signals.
Pre-launch testing
Crawl the new environment before it goes live.
And after launch?
The job is not finished when somebody presses publish.
Monitor closely.
Check:
- Search Console
- Analytics
- Indexation
- Crawl errors
- Redirects
- Rankings
- Organic landing pages
- Conversions
- Server errors
Some movement is normal.
Large unexplained losses are not something to simply wait out.
The earlier a migration issue is identified, the easier it usually is to diagnose.
What if the migration has already happened?
Do not assume the visibility is permanently lost.
Start by establishing:
What changed?
- Compare the old and new website.
- Compare traffic before and after the migration.
- Identify which pages lost visibility.
- Review redirects.
- Check indexation.
- Look for content that disappeared.
- Compare site architecture.
- Assess technical changes.
The objective is to distinguish between migration-related losses and wider changes in search behaviour.
That distinction is becoming increasingly important.
Search itself is changing.
Google's search results continue to evolve, and AI-generated answers are changing how users discover information — particularly for publishers and information-led websites.
Not every traffic decline following a migration was necessarily caused by the migration.
But you need evidence to know the difference.
A website rebuild should improve the business, not reset its visibility
Design, technology and user experience matter.
So does everything the old website has already earned.
A successful migration should carry that value forward while creating something better.
The controls required to do that are often unglamorous.
- Redirect spreadsheets.
- Crawls.
- Benchmarks.
- Testing.
- Monitoring.
But compared with rebuilding years of lost search visibility afterwards, they are remarkably inexpensive.
Treat search visibility as an asset during a website rebuild, not something to check once the new site is live.
That is how we approach search and content work: commercially first, technically where it counts.