Un déménagement de blog se passe bien, les pages s’affichent, les visiteurs arrivent. Et pourtant, quelque chose cloche depuis des mois sans que personne ne le voie. Les vieilles adresses, celles qui ont fait la réputation du site, continuent de répondre avec un code 200 bien tranquille. Google les indexe encore et leur fait confiance, mais elles ne mènent plus nulle part. C’est le genre de panne silencieuse qui coûte cher, et elle se règle souvent en une ligne.

le code 200 qui masque une adresse abandonnée

Quand vous tapez une ancienne URL d’article et que la page s’affiche sans erreur, vous vous dites que tout va bien. Sauf que ce que vous voyez n’est pas forcément ce que voit le robot d’indexation. Sur beaucoup de migrations, l’ancienne adresse renvoie un 200 vers une page générique : accueil, catégorie, contenu vide hérité de l’ancien CMS. Le robot note alors que cette URL existe toujours et qu’elle a du contenu.

Le problème, c’est que ce contenu n’a plus rien à voir avec ce que la page promettait. Google doit arbitrer entre deux versions d’un même sujet, et il choisit souvent la mauvaise. Pour comprendre finement comment les moteurs interprètent ces signaux, mohedaltrad2020.fr détaille les mécanismes d’indexation et les erreurs d’URL qui plombent un site. Une redirection mal posée ou absente produit exactement ce genre de dégât, sans jamais afficher d’alerte dans la Search Console.

Ce que la plupart des gens ignorent, c’est que le code de réponse lui-même porte l’information. Un 200 dit « cette adresse est valide, garde-la ». Un 404 dit « cette adresse n’existe plus, oublie-la ». Et entre les deux, il y a le 301, qui dit « cette adresse a déménagé définitivement, suis-moi vers la nouvelle ». Trois messages radicalement différents envoyés au même robot, et le vôtre en envoie probablement le premier par accident.

le 301 transmet presque tout, le silence ne transmet rien

Une redirection 301 est un code de réponse HTTP permanent qui indique à un navigateur et à Google qu’une URL a définitivement été déplacée vers une nouvelle adresse. Le mot important, c’est « définitivement ». Le robot comprend qu’il doit transférer tout l’historique de l’ancienne page vers la nouvelle, et ne plus revenir sur l’ancienne.

Selon la page Next Generation, le 301 transmet 99 % du PageRank de l’ancienne URL vers la nouvelle, contre 0 % pour un 404. Reprenez ce chiffre et regardez votre situation. Si vos anciennes URL répondent 200, elles ne transmettent pas 99 % de leur autorité à vos nouvelles pages : elles gardent cette autorité pour elles, sur des pages qui n’ont plus de raison d’exister. Le lien entrant d’un partenaire, la citation d’un confrère, le partage sur un forum, tout cela pointe encore vers l’adresse morte. Et l’adresse morte ne rend rien à personne.

Le 302 existe aussi, et il faut le distinguer. C’est une redirection temporaire, utilisée pour un A/B test ou une maintenance, et Google garde l’ancienne URL dans son index en se disant qu’elle reviendra. Le 308 est une redirection permanente (HTTP 1.1) qui préserve la méthode HTTP, utile quand des formulaires ou des appels API passent par l’adresse. Pour un blog migré, c’est le 301 qu’il vous faut, dans la grande majorité des cas.

déclarer la redirection selon votre hébergeur

La bonne nouvelle, c’est que la correction ne demande pas de toucher au code de l’application ni de réécrire les articles. Elle se déclare au niveau de l’hébergement, là où la requête arrive avant même d’atteindre votre CMS. Deux plateformes courantes ont chacune leur syntaxe, et une fois qu’on l’a vue, elle ne s’oublie plus.

les cas de figure que vous allez rencontrer

Avant d’écrire la moindre règle, il faut lister les anciennes adresses et leur associer la bonne destination. C’est l’étape que tout le monde saute, et c’est celle qui fait échouer la moitié des corrections. Sans cet inventaire, vous posez des règles au hasard et vous laissez passer les pages qui comptaient vraiment, celles qui portaient encore une part réelle de votre autorité. Sur ce point, voir aussi notre article sur article plafonne deux ans.

• Une URL d’article qui correspond à un article existant sous un nouveau chemin : redirection directe vers la nouvelle adresse.
• Les pages de catégorie supprimées lors de la refonte, souvent oubliées parce qu’elles ne génèrent aucun trafic visible.
• Que faire d’une vieille URL dont l’article n’a pas été repris sur le nouveau blog ?
• Les adresses avec paramètres de suivi ou de pagination, qui répondent encore 200 et créent des dizaines de doublons.
• Un ancien flux RSS ou un sitemap obsolète, encore accessible et encore crawlé.

Sur Vercel, une redirection permanente se déclare dans vercel.json avec la propriété « permanent: true ». Vous décrivez la source, la destination, et vous laissez cet indicateur faire le travail. Sur Netlify, une redirection 301 s’écrit dans le fichier _redirects sous la forme « /ancien-chemin /nouveau-chemin 301 ». Une ligne par adresse, un espace entre chaque champ, et le fichier est lu avant tout le reste.

Franchement, la partie la plus longue n’est pas technique. C’est de retrouver la liste des anciennes URL, de vérifier leur code de réponse actuel une par une, puis de décider vers quoi chacune doit pointer. Un ancien article fusionné part vers l’article fusionné. Une catégorie disparue part vers la catégorie la plus proche. Une page sans équivalent part vers un 404 assumé, jamais vers une page d’accueil trompeuse.

ce qui se joue vraiment dans les mois qui suivent

Poser les redirections ne produit pas d’effet le lendemain. Le robot doit revenir, constater le 301, suivre la chaîne et recalculer la valeur des pages d’arrivée. Comptez plusieurs semaines avant de voir les positions bouger, et parfois plus si le site a accumulé beaucoup d’adresses fantômes. La patience fait partie du travail, et c’est souvent là que les équipes abandonnent en concluant que « ça ne marche pas ».

Il y a un piège à éviter absolument : les chaînes de redirections. Une ancienne URL rouge vers une URL intermédiaire, qui elle-même redirige vers la destination finale, fait perdre de la valeur à chaque saut. Visez toujours la destination directe, en une seule étape. Vérifiez aussi qu’aucune redirection ne pointe vers une adresse qui renvoie un 404, ce qui arrive vite quand on déplace des pages après avoir posé les règles.

Un dernier point qui fâche : les liens externes. Vous ne contrôlez pas ce que les autres sites écrivent, et certains pointent vers une adresse que vous avez abandonnée. Sans redirection, ce lien entrant nourrit une page morte. Avec un 301, il nourrit votre nouvelle page. C’est la même ressource vue de deux façons, et la différence se chiffre en autorité accumulée pendant des années.

une ligne, et le passé recommence à travailler

Une migration réussie ne se mesure pas au fait que le site s’affiche, mais à ce que les anciennes adresses racontent au robot. Tant qu’elles répondent 200, elles retiennent leur autorité au lieu de la transmettre, et le travail éditorial des années précédentes reste bloqué sur des pages que plus personne ne met à jour.

La correction tient dans un fichier de configuration, souvent moins de dix lignes au total, et elle se vérifie en une soirée avec un simple outil de contrôle des codes HTTP. Votre blog a survécu à la migration ; la question est de savoir s’il en profite, ou s’il traîne encore son ancienne adresse comme un bagage inutile.