Redesigning your site without losing your SEO

You can recognize this one over the phone. The new site went live three weeks ago, everyone agrees it looks great, and organic traffic is down by half. Nobody understands it, because nobody broke anything. That's exactly the problem: the redesign was run as a design project, and SEO lives in the plumbing. It's the part we take on under a subscription, and the part we most often get called in to rescue after the fact.

Google doesn't index your design, it indexes addresses. Every URL on your current site carries a history: external links, a ranking position, accumulated performance data. Change the address without telling Google where the page went, and that history stays attached to a door that no longer opens.

This is the technical companion to our piece on when and how to redesign a site, in the real order of operations: what to write down before you start, why the best redirect is the one you avoided, what to check on launch day, and which drop is normal afterwards.

The short answer, for the busy

A redesign rarely loses SEO because of the new design. It loses it because page addresses change and nobody wrote down, before starting, which pages were earning. The sequence that protects traffic has four steps. First, export from Search Console the pages and queries that generate your clicks: Google keeps only sixteen months of data, and you can't go back in time afterwards. Second, keep your existing addresses wherever you can, because a redirect you avoided is a redirect that can't go wrong. For the addresses that genuinely change, write a page-by-page mapping and serve permanent server-side 301 redirects, and keep them for at least a year. Finally, on launch day, check that the staging site's noindex or robots.txt block didn't ship to production, the mistake Google lists first in its migration troubleshooting guide. Expect a few weeks of ranking fluctuation while Google recrawls.

The inventory, before you touch anything

This is the step everyone skips, and the only one you can't recover from. Search Console keeps sixteen months of data and no more, which Google states in its own documentation. Once the redesign ships, you cannot reconstruct what you had.

Export three lists before the first hammer swing. The pages receiving organic clicks, sorted by clicks over twelve months. The queries bringing them in. And the addresses actually indexed, which the Page Indexing report shows in example lists capped at 1,000 URLs; past that, the Search Analytics API accepts up to 25,000 rows per request, against 1,000 by default.

That inventory earns its keep twice. It tells you which pages have to survive the redesign, and the answer is almost always a surprise: rarely the ones discussed in meetings. A 2019 blog post answering one narrow question in your trade often brings in more enquiries than the "About" page. And three months later, it's the only honest reference you have for judging whether you lost anything.

The best redirect is the one you didn't have to write

A redirect is a repair. It works, but it's never free: it adds a round trip for the user, it can be written wrong, and it eventually disappears the day someone tidies a config file.

Google is explicit in its Change of Address documentation: keeping the same site architecture in the new location helps pass the signals more directly, and combining a site move with a redesign of content and URL structure will probably cost you some traffic, because Google has to relearn and reassess the individual pages. The same documentation says to change only one thing at a time.

The practical consequence is unglamorous: redo the design, keep the addresses. If the new CMS imposes its own URL formats, the question is budgetary before it's technical. Either you configure it to reproduce the existing addresses, or you pay for a full migration with the redirect map and the monitoring that go with it. The worst of both worlds is discovering that constraint during launch week.

A page-by-page map, never "everything to the homepage"

For the addresses that do change, each old URL has to point at the page that genuinely replaces its content.

The classic mistake is redirecting everything that disappeared to the homepage, because that's a single line of configuration. Google rules it out explicitly: don't redirect many old URLs to one irrelevant single destination such as the home page of the new site, because it confuses users and might be treated as a soft 404 error. If you did consolidate several pages into one, redirecting the old ones to that consolidated page is fine.

Three rules cover the rest. Use permanent server-side redirects, 301 or 308: Google treats them as a strong signal that the new address is the right one, while a 302 or 307 is a weak, temporary signal that leaves the old address in the results. Redirect straight to the final destination: Googlebot follows up to ten hops, but the official advice is to stay under three and never exceed five. And keep those redirects for at least a year, long enough for Google to transfer the signals and for the sites linking to you to update their links.

Then own the genuine deletions. A page with no equivalent should return 404 or 410 rather than being redirected somewhere arbitrary: Google then drops the address from its index, which is the behaviour you want.

The redesign that quietly deleted what was working

The other half of the problem is the content. A forty-page site becomes eight beautiful pages, and the thirty-two that disappeared were carrying most of the search traffic. Technically it's all clean. Commercially you just switched off your main acquisition channel.

This is where the inventory pays off the second time. Before signing off on the new site map, walk the list of pages that receive clicks and ask one question per page: where does this content go? Three answers are acceptable: it stays as is, it merges into a fuller page, or it gets deleted knowingly.

The loss is often subtler than a deletion. The text that explained your service in six paragraphs becomes a three-word banner. Content moves into a carousel that shows one slide at a time. Page titles, written one at a time over years, get regenerated by the new system as "Home - Company Name". Each of those moves is defensible as design, and each removes part of what made you findable.

Launch day

One item does more damage than all the others combined. The staging site is almost always protected by a noindex rule or a robots.txt block. Publishing the new site without removing that protection is the first mistake Google lists on its migration troubleshooting page, and it's invisible: the site renders perfectly for visitors while Google drops it from the index. Two traps come with it: Google does not support a noindex rule written in robots.txt, and a robots.txt block prevents Googlebot from ever seeing the noindex tag on the page.

The rest takes an hour to verify. Every new page carries a self-referencing canonical tag. On a bilingual site, hreflang annotations use the new addresses. The new sitemap is submitted in Search Console. Internal links point at the new addresses instead of travelling through the redirects. And if the domain genuinely changes, the Change of Address tool forwards signals from the old site to the new one for 180 days; it isn't for an HTTP to HTTPS move, a www to non-www move, or shifting paths inside the same domain. While you're in there, measure the new site's speed, while fixes are still cheap.

What's normal, and what's an emergency

Google says it plainly: expect temporary ranking fluctuation, and allow a few weeks for a small to medium-sized site to finish moving in the index. Seeing the old address resurface occasionally in results is normal too, since Google keeps both versions for a while. Our article on how long SEO takes gives the same orders of magnitude.

Four things, on the other hand, get fixed the same day. A noindex in production. A forgotten robots.txt block. A spike of "not found" errors in Search Console, usually because redirects point at URLs that don't exist on the new site, which is the other frequent mistake Google flags. And pages from your inventory that stop receiving impressions entirely after three weeks. If a staging site did get indexed, the Removals tool hides an address for about six months without stopping crawling: a useful bandage, but the fix is still a 404 or a noindex.

Finally, keep both sitemaps: the indexed page count on the old one should fall towards zero as the new one climbs, and warnings about redirecting URLs there are expected. Plan for server capacity too, because Google crawls the new site more heavily than usual after a migration.

None of this gets decided during the redesign. It all gets decided beforehand, from a list most companies have never made. That's exactly what an audit produces: a record of what works today, before it becomes impossible to know.

→ Request an audit before your redesign