When you move house, you can repaint, change the furniture, knock down a wall. Nobody will complain. What loses you customers is forgetting to forward the mail.
A website works the same way. Google doesn't care about your new colour palette. It knows your site by its addresses: every URL that has earned a little trust over the years is a mailbox. A redesign that breaks those addresses starts from zero, even with better content.
I recently rebuilt the website of an accounting firm: new code, new CMS, new hosting, same domain. The site moved from the old hosting to the new one without a single old address returning an error. Here is the method, in the order I applied it.
What actually makes traffic drop
Before the method, you need to know what you're protecting. When a redesign loses traffic, the cause is almost always one of these:
- URLs that disappear: the old article
/blog/creation-sasno longer exists, and nobody thought to redirect it; - content rewritten for no reason: a text that ranked well gets "refreshed" and loses whatever made it rank;
- indexing blocked by accident: the demo site's
noindexships to production; - a botched technical switch: the site is unreachable for a few hours, or the domain's email stops arriving.
None of these causes has anything to do with design. All of them come down to inventory and procedure. That's good news: they can be prevented.
Step 1: the inventory, before the first line of code
You can't protect what you haven't listed. On this project, the old site had 36 public pages. I recorded every one of them, with three pieces of information per address:
- the exact URL, as indexed;
- its current title and description;
- its destination in the new site.
That third column is the one that matters. Every old address must have one answer: either it exists as is, or it redirects with a 301 to the page that replaces it. "We'll see" is not an answer.
I also archived all 36 pages as they were, with a fingerprint of each file. Not out of nostalgia: when someone asks three weeks later "wasn't there a paragraph about holding companies before?", the answer has to be verifiable, not a hunch.
Step 2: keep the same addresses whenever possible
The best redirect is the one you don't need.
The blog's 11 old articles and 9 additional pages were carried over at the same addresses in the new CMS. A 301 redirect passes on most of a page's value, but not all of it, and it adds a hop to every visit. An identical URL loses nothing.
Second rule, harder to keep: the old texts were kept as they were. Not rewritten, not "optimised". The temptation is strong, especially when you're rebuilding everything else. But an article that has been bringing in visits for two years does so for reasons you don't always know. You improve it later, one page at a time, measuring the effect. Never during the migration.
Step 3: build alongside, never in place
The new site was built and tested without touching the old one. It ran on the new server, in its container, without being exposed on the public domain. The old site stayed online, untouched.
That sounds obvious. It isn't: many redesigns happen "live", replacing pages one by one on the production server. The day something breaks, there's no previous state left to go back to.
With two sites side by side, rolling back takes one line: you don't switch.
Step 4: an acceptance check that verifies facts, not impressions
"I clicked around a bit and it looks fine" is not acceptance testing. On the candidate version, before any switch, I checked each of the 36 old addresses:
- that it responds normally (or redirects where planned);
- that the H1 title is present and unique;
- that the canonical URL points to itself, on the right domain;
- that the structured data is valid;
- that no internal link along the way leads to an error.
Then site-wide checks: a sitemap of 42 URLs consistent with what actually exists; no global noindex in production, but one on the demo; no page overflowing horizontally on a 390-pixel phone screen.
And a check people often forget: I went through the 68 built files to make sure no private key (forms, CRM, CMS) had ended up in them. A static site publishes whatever you give it. A CMS write token in a public JavaScript file is a site anyone can edit.
Step 5: the DNS switch, the scary part
The domain stays the same; only the server it points to changes. It's the shortest step, and the one where mistakes cost the most, because they don't show up right away.
Lower the TTLs, then wait
Every DNS record carries a lifetime (TTL): how long resolvers around the world keep the old answer cached. Here it was 24 hours.
If you change the server address with a 24-hour TTL, some of your visitors will see the old site for a day. If things go wrong, your rollback will also take a day to propagate.
So: lower the TTL to 5 minutes first, then wait at least the old TTL, 24 hours. Not the new 5 minutes: caches that read the old value will keep it until it expires.
Only touch what you're switching
A domain isn't just for the website. This firm also ran its email through it: MX, SPF, DKIM and DMARC records, plus two Google service verifications. One hastily edited zone file, and the firm's email stops arriving. You find out on Monday, when a client asks why nobody replies.
I recorded the zone's 23 records before touching anything, and checked after each import that the email values were unchanged.
That inventory surfaced a trap: three old subdomains were aliases of the main domain. They would have followed it to the new server, which didn't know about them. They were handled separately instead of switching by accident.
The certificate before the switch, not after
The new server's HTTPS certificate was obtained before the domain pointed to it, through DNS validation. Otherwise, for the first minutes after the switch, visitors land on a security warning: the worst possible welcome for an accounting firm.
Keep the old hosting alive
After the switch, the old hosting stayed active. Some networks keep the old address cached longer than expected: on my own machine, the local resolver still showed the old site at the first check. You only cancel the old hosting once the monitoring period is over.
Step 6: after the switch, watch what you can't see
The site loads? Good. That's not the end.
- Search Console: submit the new sitemap. No change-of-address request, since the domain hasn't changed.
- 404s: watch them for several weeks. An address missed in the inventory always ends up there.
- Forms: a real submission, end to end, all the way to the inbox. A form that displays correctly can still send nothing.
- Email: a real send-and-receive test on the domain, not just reading the DNS records.
Bonus: publishing without breaking things
One last thing, which protects your ranking over time. The firm publishes its articles in the CMS. Each publication builds a new candidate version, which goes through the checks (pages, titles, SEO) before replacing the live version.
During acceptance testing, I deliberately made a candidate fail: the live site didn't budge. A badly entered article must never be able to take the whole site down.
The takeaway
A redesign doesn't lose your search ranking. Improvisation does:
- List every old address and give each one a destination.
- Keep URLs identical whenever possible, 301 redirect otherwise.
- Don't rewrite content that works during the migration.
- Build alongside, never in place.
- Check facts: titles, canonicals, structured data, links, sitemap.
- Lower the TTLs and wait out the old one, keep email intact, get the certificate first.
- Keep the old hosting until monitoring is over.
None of this is spectacular. That's exactly why people skip it, and pay for it three months later in their analytics.
If the topic interests you more broadly, I've written about what search engines and AI actually read on a site, and about what happens when a site loses its data without saying so.
The firm's site is live, and the project is described here. Planning a redesign and worried about losing what your site has earned? Message me: I always start with the inventory.