“We’re doing a relaunch” can mean five completely different things. And that’s exactly why traffic so often collapses after a migration: teams treat a harmless server move the same way they treat a full platform switch – even though one carries almost no risk and the other can seriously damage organic visibility.

The most important question is never how big your project feels. It’s this:

What changes from Google’s point of view?

If URLs change, signals have to be redirected. If content or structure changes, relevance signals shift. If only the technology underneath changes, nothing should happen at all.

So we’ll sort the migration types by risk – from practically invisible to genuinely dangerous. If you’re planning a move right now, you’ll find your case in this list. And you’ll see immediately how much caution it needs.

Hosting or server migration: the lowest risk

You’re only changing the infrastructure – new host, different server, new IP. URLs, content and structure stay the same.

For Google, this should be completely invisible. If something does go wrong here, it’s never the migration itself – it’s a workmanship error: a forgotten robots.txt from the staging system that goes live, a missing SSL certificate, or a noticeably slower new environment. Check those off and nobody notices the move.

As an aside: the once-feared move from http:// to https:// you can mentally cross off – practically every site has long since been on HTTPS, so you’ll rarely run into this case today. If you do catch one of the last exceptions: every URL needs a 301 to its HTTPS counterpart, and watch out for “mixed content” (a secure page still loading insecure resources).

Domain move, rebrand, merger: this is where all your authority travels

When you move to a new domain, the entire authority you’ve built over years travels to a new name. That’s one of the trickier standard cases – but “new domain” isn’t one case, it’s three, and they differ sharply in risk. Before you start, work out which one actually applies to you:

Pure domain change – same brand, new address (e.g. .de to .com, or a new company name with no break in content). This is the cleanest case: it’s almost entirely about transferring signals technically. Every old URL gets a 301 to its exact new counterpart, and the authority travels with it.

Rebrand – new name and new positioning. Here a second problem joins the technical transfer: the brand itself has to be re-established. From the perspective of classic search, clean redirects are enough; from the perspective of LLMs they aren’t (more on that below) – the rebrand is the case with the longest aftershock.

Merger – two or more domains become one. Now you’re combining two grown authority profiles, and for every overlap you have to decide which URL wins. The main danger is duplicate content cannibalising itself. (The reverse case – splitting one site into several – is further down under site split.)

Across all three cases the same iron rule applies: 301 to the exact new target, never just dump everything on the homepage – that throws away the individual ranking signals. And expect a period of fluctuation until Google has processed the transfer. The same principle already applies to the often-underestimated switch between www and non-www.

Changing URL structure: where it goes wrong in practice

The domain stays, but the way your addresses are built changes. In theory this is a domain move in miniature – every changed URL needs its 301. In practice, though, the risk rarely shows up as a cleanly planned project. It shows up in four typical patterns, three of which are avoidable own goals:

Planned restructuring – new permalinks, different directories, or moving the blog from blog.yoursite.com into the directory yoursite.com/blog. The uncritical case, if the redirect plan is in place.

Parallel URLs – the old and the new address both exist for a while because nobody switches the old one off. The result is duplicate content cannibalising itself: Google doesn’t know which version counts. Fix: one version is canonical, the other gets a 301 or is clearly assigned via canonical tag.

Delete and recreate instead of redirecting – someone removes a page and recreates the content under a new URL, with no 301. This is the single most common own goal: the old URL runs into a 404, all of its ranking signals expire, and the new page starts from zero even though the content is identical.

Spontaneous ad-hoc changes – “that URL is ugly, I’ll just change it real quick.” With no redirect and no documentation, redirect debt piles up over months until nobody can trace it anymore. A rule for the whole team: never change a URL without setting and recording the redirect in the same step.

And across every case: watch out for redirect chains – if A points to B and B only then to C, instead of A straight to C, you dilute link equity and burn crawl budget.

Platform or CMS switch (replatforming): nothing works without a complete mapping

When you switch your CMS or shop system, almost never does just one thing change. New systems bring new URL patterns, new HTML, different internal linking and often changed rendering – all at once. That’s exactly why spot-checking isn’t enough here.

What replatforming absolutely requires is a complete URL mapping: a list in which every old URL is matched to its exact new target – built and checked before go-live, not after. Not “the most important pages,” not “the top 100,” but every indexed URL. Whatever isn’t in the mapping runs into a 404 on moving day – and those are exactly the gaps you only see once the traffic is already gone.

In e-commerce this gets genuinely tricky, because product, category and filter URLs are affected in large numbers and you also have to decide what happens to discontinued products. By this point at the latest, a technical migration audit before go-live is no longer optional – it’s mandatory.

Design relaunch: “just” visual is a fallacy

A pure redesign appears at first glance to change only the looks. Don’t be fooled: along with the new look, the HTML structure, heading hierarchy, amount of text and internal linking usually change too – all things that count toward your relevance.

The most common mistake: during the redesign, texts get “tidied up” and shortened – and the very content your pages ranked for disappears. Visually it feels like progress. Organically it’s often a step back.

Content and structure migration: you’re touching relevance directly

Here you change the information architecture itself: pages are merged, content is consolidated, thin pages are removed, the navigation is recut.

This touches your topical relevance and the distribution of link equity directly. With a strategy it can even improve your rankings. Without clean redirects and a thought-through mapping, you tear holes where formerly strong pages simply fall away.

Site merge and site split: everything at once, but on purpose

In acquisitions or restructurings you merge several sites into one or split one into several. With that you combine domain, structure and content migration into a single project – including the question of how to bring duplicate or competing content together without it cannibalising itself.

Internationalisation: when languages and countries come into play

When your site goes multilingual or rolls out across several countries, language directories, country-specific domains or hreflang annotations come into play. Errors in hreflang logic are some of the nastiest of all, because they rarely crash hard – they quietly cause wrong country assignment, and that often only shows up weeks later.

The most dangerous case: everything at once

The riskiest “type” isn’t a path of its own at all, but a combination: new domain, new platform, new design and new structure in a single go-live.

The problem isn’t just the combined risk – it’s the diagnosis afterward. If traffic collapses, you can barely tell which of the four simultaneously changed levers was to blame. Whenever you possibly can, stagger your migration: platform first, then the redesign after things stabilise. That way every change stays individually measurable – and fixable.

Why this distinction decides everything

Most “ranking losses after a relaunch” are not a mysterious Google penalty. They’re the predictable consequence of treating one migration type like another. A hosting move needs a technical checklist. A domain move needs a complete redirect plan. A structure migration needs a content mapping. Get those confused and you secure the wrong things.

And across all types, one sentence holds: what you don’t measure beforehand, you can’t judge afterward. Without a clean before-snapshot – which URLs rank for which terms, which pages bring which traffic – all you have after go-live is the gut feeling that “something’s running worse,” with no clue what or why.

The second layer: migration from the perspective of LLMs

So far we’ve only talked about classic search engines. Since ChatGPT, Perplexity, Google AI Overviews and the rest now make up a growing share of how people discover brands, a second visibility layer has appeared – and it behaves completely differently during migrations. If you only secure your Google rankings, you’re securing half of it.

The key is that a language model reaches your content via two routes, and migrations hit them differently. One is live search at runtime – AI Overviews draw on the Google index, while ChatGPT Search relies heavily on Bing’s index and Microsoft’s search infrastructure (though not Bing alone – it also uses its own retrieval). Here the usual rules apply: clean 301s, crawlability, fast reindexing. The other route is the model’s training knowledge – a static snapshot of the web, with no live retrieval – and it’s the bigger share: recent analyses suggest only about a third of ChatGPT queries trigger a web search at all, with the rest answered straight from training.

That training route is the effect your normal monitoring misses. After a domain or URL change, models keep citing your old domain from memory for months – addresses long since 301’d or deleted. The redirect repairs the search index, not the model’s memory, so you can execute a move flawlessly and still surface under the old address in AI answers. That models lean on stored knowledge over live retrieval for known brands is documented: in one study, 16 percent of the brands named appeared in no retrieved source at all.

The rebrand is the hardest case here. For models, what counts is less the URL than the entity – your brand – and how consistently it appears across the web. How often other sites mention you is in fact the strongest measurable driver of whether AI systems cite you, stronger than classic backlinks. And they lean noticeably on third-party directories, review sites and comparison portals – so after a name change, those listings carry your visibility, and they have to catch up to the new name before the models do.

The two layers really are separate now. A peer-reviewed University of Toronto study measured, across 1,000+ queries, how much AI-cited domains overlap with Google’s top-10 – consistently