Ce qui casse vraiment lors d'une migration SEO (et jamais le design)

Quatre signaux techniques concentrent le risque d'une refonte : un mapping d'URL incomplet, une chaîne de redirections trop longue, un canonical contradictoire, un hreflang oublié. Ce modèle de risque se vérifie URL par URL, avant la bascule (jamais après, sur une courbe de trafic qui a déjà décroché).

Le mauvais diagnostic : accuser le design

Une équipe qui perd du trafic après une refonte cherche d'abord du côté du visuel (une hiérarchie de page changée, un menu réorganisé, une densité de texte réduite). C'est rarement là que se joue la perte. Le pilier Migration SEO technique pose déjà le principe : ce sont les URLs déplacées sans plan, pas le nouveau gabarit graphique, qui font perdre le trafic organique acquis.

Le design est visible, débattu en réunion, validé par plusieurs regards avant la mise en ligne. Les signaux techniques qui suivent, eux, ne sont vérifiés par personne s'ils ne figurent pas explicitement dans un plan de recette. C'est ce déséquilibre d'attention qui produit la perte : on soigne ce qu'on voit, on oublie ce que seul un moteur de recherche lit.

Les quatre signaux qui cassent en silence

Chacun de ces signaux peut, seul, faire perdre une part significative du trafic organique d'un site migré, et aucun n'est visible à l'œil nu sur le nouveau site en ligne.

Un mapping d'URL incomplet

Ce qu'il faut préserver : chaque URL de l'ancien site doit être associée explicitement à sa destination sur le nouveau site, avant la bascule, pas après. Google recommande de dresser la liste complète des anciennes URLs et de décider, pour chacune, où elle redirige (Google Search Central).

Ce qui casse si on l'ignore : une URL orpheline, absente du mapping, ne redirige nulle part. Elle renvoie une erreur 404 le jour de la bascule, et avec elle disparaît tout le signal accumulé sur cette page : ancienneté, liens entrants, position acquise.

Des chaînes de redirection trop longues

Ce qu'il faut préserver : une redirection directe, de l'ancienne URL vers sa destination finale, en un seul saut. Googlebot suit jusqu'à dix redirections en chaîne, mais Google déconseille fortement cette pratique et recommande de rediriger directement vers la destination finale, ou à défaut de limiter la chaîne à quelques sauts au maximum (Google Search Central).

Ce qui casse si on l'ignore : chaque saut ajoute de la latence et une occasion supplémentaire d'erreur de configuration. Une chaîne héritée d'une précédente migration, jamais nettoyée, se rallonge silencieusement à chaque refonte suivante jusqu'à devenir un point de fragilité que plus personne ne documente.

Des canonicals contradictoires

Ce qu'il faut préserver : chaque nouvelle URL doit porter une balise canonique auto-référente, cohérente avec l'URL réellement servie. Google le formule sans ambiguïté : chaque nouvelle URL doit avoir sa propre balise rel="canonical" qui pointe vers elle-même (Google Search Central).

Ce qui casse si on l'ignore : un gabarit de page dupliqué en urgence pendant la refonte, qui hérite du canonical d'une page source sans le corriger, indique à Google de tout indexer sous l'ancienne référence. Le nouveau contenu existe, mais n'est jamais reconnu comme la page à afficher.

Un hreflang oublié ou mal reporté

Ce qu'il faut préserver : pour un site multilingue ou multi-domaines, chaque annotation hreflang doit être mise à jour vers les nouvelles URLs au moment de la bascule, jamais après coup. La documentation est explicite sur ce point : les annotations hreflang doivent être actualisées pour pointer vers les nouvelles URLs (Google Search Central).

Ce qui casse si on l'ignore : un ciblage international qui pointait juste avant la migration continue de pointer vers des URLs qui n'existent plus. Le résultat n'est pas une erreur visible, mais un ciblage géographique et linguistique qui se dégrade progressivement, sans alerte immédiate.

Le tableau de synthèse

Signal	Ce qu'il faut préserver	Ce qui casse en silence
Mapping d'URL	Chaque ancienne URL associée à sa destination avant bascule	URL orpheline → 404 → perte du signal accumulé
Chaîne de redirection	Redirection directe, un seul saut	Latence + fragilité qui s'accumule migration après migration
Canonicals	Balise auto-référente cohérente par URL	Indexation qui reste bloquée sur l'ancienne référence
Hreflang	Annotations mises à jour au moment de la bascule	Ciblage international qui se dégrade sans alerte

Combien de temps garder les redirections

Un an au minimum : c'est la durée que recommande Google pour conserver les redirections après une migration, le temps que l'ensemble des signaux se transfère vers les nouvelles URLs (Google Search Central). Une équipe qui retire ses redirections trois mois après la bascule, pressée de simplifier sa configuration serveur, coupe le transfert de signal en cours de route, souvent sans le savoir avant l'analyse du trafic suivante.

D'après notre expérience, la période la plus fragile n'est jamais le jour de la bascule elle-même, mais les semaines qui suivent : c'est là qu'une redirection retirée trop tôt, ou un mapping découvert incomplet, produit ses effets sur le trafic sans qu'un signal d'alerte évident ne le désigne.

La doctrine : cartographier avant de coder

Une règle organise ces quatre signaux, et elle précède tout chantier de développement : on cartographie l'existant avant de toucher au code, jamais l'inverse.

Une migration ne se sécurise pas en corrigeant les redirections après la mise en ligne. Elle se sécurise en décidant, pour chaque URL existante, de son sort exact avant que la première ligne de la nouvelle architecture ne soit écrite.

Cette cartographie est le sujet de l'architecture d'URL qui survit à une refonte : la méthode et le gabarit à remplir avant toute bascule. Une fois cette base posée, la vérification technique se rejoue systématiquement via la recette preprod migration SEO, et deux risques dérivés méritent leur propre diagnostic : la cannibalisation entre sites d'une même enseigne et les signaux propres à un changement de CMS.

Cette fondation SEO (indexation propre, canonicals cohérents, structure stable) est aussi la condition d'entrée de toute couche GEO ultérieure : un GEO ne se pense jamais sans elle.

Pour une migration qui vérifie ces quatre signaux avant la bascule plutôt qu'après, notre accompagnement sécurise la recette de bout en bout, avec un verdict go/no-go objectivé.

Questions fréquentes

Combien de temps faut-il garder les redirections après une migration ?

Au moins un an, selon la recommandation de Google, le temps que les signaux se transfèrent intégralement vers les nouvelles URLs. Les retirer plus tôt coupe ce transfert avant qu'il ne soit terminé.

Une chaîne de redirections pose-t-elle vraiment un problème ?

Oui. Googlebot suit une chaîne jusqu'à dix sauts, mais chaque saut ajoute de la latence et un risque de rupture. La bonne pratique reste une redirection directe vers la destination finale, en un seul saut.

Un canonical mal configuré peut-il expliquer une perte de trafic après refonte ?

Oui, et c'est un des cas les plus fréquents. Une URL migrée qui hérite par erreur du canonical d'une autre page indique à Google de continuer à indexer l'ancienne référence : le nouveau contenu existe, mais n'est jamais reconnu comme la version à afficher.

Le hreflang doit-il être mis à jour immédiatement lors d'une bascule ?

Oui, au moment même de la bascule, jamais après coup. Un hreflang qui pointe encore vers des URLs disparues dégrade le ciblage international sans produire d'erreur immédiatement visible.