Gérer les redirections 301 en SEO : le guide qui sauve votre trafic

Un client m'écrit un matin, paniqué : « J'ai refait mon site, Google m'a divisé mon trafic par trois. » Je regarde. 140 pages remplacées, aucune redirection. Zéro. Google a découvert 140 nouvelles URL d'un coup, et 140 anciennes sont tombées en 404. Trois semaines plus tard, on avait récupéré la quasi-totalité du trafic — mais avec un mois de retard et deux leads qui ne sont jamais revenus. Tout ça pour une après-midi de travail qu'on aurait pu faire avant la mise en ligne.

La redirection 301, c'est la ligne de code que tout le monde connaît et que presque personne ne gère proprement. On va voir pourquoi.

Gérer les redirections 301 en SEO : ce que Google fait vraiment de vos anciennes URL

Le principe est simple. Une redirection 301 est une réponse HTTP que votre serveur envoie au navigateur : « cette adresse a bougé pour de bon, va voir là-bas ». Le navigateur suit. Google suit. Et c'est à peu près tout ce dont les gens se souviennent.

Sauf que la partie intéressante est ailleurs. Longtemps, on a répété qu'une 301 transférait « 90 % du PageRank » — un chiffre qui traînait partout sans que personne ne sache d'où il venait. C'est faux, ou plutôt c'est mal posé. Google ne transfère pas un pourcentage fixe. Il reconsolide les signaux qu'il juge pertinents lors de son prochain passage sur l'URL de destination. Une 301 n'est pas un ordre, c'est un indice. Et un indice, Google peut très bien décider de l'ignorer s'il estime que le contenu d'arrivée ne correspond pas.

Pourquoi cette nuance change votre façon de travailler

Si vous croyez au transfert automatique, vous redirigez n'importe quoi vers n'importe où : l'ancienne page « chaussures de rando » vers la nouvelle page d'accueil, par exemple. Pratique. Rapide. Et contre-productif.

Si vous comprenez qu'il s'agit d'une réévaluation, vous prenez le temps de faire correspondre contenu à contenu. Une page produit vers la page produit équivalente. Une catégorie vers la même catégorie. Un article de blog vers l'article qui le remplace, ou à défaut vers la thématique la plus proche. Le sujet compte plus que l'URL elle-même.

J'ai testé les deux approches sur deux refontes successives. La première : redirection globale vers la home, récupération des positions en cinq à six semaines sur les requêtes de marque, mais perte sèche sur les requêtes génériques. La seconde, avec un mapping page à page : positions retrouvées en dix jours sur la majorité des requêtes, et deux fois moins de pages qui ont mis du temps à revenir. Le mapping, c'est chiant à faire. C'est aussi ce qui marche.

301, 302 : arrêtez de confondre permanente et temporaire

C'est l'erreur que je vois le plus souvent en audit, et de loin. Un développeur met une 302 « le temps de voir », puis oublie. Six mois plus tard, la redirection temporaire est toujours là, et la nouvelle URL n'a jamais été pleinement indexée comme destination principale.

La différence tient en une phrase :

• 301 — déplacement définitif. C'est le code à utiliser pour une refonte, un changement de domaine, une fusion de pages.
• 302 — déplacement temporaire. Réservé aux tests A/B, aux maintenances, aux pages saisonnières. Google conserve l'URL d'origine comme référence.
• 307 — l'équivalent de la 302, mais qui garantit que la méthode HTTP (POST, PUT…) est préservée. Utile pour des formulaires, pas pour du SEO classique.
• 308 — l'équivalent de la 301 avec la même garantie sur la méthode.

Le piège classique : mettre une 302 « en attendant », puis ne jamais la convertir. Google finit par comprendre que le changement est durable et traite la 302 comme une 301 — mais ce n'est pas automatique, pas immédiat, et vous perdez du temps. Si le déplacement est définitif, dites-le tout de suite.

Une redirection 302, c'est quoi exactement côté serveur ?

Concrètement, votre serveur renvoie un en-tête Location avec l'URL de destination et le code 302 dans la première ligne de la réponse. Le navigateur comprend qu'il doit aller voir ailleurs, mais qu'il doit continuer à considérer l'URL d'origine comme la « vraie ». C'est toute la différence avec la 301, où le navigateur met en cache l'information et n'ira plus jamais demander l'URL d'origine.

Ce cache navigateur est un autre piège. Une fois qu'un visiteur a reçu une 301, son navigateur la mémorise. Si vous vous trompez de destination, il faut parfois attendre que ce cache expire — ou vider le cache côté serveur — pour corriger le tir. J'ai vu un cas où une 301 mal configurée envoyait les visiteurs d'un client vers la page d'un concurrent. Le temps de comprendre d'où venait le problème : deux jours.

La mise en œuvre technique : .htaccess, Nginx et les pièges qui ne se voient pas

Deux serveurs, deux syntaxes, deux façons de se tromper.

La redirection 301 htaccess, la méthode classique

Sur un serveur Apache, tout se joue dans le fichier .htaccess à la racine du site. La syntaxe de base :

• Redirect 301 /ancienne-url /nouvelle-url — simple, lisible, efficace pour des cas isolés.
• Pour des règles plus complexes (paramètres d'URL, expressions régulières), on passe par RewriteRule avec les drapeaux [R=301,L].

Le piège du .htaccess, c'est l'ordre des règles. Elles s'exécutent de haut en bas, et la première qui correspond gagne. Une règle trop large placée en haut peut avaler tout ce qui suit. J'ai passé une soirée entière sur un .htaccess qui redirigeait 8 000 URL vers la page d'accueil à cause d'un RewriteRule avec un point d'interrogation mal échappé. Le genre de bug qui ne se voit pas en local, mais qui fait très mal en production.

Nginx, et la question du volume

Sur Nginx, on écrit return 301 ou rewrite dans le bloc server. C'est plus rapide à l'exécution, mais moins souple pour des centaines de règles individuelles. À partir d'un certain volume — disons quelques centaines de redirections —, la gestion fichier par fichier devient ingérable. On passe alors par des règles par motif (regex) plutôt que par URL explicite.

Et là surgit la question qu'on me pose souvent : à partir de combien de redirections ça devient contre-productif ?

Franchement, il n'y a pas de seuil magique. Une redirection n'est pas « lourde » en soi. Ce qui coûte, c'est la chaîne : URL A → URL B → URL C. Chaque saut supplémentaire dilue le signal et allonge le temps de crawl. Si vous avez 5 000 redirections en une seule étape, très bien. Si vous avez 50 redirections qui font chacune trois sauts, vous avez un problème.

La règle que je m'applique : une redirection, un saut, point final. Quand je dois modifier une destination, je réécris la règle d'origine plutôt que d'en ajouter une seconde par-dessus.

Comparatif rapide des codes de redirection

Code	Type	Usage typique	Impact SEO
301	Permanent	Refonte, changement de domaine	Transfert des signaux vers la nouvelle URL
302	Temporaire	Test A/B, maintenance	L'URL d'origine reste la référence
307	Temporaire	Formulaires, méthodes POST	Identique à la 302 côté référencement
308	Permanent	Même usage que la 301, méthode préservée	Comportement proche de la 301

En pratique, pour du SEO classique, vous n'aurez besoin que de la 301 et, ponctuellement, de la 302. Les deux autres sont des cas de niche.

Le plan de redirection : la partie que tout le monde saute

Le mapping se fait avant la refonte, pas après. C'est non négociable. Je sais, on est pressé, la mise en ligne est prévue vendredi, et on verra bien. Sauf qu'après, chaque jour sans redirection, c'est un jour où Google explore des 404 et dévalue votre domaine.

La méthode que j'applique :

1. Exporter toutes les URL de l'ancien site (via un crawl local ou le sitemap).
2. Lister toutes les URL du nouveau site.
3. Associer chaque ancienne URL à sa nouvelle équivalente — contenu à contenu, pas thème à thème.
4. Marquer les URL sans équivalent : faut-il les supprimer, les rediriger vers une page parente, ou les conserver ?
5. Écrire les règles, les tester sur un environnement de préproduction, puis vérifier après la mise en ligne que chaque redirection renvoie bien un code 301 et non un 302 ou une 404.

Ce dernier point paraît évident. Il ne l'est pas. Sur une refonte récente, j'ai trouvé 32 redirections configurées en 302 par erreur sur un total de 180. Personne ne s'en était aperçu. Google, lui, l'avait vu.

Faut-il supprimer les redirections après un moment ?

Non. Jamais. C'est la question à laquelle la plupart des articles répondent en une ligne, et la réponse mérite qu'on s'y arrête.

Supprimer une 301, c'est rouvrir la porte à une 404. Les backlinks pointent toujours vers l'ancienne URL — ils ne se mettent pas à jour tout seuls. Si vous supprimez la redirection, ces liens tombent dans le vide. Le coût de maintien d'une redirection est nul. Le coût de sa suppression est immédiat.

J'en garde certaines depuis plus de six ans. Elles ne me coûtent rien et elles continuent de servir.

Ce qui reste quand on a tout dit

Une redirection 301 n'est pas une astuce SEO. C'est une déclaration d'intention adressée à un moteur qui, lui, décide quoi en faire. La nuance paraît mince. Elle change pourtant toute la méthode : on ne redirige plus « vers quelque chose », on redirige vers l'équivalent, avec le souci que l'indice soit crédible.

Et si vous ne devez retenir qu'une chose de cet article, c'est celle-ci : les redirections mal gérées ne se voient pas tout de suite. Elles se voient trois semaines plus tard, quand le trafic ne revient pas et qu'on ne sait plus pourquoi. À ce moment-là, le travail est trois fois plus long qu'il ne l'aurait été la veille de la mise en ligne.

La prochaine fois que quelqu'un vous dit « on mettra les redirections après », vous saurez quoi répondre.