Skip to content
Get a quote

Article

What you lose in a site migration, and how to avoid it

A study of 892 migrations shows an average recovery of 523 days. What causes the traffic loss and how a proper redirect map prevents it.

6 September 2026site migration · technical seo · website rebuild

“We want to change platform, but we’re afraid of losing our Google rankings.” It is the most frequent and most justified objection you hear from any company with organic traffic built up over years. Justified because the risk is real and documented, not justified as a reason to postpone a necessary migration indefinitely. The difference between a recovery of a few weeks and one that never happens comes down almost entirely to one thing: the quality of the redirect map.

How big the risk is, with real numbers

A Search Engine Journal study of 892 domain migrations found an average organic traffic recovery time of 523 days. The fastest recoveries happened between 19 and 33 days, but 17% of sites had not recovered their traffic even after 1,000 days. The difference between three weeks and “never” is not luck, it is execution.

Two documented cases show exactly what produces the disaster. Sistrix IndexWatch data shows an 85.10% year on year visibility loss at NerdWallet, after an incomplete URL restructure where the sitemap declared only 255 URLs against 12,828 actively indexed. At BioMed Central the loss reached 98.40%, because the old URLs were redirected en masse to a single brand page rather than mapped individually. The methodological conclusion is direct: every old URL with traffic or authority has to be mapped individually to the most relevant new URL, never redirected generically to the homepage or to an “umbrella” page.

Google Search Central’s official recommendations are clear: server-side 301 redirects should be kept active for at least a year, so ranking signals transfer fully. Temporary visibility fluctuations during recrawling are normal, stabilising within a few weeks for mid-sized sites, but that assumes a correct migration map from the start, not one improvised after launch.

How to decide whether to repair or rebuild

Before the migration conversation there is an earlier question, just as important: does the current site need a redesign on its existing structure, or a full platform migration? The decision is not an aesthetic preference, it is a technical calculation across five criteria.

Maintenance risk: can a developer make a routine change, content, layout, without significant risk of breaking something else? Core Web Vitals: an LCP over 4 seconds, an FID over 300 milliseconds or a CLS over 0.25 on mobile point to a rendering architecture problem, not a cosmetic one fixable with surface optimisations. Platform support: does the framework or CMS version still receive active security patches? Integration stability: do payments, couriers, the CRM or the forms break repeatedly? Isolation of new features: can a new function be added without having to change code unrelated to it?

Three or more problematic answers out of five tip the decision toward a full platform migration rather than a redesign on the current structure. One warning worth remembering: applying a visual redesign over fundamentally broken code produces a visible short term improvement, but the problems come back within about six months, at which point the conversation about full migration returns, with extra costs already sunk.

Why the old platform matters more than it seems

A significant share of rebuild projects start from unpatched WordPress installations, and the 2025 security data shows why that matters beyond the aesthetic argument. There were 11,334 vulnerabilities discovered in the WordPress ecosystem in 2025, against 7,966 in 2024, of which 91% were in plugins and only 6 in the WordPress core. Exploitation is fast: mass exploitation of a published vulnerability begins on average within 5 hours, with 45% of vulnerabilities exploited in the first 24 hours and 70% in the first week. At installation level, around 2.5% of WordPress sites still run version 4.x or older, and only 48% run PHP with active security patches.

Those figures explain a frequent audit finding: a WordPress site from 2018-2021, with a premium theme that no longer gets updates, plugins abandoned by their developers, and a PHP version no longer officially supported. Every extra month of running unpatched widens the exposure window rather than holding it steady, and in serious cases leads to active compromise, injected phishing pages, suspicious redirects, the “this site may be dangerous” warning in Chrome. In those situations, inaction has a direct cost: Google blacklisting, loss of visitor trust, sometimes loss of customer data.

What process actually reduces the risk

A well executed migration starts with a technical and content audit that inventories every indexed URL, not just the ones in the sitemap, which is exactly where traffic is lost in the cases documented above, and verifies real access to the domain, hosting and accounts. Next comes the SEO migration map, a URL by URL mapping of every indexed old page to the new structure, with a plan of 301 redirects kept for at least a year, and explicit identification of pages with authority or backlinks that need special attention.

Execution happens in a staging environment, separate from the live site, so visitors and Google indexing are unaffected until launch. After launch, monitoring for at least 30 days tracks the recrawl rate, 404 errors on URLs that were not redirected correctly, and weekly organic traffic compared with the period before the migration.

Actual duration varies by scope: a redesign on an existing structure usually takes 4-8 weeks, a full platform migration 8-16 weeks. A distinct and frequent situation is recovering an abandoned site, where access to the domain, hosting or admin account was lost along with the company or the person who originally built it: the domain on a former contractor’s personal email, the password lost along with their laptop. In those cases, regaining control becomes the mandatory first step, before any discussion of design or platform.

The most frequent starting point: lost access

Before any discussion of platform or design, some rebuild projects start from a simpler and more urgent problem: access. “The company that built my site no longer exists” or “the guy who made it for us left the country and doesn’t answer” is the most frequent starting situation. The domain is registered on a former contractor’s personal email, the hosting sits on an account nobody at the company administers, and the admin password was lost along with that person’s laptop.

Regaining full control, transferring domain ownership, migrating hosting, resetting administrative access, becomes the mandatory first step of the project, before any discussion about design or platform. Checking the transfer and migration options can be done even without the former supplier’s cooperation, depending on the registrar and the available proof of ownership, but the process takes time and has to be treated as a separate stage, not as an administrative detail to be sorted in parallel with the rest of the project.

Comparing the cost properly

A redesign on the existing structure usually costs 60-80% of the price of an equivalent new project. The correct comparison is not “price of a new build” against “price of a rebuild”, but “price of a rebuild” against “price of a new build plus the cost of winning back traffic lost through a badly executed migration”, which, as the data above shows, can run past 500 days. A rushed migration, with no URL map and no proper redirects, is precisely the recipe for long term traffic loss. A realistic timeline of a few months, with a documented process, costs far less than a fast launch followed by a recovery that takes over a year.

If you are weighing up a platform change or a redesign and your current organic traffic has real value to you, the website rebuild & migration page describes the full audit and migration map process, while the technical SEO page details exactly what Google checks when URLs change.

Sources

In a similar situation?

Tell us where you stand. If the right answer is not the one you just read here, we will say so.

Request a quote