Une URL indexée qui tombe sur une page blanche après une migration de CMS, c’est le genre de découverte qui gâche une matinée. Le site répond, le code HTTP affiche 200, et pourtant le visiteur voit un gabarit vide. La plupart des responsables techniques cherchent alors la panne du côté du serveur ou du module de redirection. Le plus souvent, le problème est ailleurs : le plan d’URL a été pensé à moitié, et la redirection sert de pansement sur une page qui n’a jamais été migrée.
Une page vide, un statut correct, et un problème invisible
Le statut 200 est un piège confortable. Il dit au robot que tout va bien, que la page existe, qu’elle a du contenu à indexer. Sauf qu’à l’arrivée, le gabarit du nouveau CMS s’affiche sans le corps de texte, parce que le contenu attendu n’a jamais été importé ou que l’identifiant de la page ne correspond plus à rien dans la nouvelle base.
Comprendre ce décalage demande de sortir du seul prisme technique. Un audit de bertseo.fr sur les migrations ratées montre souvent la même séquence : l’ancienne URL redirige correctement, la nouvelle URL répond, mais le contenu rattaché est vide ou générique. Ce n’est pas la redirection qui casse, c’est la destination. On a traité le renvoi d’URL comme une formalité de routage alors qu’il s’agit d’un transfert de matière éditoriale d’une page vers une autre.
Croiser les sources d’URL avant de toucher au code
La liste des URLs à surveiller ne se limite jamais au sitemap. Un plan de redirection honnête part de plusieurs gisements, parce que chacun révèle des pages que les autres ignorent. Le sitemap donne l’intention, le crawl donne la réalité des liens internes, Analytics donne le trafic réel, Search Console donne les impressions et les clics, les backlinks donnent les pages qui comptent vraiment pour Google, et les campagnes marketing rappellent les anciennes URL diffusées en publicité ou sur des supports imprimés.
Le croisement se fait ligne par ligne, avec une correspondance explicite entre l’ancienne adresse et la nouvelle. L’auteur de We Growth le raconte sans détour : il est intervenu sur quatre sites après migration dont le trafic avait décroché jusqu’à moins 70 %, dans des cas où une agence web et SEO avait piloté le projet.
Dans le même texte, il indique avoir redirigé un site de 6 000 pages sans constater de pertes durables de positionnement ou de trafic, hormis les quatre semaines qui ont suivi la bascule. La différence entre les deux situations ne tenait pas à la qualité du serveur, mais à la rigueur du plan.
Les erreurs qui vident une redirection de son sens
Une redirection peut être techniquement parfaite et transférer zéro autorité. C’est le cas quand la chaîne passe par trois ou quatre sauts avant d’atteindre la page finale, ou quand tout atterrit sur la page d’accueil. Ivan Cappelli cite justement ces deux travers, les boucles de redirection et la redirection massive vers la home, parmi les erreurs à éviter dans un plan de migration.
Ce qui trahit un plan d’URL incomplet
Le symptôme revient souvent dans les rapports post-migration, et il ne se lit pas dans les logs du serveur. Il se lit dans la correspondance entre anciennes et nouvelles pages.
- Une landing page qui n’a jamais été recréée dans le nouveau CMS, et dont l’ancienne URL pointe vers une catégorie vide.
- Les images oubliées pendant l’import, qui laissent des balises cassées dans le corps de page.
- Pourquoi le robots.txt et les canonicals n’ont-ils pas été mis à jour en même temps que les URL ?
- Un hreflang resté sur les anciennes adresses, qui envoie les versions linguistiques vers du vide.
- Une redirection en 302 posée « le temps de vérifier », puis oubliée pendant des mois.
Le point commun de ces cas : la page de destination existe au sens technique, mais elle ne contient pas la page d’origine. Le robot suit le lien, charge un gabarit sans substance, et repart sans rien transférer. Sur ce point, voir aussi notre article sur site marque referencement.
Vérifier le transfert d’autorité, pas seulement le code de statut
Un plan de redirection correct transfère une grande partie de l’autorité vers les nouvelles pages, et c’est bien le PageRank qui change de main quand la correspondance est juste. La vérification ne peut donc pas se limiter à un « 301 OK » dans un outil de crawl. Il faut comparer, page par page, ce que l’ancienne adresse portait comme liens entrants et ce que la nouvelle adresse reçoit réellement.
La méthode tient en une passe de contrôle après la migration. On reprend la liste croisée, on vérifie que chaque ancienne URL arrive en un seul saut sur une page au contenu équivalent, et on regarde dans Search Console si la nouvelle adresse reprend les impressions de l’ancienne.
Si une page vide apparaît en destination, c’est le signe que le contenu n’a pas été migré, pas que la redirection est mal configurée. La question posée par beaucoup de lecteurs, comment résoudre un problème de redirection d’une page web, trouve ici sa vraie réponse : on répare la destination avant de retoucher la règle.
Il reste la question du site entier redirigé vers une autre adresse. Quand quelqu’un demande comment éviter les redirections vers un autre site, la réponse tient à la traçabilité : chaque règle de redirection doit être documentée avec son motif, sa date et son propriétaire, sinon une règle héritée d’un ancien projet peut survivre à la migration et envoyer du trafic ailleurs sans que personne ne s’en aperçoive. Un fichier de suivi des redirections, relu à chaque déploiement, évite ce genre de surprise.
Le plan compte plus que la règle technique
Une redirection n’est jamais qu’un panneau indicateur. Si la route mène à une maison vide, le panneau n’y change rien. La migration réussie est celle où l’on a listé les pages avant de basculer, croisé les sources, écrit la correspondance une par une, puis contrôlé le contenu à l’arrivée, pas seulement le statut HTTP. Le reste, les chaînes, les boucles, la home par défaut, ce sont des symptômes d’un travail fait à l’envers.
Reste une question à se poser avant chaque migration : combien d’URL de votre site actuel sont capables de citer leur page de destination, sans consulter un tableur ?
