We relaunched the site and traffic dropped: protecting search during a redesign or migration

When traffic falls after a relaunch, the cause is rarely the new design. It is the addresses. Pages moved to new URLs and the old ones were never mapped one to one onto their replacements, so when Google requests an old URL it finds a 404 or a bounce to the home page. Either way, the signals that page accumulated over years do not reach the new address. Some turbulence is normal even in a clean migration: Google's own documentation says most pages on a small to medium site take a few weeks to move across. A loss that is still there months later is not turbulence. It is a mapping failure.

Three different jobs under one name

"Site relaunch" covers three scenarios whose risk profiles have almost nothing in common.

The first is a visual refresh: templates and design change, URLs stay put. Technical risk is lowest here, though not zero, for reasons covered under content parity below.

The second is a change in URL structure. You are moving to a new CMS, flattening the category tree, or turning /product/12345 into readable addresses. This is where the real work lives.

The third is a domain change, whether from a rebrand, a merger, or a move from a country domain to .com. It includes everything in the second scenario and adds a separate step in Search Console.

Two things that do not belong on this list: moving from http to https, and switching between www and non-www. Google states plainly that the Change of Address tool should not be used for either.

No migration plan without a URL inventory

The raw material for a redirect map is a complete list of the old site's URLs, and no single source gives you one. The existing sitemap is a starting point but it is incomplete, because pages that never made it into the sitemap can still be collecting links. The CMS export is the second source. Server access logs are the third and the most valuable, since they show the addresses that are actually being requested. Pull at least twelve months of logs, or you will miss the campaign and seasonal pages that only earn traffic one month a year. Analytics is the fourth source, the Search Console performance report the fifth, a backlink tool the sixth.

Google adds one item explicitly: include the URLs of embedded content, meaning images and video. Sites with meaningful image search traffic skip this and then take weeks to notice what went missing.

While you are gathering all that, take a baseline. Export clicks and impressions per URL for the last three to six months before the migration goes out. Without it, the post-launch conversation about whether traffic dropped, by how much, and on which pages runs on impressions instead of data.

Map page to page, and stop dumping everything on the home page

The most common shortcut in a migration is redirecting every old address to the home page. The 404s disappear, the report looks clean, and the job feels finished. Google's migration guidance argues directly against it and asks for page-level mapping, where each old page points at its counterpart on the new site.

This is not only about user experience. A redirect to an irrelevant destination can be treated as a soft 404. The old URL keeps getting crawled but never gets indexed, and the signals you expected to carry over do not carry over. You end up paying the cost of a 404 without collecting the benefit of a redirect.

For content that genuinely has no replacement, a redirect is the wrong answer. A retired campaign page or a product you no longer sell should return 404 or 410. That is not a failure, it is the honest way to tell Google there is nothing here anymore.

301 or 302, and why it matters

Google's redirect documentation splits the signals in two. Permanent redirects, 301 and 308, are strong signals: the indexing pipeline treats the redirect as an indication that the target should be canonical. Temporary ones, 302, 303 and 307, are weak signals. Googlebot follows them but does not use them for canonicalisation, which means the old URL can stay in the index. In a migration you want permanent redirects.

Where a server-side redirect is impossible, the order of preference is clear. Google describes an instant meta refresh as a viable alternative, and recommends JavaScript redirects only when neither of the other two is available, because if the page fails to render Google may never see the redirect at all.

Watch for chains. Google's crawlers follow up to 10 redirect hops by default, but that is a ceiling, not a target. Rules left over from earlier migrations stack up, and /old-category/product ends up reaching its destination in three or four hops, each of which is also latency for a real visitor. Point your internal links and your new sitemap straight at the final address rather than routing them through a redirect.

How long to keep redirects is not up for debate: Google says keep them as long as possible, generally at least a year. Since a large share of external links will never be updated, leaving them in permanently is the more realistic policy.

Launch day: all at once or in sections?

Google's advice scales with the site. For small and medium sites it recommends moving all URLs at the same time, both for a consistent user experience and so its algorithms detect the change faster. For large sites, moving in sections makes monitoring more manageable.

There is one launch-day preparation that teams routinely skip: server capacity. Google notes that it will temporarily crawl the new site more heavily after a migration. That extra load lands on day one of your new infrastructure, and on a tight server it turns into slow responses or 503s, which in turn slows crawling. Raising capacity for launch week is cheap insurance. How to run the release itself without downtime is covered in our post on zero-downtime deployments.

The pre-launch checklist

Most of these appear in Google's own list of common migration mistakes.

• Are the noindex tags and robots.txt blocks from the staging environment gone? One leftover line that de-indexes the entire new site is the most expensive mistake in this whole process.
• Do not block old URLs in robots.txt. If Google cannot crawl them, it cannot see the redirects.
• Do the new pages carry a self-referencing rel="canonical"? A leftover canonical pointing at the old address contradicts the redirect.
• On a multilingual site, hreflang annotations must point at the new URLs and must be reciprocal. We covered that side in our post on multilingual site architecture.
• Have internal links been updated, including navigation, footer and in-content links?
• Is the new sitemap ready to submit in Search Console?
• Will your Search Console verification method survive the move? If you verified with an HTML file uploaded to the server, that file may not exist on the new site.
• Test the redirect rules on staging before launch. Write a check that walks the old URL list automatically rather than spot-checking by hand; nobody verifies a twenty-thousand-row map manually.

If the domain changes: the Change of Address tool

The Change of Address tool in Search Console applies only to domain and subdomain changes, and it comes with firm conditions. Both the old and the new property must be verified in the same Google account. The 301 redirects have to be in place before you use it. It works only for domain-level properties, so you cannot use it for a path-level property such as example.com/store. Each subdomain variant, www and non-www included, needs its own request.

What the tool does is tell Google to prioritise crawling the new site and forward signals to the new addresses. Its effect lasts 180 days. Google says that after that window it no longer recognises a relationship between the two sites, and treats the old one as an unrelated site if it is still up and crawlable.

Two practical conclusions follow. First, 180 days is not permission to remove the redirects; the tool and the redirects are separate mechanisms, and the guidance on redirects is still at least a year. Second, do not let the old domain lapse. You need it for the redirects to keep working, and an abandoned domain picked up by someone else puts both your old links and your brand at risk.

The redesign itself can cost you traffic

Even when URLs do not change, a new template can move rankings, because what the page shows Google changes. The recurring losses look like this: descriptive copy trimmed so the layout looks cleaner, an h1 replaced by an image, intro paragraphs removed from category pages, an FAQ section dropped, internal link counts falling sharply, and structured data markup that never made it into the new templates. When product, breadcrumb and FAQ markup gets forgotten, the rich results in search go with it.

There is a rendering side too. If the new interface builds its content entirely in the browser, what Google sees may differ from what you see. When in doubt, use the live test in the URL Inspection tool and read the rendered HTML.

Performance regressions belong in the same category. A heavier bundle degrades your field metrics, and the thresholds and the order in which to fix things are in our post on Core Web Vitals.

The practical check is simple. Take your twenty highest-traffic pages, put the old and new templates side by side, and compare four things: word count, heading hierarchy, number of internal links, and schema markup.

The first thirty days after launch

On day one, test a sample of URLs with the URL Inspection tool. The live test tells you how Google sees the redirect and whether the destination is indexable. Sample from both the old addresses and the new ones.

In the first week, server logs are your fastest feedback loop. Pull the old addresses where Googlebot received a 404, join them against your pre-launch traffic data, and sort. That is your fix list, and the top fifty rows usually explain most of the loss. In the same week, watch the page indexing report in Search Console for rising 404s, the redirect category and server errors.

From the second week, compare impression curves for old and new URLs in the performance report. The expected shape is old addresses declining while new ones climb. If both are falling, something is missing in the map.

Set the timing expectation up front. Google's range is a few weeks for small and medium sites, longer for large ones, and Search Console data itself arrives with a lag of a few days. Rewriting redirect rules in a panic on day two mostly guarantees you will never diagnose what happened.

AI answers follow the same redirects

Part of search traffic now arrives through chat interfaces and answer engines, and those systems cite sources by URL as well. A broken redirect map costs you those citations along with the classic rankings. Address stability is a baseline requirement on that side too. How visibility there is measured, and what actually moves it, is in our post on visibility in AI search.

A step you can take this week

If the migration has not shipped yet, produce one artefact: the old URL inventory with a destination next to every row. The number of rows with an empty destination is the real measure of your migration risk. Do not commit to a launch date until that number is close to zero.

If the migration already happened and traffic fell, the order is different. Pull the addresses returning 404 over the last 30 days from your server logs, join them with your old traffic data, sort descending, and wire the top fifty to the right destinations. In most cases that single piece of work brings back the bulk of the loss. If the list is large, or you cannot tell where the loss is coming from, we can go through your redirect map and post-launch data together.