Qu’est-ce qu’une redirection ? Explication des redirections (301 vs 302)

TL;DR : Rediriger signifie qu’une URL transfère automatiquement les visiteurs et les moteurs de recherche vers une autre URL. Utilisez un 301 pour un changement permanent et un 302 pour un changement temporaire. Les redirections ne font pas perdre le PageRank “par nature”, mais des chaînes de redirections, des boucles, des destinations cassées ou des redirections vers une page d’accueil non pertinente peuvent quand même provoquer de vrais problèmes de SEO et d’utilisabilité.

Que signifie rediriger ?

Une redirection est une instruction qui dit : « Cette URL a changé. Allez plutôt à cette autre URL. »

Techniquement, un navigateur demande une adresse et le serveur peut répondre avec un code d’état HTTP 3xx accompagné d’un en-tête Location contenant une adresse différente. Le navigateur demande ensuite automatiquement cette destination. Les robots d’indexation des moteurs de recherche peuvent suivre la même instruction.

Concrètement, la signification est plus simple : l’ancienne URL ne sert plus son propre contenu ; elle redirige la requête vers une nouvelle URL.

Les redirections sont nécessaires parce que les URL changent. Les pages sont renommées, des produits sont supprimés, des sites passent de HTTP à HTTPS, des articles se recouvrant sont consolidés, et des domaines sont remplacés. Sans redirection, quelqu’un qui suit l’ancienne adresse aboutit généralement à une erreur 404. Les backlinks continuent de pointer vers une URL abandonnée, et Google ne reçoit pas d’instruction explicite reliant l’ancienne page à son remplacement.

Nous avons réglé ce point directement quand Lida et moi avons migré SEOJuice d’seojuice.io vers seojuice.com en janvier 2026. Une migration de domaine rend la finalité des redirections exceptionnellement claire : chaque ancienne URL doit avoir une destination prévue à l’avance, pas juste une règle qui envoie le domaine quelque part de façon vaguement logique. À deux, il était difficile de déléguer la réflexion : la cartographie des redirections devait être traitée comme faisant partie intégrante de la migration (et pas comme une tâche administrative “après”).

Cette distinction compte. Rediriger un ancien article vers son équivalent sur le nouveau domaine préserve l’itinéraire. Rediriger toutes les anciennes adresses vers la page d’accueil du nouveau site ne fait que masquer les itinéraires manquants.

301 vs 302 : la permanence, c’est le vrai choix

La différence entre un 301 et un 302 n’est pas que l’un serait “bon pour le SEO” et l’autre mauvais. Chaque code communique une attente différente sur ce qui va se passer ensuite.

Un redirection 301 signifie que le déplacement est permanent. Un redirection 302 signifie que le déplacement est temporaire et que l’URL d’origine est censée revenir. Google suit les deux, mais ne traite pas leurs signaux canoniques de la même manière.

« Googlebot suit la redirection, et le pipeline d’indexation utilise la redirection comme signal pour que la destination devienne canonique. »

Pour les redirections temporaires : « Googlebot suit la redirection, mais le pipeline d’indexation n’utilise pas la redirection comme signal que la destination doit être canonique. »

Ce sont des formulations propres à Google Search Central, issues de sa documentation Redirects and Google Search.

En termes de SEO opérationnel, une redirection permanente demande à Google de remplacer l’ancienne URL par la destination dans son index. Une redirection temporaire envoie les utilisateurs vers la destination tout en conservant généralement l’URL d’origine comme canonique. Si la canonicalisation est la partie la plus déroutante, notre guide sur le fonctionnement de l’indexation Google explique comment le crawl, la sélection canonique et l’indexation s’emboîtent.

Utilisez un 301 pour les changements d’URL permanents

Un 301 est le choix conventionnel pour une URL de contenu dont le déplacement est durable. Les cas typiques incluent :

• Renommer une page ou modifier son slug d’URL
• Passer de HTTP à HTTPS
• Standardiser avec ou sans www
• Changer de domaine
• Fusionner des pages en double ou qui se recouvrent
• Remplacer une ancienne page par un successeur réellement équivalent

Google recommande d’utiliser une redirection serveur permanente dès que possible lorsqu’une URL doit changer dans les résultats de recherche. L’objectif est, selon eux, d’assurer que les utilisateurs et Google Search atteignent la bonne page.

Voici le même exemple de redirection permanente sur les deux serveurs web les plus courants :

# Nginx — rediriger une ancienne URL vers son nouvel emplacement
location = /old-page/ {
    return 301 https://example.com/new-page/;
}

# Apache (.htaccess) — la règle équivalente en une ligne
Redirect 301 /old-page/ https://example.com/new-page/

Le mot équivalent fait toute la différence ici. Un produit supprimé ne devient pas “équivalent” à votre page d’accueil uniquement parce que les deux URL appartiennent à la même entreprise.

Utilisez un 302 lorsque l’URL d’origine revient

Un 302 convient à une page de maintenance temporaire, à une expérimentation, à une prise de contrôle saisonnière à courte durée, ou à une logique de routage que vous comptez inverser. Il indique à Google que la destination n’est pas destinée à devenir le remplacement permanent.

Si une page a été déplacée “pour de bon” mais reste derrière un 302, Google peut continuer à indexer l’ancienne adresse. La redirection peut sembler parfaitement fonctionnelle dans un navigateur tout en transmettant une intention d’indexation incorrecte (un rappel utile : “ça se charge” n’est pas un test complet de redirection).

Choisissez selon votre intention de revenir en arrière ou non. Permanent signifie 301 ; temporaire signifie 302. Notre comparaison dédiée de 301 vs 302 couvre aussi les cas de migration et de canonicalisation moins évidents.

Et les redirections 303, 307 et 308 ?

La plupart des sites éditoriaux et marketing peuvent utiliser des redirections 301 et 302 pendant des années sans avoir besoin des autres codes. Les distinctions deviennent importantes autour des formulaires, des API et d’autres requêtes qui ne sont pas en GET.

Comme documenté dans le guide sur les redirections HTTP de MDN Web Docs, les redirections 301 et 302 portent une ambiguïté historique sur la gestion des méthodes de requête. Certains clients peuvent transformer une requête POST en GET en les suivant.

Ce comportement est souvent sans conséquence pour une simple consultation de page. Il ne l’est plus si un endpoint attend un corps de requête.

307 conserve la requête temporairement

Une redirection temporaire 307 exprime la même intention temporaire qu’un 302, mais garantit que la méthode HTTP et le corps de la requête sont conservés. Un POST reste un POST après la redirection.

308 conserve la requête de façon permanente

Une redirection permanente 308 est l’équivalent qui préserve la méthode face à un 301. MDN explique que « le 308 a été créé pour supprimer l’ambiguïté du comportement lors de l’utilisation de méthodes autres que GET ».

Pour une page de contenu demandée avec GET, les utilisateurs verront peu de différence pratique entre 301 et 308. Il en va de même pour 302 et 307. La conservation de la méthode devient cruciale pour les requêtes POST et PUT, les formulaires et les API (à ce moment-là, je ferais intervenir la personne qui possède le backend plutôt que choisir un statut à partir d’un rapport SEO).

303 change délibérément la requête en GET

Une redirection 303 See Other est temporaire et transforme volontairement la requête suivante en GET. Un usage courant consiste à envoyer l’utilisateur depuis un formulaire soumis vers une page de confirmation ou de résultat distincte, afin d’éviter qu’un rafraîchissement ne renvoie une resoumission du POST initial.

C’est d’abord un comportement HTTP, et seulement ensuite un comportement SEO. N’inventez pas des redirections de page plus exotiques que nécessaire.

Les redirections côté serveur valent mieux que les contournements côté navigateur

Les redirections via des statuts HTTP se produisent côté serveur. Deux alternatives côté client existent aussi : la méta-refresh HTML et les redirections JavaScript.

Une méta-refresh s’exécute après le démarrage du chargement d’un document HTML. MDN recommande de fixer son délai à zéro pour respecter l’accessibilité, et avertit que des règles de redirection HTTP et HTML qui ne sont pas synchronisées peuvent générer une boucle infinie ou « d’autres cauchemars ». La formulation est marquante parce que l’échec est bien réel : deux couches de routage gérées séparément peuvent commencer à diverger après un changement autrement banal de CMS.

Une redirection JavaScript dépend du client qui exécute le JavaScript. Google Search Central indique : « Utilisez uniquement des redirections JavaScript si vous ne pouvez pas faire de redirections côté serveur ou via meta refresh. Même si Google tente de rendre chaque URL que Googlebot a explorée, le rendu peut échouer pour diverses raisons. »

Mon ordre de préférence est :

1. Une redirection HTTP côté serveur avec le bon statut permanent ou temporaire
2. Une méta-refresh à zéro seconde si la configuration serveur n’est pas disponible
3. Une redirection JavaScript uniquement si aucune des options ci-dessus n’est possible

Certains hébergements statiques et plateformes CMS contraignantes n’exposent pas la couche serveur idéale. Cette contrainte est réelle. Malgré tout, le fait qu’un navigateur finisse par atteindre la destination n’est pas la même chose qu’une redirection propre que chaque client peut interpréter de manière cohérente.

Les redirections font-elles perdre du PageRank ?

Une règle SEO historique affirmait que chaque redirection faisait perdre un pourcentage fixe de “link juice”. Les pourcentages continuent de circuler, mais ils ne devraient pas guider les décisions d’implémentation. Ils ne sont pas étayés par la position actuelle de Google.

« Les redirections 30x ne perdent plus de PageRank. »

Gary Illyes de Google a fait cette déclaration en 2016, telle que rapportée par Search Engine Land. La conclusion logique est étroite mais importante : la simple présence d’une redirection 301, 302 ou autre 30x n’entraîne pas automatiquement de pénalité de PageRank.

Et il ne faut pas en déduire que 301 et 302 sont interchangeables.

Un 301 indique à Google de traiter la destination comme un remplacement canonique permanent. Un 302 laisse généralement l’URL d’origine canonique car le déplacement est temporaire. La gestion du PageRank et l’intention canonique sont liées, mais ce n’est pas la même question.

Je ne promettrais pas non plus qu’une migration de domaine préserve le classement sans aucune fluctuation. Les redirections envoient un signal important, mais Google doit quand même recrawler les URLs, traiter les canoniques et mettre à jour son index. Un routage propre supprime une source majeure d’ambiguïté ; il ne fige pas les résultats de recherche.

Les erreurs de redirection qui causent de vrais dégâts

Les chaînes de redirection

Une chaîne de redirection fait passer une requête par plusieurs URL :

URL A → URL B → URL C → URL D

Le parcours le plus propre est : URL A directement vers URL D. Si B et C sont encore liés en interne, mettez aussi ces liens à jour vers D.

Chaque étape ajoute une requête, consomme des ressources d’exploration et crée une règle de plus qui peut échouer. Les chaînes longues augmentent aussi le risque que la destination finale ne soit pas atteinte lors d’un crawl donné. Répété sur des milliers de pages, cela devient un vrai problème de budget de crawl, pas juste un avertissement d’audit cosmétique.

Inutile d’associer un pourcentage inventé de perte de PageRank à chaque étape. Plus de requêtes, un routage plus lent, des explorations gaspillées et davantage de points de défaillance suffisent largement à justifier la suppression de la chaîne.

Les boucles de redirection

Une boucle envoie la requête en rond, par exemple A → B → A. Les navigateurs finissent par s’arrêter et afficher une erreur “trop de redirections”. Le contenu devient inaccessible pour les utilisateurs et les robots.

Les boucles viennent le plus souvent de règles contradictoires : une règle HTTPS qui “se bat” avec une règle de hostname, une règle de slash final qui inverse une autre redirection, ou une meta refresh qui n’est pas d’accord avec le serveur. L’erreur finale côté navigateur masque le chemin : inspectez chaque réponse plutôt que de rafraîchir la page encore et encore (ou, plus souvent que je ne voudrais, de vider les caches en espérant).

Rediriger toutes les URL supprimées vers la page d’accueil

Ce n’est pas une stratégie de nettoyage. Vous remplacez une réponse claire de page absente par une destination non pertinente.

Les recommandations “soft-404” de Google expliquent que des redirections vers des pages non pertinentes peuvent être interprétées comme des soft 404. Redirigez une ancienne URL uniquement lorsqu’il existe un remplacement réellement pertinent. S’il n’y a pas de remplacement, renvoyez un vrai 404 ou 410.

Un produit arrêté peut raisonnablement rediriger vers son successeur direct ou, dans certains cas, vers une catégorie étroitement liée. Il ne devrait pas envoyer automatiquement les utilisateurs vers une page d’accueil générique qui ne répond pas à la demande.

Versions mixtes de protocole et de hostname

Si HTTP, HTTPS, www et non-www servent tous du contenu, plusieurs adresses “concourent” pour représenter la même page. Choisissez un hôte et un protocole canoniques, puis redirigez définitivement toutes les variantes directement vers ce choix.

Testez toutes les combinaisons. Une règle HTTP peut fonctionner correctement seule, puis créer une étape supplémentaire ou une boucle lorsqu’elle est combinée avec la règle de hostname.

Les redirections qui s’arrêtent sur une erreur

Une redirection n’est pas réussie simplement parce que sa première réponse est un 301. Sa destination finale doit renvoyer une réponse fonctionnelle.

Un 301 qui mène à un 404 reste cassé pour la personne qui a suivi la redirection. Une redirection qui se termine par une réponse de la famille 500 est tout aussi mauvaise. Voilà pourquoi se contenter de vérifier le code d’état initial fait manquer une partie importante du trajet.

Comment trouver et corriger les problèmes de redirection

Commencez par un outil de crawling comme Screaming Frog, Ahrefs Site Audit ou l’audit de SEOJuice. Explorez les URL sources et suivez chaque itinéraire jusqu’à la réponse finale. Cherchez :

• Des chaînes de redirection avec plusieurs étapes
• Des boucles de redirection
• Des redirections qui aboutissent à une réponse 4xx ou 5xx
• Des liens internes qui pointent encore vers des URL déjà redirigées
• Des déplacements permanents mis en place avec des redirections temporaires

D’après ce que nous constatons sur les sites suivis via SEOJuice, les liens internes pointant vers des URL déjà redirigées méritent plus d’attention que celle qu’ils reçoivent. La redirection peut “marcher”, donc le problème semble inoffensif. Pourtant, votre site fait passer chaque utilisateur et chaque robot par une requête inutile, et des modifications futures de redirection peuvent transformer ce vieux lien interne en élément d’une chaîne.

Ce point est devenu particulièrement pertinent pendant notre migration .io vers .com. Des règles au niveau du domaine peuvent donner l’impression que le site est migré, alors que de vieux liens absolus restent enfouis dans des pages, des templates ou du contenu structuré. Une redirection globale qui fonctionne masque ces liens ; un crawl les révèle.

Google Search Console fournit la vision de Google sur le résultat. Le rapport sur l’indexation des pages peut afficher des statuts tels que “Page with redirect” et “Redirect error”. L’outil d’inspection d’URL affiche la canonique déclarée par l’utilisateur et celle choisie par Google, ce qui aide quand Google n’a pas accepté la destination attendue.

Pour une seule URL suspecte, utilisez le panneau Network dans les DevTools du navigateur. Vérifiez chaque statut et chaque réponse Location jusqu’au chargement de la page finale, ou jusqu’à l’échec du trajet. C’est plus rapide qu’un crawl complet quand vous dépannez une seule règle.

Priorisez les corrections dans cet ordre :

1. Supprimez les boucles : elles rendent les pages inaccessibles.
2. Réparez les redirections qui aboutissent à des réponses 4xx ou 5xx.
3. Réduisez les chaînes pour que les vieilles URL pointent directement vers les destinations finales.
4. Remplacez les redirections non pertinentes par des destinations pertinentes ou par des vraies réponses 404/410.
5. Mettez à jour les liens internes pour contourner les redirections.
6. Confirmez que les déplacements permanents utilisent un statut permanent.

Le SEO audit de SEOJuice met en évidence les chaînes de redirection, les redirections cassées et les liens internes pointant vers des URL redirigées, ce qui vous donne une liste exploitable. Il ne réécrit pas pour vous les règles nginx, .htaccess, CDN ou CMS ; ces modifications doivent rester du côté de l’infrastructure qui contrôle la réponse.

Une checklist de redirection pour les migrations de site

Traitez les redirections comme des règles de routage, pas comme de la “magie SEO”. Choisissez une destination pertinente, indiquez si le déplacement est permanent, et supprimez les sauts évitables. La plupart des décisions de redirection deviennent évidentes dès que ces trois points sont explicites.

Questions fréquentes

Que signifie “redirection” ?

Rediriger signifie qu’une URL ne sert plus son propre contenu et qu’elle transfère plutôt les visiteurs et les moteurs de recherche vers une autre URL. Une redirection côté serveur renvoie normalement un statut HTTP 3xx ainsi que l’adresse de destination, que le navigateur demande automatiquement.

Quelle est la différence entre une redirection 301 et une redirection 302 ?

Un 301 indique que le déplacement est permanent, ce qui permet à Google de traiter la destination comme canonique. Un 302 indique que le déplacement est temporaire : Google conserve généralement l’URL d’origine indexée. Utilisez un 301 si la page ne reviendra pas et un 302 si elle revient.

Les redirections nuisent-elles au SEO ?

Une redirection correctement implémentée ne nuit pas “par nature” au SEO. Google recommande des redirections serveur permanentes pour les déplacements permanents, et Gary Illyes a déclaré que les redirections 30x ne font pas perdre de PageRank. Les problèmes SEO apparaissent avec les chaînes, les boucles, les destinations cassées, les redirections non pertinentes et les statuts qui communiquent une intention incorrecte.

Qu’est-ce qu’une chaîne de redirection ?

Une chaîne de redirection se produit lorsqu’une URL A redirige vers une URL B, qui redirige à son tour vers une URL C. Elle ajoute des requêtes inutiles et du travail de crawl. Corrigez-la en faisant pointer URL A directement vers URL C et en mettant à jour les liens internes pour utiliser l’adresse finale.

Qu’est-ce qui provoque une erreur “trop de redirections” ?

Une boucle de redirection provoque cette erreur. Deux règles ou plus font tourner la requête en rond, souvent à cause de conflits entre des règles HTTPS, www, slash final, côté serveur ou meta-refresh. Le navigateur finit par arrêter de suivre la boucle.

Quand dois-je utiliser une redirection 307 ou 308 ?

Utilisez 307 pour un déplacement temporaire et 308 pour un déplacement permanent quand il faut préserver à la fois la méthode HTTP d’origine et le corps de la requête. Elles sont surtout importantes pour les formulaires et les requêtes API qui utilisent des méthodes comme POST ou PUT. Pour les pages de contenu ordinaires demandées avec GET, les choix conventionnels restent 301 et 302.