Why rebuilds lose traffic
Most traffic loss after a rebuild comes from a handful of avoidable mistakes, not from the new design. The most common one is changing page addresses without redirects. A page that used to rank at /services/brakes now lives at /brake-repair, the old address returns "not found", and the signals that page had collected over the years stop counting.
The others are quieter:
- Content cut during the redesign. Long pages trimmed to look tidy often lose the paragraphs that answered what people searched for.
- Titles rewritten wholesale. A page title is one of the clearest signals of what a page is about.
- The staging block left on. The test copy was hidden from search engines, and the setting went live with the new site.
- Internal links lost. A new menu that drops whole sections makes those pages harder for Google to find.
When we rebuild a product or website, the old site's search footprint is treated as a requirement, written down before design starts. This guide sits in our rebuild guides and explains how that works in plain terms.
What has to survive the rebuild
Think of the old site as a set of promises Google has learned. The new site should keep each one, or say clearly where it moved.
| Carry over | Why it matters | How to check |
|---|---|---|
| Page addresses | Google ranks pages, and pages are addresses | Every old address loads or redirects in one hop |
| Titles and descriptions | They say what each page is about and shape the search snippet | Compare old and new, page by page, for the top pages |
| Main content and headings | The text is what matched the searches | Nothing that answered a query was dropped without a reason |
| Internal links | They tell Google which pages matter | Important pages are still linked from menus and related pages |
| Structured data | Product, FAQ and organisation markup feed rich results | Google's Rich Results Test on key templates |
| Language versions | hreflang tags connect translations of the same page | Each language page points to the others |
| Sitemap and robots.txt | They tell crawlers what exists and what to skip | New sitemap lists only live, final addresses |
| Search Console and analytics | Without them you are flying blind after launch | Verification record kept; tracking fires after consent |
Build the address map before you build the site
The address map is a spreadsheet with one row per old page and three columns: the old address, the new address and what happens to it. It is the single most useful document in a rebuild, and it should exist before anyone designs a page.
- Collect every old address from the current sitemap and a crawl of the site.
- Add the pages that earn visits. Search Console's Performance report keeps up to 16 months of data, enough to catch seasonal pages.
- Add pages that other sites link to, from the Links report in Search Console.
- For each row decide: keep the same address, redirect to the closest new page, or retire it.
- Review the map with whoever owns the content, then hand it to the developers as a requirement.
| Old address | New address | Action |
|---|---|---|
| /services/brakes | /services/brakes | Keep as is |
| /brakes-offer-2024 | /services/brakes | 301 to the closest page |
| /blog/?p=118 | /blog/winter-tyres-guide | 301 to the same article |
| /old-careers-form | none | Retire (404 or 410) |
Don't send everything to the home page. Google's own guidance warns against redirecting many old pages to one unrelated page. It treats those like missing pages, so the redirect does nothing for you.
Launch day checklist
Most of the risk sits in the first hour after the switch. Work through this list before you announce anything.
- Redirects are live and testedRun the full old-address list against the new site. Each should land on its target in one hop, with no chains or loops.
- The staging block is goneNo "noindex" tag on live pages, and robots.txt doesn't block the site.
- The new sitemap is submitted in Search ConsoleIt should list final addresses only, not redirects.
- Search Console verification still worksA DNS record survives a rebuild. A verification file on the old server may not.
- Change of Address, only if the domain changedThe tool in Search Console is for moving domains, not for new addresses on the same one.
- Analytics and consent are recordingCheck that visits are counted, and only after the visitor's consent where the law requires it.
What the weeks after launch look like
Expect movement. Google's documentation on site moves says rankings can fluctuate during a move and that a small or medium site can take a few weeks for most pages to be recrawled. Larger sites take longer. A dip in the first weeks isn't proof that something broke.
What separates a normal dip from a real problem is what Search Console shows:
- Normal: old addresses gradually reported as redirects, new addresses appearing in the index, clicks returning as they do.
- A problem: a rising count of "not found" pages that used to get visits, or new pages reported as excluded by a noindex tag.
Check the Pages report weekly for the first two months and fix missing redirects as they show up. Then leave the redirects alone. Google recommends keeping them for as long as possible, generally at least a year, and links on other sites will keep using old addresses for much longer than that.
How we handle it
On a rebuild we carry your page addresses over or redirect them, so Google can follow the move. The address map is agreed with you before design, tested before launch and checked again in the weeks after, and our weekly reports show what we found and fixed. We don't promise that traffic or positions stay where they were; nobody can, and you should be wary of anyone who does.
Sitemaps, structured data, hreflang for language versions and IndexNow notifications are part of the stack we work with, so the new site gives search engines the same clear signals the old one did, or clearer ones.
What this guide doesn't cover
- Choosing a new platform. Whether to rebuild at all is a separate decision.
- New content and keyword strategy. This guide is about keeping what works, not growing past it.
- Penalties and spam problems. A site with a manual action in Search Console needs that fixed first.
- Getting the old site back from an agency. See the website handover checklist.
Questions owners ask
Will my rankings drop after a redesign?
Some movement is normal for a few weeks while Google recrawls the site, and Google says so in its own documentation. A careful move limits the damage and lets the site recover; nobody can honestly promise that positions stay exactly where they were.
Should redirects be 301 or 302?
Use permanent redirects (301 or 308) for pages that have moved for good. Temporary redirects tell Google the old address may come back, which is the wrong message after a rebuild.
How long should old redirects stay in place?
Google recommends keeping them for as long as possible, generally at least a year. Old links on other sites, bookmarks and emails keep using the old addresses long after Google has moved on.
Can I change the domain at the same time as the rebuild?
You can, but each change makes it harder to tell what caused a drop. If you can, move the domain and rebuild the site as separate steps. If you do change the domain, use the Change of Address tool in Search Console.
Do I need redirects if only the design changes?
Not if every address stays exactly the same. You still need to check that titles, main content and internal links survived the new design.
Sources
Related work
Case · Car service A car-service site in three languages Built with a sitemap, llms.txt and IndexNow notifications on deploy.See also
- ChecklistWebsite handover checklistGet the old site's accounts and address list into your hands first.
- ServiceProduct developmentHow we plan and run a rebuild.
- ServiceSearch and AI-assistant visibilityFor after the move, when the goal shifts to growth.
- IndustryOnline shopsCategory and product pages carry most of a shop's search visits, so they need the most care in a move.