How to rebuild your website without losing your rankings
The most expensive mistake in this sector is not a bad website. It is a good new one that quietly destroys ten years of search visibility on launch day.
The most expensive mistake in this sector's marketing is not a bad website. It is a good new website that quietly destroys ten years of search visibility on the day it goes live.
It happens routinely, it is entirely preventable, and it is almost never the designer's fault. Nobody was made responsible for the part of the project that has no visual output and does not appear in any presentation.
What actually goes wrong
URLs change without redirects
Every page that moves without a permanent redirect from its old address to the new one is a page whose accumulated authority has been thrown away. This is the big one, and it accounts for most catastrophic drops.
Content gets tidied away
A rebuild is a natural moment to delete pages nobody looks at. Some of those pages are the ones ranking, and recent analytics will not tell you that if the traffic was seasonal or slow.
The staging site gets indexed
A development site left open to crawlers creates duplicate content and, in the worst cases, ends up ranking in place of the real thing.
The live site launches blocked
The opposite error, and a common one: the robots directive that kept staging private goes live along with the site and quietly deindexes everything.
Text becomes an image
Handsome new hero sections with the words baked into graphics. The design improves and the page becomes unreadable to search engines and AI assistants alike.
The work to do before anything is designed
Take a full crawl of the existing site and export every URL. Then pull twelve months of data from Search Console and analytics and mark every page that has ever received search traffic or earned a link. That list is the thing being protected, and it is usually longer and stranger than anyone expects.
Then map it. Every old URL gets a destination on the new site: the same page, an equivalent page, or the closest relevant parent. Nothing is left unmapped, and nothing gets pointed at the homepage as a lazy default, because a redirect to an irrelevant page is treated much the same as a dead end.
Launch day, in order
Redirects live at the same moment the site is
Not the following morning. The gap is where the damage happens, and it does not need to be long.
Check the robots file and meta directives first
Before anything else at all. It takes thirty seconds and it prevents the single most embarrassing outcome available.
Submit the new sitemap
Then leave it alone. Repeatedly resubmitting does not speed anything up and it makes it harder to read what is happening.
Crawl the live site immediately
Looking for broken links, redirect chains, and pages that lost their titles or descriptions somewhere in the migration.
Watch Search Console daily for a fortnight
Coverage errors, sudden falls in impressions and pages moving to crawled but not indexed all surface here first.
What normal looks like afterwards
Expect some movement. A rebuild done properly still produces a few weeks of fluctuation while Google recrawls and reassesses, and rankings often dip slightly before recovering above where they started, because the new site is faster and better structured than the old one.
What is not normal is a sustained fall over several weeks with no recovery. That is a mapping problem, and it is nearly always fixable when it is caught early, which is the whole reason for watching rather than waiting for the quarterly report to tell you.
Who owns this on the project
The reason migrations go wrong is almost always organisational rather than technical. A rebuild has a designer, a developer and somebody signing it off, and the search side belongs to none of them by default.
Name it in the scope
Redirect mapping, indexation checks and post-launch monitoring should appear on the project plan as tasks with an owner, not as an assumption that somebody will remember on the day.
Ask who is doing the mapping
If nobody can answer, the answer is nobody. It is the single most useful question a client can ask at the start of a website project.
Keep the old site accessible
A copy of the previous site, or at minimum a full crawl of it, makes fixing anything that was missed straightforward rather than archaeological.
It is also worth agreeing in advance what happens if traffic falls and who is responsible for investigating. Migrations that are watched get fixed inside a fortnight. Migrations nobody owns get discovered at the quarterly review, by which point recovery is far slower.
If you are commissioning a rebuild, that one paragraph in the brief is worth more than any amount of feedback on the design.
None of this is glamorous and none of it appears in a design presentation. It is perhaps two days of work on a project costing many times that, and it is the difference between a rebuild that pays for itself and one that sets the business back a year.
It is worth adding that the same discipline applies to smaller changes, not only full rebuilds. Reorganising a navigation, consolidating service pages or moving a blog to a new path all move URLs, and all of them do the same damage on a smaller scale when nobody maps the redirects. The rule is simple enough to remember: if an address changes, something has to point the old one at the new one, permanently.
Rebuild on the horizon?
Send us the current site and the plan. We will map what has to be protected before anybody starts designing.
Protect the rankings →
