Une migration de site se joue rarement sur la page d’accueil. Elle se joue sur les vieilles URL que personne n’a testées, celles qui traînent dans un coin du serveur ou qui pointent vers une adresse oubliée. Basculer sans avoir vérifié chaque redirection une par une, c’est parier sur la chance. Et sur un site un peu ancien, la chance ne suffit pas. Cet article propose une méthode de contrôle manuel, celle qu’on peut faire avant la mise en ligne, pour éviter de découvrir les dégâts une fois le trafic perdu.
La 301, ce code qui dit à Google de déplacer ses billes
Une redirection 301 signifie « déplacé définitivement ». Concrètement, le serveur répond à la requête en indiquant l’adresse de la nouvelle page, et le navigateur comme le robot y vont sans discuter. On l’utilise pour un changement d’URL, un passage en HTTPS ou une migration de domaine. Sur rick-hunter.com, le sujet revient souvent, parce que c’est la base de tout déplacement de site propre.
Le code de statut, lui, n’est pas un détail cosmétique. Il classe la nature du déplacement dans l’esprit du moteur : définitif ou temporaire. Une 301 transmet ce qu’elle peut de l’historique de l’ancienne page vers la nouvelle. Une 302, elle, annonce un mouvement provisoire, et Google garde alors l’adresse d’origine dans ses résultats. Comprendre cette différence avant de toucher au serveur évite bien des corrections après coup.
Ce qui casse sans bruit quand on empile les redirections
Googlebot suit au maximum dix sauts dans une chaîne de redirections. Au-delà, la page n’est pas explorée. Dix sauts paraissent énormes, jusqu’au jour où l’on découvre qu’une URL ancienne redirige vers une autre URL qui redirige vers une troisième, elle-même gérée par un module du serveur. Ces empilements apparaissent avec les années, à force de changer des adresses sans jamais nettoyer les anciennes règles.
Le cas le plus vicieux reste la 302 posée en fin de chaîne. Le visiteur arrive bien sur la bonne page, alors le problème passe inaperçu. Le robot, lui, lit le dernier code et conclut à un déplacement provisoire, ce qui annule le bénéfice de la 301 placée plus haut. Une chaîne peut donc avoir l’air correcte en navigation et perdre tout son intérêt côté moteur, sans que rien ne le signale dans un navigateur.
La 308 répond à un problème plus étroit mais bien réel. Elle garde la méthode HTTP : un formulaire envoyé en POST reste en POST après redirection. Si votre site accepte des envois de données via un formulaire ancien, ce code évite de casser les traitements serveur au moment du changement d’adresse. La vérifier mérite quelques minutes, surtout sur les pages de contact ou de commande.
Le test des quatre variantes, à faire avant la bascule
Prenez votre domaine. Écrivez dans la barre d’adresse les quatre versions possibles : http sans les www, http avec les www, https sans les www, https avec les www. Chacune doit arriver sur la même URL finale, en un seul saut. Si deux variantes passent par des chemins différents, ou si l’une répond encore en clair, le travail n’est pas fini. Chaque saut supplémentaire rapproche de la limite des dix et brouille le signal envoyé au robot.
Comment repérer une chaîne à rallonge
Un outil comme la courbe réseau du navigateur affiche les codes de réponse. Ouvrez l’onglet réseau, cochez la case pour tout afficher, et rechargez. Vous voyez chaque étape de la redirection. Le but est de n’en avoir qu’une. Une fois la bascule faite, ces règles doivent rester actives au minimum un an, le temps que le robot repasse et consolide l’adresse finale. Sur ce point, voir aussi notre article sur creer un site web.
- Ouvrez la page en navigation privée, sinon le cache vous ment.
- Vérifiez le nombre de réponses avant d’atteindre la page final,e et notez-le.
- Combien de sauts voyez-vous sur cette adresse ancienne ?
- Un lien dans un vieil article de blog mène vers une page morte, c’est le cas classique.
- Testez ensuite la même adresse en https pour voir si le chemin raccourcit ou s’allonge.
Un site redirigé vers un autre site pose une question différente. Si vous déplacez l’ensemble du domaine vers une nouvelle marque, chaque ancienne URL doit pointer vers la page équivalente de la nouvelle adresse, pas vers la page d’accueil.
Tout envoyer à la racine donne un signal de page vide au robot et dilue l’historique. Franchement, ce point se règle au cas par cas, page par page, ce qui prend du temps mais évite de tout perdre d’un coup.
Les pièges qui restent invisibles dans un navigateur
Une redirection peut fonctionner pour un humain et échouer pour le robot. Les règles conditionnées à l’agent, les scripts côté client, les chaînes qui dépendent d’un cookie : tout cela passe en navigation et disparaît en exploration. Le contrôle utile se fait donc dans un contexte froid, sans cache, sans session, avec un en-tête qui imite celui de Googlebot. Sans cette précaution, on valide une expérience que le moteur ne verra jamais.
La vérification une par une est fastidieuse, mais elle a un mérite : elle oblige à regarder chaque URL et à se demander où elle devrait arriver. La plupart des erreurs se voient à ce moment-là, pas dans les semaines qui suivent. C’est aussi l’occasion de retirer les redirections devenues inutiles, celles qui pointent vers des adresses qui n’existent plus et qui rallongent une chaîne déjà chargée.
Le vrai contrôle, c’est la liste complète, pas l’échantillon
Sur un site de quelques centaines de pages, tester chaque URL prend une après-midi, peut-être une journée. Ce temps se récupère largement sur la perte de trafic évitée après la bascule, quand on n’a pas à courir après des redirections qui n’ont jamais été corrigées.
La méthode ne promet pas la perfection, elle garantit seulement qu’on a regardé ce qu’on allait casser. Le fichier de suivi et les codes de réponse se gardent jusqu’à ce que l’année soit passée. Combien de vieilles adresses de votre site n’ont jamais été ouvertes depuis trois ans ?
