Un client m'appelle un mardi matin, la voix blanche. Son site marchand affiche une page blanche depuis la veille au soir. Sa boutique en ligne faisait 40 % de son chiffre. Il venait de changer d'hébergeur "pour gagner en vitesse". Deux jours plus tard, il avait perdu la moitié de son trafic organique, et il ne comprenait pas pourquoi la redirection de ses anciennes fiches produit aboutissait sur une page d'erreur.
Voilà ce que personne ne dit assez fort : la plupart des erreurs fatales lors de la migration de votre site web ne se voient pas le jour J. Elles se voient trois semaines plus tard, dans les statistiques, quand Google a fini de recrawler et de décider que votre site ne ressemble plus à celui qu'il connaissait.
Je ne vais pas vous faire une checklist de plus. Je vais vous raconter ce que j'ai vu casser, ce que j'ai cassé moi-même, et ce qui se récupère — ou pas.
Points clés à retenir
- Une redirection mal configurée peut mettre plusieurs semaines à se faire absorber par le moteur, et certaines ne se récupèrent jamais.
- Le vrai danger n'est pas la mise en ligne : c'est l'absence de plan de retour arrière et de sauvegarde testée.
- Les erreurs irréversibles sont peu nombreuses mais brutales : désindexation massive, backlinks perdus, domaine expiré par mégarde.
- Un site en test accessible publiquement peut être indexé — et créer des milliers de doublons.
- Le trafic se récupère souvent, le référencement des pages supprimées sans équivalent, beaucoup moins.
Les erreurs fatales lors de la migration de votre site web : celles qui ne se réparent pas
D'abord, une question qu'on me pose souvent et qui mérite une réponse claire : qu'est-ce que la migration de site web ? C'est tout changement qui déplace vos pages d'un endroit à un autre — nouveau nom de domaine, nouveau serveur, refonte technique, passage en HTTPS, changement de CMS. Le contenu peut rester identique, l'adresse change. Et c'est précisément là que tout se joue.
Une opération à trois niveaux
Une migration touche toujours trois couches en même temps : les URL (ce que le moteur connaît), le contenu (ce que le visiteur lit) et la technique (ce que le serveur répond). Si une seule des trois se désynchronise, vous avez un problème. Si deux se désynchronisent, vous avez une catastrophe.
Franchement, la plupart des gens traitent ça comme un déménagement : on prend les cartons, on change d'adresse, on prévient la poste. Sauf qu'ici, la poste ne prévient personne. Elle oublie.
Fatale, réversible, ou juste gênante
Toutes les erreurs ne se valent pas, et c'est la distinction que je n'ai jamais vue correctement traitée ailleurs. Il faut séparer trois familles :
- Les réversibles — un sitemap oublié, un robots.txt trop strict, un tracking cassé. On corrige, on attend, ça revient.
- Les coûteuses — des chaînes de redirection sur 300 URL. Récupérables, mais il faut des semaines de patience et parfois une reprise manuelle.
- Les fatales : pages supprimées sans équivalent, backlinks pointant vers des 404 définitifs, domaine laissé expirer. Là, on ne récupère pas le signal perdu. On repart de zéro sur ces pages.
C'est la troisième catégorie qui tue. Et elle représente, dans mon expérience, une minorité des cas mais la quasi-totalité des dégâts durables.
Le problème de redirection : là où presque tout le monde se plante
Une page ancienne qui pointe vers une page morte, c'est une porte qu'on ferme à la volée devant un visiteur. Il repart. Parfois il ne revient pas.
Comment puis-je résoudre le problème de redirection d'une page web ?
Il faut d'abord identifier la nature exacte du problème, parce que les causes n'ont rien à voir. Une redirection 301 (permanente) transmet le signal de l'ancienne page à la nouvelle ; une 302 (temporaire) ne le fait pas. Une chaîne A → B → C dilue ce signal à chaque saut. Une boucle A → B → A fait échouer le navigateur, qui affiche une erreur.
La méthode qui fonctionne :
- Lister toutes les anciennes URL depuis les données de trafic et une sauvegarde du sitemap précédent.
- Pour chacune, décider d'une destination unique et directe — jamais une redirection vers une autre redirection.
- Vérifier le code de statut retourné pour chaque URL, une par une, pas en échantillon.
- Traquer les 404 résiduelles après la bascule, sur plusieurs semaines, pas seulement le lendemain.
Sur un site de 800 pages que j'ai suivi, la première passe de vérification avait laissé passer 27 redirections en boucle. Elles ne concernaient que des pages secondaires, mais elles représentaient une part non négligeable des anciennes visites. Trouvées au bout de dix jours, corrigées le jour même : le trafic sur ces pages est revenu en trois semaines environ. Pas le lendemain, trois semaines.
Pourquoi la redirection ne fonctionne pas ?
Les causes que je rencontre, dans l'ordre de fréquence :
| Cause | Symptôme observable | Gravité |
|---|---|---|
| Code de statut incorrect (302 au lieu de 301) | La page s'affiche, mais le signal n'est pas transmis | Moyenne, corrigeable |
| Chaîne de redirections | Délai de chargement, signal dilué | Moyenne |
| Règle serveur mal ordonnée | Boucle infinie, navigateur bloqué | Élevée |
| Destination supprimée après coup | 404 en bout de chaîne | Élevée |
| Redirection oubliée sur une partie des pages | 404 sèche, aucune transmission | Élevée si massive |
Le piège classique du mauvais ordre des règles serveur m'a coûté une nuit blanche. Une règle générique placée avant une règle spécifique : toutes les requêtes partaient dans la mauvaise direction. Une seule ligne déplacée, et tout fonctionnait. Le genre d'erreur qu'on ne voit pas en relisant, seulement en testant.
L'erreur « ce site est inaccessible » après migration
Vous basculez le DNS, vous rechargez, et là : page blanche, message d'erreur, rien. Ça arrive à tout le monde. Ce qui distingue une migration propre d'un désastre, c'est ce qui se passe dans les minutes qui suivent.
Comment corriger l'erreur « ce site est inaccessible » ?
Cette erreur signifie le plus souvent que la propagation DNS n'est pas terminée ou que le serveur de destination ne répond pas encore. Trois vérifications dans l'ordre :
- Le domaine pointe-t-il bien vers la nouvelle adresse serveur ? Les changements de DNS prennent du temps, de quelques minutes à plusieurs heures selon le réglage de durée de vie.
- Le certificat de sécurité est-il valide sur le nouveau serveur ? Un certificat expiré ou mal installé bloque l'affichage.
- La configuration du serveur autorise-t-elle bien le nom de domaine ? Un serveur qui ne reconnaît pas le domaine répond par une erreur générique.
Et voici l'erreur fatale cachée derrière cette panne : pendant que le site est inaccessible, si vous avez laissé le mode "maintenance" actif trop longtemps, ou pire, si vous avez laissé le site en test accessible et indexable, le moteur crawle des pages qui ne devraient pas exister. J'ai vu un site de test générer plus de 4 000 URL en doublon en une semaine. Nettoyage : deux mois.
Un conseil que je donnerai sans hésiter : protégez l'environnement de test par mot de passe. Toujours. Ce que vous croyez invisible ne l'est pas.
Le plan de retour arrière : la seule erreur vraiment impardonnable
Si je devais n'en garder qu'une : ne jamais migrer sans pouvoir revenir en arrière en quelques minutes. C'est la différence entre un incident et un désastre.
Sauvegarde testée et critères de décision chiffrés
Avant toute bascule, il faut trois choses : une sauvegarde complète et testée en restauration (une sauvegarde non restaurée n'est pas une sauvegarde), un accès au DNS modifiable rapidement, et des critères Go/No-Go écrits à l'avance. Par exemple : si plus de X % des URL critiques renvoient une erreur à la première heure, on revient en arrière sans discussion.
Le problème, c'est que dans la précipitation, personne ne définit ces critères. On avance, on espère, on découvre. Et quand on enclenche le retour arrière trop tard, on a déjà laissé le moteur crawler un site cassé.
Ce qui n'est pas une erreur fatale (pour relativiser)
Un sitemap oublié ? Gênant, pas grave. Un tracking cassé pendant deux jours ? Vous perdez de la donnée, pas du trafic. Une page de contact qui redirige mal ? Agaçant pour l'utilisateur, sans impact lourd.
Le vrai test, c'est de se demander : est-ce que je peux revenir à l'état d'avant ? Si la réponse est non, vous êtes dans la zone dangereuse.
Ce que j'ai fini par retenir
La migration parfaite n'existe pas. La migration réversible, si.
Ce qui m'a le plus marqué, après toutes ces années à réparer des sites cassés, c'est à quel point le facteur décisif n'est presque jamais technique. C'est le rythme. On presse, on coupe les étapes, on migre un vendredi soir pour "profiter du week-end". Le week-end, le moteur travaille, lui.
Si vous ne devez retenir qu'une chose de ces erreurs fatales lors de la migration de votre site web : prévoyez un moment où vous pourrez tout annuler. Un point de non-retour mal placé transforme une opération de routine en reconstruction de plusieurs mois.
Et si vous êtes en train de vous dire "chez moi, ça se passera bien, j'ai fait attention" — c'est exactement ce que m'a dit mon client au téléphone, ce mardi matin. Trois semaines avant de m'appeler.
