How to protect your SEO during a website rebuild
The sequence that keeps a redesign from erasing your organic traffic, what to record before launch and the recovery nobody can promise you.
Why rebuilds destroy traffic
A redesign is the most reliable way an established business loses its organic traffic in a single night. The reason is organisational rather than technical. The designer is judged on how the new site looks. The developer is judged on whether it works. Nobody in the room is responsible for the three hundred URLs that currently earn enquiries.
Two things cause almost all of the damage. URLs change and nothing tells Google where they went. Content gets quietly dropped because a cleaner layout had no room for it. Both are decisions taken casually by people who had no way of knowing which paragraphs were doing the work.
What protection excludes and what it costs
Redirects do not recover rankings for a page whose content was deleted. If the new site says less than the old one then mapping the URL correctly preserves nothing but the address. No audit prevents that loss because it is a content decision rather than a technical fault.
The cost is mostly careful recording before launch and verification after it. Somebody has to crawl the old site and export a full URL list. Somebody has to pull a year of landing page data. Somebody has to test the new site on staging and then re test it live on launch day. A technical SEO audit covers that pre launch and post launch checking and its scope and rate sit on the service page. Professional fees attract GST at 18%.
When this needs a project and when it does not
It needs a project when the site already earns organic traffic or has more pages than one person can check by hand. It needs a project when any URL is changing or when the platform is changing.
It does not need a project for a brand new site with no history because there is nothing to lose. It does not need a project for a five page brochure site that receives no organic visits. Spending on migration protection there is spending to protect zero. It also does not need one if you are keeping every URL and every piece of copy and only changing the visual theme. That is a redesign rather than a migration and buying a migration package for it is paying for work with nothing to do.
The sequence that actually protects you
Before anything is built record the current state. Crawl the live site and export every URL with its title and headings. Export a full year of landing page data from analytics and the query to page report from Search Console. Note which pages have links from other websites because those links are the hardest asset to replace. This record is the only evidence you will have later about what changed.
During the build keep URLs identical wherever it is possible. That is the cheapest protection available and it is routinely given away for a tidier structure nobody asked for. Where an address must change map it one to one with a permanent redirect. Never point a batch of old URLs at the home page. Carry the content across before worrying about the layout. Keep canonical tags and structured data. Update internal links to the new addresses rather than letting them pass through redirects.
Block the staging site from being indexed and then make certain the block is removed at launch. A live site still carrying a no index instruction from staging is the most common single cause of total disappearance after a rebuild and it is invisible to everybody looking at the design.
What to watch after launch
Crawl the live site on launch day and check that every URL from your old list returns either the page itself or a permanent redirect to its closest equivalent. Submit the new sitemap. Then watch Search Console page indexing and the not found report daily for the first fortnight. Server logs tell the same story faster if you have access to them.
The number that matters is clicks and conversions by landing page compared with the same weeks a year earlier. Compare like with like because seasonality will otherwise be credited or blamed for the rebuild. The numbers that flatter are the performance score which usually improves on a new build and total sessions in launch week which is inflated by your own team and the developer testing pages.
The mistake and the timeline nobody can promise
The expensive mistake is launching first and building the redirect map afterwards. The loss happens in the days before the fix arrives and recovery is not symmetric. Google has to recrawl and reassess every page and some of the sites that linked to you will have removed a link that returned an error. Keep the redirects in place permanently rather than for a tidy ninety days.
Even a clean migration usually shows weeks of movement while Google reprocesses the site. Nobody can promise the transition will be invisible or that the previous positions return exactly as they were. What a careful sequence buys is the removal of the avoidable damage. The rest is outside anybody's control.
This guide explains how something works. It is not legal, tax or financial advice, and rules change. Confirm anything regulatory with a qualified professional before you act on it.