Vous avez fait le plus dur. Le site est prêt en préproduction, le développeur vous envoie un « c'est bon, on peut basculer », et vous appuyez sur Entrée un vendredi à 17h. Le lundi matin, vous ouvrez Search Console et vous voyez la courbe tomber. Pas une petite chute. Une falaise.
Je l'ai vécu avec un client qui vend du matériel de pêche. Migration vers une refonte complète, jolie, rapide, responsive. On a perdu 62 % du trafic organique en trois jours. La cause ? Un fichier robots.txt oublié en préproduction et copié tel quel en production, avec un Disallow: / bien tranquille dedans. La page d'accueil n'était plus indexée. Personne ne s'en était rendu compte parce que le site avait l'air parfait.
C'est ça, le piège de la migration : tout semble fonctionner visuellement alors que Google voit un site différent. Et les erreurs courantes lors de la migration d'un site web ne tiennent pas à la technique pure. Elles tiennent aux angles morts.
Points clés à retenir
- Un robots.txt ou une balise noindex oubliée en préproduction reste la première cause de catastrophe, et elle est invisible à l'œil nu.
- Une redirection en chaîne (A vers B vers C) dilue la valeur transmise ; une seule saut suffit, toutes les anciennes URLs doivent pointer directement vers la nouvelle.
- Le crawl complet avant/après est votre seule preuve objective : sans lui, vous naviguez à l'aveugle pendant des semaines.
- La propagation DNS se compte en heures, mais la réindexation complète prend souvent plusieurs semaines.
- Basculez un jour de semaine en début de matinée, jamais un vendredi, jamais en pleine campagne marketing.
Les erreurs courantes qui font le plus de dégâts lors d'une migration
Sur le papier, une migration c'est simple : on copie, on redirige, on indexe. Dans les faits, chaque étape réunit une dizaine de décisions qui peuvent mal tourner, et la plupart des ennuis viennent de décisions prises par défaut, pas par choix.
Je classe les erreurs en deux familles : celles qui cassent l'indexation (visibles tout de suite) et celles qui la dégradent lentement (détectées trois mois plus tard). Les secondes sont les plus dangereuses.
Erreur n°1 : le robots.txt et le noindex oubliés
C'est l'erreur bête, celle dont tout le monde parle, et celle que tout le monde refait. Un site en préproduction est bloqué aux robots, c'est normal. Le problème est que ce fichier est parfois déployé en production par le même pipeline.
Autre variante : l'équipe applique une balise meta noindex sur un modèle de page pendant les tests pour éviter le contenu dupliqué, puis oublie de la retirer. Le site est en ligne, il est rapide, il est beau, et il n'existe pas pour Google.
Ma règle : juste après la bascule, ouvrez le site en ligne et tapez l'URL dans une recherche Google avec le préfixe site:. Puis vérifiez le fichier robots.txt à la racine, à la main, sans passer par un outil. Ça prend trente secondes et ça sauve des semaines.
Erreur n°2 : les redirections approximatives
Deux erreurs ici. La première : rediriger tout le monde vers la page d'accueil. Une ancienne page sur les moulinets qui renvoie vers l'accueil, c'est une page morte pour Google. Une redirection 301 doit pointer vers la page la plus proche sémantiquement, sinon vous perdez la valeur et l'internaute tombe sur un contenu qui ne correspond pas à sa recherche.
La seconde : les chaînes. J'ai audité un site qui avait des redirections en trois sauts (ancienne URL vers intermédiaire vers intermédiaire vers page finale). Chaque saut affaiblit le signal. Corriger ça, sur environ 400 URLs, nous a pris deux jours, et le trafic des pages concernées a remonté de 18 % en un mois. Ça valait les deux jours.
Erreur n°3 : basculer sans surveiller le DNS
La propagation DNS, c'est le moment où deux versions du site coexistent sur Internet. Certains visiteurs voient l'ancien, d'autres le nouveau. Si votre plan de redirections n'est pas prêt à ce moment-là, vous avez une fenêtre où les moteurs explorent un site hybride, moitié ancienne arborescence, moitié nouvelle.
Réduisez le TTL de vos enregistrements DNS à 300 secondes au moins 48 heures avant la bascule. Ensuite, vous ne subissez pas les heures de propagation imposées par des enregistrements configurés à 24 heures.
Erreur n°4 : le plan de site laissé à l'abandon
Un sitemap XML qui contient encore les anciennes URLs après migration, c'est une invitation envoyée à Google pour explorer des 404. Générez-en un nouveau à la date de bascule, soumettez-le, et retirez l'ancien. Évidence ? Oui. Fait systématiquement ? Non.
Quels sont les risques liés à la migration ?
Le risque principal est la perte de trafic organique durable, et elle ne se récupère pas toujours. J'ai vu un site perdre 40 % de ses visites et ne jamais retrouver son niveau de départ, même après un an, parce que les redirections n'ont pas été corrigées assez vite. Google a désappris le site.
Les autres risques, dans l'ordre de fréquence réelle :
- La perte de positions sur les pages à fort trafic quand leur équivalent n'existe pas dans la nouvelle arborescence
- La casse de liens internes, qui transforme votre maillage en gruyère sans que personne ne s'en aperçoive avant plusieurs semaines
- L'arrêt de service pendant la bascule, qui affecte aussi les conversions directes et le support client
- La perte de balisage structuré (données produits, avis), qui fait disparaître vos rich snippets dans les résultats de recherche
Un point important : la migration ne fait pas que déplacer l'ancien. Elle peut aussi corriger. Sur un site que j'ai accompagné, les pages produits étaient mal balisées depuis des années. La migration a été l'occasion de repartir proprement, et les résultats enrichis sont apparus dans les trois semaines suivantes.
Comment puis-je résoudre le problème de redirection d'une page web ?
D'abord, identifiez la nature du problème. Trois cas, trois solutions.
La redirection en boucle. La page A redirige vers B, qui redirige vers A. Le navigateur affiche une erreur. La cause est presque toujours une règle de redirection écrite dans deux fichiers de configuration différents (par exemple .htaccess et configuration serveur), qui se contredisent. Cherchez la règle en double, supprimez-en une.
La chaîne de redirections. A vers B, B vers C. Fonctionnellement ça marche, mais vous perdez de la valeur à chaque saut. La solution est de réécrire la règle pour que toutes les anciennes URLs pointent directement vers la cible finale. Outil indispensable : un crawler qui liste les chaînes, puis une correction manuelle des règles concernées.
La redirection retournée. L'ancienne URL redirige vers la nouvelle, puis quelqu'un inverse les deux par erreur. Résultat : toutes les pages stratégiques renvoient vers des URLs obsolètes. Vérifiez systématiquement le sens de vos règles 301 juste après la bascule, page par page, sur les dix pages qui génèrent le plus de trafic.
Un contrôle simple : avec l'outil de développement de votre navigateur, l'onglet Réseau, ouvrez chaque ancienne URL. Vous voyez immédiatement le code de statut, la cible, et le nombre de sauts.
Qu'est-ce que la migration d'un site web ?
Une migration, c'est tout changement qui déplace le site d'un environnement à un autre, ou qui modifie en profondeur son adresse, son architecture ou sa plateforme technique. Changer de CMS, passer en HTTPS, modifier l'URL racine, réorganiser les catégories : ce sont toutes des migrations, avec les mêmes risques.
Je distingue deux types, et cette distinction change tout dans la préparation :
| Type de migration | Ce qui change | Risque principal |
|---|---|---|
| Technique pure | Serveur, hébergement, CMS, protocole | Liens cassés et temps d'arrêt |
| Avec refonte | Arborescence, design, contenus | Pages supprimées sans équivalent, perte de positions |
Une migration technique pure se prépare en général sur une fenêtre de quelques jours, avec un plan de redirections mécanique. Une refonte avec refonte d'arborescence demande un travail de cartographie page par page, souvent plusieurs semaines avant la bascule.
Quelles sont les étapes d'une migration informatique ?
Voici l'enchaînement que j'applique, et que je recommande. Il n'est pas théorique : chaque étape correspond à un problème que j'ai vu se produire une fois.
- Inventaire des URLs existantes. Un crawl complet du site avant toute chose. Exportez toutes les URLs, leur statut, leur trafic. Sans cette liste, vous ne saurez jamais ce que vous avez perdu.
- Cartographie des redirections. Une ligne par ancienne URL, une colonne pour sa nouvelle destination. Les pages sans équivalent méritent une décision explicite : redirection vers la catégorie parente, ou redirection vers l'accueil avec remplacement de contenu prévu.
- Préparation de l'environnement de recette. Le site doit être testable sans être indexé. Utilisez un environnement protégé par mot de passe ou par domaine distinct, jamais une balise noindex sur la production.
- Tests de recette. Vérifiez les redirections 301, les liens internes, les formulaires, le balisage structuré, les balises canoniques, la vitesse de chargement.
- Bascule. Un matin de semaine, avec l'équipe disponible dans les heures qui suivent. Un plan de retour arrière écrit, avec la procédure exacte pour revenir à l'ancienne version.
- Surveillance post-bascule. Crawl de contrôle le jour même, puis quotidiennement pendant deux semaines. Suivi de la couverture d'indexation et du trafic organique.
Le point qu'on oublie le plus souvent : le plan de retour arrière. Sur une bascule que j'ai supervisée, le DNS n'avait pas été correctement propagé vers la nouvelle infrastructure. Le site principal était inaccessible depuis certaines régions. On a pu revenir à l'ancien environnement en quatre-vingt-dix minutes, uniquement parce que le plan de retour existait par écrit. Sans lui, on aurait improvisé pendant une demi-journée.
La surveillance qui fait la différence
Trois semaines après la migration, on croit que c'est fini. C'est là que les problèmes de maillage interne apparaissent, quand Google explore en profondeur et découvre les liens morts que le crawl initial n'avait pas vus.
Ce que je surveille personnellement pendant les deux mois qui suivent :
- Le nombre de pages indexées, semaine par semaine. Une chute progressive signale un problème de qualité perçue.
- Le nombre de pages en erreur 404 dans la console de recherche.
- Le trafic organique sur les dix pages historiquement les plus fortes. Ces pages sont votre thermomètre.
Et une chose que j'ai apprise à la dure : ne comparez pas le trafic au jour près juste après une migration. Le décalage d'indexation crée des variations qui ne veulent rien dire. Comparez semaine contre semaine, sur une période glissante.
Une migration réussie, au fond, ce n'est pas une migration dont on ne parle pas. C'est une migration dont on connaît chaque risque avant de la lancer. Le jour où vous saurez, avant de basculer, quelle page vous allez perdre et pourquoi elle n'a pas d'équivalent, vous aurez gagné l'essentiel.
Et si vous hésitez encore sur la nécessité de migrer : demandez-vous si le problème que vous voulez résoudre ne peut pas l'être sans toucher à l'arborescence. Parfois, le vrai gain est de ne pas migrer.
