Migration SEO : le vrai risque n'est pas la mauvaise redirection, c'est la page abandonnée

Vous refaites votre site. La question qui revient à chaque réunion n'est pas « est-ce que ce sera plus beau », c'est « est-ce qu'on va perdre notre trafic ». La réponse honnête, c'est que personne ne peut vous la donner à l'avance. Ce qui se perd pendant une migration, ce sont des URLs, et on ne le constate qu'après.

Alors on a pris le problème à l'envers. Au lieu de décrire ce qui devrait se passer, on est allé regarder ce qui se passe vraiment chez les autres. 883 URLs suivies saut par saut sur 23 domaines publics, le 28 août 2026 : 12 agences SEO françaises, 8 outils SEO et GEO, 2 médias français, et vydera.com dans le lot, pour ne pas s'exclure de sa propre grille.

On partait avec l'idée que tout le monde répète : la migration bâclée, c'est le site qui renvoie tout vers sa page d'accueil. La mesure a dit non. Le défaut dominant est ailleurs, il est beaucoup plus banal, et il est plus facile à éviter.

Ce qu'on a mesuré, et comment

Le panel comptait 25 domaines. Il en reste 23 : decathlon.fr et fnac.com répondent 403 à toutes nos requêtes, mur anti-bot dès la page d'accueil. Un 403 n'est pas un blocage mesuré, c'est une mesure ratée, et les deux domaines sont écartés plutôt que comptés comme des zéros.

C'est une perte sèche pour l'étude, et autant le dire tout de suite : c'étaient les deux candidats les plus susceptibles d'avoir mené une migration de grande ampleur. Ce qui reste, ce sont surtout des agences et des outils, c'est-à-dire des sites qui migrent rarement. Ce panel n'est pas représentatif des sites en cours de migration. Il est représentatif de ce que des sites techniquement soignés laissent traîner en régime de croisière, ce qui est déjà instructif.

Pour chaque domaine, six familles d'URLs, 30 URLs quand tout répond :

• les 4 portes d'entrée : http et https croisés avec l'apex et le www
• 4 variantes d'une même page profonde : telle quelle, slash final inversé, en http, avec l'hôte inversé
• 2 chemins inventés, que le site n'a jamais servis
• 10 URLs tirées du sitemap déclaré dans robots.txt
• 10 liens sortants de la page d'accueil
• 12 URLs servies entre 2019 et 2022, lues dans l'index CDX de l'Internet Archive

Chaque URL est suivie saut par saut, en relevant le code et l'en-tête Location de chaque étape, jusqu'au statut final. 271 sauts ont été observés au total. Aucune donnée privée n'entre là-dedans : seulement du HTTP public sur des domaines publics.

Le premier résultat : ils ne redirigent pas mal, ils ne redirigent pas

La famille la plus instructive est celle des anciennes URLs. 209 d'entre elles, servies entre 2019 et 2022 chez 18 domaines, ont été redemandées telles quelles aujourd'hui. Voilà ce qu'elles sont devenues :

• 105 sont intactes : elles répondent 200, sans le moindre saut
• 51 redirigent vers une autre page : le travail a été fait
• 50 rendent un 404
• 3 finissent sur la page d'accueil

12 des 18 domaines dont l'archive était lisible servent au moins une ancienne URL en 404 sec. C'est le chiffre à retenir, parce qu'il résiste au tri : il compte des domaines, pas des URLs, et il ne dépend donc pas de la tranche prélevée chez chacun.

Le taux, lui, ne se publie pas, et il vaut la peine d'expliquer pourquoi. L'index CDX rend ses résultats triés par clé d'URL. Sur un gros domaine, les premières lignes forment une tranche alphabétique, pas un tirage au sort. Chez journaldunet.com, cette tranche tombe sur ses archives en .shtml des années 2000 : 12 sur 12 en 404. Retirez ce seul domaine et le taux global passe de 23,9 % à 19,3 %. Un chiffre qui bouge de quatre points quand on enlève une ligne n'est pas un taux de marché. Le comptage par domaine, lui, tient.

Ce que coûte un 404 sur une ancienne URL n'a rien de mystérieux, et il ne demande aucune estimation de trafic pour être compris. L'URL cesse d'être indexable, sa position tombe, et les liens externes qui pointaient vers elle atterrissent dans le vide. Une page qui répond 404 sort de l'index et n'y revient pas toute seule, comme on l'a détaillé dans notre arbre de décision sur les pages non indexées.

La redirection vers l'accueil n'est pas le fléau qu'on décrit

Le test le plus direct de la règle attrape-tout tient en deux URLs : deux chemins que nous avons inventés, que personne n'a jamais servis. Un site qui redirige aveuglément les renvoie vers l'accueil. Un site propre rend un 404.

22 des 23 domaines rendent un 404 ou un 410 propre. Un seul, korleon-biz.com, renvoie nos deux chemins inventés en 301 vers sa racine. C'est un cas, pas une tendance, et le compter deux fois parce qu'il y a deux URLs serait malhonnête : c'est un fait, pas deux.

Sur les anciennes URLs, la conclusion est la même : 3 sur 209 finissent à l'accueil. Sur les 4 domaines qui redirigent au moins une URL vers leur racine, le détail change complètement la lecture :

• seomix.fr renvoie /citations-web-et-seo/ vers sa racine : une vraie page de contenu perdue
• oncrawl.com renvoie /platform/ vers sa racine, et sa propre page d'accueil pointe encore vers cette URL
• digimood.com range /author/mboissy/, une archive d'auteur
• korleon-biz.com range /blog/page/3, une page de pagination

Les deux derniers ne sont pas des fautes. Renvoyer une taxonomie vide vers la racine est un ménage défendable, et le confondre avec une migration bâclée reviendrait à reprocher à un site d'avoir rangé. Sur ces 4 domaines, 2 perdent une page, 2 font le ménage. La leçon opérationnelle est simple : avant de compter les redirections vers l'accueil, regardez ce qu'il y avait au bout.

« 19 domaines sur 23 ont une chaîne de redirection » : le chiffre qui ne veut rien dire

Voilà exactement le genre de ligne qu'un rapport d'audit vous sortira, et elle est trompeuse. Oui, 19 des 23 domaines servent au moins une chaîne de 2 sauts ou plus. Mais 11 de ces 19 ne l'ont que sur la racine, c'est-à-dire sur http://<hôte non canonique>/.

Cette URL-là, presque personne ne l'emprunte. Et la chaîne qu'elle produit est le comportement par défaut de la plupart des serveurs : une règle force https, une autre force l'hôte canonique, les deux s'empilent. Ce n'est pas de la négligence, c'est une configuration ordinaire, et son coût réel est proche de zéro.

Le chiffre qui compte est 8 sur 23 : les domaines qui portent une chaîne de 2 sauts ou plus sur une URL de contenu. La répartition des 35 chaînes relevées le dit mieux qu'un pourcentage : 17 sur la racine, 9 sur les anciennes URLs, 5 sur le sitemap, 4 sur la page profonde. Autrement dit, la moitié du problème apparent se concentre sur la porte que personne ne pousse.

Saut maximum observé sur tout le panel : 3. Sur semji.com, et sur vydera.com.

Quatre défauts qu'aucun rapport d'outil ne vous montrera

Ce sont les cas où le statut final est parfait, où le crawler affiche du vert, et où quelque chose cloche quand même dans le détail des en-têtes.

1. La chaîne qui repasse en clair

2 domaines sur 23 servent une chaîne qui part en https, traverse un saut en http, puis revient en https. semji.com envoie https://www.semji.com/ vers http://semji.com/, qui repart vers https://semji.com/. Chez blogdumoderateur.com, c'est la règle de retrait du suffixe /amp/ qui émet un Location en clair, sur 5 URLs mesurées.

Personne ne voit ça dans un tableau de bord : la chaîne finit en 200 et en https, tous les compteurs de statut final sont au vert. Il faut relever chaque en-tête Location, un par un, pour que le défaut apparaisse.

2. La porte d'entrée morte

1 domaine sur 23. eskimoz.fr renvoie http://www.eskimoz.fr/ vers https://www.www.eskimoz.fr/, un hôte qui n'existe pas. La cause est un classique : une règle « préfixer www » appliquée à un hôte qui l'avait déjà. Le 301 est bien émis, la destination ne résout pas.

Ce cas mérite un mot de méthode, parce qu'il aurait pu disparaître dans les statistiques. Le script distingue trois états : l'URL mesurée jusqu'au bout, la chaîne rompue, c'est-à-dire au moins un 3xx suivi d'une destination injoignable, et l'échec pur, où rien n'a été obtenu. Une chaîne rompue est un résultat du site, pas une erreur de mesure. Sans cette distinction, eskimoz.fr serait rangé en incident réseau et le défaut ne serait jamais remonté.

3. Le sitemap qui déclare des redirections

4 domaines sur 23 déclarent dans leur sitemap des URLs qui ne répondent pas 200 directement : haloscan.com 8 sur 10, avec des 307 de /fr/... vers /... ; semrush.com 7 sur 10, dont 5 chaînes de 2 sauts vers son sous-domaine développeur ; screamingfrog.co.uk 4 sur 10, en 301 vers /blog/... ; peec.ai 2 sur 10, en 308. screamingfrog.co.uk déclare en plus une URL qui rend un code 4xx.

Un sitemap est une liste d'URLs de référence. Y laisser des redirections, c'est demander à Google de dépenser du crawl pour apprendre ce qu'on aurait pu lui écrire directement. Après une migration, c'est le fichier qu'on oublie le plus souvent de régénérer.

4. La page d'accueil qui pointe vers des redirections

3 domaines sur 23 ont au moins un lien sortant de leur propre accueil qui redirige : uplix.fr 2 sur 10, oncrawl.com 1 sur 10, babbar.tech 1 sur 6. Le cas d'oncrawl.com est le plus parlant : sa page d'accueil recommande encore /platform/, une URL qui renvoie à la racine. La page a disparu, le lien est resté.

Une redirection interne n'est pas une catastrophe, mais elle signale qu'un lot de liens n'a pas été mis à jour après une bascule. Sur un site entier, ces liens dessinent une carte de ce qui a été oublié, et c'est exactement le genre de chose qu'un audit de maillage interne fait remonter en quelques minutes.

Note d'honnêteté sur babbar.tech : 21 URLs seulement y ont été observées, contre 42 chez la plupart des autres. Le domaine ne déclare aucun sitemap et sa page d'accueil ne portait que 7 liens sortants, dont 6 testés. Ses indicateurs sont plus fragiles que ceux du reste du panel.

Les codes : 301, et le piège du temporaire

Sur les 271 sauts observés, 229 sont des 301, 15 des 308, 15 des 302 et 12 des 307. Le marché a donc massivement adopté le permanent, ce qui est la bonne nouvelle de cette mesure.

6 domaines sur 23 emploient malgré tout au moins un code temporaire, 302 ou 307, et 4 emploient du 308. Le 308 ne pose pas de problème : c'est un 301 qui préserve la méthode HTTP. Le 302 et le 307, eux, disent au moteur « ne mets pas à jour ton index, ça va revenir ». Sur une redirection destinée à durer, c'est un contresens.

Vydera.com passe dans la même grille, et n'en sort pas indemne

Publier une grille sur des sites publics oblige à s'y soumettre. Voici donc nos propres résultats, qui ne sont pas bons :

• 3 de nos 4 portes d'entrée coûtent 2 sauts ou plus. http://www.vydera.com/ en coûte 3, le maximum observé sur tout le panel, à égalité avec semji.com
• notre redirection de locale vers /fr est un 302, donc temporaire, alors qu'elle est là pour rester
• notre archive n'est pas mesurable : l'index CDX n'a capté aucune page de vydera.com entre 2019 et 2022, le domaine est trop récent. On ne peut donc rien affirmer sur nos anciennes URLs

Les deux premiers points sont des chaînes de racine, exactement le défaut que l'on vient de relativiser pour les autres. Le 302 de locale, lui, n'a aucune excuse, et il touche une redirection multilingue, sujet où les erreurs se paient cher : on en parle dans notre guide hreflang.

Le plan de redirection, en 9 contrôles

Chacun de ces contrôles est adossé à un défaut mesuré sur le panel, pas à une bonne pratique récitée. Cochez-les au fur et à mesure.

Ce que cette mesure ne dit pas

Autant poser les limites franchement, parce qu'elles décident de ce qu'on a le droit de conclure.

• Aucun navigateur n'a été utilisé. Les redirections par meta refresh ou par JavaScript ne sont donc pas dans cette mesure. Elles existent, elles ne sont pas comptées
• Un seul User-Agent, celui de Chrome. Rien ici ne dit ce que ces sites servent à Googlebot ou aux robots IA
• On voit le résultat, jamais la date. Impossible de savoir si une redirection vient d'une migration ou d'un simple ménage, ni quand elle a été posée
• La puissance de l'échantillon est faible : 10 URLs par sitemap, 10 liens de page d'accueil, 12 URLs archivées. Un zéro veut dire « rien détecté sur cet échantillon », jamais « ce site est propre ». Les 18 domaines à 0 sur 10 sur le sitemap ne sont pas 18 sitemaps sains. Les positifs, eux, sont des faits
• La comparabilité entre domaines est partielle : seule la famille racine est strictement identique d'un site à l'autre. La page profonde est un type de page différent selon les sites
• Deux archives manquent pour cause de panne : l'index CDX a rendu un 504 sur haloscan.com et ahrefs.com après trois tentatives. C'est gênant, parce que haloscan.com est justement le domaine au pire décalage de sitemap
• Aucune propriété Search Console ni GA4 n'a été ouverte. Cette mesure ne dit rien du trafic réellement perdu ou gagné sur ces redirections, et nous n'en donnerons donc aucun chiffre

Refaire la mesure chez vous

Elle ne demande ni compte, ni outil payant, ni accès privilégié. Le principe tient en trois gestes.

1. Récupérez la liste de vos anciennes URLs. L'API CDX de l'Internet Archive rend l'inventaire de ce qui a été capturé sur votre domaine, filtrable par période. C'est la seule source qui connaisse les URLs que votre CMS actuel a oubliées
2. Suivez chaque URL saut par saut, en relevant le code et le Location de chaque étape. Une requête qui suit les redirections automatiquement vous cache exactement ce qu'il faut voir : la chaîne, pas la destination
3. Recoupez avec vos propres sources d'URLs : sitemap déclaré, liens de votre page d'accueil, et les quatre portes d'entrée. Trente URLs par domaine suffisent à faire sortir les défauts structurels

Comptez une seconde par requête pour rester poli avec les serveurs. Sur un domaine, la mesure prend moins d'une minute. Si votre bascule change aussi la forme de vos adresses, relisez d'abord notre définition de la structure d'URL : une migration est le seul moment où ça se corrige sans coût supplémentaire.

Et si vous préparez une bascule de CMS, c'est précisément le travail que nous prenons en charge, de l'inventaire d'avant à la revérification d'après : notre offre de migration.