Une migration ratée ne se voit jamais le jour de la mise en ligne. Elle se voit trois semaines plus tard, quand le trafic organique a fondu de moitié et que plus personne ne sait par quel bout reprendre le dossier. SALT.agency a documenté 1 052 migrations de domaine : la médiane de récupération s’établit à 304 jours, et 27 % seulement retrouvent leur niveau de trafic en moins de 90 jours. L’échantillon est déclaratif, donc probablement tiré vers les cas problématiques. Il reste que l’ordre de grandeur a de quoi calmer l’enthousiasme d’un comité de direction pressé de lancer son nouveau site.

Les redirections 301 ne font perdre aucune autorité, et pourtant les sites chutent

Commençons par démonter le mythe le plus tenace du métier. La documentation officielle de Google sur les migrations est sans ambiguïté : « 301 and other permanent redirects don’t cause a loss in PageRank ». Gary Illyes l’avait déjà annoncé publiquement en 2016, la phrase figure aujourd’hui noir sur blanc dans la doc Search Central. L’idée d’une déperdition de 10 ou 15 % de « jus » à chaque redirection appartient au folklore.

Si les redirections ne coûtent rien, d’où vient la chute ? De trois endroits, presque toujours les mêmes.

La parité de contenu. Une refonte s’accompagne quasi systématiquement d’un allègement rédactionnel. Le nouveau template est plus aéré, le directeur artistique a raccourci les blocs de texte, et la page qui pesait 1 400 mots en fait désormais 500. La redirection fonctionne parfaitement. La position, elle, s’effondre.

Le cumul des changements. Nouveau domaine, nouvelle arborescence, nouveau CMS, nouveau design, le tout le même week-end. Google est explicite sur ce point dans la documentation du Change of Address : « If you combine a site move with a redesign of the site’s content and URL structure, you will probably see some traffic loss ».

L’exécution technique. Le noindex de préproduction oublié, les canonicals qui pointent encore vers l’ancien domaine, les chaînes de redirection à quatre sauts. Du classique, mais du classique qui coûte cher.

Une redirection préserve l’accès à une page. Elle ne préserve pas sa pertinence.

C’est la nuance que la plupart des checklists de migration passent sous silence, et c’est pourtant celle qui explique la majorité des accidents que nous constatons chez les clients qui arrivent après coup.

Hiérarchiser par valeur commerciale plutôt que par volume de trafic

Un site vitrine B2B, c’est rarement plus de 200 à 400 URLs. Sur ce volume, les process d’agence calibrés pour l’e-commerce sont surdimensionnés : le mapping manuel dans un tableur se boucle en une demi-journée, et il sera meilleur qu’un mapping automatisé par regex.

L’inventaire se construit à partir de trois sources, pas une seule :

Vient ensuite l’arbitrage qui change tout. La plupart des guides recommandent de classer les URLs par volume de trafic. En B2B, c’est une erreur de cadrage. La page qui fait 3 000 sessions par mois est souvent un article de blog informationnel, pendant que la page service à 80 visites mensuelles alimente le tiers de vos demandes de devis. Le trafic et la valeur ne se recouvrent pas.

Classez donc vos URLs selon ce qu’elles rapportent, pas selon ce qu’elles pèsent. Sur un site B2B, quinze à vingt pages concentrent l’essentiel des demandes entrantes : la page d’accueil, les pages service, quelques pages solution, une poignée d’articles qui ranquent sur des requêtes d’achat. Ce sont ces vingt URLs qu’il faut sécuriser au millimètre. Les 380 autres méritent une redirection correcte, pas une revue ligne à ligne.

Un mot sur les pages absentes de l’inventaire : celles que Google connaît mais n’a jamais indexées. Elles ne figurent ni dans vos rapports de trafic ni dans vos exports de positions, et comprendre pourquoi Google ignore certaines de vos pages avant de migrer évite de reconduire mécaniquement un problème existant dans la nouvelle arborescence.

Arbitrer chaque URL avant d’ouvrir le fichier de mapping

Le fichier de redirections est un livrable d’exécution. La décision, elle, se prend en amont, URL par URL, et se résume à quatre options.

  1. Conserver la page en l’état, avec une nouvelle URL. Redirection 301, parité de contenu à vérifier.
  2. Fusionner plusieurs anciennes pages en une seule. Google l’autorise explicitement : « if you have consolidated content previously hosted on multiple pages to a new single page, you can redirect the older URLs to that new, consolidated page ».
  3. Réécrire en profondeur. La redirection reste 301, mais attendez-vous à une période de réévaluation.
  4. Supprimer sans redirection, avec un code 410. Une refonte est aussi l’occasion légitime de se débarrasser de vingt vieilles actualités qui ne servent plus personne.

Cette dernière option fait peur et elle est pourtant saine. Rediriger une page morte vers une destination sans rapport ne transfère rien : Google prévient que le fait de rediriger de nombreuses anciennes URLs vers une destination non pertinente, typiquement la page d’accueil, « can confuse users and might be treated as a soft 404 error ». Traduction : la redirection est ignorée pour la canonicalisation. Vous avez fait le travail pour rien.

Trois règles techniques à faire respecter par votre prestataire, sans discussion possible.

Des redirections serveur, pas du JavaScript. Google recommande le 301 ou le 308 côté serveur. Depuis décembre 2025, Googlebot n’envoie pas au rendu les pages qui renvoient un statut différent de 200, ce qui condamne toute logique de redirection posée en JS. Les crawlers des IA génératives sont encore plus stricts : les mesures publiées par Vercel montrent que GPTBot et ClaudeBot n’exécutent tout simplement pas JavaScript.

Pas de chaînes. Google supporte jusqu’à dix sauts, mais sa recommandation est claire : viser une redirection directe, et si ce n’est pas possible, rester « ideally no more than 3 and fewer than 5 ». Une chaîne se forme vite quand on empile la migration HTTPS de 2018, le passage en www de 2021 et la refonte de 2026.

Un an minimum, et idéalement pour toujours. La documentation Google dit : « Keep the redirects for as long as possible, generally at least 1 year », et ajoute « From users’ perspective, consider keeping redirects indefinitely ». Attention à la confusion très répandue avec les 180 jours de l’outil Changement d’adresse : ces 180 jours correspondent à la durée de vie de la demande, pas à celle des redirections.

Une seule chose à la fois, et pas n’importe quand dans l’année

« Change only one thing at a time. » La consigne figure dans les bonnes pratiques générales de Google, en tête de sa documentation sur les migrations. Déplacer le domaine, puis changer le design. Pas les deux ensemble. Dans la vraie vie d’une PME, ce séquencement se heurte à un budget unique et à un planning agence, mais il vaut la peine d’être défendu : quand tout bouge en même temps, plus aucun diagnostic n’est possible en cas de chute.

Google recommande également de caler la bascule sur une période creuse. En B2B français, ces fenêtres sont connues : la première quinzaine d’août, la dernière semaine de décembre. Un piège d’interprétation les accompagne, cela dit. Le creux d’activité naturel se confond avec l’effet migration, et vous perdez votre point de comparaison. Prévoyez donc une baseline sur les douze mois précédents, pas sur les quatre semaines qui précèdent la bascule.

Autre point de calendrier : évitez de migrer pendant le déploiement d’une mise à jour majeure de l’algorithme. Le core update de mars 2026 s’est étalé du 27 mars au 8 avril, celui de mai du 21 mai au 2 juin. Douze jours de volatilité pendant lesquels vous serez incapable de distinguer ce qui relève de votre migration et ce qui relève de Google.

Sur l’outil Changement d’adresse de la Search Console, deux subtilités méritent votre attention. Il fonctionne uniquement au niveau domaine, jamais au niveau chemin, donc il est inutile pour une simple réorganisation d’URLs internes. Et surtout, il ne propage rien aux sous-domaines : la documentation a été mise à jour le 17 juin 2026 pour préciser qu’il faut soumettre une demande pour chaque variante vérifiée de l’ancien domaine, y compris www et non-www, y compris les variantes que vous n’utilisez pas. C’est l’oubli le plus fréquent, et il est invisible tant qu’on ne le cherche pas.

Si votre migration s’accompagne d’une réorganisation des rubriques, profitez-en pour repenser l’organisation de vos silos thématiques plutôt que de reconduire une arborescence héritée. Mais faites-le dans un second temps, une fois la migration stabilisée.

Le dommage que personne ne mesure : la continuité des conversions

Voici l’angle mort absolu du sujet. Toutes les checklists de migration parlent de trafic, de positions, de taux de couverture. Aucune ne parle de leads. Or c’est là que se joue le préjudice réel pour une PME.

Passez en revue, avant la bascule et le lendemain matin :

Un site peut conserver l’intégralité de son trafic organique et ne plus recevoir une seule demande de devis.

Ce scénario n’a rien de théorique. Il se produit chaque fois que le formulaire est reconstruit sur le nouveau CMS sans que personne ne teste l’adresse de réception. Le trafic est là, les courbes sont vertes, et le téléphone ne sonne plus.

Ce que votre migration change pour votre visibilité dans les IA

Bonne nouvelle d’abord : chez Google, il n’existe pas de circuit séparé pour les fonctionnalités génératives. La documentation est explicite, une page doit être « indexed and eligible to be shown in Google Search with a snippet » pour pouvoir être citée dans un AI Overview ou dans AI Mode. Autrement dit, une migration propre côté Search se propage mécaniquement aux surfaces IA de Google. Aucun travail supplémentaire.

Depuis le 31 août 2026, le rapport Generative AI de la Search Console est déployé mondialement, avec une dimension Pages définie comme « the final URL linked by a generative AI feature after any redirects ». Vous disposez donc, pour la première fois, d’un moyen de mesurer l’effet d’une migration sur votre visibilité dans les réponses IA. La métrique se limite aux impressions pour l’instant, mais elle suffit à repérer un décrochage.

Le sujet se complique côté modèles de langage. Les crawlers d’OpenAI, d’Anthropic et de Perplexity ne documentent nulle part leur gestion des redirections. On sait qu’ils suivent les redirections HTTP serveur, on ne sait pas ce qu’ils en font en matière de transfert de signaux. Et surtout, votre ancien nom de domaine restera présent dans les données d’entraînement des modèles déjà entraînés. Il n’existe aucun formulaire de changement d’adresse pour un modèle figé.

La conséquence pratique tient en une ligne : gardez l’ancien domaine, payez-le, laissez les redirections en place. Google recommande d’ailleurs de continuer à le renouveler au moins un an pour éviter qu’un tiers ne le récupère. Sur les enjeux de visibilité IA, la bonne durée est plutôt indéfinie.

Les trois documents à exiger avant d’autoriser la mise en ligne

Vous n’avez ni référenceur interne ni chef de projet digital. Vous pilotez une agence web dont le SEO n’est pas le métier principal. Dans cette configuration, une checklist de quarante-cinq points ne sert à rien. Trois livrables suffisent, à condition de les exiger avant la bascule et non après.

Le fichier de mapping complet. Une ligne par ancienne URL, la destination associée, le code de redirection retenu et la décision d’arbitrage. Aucune ligne vide. Aucune destination pointant vers la page d’accueil sans justification écrite.

Le rapport de recette de préproduction. Il doit attester nommément : absence de noindex résiduel, robots.txt de production validé, canonicals auto-référents sur les nouvelles URLs, liens internes mis à jour dans le corps des contenus, formulaires testés avec réception confirmée.

Le plan de suivi à trente jours. Qui regarde quoi, à quelle fréquence, et surtout qui a le pouvoir de déclencher un retour arrière. Les indicateurs à suivre sont, dans l’ordre : le nombre de demandes entrantes à J+30 comparé à J-30, les erreurs d’exploration dans la Search Console, la couverture d’indexation des vingt URLs prioritaires, puis seulement les positions.

Et une question à poser à votre prestataire, une seule, avant de signer : « qui est responsable si le trafic n’est pas revenu dans trois mois ? » La réponse vous en apprendra beaucoup sur le sérieux du dispositif.

Questions fréquentes

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

Google recommande de les conserver au minimum un an, et suggère même de les garder indéfiniment du point de vue des utilisateurs. Ne coupez jamais vos redirections tant que la Search Console montre du trafic sur les anciennes URLs.

L’outil Changement d’adresse de la Search Console est-il obligatoire ?

Il est utile pour un changement de nom de domaine, à condition que les redirections soient déjà en place. Il ne sert à rien pour un passage en HTTPS, pour une réorganisation d’URLs internes ou pour un changement d’hébergeur. Pensez à soumettre une demande pour chaque variante de domaine vérifiée.

Combien de temps avant de retrouver son niveau de trafic ?

Google annonce quelques semaines pour un site de taille moyenne. Les données observées sur le terrain sont nettement plus prudentes, avec des médianes qui dépassent souvent le trimestre sur les changements de domaine. Comptez large et évitez de migrer juste avant un pic commercial.

Peut-on refondre le design en même temps que l’on migre le domaine ?

Techniquement oui, stratégiquement non. Google recommande de ne changer qu’une chose à la fois et signale qu’une migration combinée à une refonte d’architecture entraînera probablement une perte de trafic. Si le budget impose de tout faire ensemble, sécurisez au minimum la parité de contenu sur vos vingt pages les plus rentables.

Faut-il conserver l’ancien nom de domaine après la migration ?

Oui, et pour longtemps. Il porte vos redirections, il protège votre marque contre un rachat malveillant, et il reste présent dans les données d’entraînement des modèles de langage bien après votre bascule.

Une migration se joue à 80 % avant la mise en ligne. Le mapping, la recette et le plan de suivi coûtent quelques jours de travail ; une migration mal préparée coûte plusieurs trimestres de génération de leads. Si une refonte se profile chez vous dans les mois qui viennent, faites auditer le plan de migration avant que le développeur ne touche au serveur.

Retour au blog