SEO migration: the real risk isn't the bad redirect, it's the abandoned page

You are rebuilding your site. The question in every meeting is not "will it look better", it is "are we going to lose our traffic". The honest answer is that nobody can tell you in advance. What gets lost in a migration is URLs, and you only find out afterwards.

So we took the problem from the other end. Instead of describing what should happen, we went to look at what actually happens elsewhere. 883 URLs followed hop by hop across 23 public domains, on 28 August 2026: 12 French SEO agencies, 8 SEO and GEO tools, 2 French media sites, and vydera.com in the sample, so as not to exempt ourselves from our own grid.

We started with the idea everybody repeats: the botched migration is the site that redirects everything to its home page. The measurement said no. The dominant defect sits elsewhere, it is far more mundane, and it is easier to avoid.

What we measured, and how

The panel held 25 domains. 23 remain: decathlon.fr and fnac.com answer 403 to every request, an anti-bot wall from the home page onwards. A 403 is not a measured block, it is a failed measurement, so both domains are set aside rather than counted as zeroes.

That is a real loss for the study, and worth stating plainly: those two were the likeliest candidates to have run a large-scale migration. What remains is mostly agencies and tools, that is to say sites that rarely migrate. This panel is not representative of sites currently migrating. It is representative of what technically careful sites leave lying around in normal operation, which is instructive enough.

For each domain, six families of URLs, 30 URLs when everything answers:

• the 4 entry points: http and https crossed with the apex and the www host
• 4 variants of the same deep page: as is, with the trailing slash flipped, over http, and with the host flipped
• 2 invented paths the site has never served
• 10 URLs drawn from the sitemap declared in robots.txt
• 10 outbound links from the home page
• 12 URLs served between 2019 and 2022, read from the Internet Archive CDX index

Every URL is followed hop by hop, recording the status code and the Location header at each step, through to the final status. 271 hops were observed in total. No private data is involved: public HTTP on public domains, nothing else.

The first result: they do not redirect badly, they do not redirect at all

The most instructive family is the old URLs. 209 of them, served between 2019 and 2022 across 18 domains, were requested again as they stood. Here is what became of them:

• 105 are intact: they answer 200, with no hop at all
• 51 redirect to another page: the work was done
• 50 return a 404
• 3 end up on the home page

12 of the 18 domains with a readable archive serve at least one old URL as a plain 404. That is the figure to keep, because it survives the sampling: it counts domains rather than URLs, so it does not depend on which slice was drawn from each site.

The rate does not get published, and it is worth explaining why. The CDX index returns results sorted by URL key. On a large domain the first rows form an alphabetical slice, not a random draw. On journaldunet.com that slice lands on its .shtml archives from the early 2000s: 12 out of 12 returning 404. Remove that single domain and the overall rate falls from 23.9% to 19.3%. A figure that moves four points when you drop one row is not a market rate. The domain count, on the other hand, holds.

What a 404 on an old URL costs is no mystery, and it needs no traffic estimate to be understood. The URL stops being indexable, its ranking falls away, and the external links that pointed at it land nowhere. A page returning 404 leaves the index and does not come back on its own, as we detailed in our decision tree on pages that are not indexed.

Redirecting to the home page is not the plague it is made out to be

The most direct test of a catch-all rule takes two URLs: two paths we invented, that nobody has ever served. A site redirecting blindly sends them to the home page. A clean site returns a 404.

22 of the 23 domains return a proper 404 or 410. Only one, korleon-biz.com, 301s both invented paths to its root. That is one case, not a trend, and counting it twice because there are two URLs would be dishonest: it is one fact, not two.

On the old URLs the conclusion is the same: 3 out of 209 end up on the home page. And across the 4 domains that redirect at least one URL to their root, the detail changes the reading entirely:

• seomix.fr sends /citations-web-et-seo/ to its root: a genuine content page lost
• oncrawl.com sends /platform/ to its root, and its own home page still links to that URL
• digimood.com tidies away /author/mboissy/, an author archive
• korleon-biz.com tidies away /blog/page/3, a pagination page

The last two are not faults. Sending an empty taxonomy page back to the root is defensible housekeeping, and confusing it with a botched migration would mean blaming a site for tidying up. Across those 4 domains, 2 lose a page and 2 are housekeeping. The operational lesson is simple: before counting redirects to the home page, look at what was at the other end.

"19 of 23 domains have a redirect chain": the figure that means nothing

This is exactly the sort of line an audit report will hand you, and it is misleading. Yes, 19 of the 23 domains serve at least one chain of 2 hops or more. But 11 of those 19 only have it on the root, that is to say on http://<non-canonical host>/.

Almost nobody uses that URL. And the chain it produces is the default behaviour of most servers: one rule forces https, another forces the canonical host, and the two stack. That is not negligence, it is an ordinary configuration, and its real cost is close to zero.

The number that matters is 8 out of 23: the domains carrying a chain of 2 hops or more on a content URL. The breakdown of the 35 chains recorded says it better than any percentage: 17 on the root, 9 on old URLs, 5 on the sitemap, 4 on the deep page. In other words, half of the apparent problem sits on the door nobody pushes.

Longest chain observed across the whole panel: 3 hops. On semji.com, and on vydera.com.

Four defects no tool report will show you

These are the cases where the final status is perfect, the crawler shows green, and something is still wrong inside the headers.

1. The chain that drops back to cleartext

2 domains out of 23 serve a chain that starts on https, passes through an http hop, then returns to https. semji.com sends https://www.semji.com/ to http://semji.com/, which goes back to https://semji.com/. On blogdumoderateur.com it is the rule stripping the /amp/ suffix that emits a cleartext Location, on 5 measured URLs.

Nobody sees this in a dashboard: the chain ends in 200 and in https, so every final-status counter reads green. You have to record each Location header, one by one, for the defect to appear.

2. The dead entry point

1 domain out of 23. eskimoz.fr sends http://www.eskimoz.fr/ to https://www.www.eskimoz.fr/, a host that does not exist. The cause is a classic: an "add www" rule applied to a host that already had it. The 301 is duly emitted, the destination does not resolve.

This case deserves a note on method, because it could easily have vanished into the statistics. The script separates three states: a URL measured through to the end, a broken chain, meaning at least one 3xx followed by an unreachable destination, and outright failure, where nothing was obtained. A broken chain is a result produced by the site, not a measurement error. Without that distinction, eskimoz.fr would have been filed as a network incident and the defect would never have surfaced.

3. The sitemap that declares redirects

4 domains out of 23 declare sitemap URLs that do not answer 200 directly: haloscan.com 8 out of 10, with 307s from /fr/... to /...; semrush.com 7 out of 10, including 5 two-hop chains to its developer subdomain; screamingfrog.co.uk 4 out of 10, 301s to /blog/...; peec.ai 2 out of 10, in 308. screamingfrog.co.uk also declares a URL returning a 4xx code.

A sitemap is a list of reference URLs. Leaving redirects in it means asking Google to spend crawl budget learning something you could have written down directly. After a migration, it is the file most often forgotten at regeneration time.

4. The home page that links to redirects

3 domains out of 23 have at least one outbound link on their own home page that redirects: uplix.fr 2 out of 10, oncrawl.com 1 out of 10, babbar.tech 1 out of 6. The oncrawl.com case is the most telling: its home page still recommends /platform/, a URL that lands back on the root. The page is gone, the link stayed.

An internal redirect is not a disaster, but it signals a batch of links that was never updated after a switch. Across a whole site, those links map out what was forgotten, and that is exactly what an internal linking audit surfaces in minutes.

A note of honesty on babbar.tech: only 21 URLs were observed there, against 42 on most of the others. The domain declares no sitemap at all, and its home page carried just 7 outbound links, 6 of which were tested. Its indicators are more fragile than those of the rest of the panel.

The codes: 301, and the temporary trap

Across the 271 hops observed, 229 are 301s, 15 are 308s, 15 are 302s and 12 are 307s. The market has therefore adopted the permanent code wholesale, which is the good news of this measurement.

6 domains out of 23 still use at least one temporary code, 302 or 307, and 4 use 308. The 308 is not a problem: it is a 301 that preserves the HTTP method. The 302 and the 307, on the other hand, tell the engine "do not update your index, this will come back". On a redirect meant to last, that is a contradiction.

Vydera.com goes through the same grid, and does not come out clean

Publishing a grid on public sites means submitting to it. Here are our own results, and they are not good:

• 3 of our 4 entry points cost 2 hops or more. http://www.vydera.com/ costs 3, the longest chain observed across the whole panel, tied with semji.com
• our locale redirect to /fr is a 302, therefore temporary, when it is there to stay
• our archive cannot be measured: the CDX index captured no vydera.com page between 2019 and 2022, the domain is too recent. So we can claim nothing about our own old URLs

The first two are root chains, exactly the defect we have just put into perspective for everyone else. The locale 302, though, has no excuse, and it sits on a multilingual redirect, an area where mistakes are expensive: we cover it in our hreflang guide.

The redirect plan, in 9 checks

Each of these checks is backed by a defect measured on the panel, not by a recited best practice. Tick them off as you go.

What this measurement does not say

Better to state the limits plainly, because they decide what may legitimately be concluded.

• No browser was used. Redirects served by meta refresh or by JavaScript are therefore not in this measurement. They exist, they are not counted
• A single User-Agent, Chrome's. Nothing here says what these sites serve to Googlebot or to AI crawlers
• We see the outcome, never the date. There is no way to tell whether a redirect comes from a migration or from ordinary housekeeping, nor when it was put in place
• Sample power is low: 10 URLs per sitemap, 10 home page links, 12 archived URLs. A zero means "nothing detected in this sample", never "this site is clean". The 18 domains at 0 out of 10 on the sitemap are not 18 healthy sitemaps. The positives, though, are facts
• Comparability between domains is partial: only the root family is strictly identical from one site to the next. The deep page is a different type of page on each site
• Two archives are missing to a fault of the source: the CDX index returned a 504 on haloscan.com and ahrefs.com after three attempts. That is awkward, because haloscan.com is precisely the domain with the worst sitemap drift
• No Search Console or GA4 property was opened. This measurement says nothing about traffic actually lost or gained on these redirects, so we will give no figure for it

Running the measurement yourself

It requires no account, no paid tool and no privileged access. The principle comes down to three moves.

1. Recover the list of your old URLs. The Internet Archive CDX API returns an inventory of what was captured on your domain, filterable by period. It is the only source that knows the URLs your current CMS has forgotten
2. Follow each URL hop by hop, recording the code and the Location at every step. A request that follows redirects automatically hides exactly what you need to see: the chain, not the destination
3. Cross-check against your own URL sources: declared sitemap, links on your home page, and the four entry points. Thirty URLs per domain are enough to bring structural defects out

Allow one second per request to stay polite with the servers. On a single domain the measurement takes under a minute. If your switch also changes the shape of your addresses, start by reading our definition of URL structure: a migration is the one moment when that gets fixed at no extra cost.

And if you are preparing a CMS switch, this is precisely the work we take on, from the inventory before to the re-check after: our migration offer.