Redesigning Without Losing Google: The Migration Guide Nobody Reads in Time

The pattern is depressingly consistent. A company invests months in a beautiful new website, launches it with some pride, and six weeks later organic traffic is down forty per cent. Nobody warned them, because the people who built the site were designers and developers, and nobody asked the question that matters: what happens to the addresses that Google already knows about?

This article is the checklist we run on migrations, using the Semalt platform to capture the before-state and to diagnose the after-state. It applies to redesigns, replatforming, domain changes and — the case people forget — a large restructure of an existing site's navigation.

What actually breaks

Traffic loss after a migration nearly always traces back to a short list of causes. Knowing the list means you can check for each one specifically rather than searching in the dark.

The fourth row deserves its reputation. A noindex tag left over from staging is the single most damaging and most easily prevented migration failure, and it happens to competent teams regularly because the tag is invisible to everyone reviewing the site visually.

Working parameters from the process described below.

Before: capture the baseline

Everything that makes a migration diagnosable happens before launch. Two weeks beforehand is comfortable; the day before is not.

1. A complete crawl of the current site

   Every URL, its status code, title, and where it sits in the structure. This becomes the map you redirect from, and without it you are reconstructing the old site from memory.

2. The pages that actually matter, ranked

   Sort by traffic and by conversions. On most sites, a small fraction of URLs produces almost all the value, and those are the ones whose redirects must be verified individually rather than by rule.

3. A ranking and visibility snapshot

   Positions for the tracked keyword set on a fixed date, so that "we lost rankings" becomes a measurable statement rather than an impression.

4. The inbound link inventory

   Which external pages link to which of your URLs. Any URL with external links must redirect to a genuine equivalent, not to the homepage, or the value of those links is discarded.

Building the redirect map

The redirect map is the migration. Everything else is decoration.

Start from the full URL list, sorted by value. For the top pages — usually a few dozen — decide each destination by hand and verify it after launch individually. For the long tail, patterns are fine: category paths, old blog structures, parameter formats. The mistake is treating the whole site as a pattern problem, because the exceptions are always among the pages that matter most.

Three checks before launch: no redirect points to a URL that itself redirects, no redirect points to a 404, and every URL with an external link pointing at it has a genuine destination. These three take an afternoon and prevent the majority of avoidable loss.

Launch day: the hour that matters

1. Check for noindex immediately

   First action after deployment, before anything else. View source on the homepage, a category page and a deep page. If a staging tag survived, it costs minutes to remove now and months to recover from later.

2. Verify robots.txt

   Staging robots files that block everything are the second most common launch accident. Confirm the production file is the production file.

3. Test the top twenty redirects by hand

   Not by rule, by hand, in a browser. These are the pages carrying the traffic, and rule-based redirects have exceptions precisely where the exceptions cost the most.

4. Submit the new sitemap and trigger a crawl

   You want discovery to happen quickly, and you want your own crawl running so the next day's diff shows you what changed.

5. Confirm analytics and tracking still fire

   A migration that breaks measurement leaves you blind during exactly the fortnight when you most need to see.

The first three weeks

Expect movement. A genuine restructure changes internal linking, URL depth and sometimes content, and search engines take time to re-evaluate. A dip in the first fortnight is normal and not, by itself, evidence of a mistake.

What matters is the shape. Recovery beginning within two to three weeks means the migration worked and the system is settling. A decline that is still deepening at week four means something is broken and is going unnoticed.

We cover this in detail in Four Hours a Week.

The last item on the right is the most useful diagnostic in the list. When every page of one template declines while other templates hold, the cause is in that template — a missing element, a changed heading structure, a canonical error — and you have narrowed the search from the whole site to one file.

Domain changes: the higher-risk case

Changing the domain itself adds risk that a redesign does not, because every signal the old domain accumulated has to be transferred rather than preserved.

Two rules make it survivable. Change one thing at a time — domain now, redesign later, or the reverse — because when both change simultaneously and traffic falls, you cannot tell which caused it. And keep the old domain's redirects live indefinitely, or at minimum for years rather than months. Redirects that are switched off after six months discard the links they were preserving, and the loss arrives long after anyone connects it to the decision.

There is a full walkthrough in B2B SEO with Long Sales Cycles.

Getting the checks into a project you do not control

The uncomfortable reality of most migrations is that SEO is not in the room when the decisions are made. The design agency owns the look, the development team owns the build, and search gets consulted either at the end or after the damage. Technical knowledge does not help if it arrives in week eleven of a twelve-week project.

What works is making the requirements small, specific and early. A list of forty recommendations sent to a development team a fortnight before launch will be read as obstruction and quietly deprioritised. Four items, phrased as acceptance criteria, get built into the plan:

• Every existing URL either keeps its address or redirects, in one hop, to its closest equivalent.
• Production ships without noindex and with the production robots.txt — verified after deployment, not assumed.
• Page content is carried across, not summarised. If the design requires cutting text, the cut is a content decision made deliberately, not a side effect of a template.
• The pre-launch crawl export is stored and handed over.

That last point about content deserves emphasis, because it is where SEO and design genuinely conflict rather than merely miscommunicate. Redesigns almost always reduce text — cleaner pages look better in a portfolio. Sometimes that is correct, and the old page really was padded. Sometimes the removed FAQ block was the reason the page ranked. The way to settle it is to name which sections are load-bearing before the design is signed off, so the conversation happens over a wireframe rather than over a traffic report.

See also: Local SEO for Real.

If you are the person who inherits the site after launch with no baseline and no involvement, say so explicitly in the first report. Diagnosing a migration without a record of the previous state is genuinely much harder, and setting that expectation early is fairer to everyone than discovering it in month two.

When it has already gone wrong

If you are reading this after a launch that lost traffic, work in this order rather than by instinct.

First, confirm the site is indexable at all — noindex, robots.txt, and whether the important pages return 200. This takes five minutes and resolves a surprising share of cases outright.

Second, crawl and compare against whatever record exists of the old site. Every old URL that now 404s or redirects to the homepage is a specific, fixable loss. Third, check whether content was dropped: redesigns routinely lose paragraphs, FAQs and supporting text that the pages needed to rank, and the visual result looks cleaner while performing worse.

Only after those three should anyone discuss algorithms or competitors. In our experience the cause is on that list well over ninety per cent of the time.

The short version

Migrations fail for boring, preventable reasons, and they are prevented by boring, unglamorous work done before launch: a full crawl, a value-sorted page list, a hand-checked redirect map for the pages that matter, and a ninety-second index check on the day.

The design decisions everyone argues about for months are rarely what determines the outcome. The redirect map is.

If a redesign is coming and no baseline has been captured yet, that is the first thing to fix. Open the dashboard, run a full crawl of the current site, and export it before anyone touches production.