The new site goes live on a Thursday. It looks incomparably better than the old one, everybody is pleased with it, and a fortnight later the enquiries have thinned out and nobody can work out why.
The cause is almost never the design. A website's visibility is attached to individual addresses — the URLs — and to the content sitting at them. Rebuild without carrying both across and search engines are not looking at an improved version of your website. They are looking at a new one, with a lot of missing pages.
Decide the URL question before anything is designed
The most consequential decision in a rebuild is usually made early and casually, by whoever sets up the new site's page structure: are the addresses staying the same or not?
If every page keeps its URL — yourbusiness.co.uk/services/boiler-repair stays exactly that — most of the risk described here disappears. If the addresses change, each one needs a redirect, and the job goes from trivial to a piece of work somebody has to own. Neither answer is wrong, but it should be a decision rather than a by-product of a new system's defaults.
Where addresses do have to change, resist the urge to tidy. Shortening a URL because it reads better, or restructuring for a logic only you will notice, buys very little and costs you a redirect. The safest redirect is the one you never have to write.
Build the redirect map from a crawl, not from memory
Nobody knows every page on their own website. Sites accumulate: a landing page from a campaign three years ago, blog posts written by someone who has since left, a PDF that turns out to rank for a search you had never considered. Rebuilding from memory turns those quietly into dead ends.
So start by listing every URL the old site has. Between these sources you will catch almost all of them:
- —Your existing XML sitemap, usually at /sitemap.xml
- —The Pages report in Google Search Console, which shows what Google has actually indexed rather than what you think exists
- —Analytics, sorted by landing page over the last twelve months, which shows the addresses people genuinely arrive on
- —A crawl of the live site — Screaming Frog's free tier covers a small business site comfortably
- —Search Console's Links report, which shows the pages other websites point at and which therefore matter most
Then map it one to one
Match each old URL to its closest equivalent on the new site and implement those as 301 redirects — the permanent kind, which is what signals the move is not temporary.
Three rules do most of the work. Send each page to the specific page that replaces it rather than to the homepage; Google treats a mass redirect to the homepage as a soft 404, so nothing carries across. Avoid chains, where one address points to a second that points to a third. And do not block the old addresses in robots.txt afterwards to tidy up, because a blocked URL is a redirect nobody can read.
Then leave the redirects alone. Google's site move documentation on Search Central advises keeping them in place for as long as possible and at least a year, because links on other people's sites pointing at your old addresses are re-evaluated slowly and you do not control when.
Keep the content that was doing the work
A rebuild is a natural moment to cut. Pages get merged, long text is trimmed to suit a cleaner design, and the result reads better and performs worse.
The pages earning your traffic are frequently not the ones you are proud of. A dense, unglamorous service page that answers forty questions in plain text is often the largest single source of enquiries on a small business site. Before anything is cut, open the performance report in Search Console and find which pages produce clicks and which queries produce them. Those pages should come across substantially intact — rewrite for tone and layout by all means, but keep the substance and keep the questions they answer.
The dull metadata matters as well. Title tags, meta descriptions, headings and any structured data should be carried over deliberately rather than regenerated by whatever the new system does automatically. Replacing a title that took a year to earn its position with "Services | Home" is a quietly expensive change.
Moving off a builder, or on to a new domain
Two variants complicate matters. The first is leaving a platform like Wix or Squarespace. Builders impose their own URL patterns, so moving away from one changes nearly every address on the site — the redirect map is not optional, and you need to check the old platform can serve redirects at all, or keep the subscription running long enough to do it while the change settles.
The second is changing domain, which is a separate job on top of the page-by-page redirects. You also use the Change of Address tool in Google Search Console, from a domain-level property rather than one with a path in it. Google's guidance is to submit the change for every variant of the old domain — www and non-www, plus any subdomains — including ones you never actively used.
One practical warning with a domain change: your email almost certainly runs on the old domain too. Keep it working. A move that silently stops mail arriving is a larger problem than a ranking dip, and a harder one to notice.
The launch-day list
Most disastrous launches come down to a handful of mistakes, all made at the last minute and all cheap to check:
- —Remove whatever was hiding the staging site — a noindex tag or a robots.txt disallow left in place is the classic way to disappear from Google entirely
- —Test a real sample of redirects, including your five busiest pages, and confirm each returns a 301 to the right destination
- —Check canonical tags point at the new URLs rather than at the staging address
- —Confirm HTTPS works on every version of the address, and that www and non-www resolve to one canonical version
- —Submit the new XML sitemap in Search Console, and leave the old sitemap reachable for a few weeks so crawlers find the redirects sooner
- —Check analytics and Search Console tracking survived the rebuild — they are routinely the thing nobody remembers to reinstall
- —Send yourself a test enquiry from a phone, on mobile data, and confirm it arrives
What normal looks like afterwards
Even a well-executed move produces some movement. Search engines have to recrawl the site and reassign what they knew about the old addresses, and positions wobble while that happens. A few unsettled weeks is not evidence that something has gone wrong.
What matters is the shape of it. Gradual recovery over a few weeks is the expected pattern. A sharp, total disappearance within days of launch is not — that is usually the noindex tag, and it is worth checking in the first 48 hours rather than waiting to see. If things are still meaningfully down after a month or so, stop waiting and start diagnosing: look for pages excluded in the Pages report, crawl the new site for redirect chains and broken internal links, and compare the current title tags against the old ones.
Resist changing everything at once while you wait. Rewrite half the site in week three and you will never know which change did what.
Sometimes losing a little is the right trade
There is an honest counterweight to all of this. Preserving rankings is not the only thing a rebuild is for, and a site that holds every position while converting as poorly as it did before has not achieved much.
Some pruning is genuinely sensible: pages built for searches that never produced a customer, near-duplicate location pages, posts written to fill a content calendar years ago. Cutting those can reduce your traffic and improve your business.
The distinction worth holding on to is between deciding to lose something and discovering that you have. Losing rankings on purpose, on pages you can name, is a strategy. Losing them by accident is what this is written to prevent.
How we handle this
Every rebuild we take on starts with the old site rather than the new one: a full crawl, the Search Console data, and a redirect map agreed before design work begins. Where the existing platform is sound and the URLs can stay where they are, we say so — keeping the addresses is cheaper and safer than a migration nobody needed.
If you are weighing up a rebuild and want to know what it would put at risk, tell us where your site is now and we will look at what is actually ranking and what would have to be carried across. Often the answer is that the risk is small and easily managed, and when that is the answer we would rather tell you.