Redirection 302

Une redirection est une réponse du serveur qui dit au navigateur, et au robot, que la ressource demandée se trouve ailleurs. D'un code à l'autre, seule change l'intention déclarée, selon que le déplacement est définitif ou non. Google en tire des conséquences opposées.

Ce que Google fait de chaque code

La différence entre les codes courts et les codes stricts porte sur le comportement des requêtes qui envoient des données, comme la soumission d'un formulaire. Pour des pages consultées normalement, l'effet en référencement est identique, et le choix relève de la préférence technique de l'équipe.

Google a indiqué qu'une redirection temporaire maintenue longtemps finit par être traitée comme définitive. Ce rattrapage arrive sans qu'on sache quand, et il ne dispense de rien. Pendant tout le temps où il n'a pas eu lieu, c'est l'ancienne adresse qui reste affichée dans les résultats.

Les trois cas où la 302 est le bon choix

Dans les trois, on sait dire à quelle date la situation reviendra à la normale.

Une indisponibilité passagère. Un produit en rupture pour trois semaines, redirigé vers sa catégorie. L'adresse du produit doit rester dans l'index, puisqu'elle redeviendra la bonne. La 302 est ici le code juste, et la 301 serait une erreur coûteuse.

Une opération limitée dans le temps. Une page de collection redirigée vers une page d'opération commerciale pendant deux semaines de soldes.

Une maintenance. Le temps d'une intervention. Notez au passage qu'une vraie page de maintenance renvoie un code dédié plutôt qu'une redirection, et surtout pas une page qui répond comme si tout allait bien.

Le vrai problème : la redirection qu'on n'a pas choisie

Dans les audits que je mène, les 302 mal placées ne résultent presque jamais d'une décision. Elles viennent de trois sources, et aucune ne demande l'avis de qui que ce soit.

Les extensions de redirection. Beaucoup proposent la 302 comme valeur par défaut dans leur formulaire. La personne qui crée la règle valide sans regarder, et la redirection d'une refonte entière se retrouve en temporaire.

Les redirections automatiques du CMS. Le changement du titre d'une page peut modifier son adresse et créer une redirection sans que personne n'ait rien demandé. Ces règles s'empilent au fil des mois, et personne ne sait plus lesquelles sont volontaires.

Les couches d'infrastructure. Un service de distribution ou un équilibreur de charge peut poser sa propre redirection, invisible dans le code du site. C'est le cas le plus difficile à diagnostiquer, parce qu'on cherche la règle dans les fichiers alors qu'elle est en amont.

Les chaînes, et pourquoi elles coûtent

Une adresse qui renvoie vers une deuxième, elle-même redirigée vers une troisième, finit par arriver à destination. Le visiteur ne voit rien, sinon un léger délai. Trois coûts s'accumulent pourtant.

Chaque saut consomme du budget d'exploration, ce qui compte sur les gros sites. Le signal transmis s'affaiblit à mesure que la chaîne s'allonge. Et une boucle, c'est-à-dire une chaîne qui revient à son point de départ, rend la page définitivement inaccessible.

La correction est mécanique. On fait pointer chaque adresse de départ directement vers la destination finale, en supprimant les étapes intermédiaires. Sur un site un peu ancien, cette seule opération élimine souvent plusieurs centaines de sauts inutiles.

Ce qui ressemble à une redirection sans en être une

Deux mécanismes produisent le même effet visuel et n'ont pas les mêmes propriétés.

La redirection par balise de rafraîchissement. Elle fonctionne dans un navigateur et reste comprise par Google, mais c'est une méthode dépréciée depuis longtemps, avec un délai visible pour l'utilisateur. Il n'existe aucune raison de la préférer à une redirection serveur.

La redirection par script. Elle suppose que le robot exécute le JavaScript. Google le fait, avec un délai de rendu. Les robots des moteurs génératifs ne le font pas du tout, et la page de départ reste pour eux une page vide qui ne mène nulle part. Sur une migration, c'est disqualifiant, et le sujet est traité sur ma page JavaScript et SEO.

Où poser la règle, et pourquoi ça compte

Une même redirection peut être écrite à quatre endroits différents, et le choix n'est pas neutre. Il décide de la rapidité de la réponse, de la facilité de maintenance, et surtout de la capacité à retrouver la règle un an plus tard.

Sur un site à quelques dizaines de règles, l'extension du CMS suffit et évite les erreurs. Au-delà de quelques centaines, il vaut mieux les remonter au niveau du serveur, où elles s'appliquent plus tôt et coûtent moins cher à chaque requête.

Dans les quatre cas, tenez un fichier de suivi des redirections, avec la date et la raison de chacune. Sans ce document, une règle posée pendant une opération commerciale de deux semaines devient au bout d'un an une ligne que personne n'ose supprimer.

Comment auditer les redirections d'un site

1. Crawler le site. Un outil de parcours liste toutes les redirections rencontrées avec leur code et leur destination. C'est la photo de départ.
2. Isoler les temporaires. Toute 302 qui date de plus de quelques mois mérite une explication. Sans explication, elle devient une 301.
3. Repérer les chaînes. Les sauts multiples se voient immédiatement dans le rapport, et se corrigent en série.
4. Tester les anciennes adresses. Depuis un export de la Search Console sur seize mois, pour retrouver ce que le crawl ne voit plus, c'est-à-dire les pages qui ne sont plus liées nulle part mais que Google connaît encore.
5. Vérifier les destinations. Une redirection vers une page qui n'existe plus est pire qu'une absence de redirection, parce qu'elle ajoute une étape avant l'erreur.

Cet inventaire est aussi la première chose que je regarde devant une chute de trafic après une refonte, et c'est là que la cause se trouve dans la majorité des cas. La méthode complète figure sur ma page consacrée à la perte de trafic après une refonte.

Questions fréquentes