Comment fonctionnent les redirections 301 et 302 pour le SEO ?

Les redirections 301 envoient visiteurs et robots d’une ancienne adresse vers une nouvelle, avec un code de réponse qui précise si le changement est définitif ou provisoire. Bien posées, elles préservent l’accès aux contenus et reportent les signaux de la page d’origine ; mal posées, elles créent des chaînes, des boucles et des pages perdues. Cet article distingue les codes 301, 302, 307 et 308, détaille les bonnes pratiques, traite les cas particuliers courants, puis propose une méthode de plan, de crawl et de suivi pour migrer sereinement.

Redirections 301 et 302 : ce que chaque code HTTP dit aux moteurs

Quand une adresse change, le serveur répond à la demande par un code de la famille 3xx accompagné de la nouvelle destination, et le navigateur ou le robot la suit aussitôt. Ce code porte un sens : il indique si l’ancienne adresse est abandonnée pour de bon ou seulement mise de côté. Parmi les tutoriels SEO pas à pas, celui-ci traite l’un des gestes les plus lourds de conséquences, car une migration réussie repose presque entièrement sur ces règles. Le schéma situe les codes à connaître, avant d’examiner ce que chacun signifie pour les moteurs. Un seul code mal choisi, appliqué à des centaines d’adresses, suffit à fausser toute une migration.

301 et 308 : le déménagement définitif

Un code 301 déclare que la page a changé d’adresse de façon permanente ; le 308 dit la même chose en imposant de conserver la méthode de la requête, ce qui compte surtout pour les formulaires. Pour les moteurs, la nouvelle adresse devient en principe celle à indexer, et les signaux attachés à l’ancienne, comme les liens entrants, sont reportés vers elle. La transmission n’est pas instantanée : l’ancienne adresse peut rester affichée un temps. C’est le code d’un changement durable : refonte, nouvelle structure d’URL, fusion de pages ou changement de domaine. Le 308 reste moins répandu dans les gabarits de sites éditoriaux, où le 301 est l’usage courant.

302 et 307 : le détour provisoire

Le 302 et le 307 indiquent une redirection temporaire : l’adresse d’origine reste la référence et doit revenir en service. On les emploie pour une page en maintenance, un test, une promotion limitée ou un renvoi selon la langue du visiteur. Google traite aujourd’hui les redirections permanentes et temporaires de façon voisine pour la consolidation, ce qui ne dispense pas de choisir le code qui dit la vérité : un 302 laissé des mois pour un déménagement définitif envoie un message ambigu aux autres moteurs, aux outils et aux équipes qui reprendront le site. Le 307 joue le même rôle que le 302 en préservant la méthode de la requête.

Redirections côté serveur, meta refresh et JavaScript

La méthode la plus fiable consiste à répondre avec le bon code HTTP au niveau du serveur, du CMS ou du CDN, avant même que le contenu soit envoyé. Les redirections par balise meta refresh ou par JavaScript existent, mais elles dépendent du rendu de la page, sont plus lentes et ne donnent pas la même clarté de signal : mieux vaut les réserver aux cas où l’accès au serveur est impossible. Les règles côté serveur se testent aussi plus facilement, puisqu’un outil d’inspection des en-têtes affiche le code reçu, la destination et le nombre de sauts. En cas de doute sur l’origine d’une redirection, remontez la chaîne règle par règle jusqu’au fichier de configuration.

Bonnes pratiques des redirections 301 : page à page, sans chaîne ni boucle

Poser une redirection ne suffit pas : encore faut-il la poser au bon endroit, vers la bonne page. Les problèmes les plus coûteux ne viennent pas d’un code erroné mais d’une cible mal choisie, d’un détour inutile ou d’un lien interne oublié. La logique de la balise canonical rejoint celle des redirections : toutes deux désignent une adresse de référence, mais la première est un signal que Google peut écarter, alors que la seconde s’impose aux visiteurs et aux robots. Le tableau résume les règles, détaillées ensuite en trois points. Ces règles valent pour tout site, quelle que soit sa taille. Une relecture croisée avant la mise en ligne limite fortement les mauvaises surprises.

Une redirection page à page vers un contenu équivalent

Chaque ancienne adresse doit mener à la page qui répond à la même attente. Rediriger en masse vers l’accueil ou une catégorie générale déçoit le visiteur, et Google peut traiter ces redirections comme des erreurs de type soft 404 lorsque la destination n’a aucun rapport avec l’original. Le travail consiste donc à apparier chaque page avec son équivalent le plus proche, quitte à regrouper plusieurs pages anciennes vers une seule nouvelle. Si aucune équivalence honnête n’existe, mieux vaut laisser la page disparaître proprement, avec le code approprié, que la rediriger par principe. Une liste d’équivalences relue par la personne qui connaît le contenu évite les rapprochements hasardeux.

Éviter les chaînes et les boucles

Une chaîne apparaît quand A mène à B, qui mène à C : chaque saut ajoute du temps de chargement, consomme du budget d’exploration et augmente le risque qu’un robot abandonne. Elle naît le plus souvent de migrations successives, où l’on ajoute une règle sans retirer les précédentes. La parade : rediriger A directement vers C en réécrivant les règles. La boucle, où A renvoie à B qui renvoie à A, rend la page inaccessible et provoque une erreur dans le navigateur. Un crawler qui suit les redirections signale les deux situations ainsi que le nombre de sauts. Mieux vaut les traiter avant la mise en ligne que les découvrir au premier rapport d’erreurs.

Mettre à jour les liens internes et le plan du site

Une redirection est un filet de sécurité, pas une solution durable : les liens internes, les menus, les fils d’Ariane et les canoniques doivent pointer vers les nouvelles adresses, afin que le robot et le visiteur n’aient pas besoin de la redirection pour arriver. Le même principe vaut pour le plan du site, qui ne liste que des adresses finales. Des liens internes à jour allègent le serveur, accélèrent l’exploration et simplifient les audits. Les liens externes ne se contrôlent pas toujours : la redirection reste alors le seul pont, à conserver tant que de vieux liens existent. Ce nettoyage se fait en une opération si les liens sont gérés par le gabarit ou par une base de données.

Cas particuliers des redirections 301 : https, www, barre oblique et pages supprimées

Certaines redirections se retrouvent sur presque tous les sites, souvent posées par habitude plutôt que par choix : passage en https, forme avec ou sans www, barre oblique finale, suppression de pages. Elles obéissent aux mêmes principes, mais leurs erreurs sont plus sournoises, car elles touchent toutes les adresses à la fois. Le sitemap XML sert de contrôle utile pour vérifier qu’elles sont bien appliquées, puisqu’il ne doit contenir que les versions de référence. Le tableau résume les cas, et les paragraphes suivants en précisent les pièges. Ils méritent un contrôle systématique à chaque évolution technique du site. La règle de bon sens : une seule version par adresse, appliquée partout.

http vers https et choix du www

Le passage en https impose de rediriger chaque adresse en http vers sa version sécurisée, page par page et de façon permanente. Le choix entre avec ou sans www relève de la préférence ; l’essentiel est de n’en conserver qu’une, que tout le site utilise dans ses liens, ses canoniques et son plan. Ces deux règles s’appliquent au niveau global du serveur et doivent produire un seul saut, sans étape intermédiaire. Un test sur les quatre combinaisons (http et https, avec et sans www) vérifie qu’elles convergent toutes vers la même adresse finale, sans passer par une page d’erreur ni par un avertissement de certificat.

Barre oblique finale et variantes d’adresse

Pour un serveur, /guide et /guide/ peuvent désigner deux adresses distinctes, chacune affichant le même contenu : un doublon en puissance. On choisit une forme, on redirige l’autre systématiquement et on s’y tient dans les liens internes. Même logique pour les majuscules, les extensions superflues comme index.html ou les paramètres de suivi qui créent des variantes. La normalisation des adresses évite d’éparpiller les signaux entre plusieurs versions d’une même page. Le sélecteur ci-dessous aide à retrouver le code adapté à chaque situation, de la suppression au déménagement définitif. Une règle générale au niveau du serveur vaut mieux qu’une règle écrite page par page.

Pages supprimées sans équivalent : 404 ou 410

Quand une page disparaît sans contenu comparable, la redirection vers l’accueil n’aide personne. Le code 404 signale une adresse introuvable, le 410 une suppression volontaire et définitive ; Google traite ces deux codes de façon proche et retire les pages concernées de l’index au fil des explorations. L’important est la page d’erreur utile : un message clair, un champ de recherche et des liens vers les contenus voisins. Réservez la redirection aux pages qui ont un véritable successeur, et laissez les autres sortir sans bruit, en vérifiant qu’aucun lien interne ne continue de les viser. Une page d’erreur bien conçue limite aussi les départs immédiats de visiteurs arrivés par un ancien lien.

Un plan de redirections 301 : tableau de correspondance, crawl et suivi des erreurs

Une migration se joue avant la mise en ligne : le plan de redirections est le document qui rend l’opération vérifiable. Il liste chaque ancienne adresse, sa destination, le code retenu et son statut de test, puis sert de référence pour comparer ce que le site renvoie réellement une fois en production. La méthode tient en quelques étapes, qui s’enchaînent de façon répétable sur un site de n’importe quelle taille, du petit site vitrine à la boutique en ligne comptant de nombreuses fiches produits. Sans ce document, chacun vérifie à sa façon, et les oublis se découvrent trop tard. Il fait gagner du temps à toutes les équipes concernées.

1. Inventorier les adressesCrawler l’ancien site et compléter avec la Search Console.
2. Associer chaque adresseUne destination équivalente et un code pour chaque ligne.
3. Appliquer les règlesCôté serveur, d’abord en préproduction puis en production.
4. Crawler après la basculeComparer codes et destinations avec le plan prévu.
5. Suivre les erreursSurveiller les 404 et l’indexation dans les semaines suivantes.

Le tableau de correspondance

Le tableau se construit à partir d’un crawl complet de l’ancien site, complété par les adresses connues de la Search Console, du plan du site et des liens entrants. Chaque ligne associe une ancienne adresse à sa destination, avec le code de réponse attendu et une colonne de remarques. Pour de grands volumes, on regroupe par motifs plutôt que ligne à ligne, tout en gardant un échantillon vérifié à la main. Le tableau reste ensuite en archive : il documente les décisions et permet de retrouver l’origine d’une anomalie des mois plus tard. Les colonnes utiles se limitent à l’origine, la destination, le code et l’état du test.

Crawler avant et après la bascule

Un crawl de l’ancien site fournit la liste de départ ; un second, lancé sur le nouveau site dès la mise en production, vérifie que chaque ancienne adresse répond par le code et la destination prévus. On compare les deux jeux de données : adresses perdues, redirections temporaires à corriger, chaînes, cibles en erreur, pages orphelines. Un essai en préproduction avec des règles identiques évite les mauvaises surprises. Le second crawl doit se faire le jour même, pas une semaine plus tard, car toute journée d’erreur est une journée d’exploration perdue. Notez les écarts dans le plan pour garder la trace de chaque correction.

Suivre les erreurs dans la durée

Après la bascule, la Search Console devient l’outil de veille : le rapport d’indexation des pages révèle les erreurs 404 et les pages explorées mais non indexées, tandis que l’inspection d’URL montre l’adresse canonique retenue. Pour un changement de domaine, l’outil de changement d’adresse de la Search Console complète le dispositif. Les journaux du serveur indiquent quelles anciennes adresses reçoivent encore des visites. On garde les redirections aussi longtemps que d’anciennes adresses reçoivent des visites ou des liens, et on ne les retire qu’après vérification de cet usage. Une revue hebdomadaire de ces écrans suffit pendant le premier mois. Le suivi reste simple tant que le plan de départ est précis.

À lire aussi dans la même rubrique

Comment structurer ses titres avec les balises Hn ?

Balises Hn : rôle de chaque niveau, règles de hiérarchie, rédaction de titres informatifs et erreurs à éviter pour un pl…

Comment bien utiliser la balise canonical ?

Balise canonical : rôle, cas d’usage (paramètres, pagination, http et https), erreurs qui l’annulent et contrôle avec l’…

Comment rédiger une meta description efficace ?

Meta description : statut réel, longueur indicative, verbes d’action, gabarits pour gros sites et mesure du CTR pour réd…