Vous avez modifié une redirection 301, mais le navigateur continue obstinément d’envoyer les visiteurs vers l’ancienne URL? Un casse-tête familier pour quiconque a déjà configuré des migrations de site ou restructuré des liens.

Le problème ne vient ni du serveur ni de WordPress. Le navigateur mémorise de façon permanente une redirection permanente et n’interroge plus le serveur; c’est ainsi que fonctionne la spécification HTTP. Tant que le cache n’expire pas ou que l’utilisateur ne le vide pas manuellement, l’ancienne règle reste en vigueur.

Voici une stratégie claire: comment tester les redirections sans conséquence, pourquoi le 302 vous épargne des nerfs pendant le débogage et que faire si le cache est déjà bloqué pour les vrais visiteurs.

💡 Aperçu rapide:

• Commencez toujours par un 302 (temporaire), testez, puis passez seulement ensuite au 301 (permanent)
• Videz le cache de votre navigateur chaque fois que vous modifiez des règles de redirection
• Pour Chrome: DevTools → Network → Disable cache, ou onglet Application → Clear site data
• Si un 301 est déjà en cache chez les utilisateurs, vous ne pouvez qu’attendre ou changer l’URL de destination

Comment le navigateur met en cache une redirection 301

Lorsque le serveur répond avec un statut 301 Moved Permanently, le navigateur l’interprète littéralement: «cette URL a déménagé pour toujours». Il stocke la paire «ancienne URL → nouvelle URL» dans son propre cache de redirections, distinct du cache des pages et des images.

La prochaine fois que l’utilisateur (ou vous, le développeur) ouvre la même adresse, le navigateur n’envoie aucune requête au serveur. Il substitue immédiatement l’URL de destination sauvegardée depuis le cache. Le serveur ne voit aucune requête, et vous ne voyez pas le comportement actuel.

La spécification HTTP ne définit pas de durée de conservation stricte pour ce type de cache. En pratique, Chrome, Firefox et Safari conservent le 301 en cache jusqu’à ce qu’il soit explicitement vidé. L’en-tête Cache-Control du serveur peut être ignoré par le navigateur spécifiquement pour le 301, car «permanent» signifie permanent.

Ce comportement est une fonctionnalité, pas un bug. Il économise un aller-retour pour les déménagements permanents légitimes (par exemple, un changement de domaine). En revanche, pendant le développement, cela devient un piège.

Pourquoi cela pose problème pendant la configuration

Imaginez un scénario. Vous configurez une redirection de l’ancienne URL /old-page vers /new-page. Vous paramétrez un 301, vous testez dans le navigateur et cela fonctionne. Une heure plus tard, vous réalisez que vous avez fait une erreur: l’URL correcte est /new-page/v2.

Vous modifiez la règle sur le serveur et vous actualisez la page dans le navigateur. Vous arrivez sur /new-page. Encore une fois. Parce que le navigateur a déjà mémorisé la première paire et ne donne pas au serveur la possibilité de montrer la nouvelle règle.

Vous pensez que la redirection ne fonctionne pas. En réalité, elle fonctionne, mais pas celle que vous venez de configurer.

Sur un site de test, il nous est arrivé de passer une demi-heure à faire défiler des règles .htaccess avant de réaliser que le navigateur affichait le cache. Cache vidé, et tout a immédiatement fonctionné comme prévu.

La situation est pire avec les visiteurs. Si vous avez activé un 301 incorrect sur un site en production, tous ceux qui l’ont visité pendant ces minutes ont reçu la mauvaise règle dans le cache de leur navigateur. Vous avez corrigé l’erreur sur le serveur en 10 minutes, mais leurs navigateurs continueront de les envoyer vers l’ancienne URL pendant des jours ou des semaines, jusqu’à ce que le cache soit vidé.

Remarque: vous ne pouvez pas vider le cache de redirection du côté de l’utilisateur. Aucune astuce serveur ne peut atteindre le navigateur de quelqu’un d’autre.

La stratégie 302 → 301: tester sans conséquence

Une règle qui fait gagner des heures de débogage et protège contre les erreurs sur un site en production:

Commencez toujours par une redirection 302 (temporaire). Ne passez au 301 qu’une fois que vous êtes certain que la règle est correcte.

Le navigateur ne met pas le 302 en cache de manière agressive; il interroge le serveur à nouveau à chaque requête. Modifiez la règle sur le serveur, et le navigateur prend immédiatement en compte le nouveau comportement. Aucun vidage de cache nécessaire.

Approche étape par étape pour tout changement d’URL:

• Mettez en place une redirection 302 dans .htaccess, la configuration Nginx ou via une extension WordPress (par exemple, Redirection).
• Ouvrez l’ancienne URL en mode navigation privée ou avec l’option «Disable cache» activée dans les DevTools.
• Confirmez que vous arrivez sur la bonne page de destination.
• Vérifiez 2 ou 3 URL supplémentaires du même groupe.
• Seulement quand tout est testé, remplacez 302 par 301 dans les règles.
• Faites une vérification finale en mode de navigation normal.

En pratique, cette approche prend exactement deux minutes supplémentaires par groupe de redirections et élimine complètement le risque d’une «erreur en cache» pour les visiteurs.

Si vous utilisez l’extension Redirection pour WordPress, elle crée des 301 par défaut. Passez manuellement en 302 dans le menu déroulant lors de la création d’une règle, et n’oubliez pas de repasser en 301 après le test.

Comment vider le cache de redirection en local

Quand le navigateur a déjà mémorisé un 301 incorrect et que vous ne pouvez pas voir le comportement actuel, voici ce qui aide:

Chrome. Ouvrez les DevTools (F12), allez dans l’onglet Network et cochez Disable cache. Ou faites une réinitialisation complète: Application → Clear storage → Clear site data. La méthode la plus fiable pour un site spécifique est chrome://settings/clearBrowserData → Images et fichiers en cache.

Firefox. Outils de développement web → Network → Disable Cache. Pour un vidage complet: Historique → Effacer l’historique récent → Cache.

Safari. Développement → Désactiver les caches (le menu Développement s’active dans Réglages → Avancés).

Le mode navigation privée est un moyen rapide de vérifier un comportement frais sans vider le cache principal. Le navigateur utilise une session propre, sans redirections sauvegardées.

Nuance importante: fermer le navigateur ne vide PAS le cache de redirection 301. Contrairement au stockage de session, le cache de redirection survit aux redémarrages du navigateur. Seul un vidage explicite ou le mode navigation privée fonctionne.

Que faire si le cache est bloqué chez les utilisateurs

C’est le scénario le plus désagréable: un 301 incorrect a été actif sur le site de production pendant un certain temps, et une partie de votre audience le transporte maintenant dans le cache de son navigateur. Vous avez corrigé la règle serveur, mais ces utilisateurs continuent d’arriver au mauvais endroit.

Voici ce que vous pouvez faire:

• Changer l’URL de destination pour une nouvelle. Si l’ancien location pointait vers /page-v1 et que vous avez besoin de /page-v2, remplacez simplement l’adresse dans la même règle. Les navigateurs ayant l’ancienne URL de destination en cache continueront d’y aller (le problème). En revanche, les nouveaux visiteurs iront au bon endroit. Cela ne résout pas le problème pour ceux déjà «infectés», mais cela arrête la propagation.

• Utiliser une méthode de redirection différente. Si le 301 est en cache, le navigateur n’interroge pas le serveur, mais la logique serveur fonctionne toujours pour les nouveaux visiteurs. Ajoutez une redirection JavaScript sur la page de destination comme couche supplémentaire par-dessus la redirection HTTP pour ceux qui atterrissent encore sur l’ancienne page.

• Reconnaître honnêtement: il n’y a pas de remède direct. Vous ne pouvez pas atteindre le navigateur de l’utilisateur. Si le cache est déjà chargé, le seul moyen de le réinitialiser est que l’utilisateur vide son cache ou visite via un lien en navigation privée. Heureusement, le cache de redirection ne vit pas éternellement: la réinstallation du navigateur, les changements d’appareil et les mises à jour du système d’exploitation finissent par le réinitialiser.

D’après notre expérience, un 301 incorrect ne devient critique que dans deux cas: une migration de masse (des centaines d’URL) avec une erreur dans les règles, ou une redirection de la page d’accueil. Dans les deux cas, le préjudice causé par une erreur en cache dépasse tout gain de temps obtenu en sautant la phase de test.

301, 302, 307, 308: Quand utiliser quoi

Pour éviter toute confusion, gardez à portée de main ce tableau rapide des codes de redirection:

Pour un site WordPress, connaître la différence entre 301 et 302 est suffisant dans la grande majorité des cas. Les codes 307 et 308 sont des outils de niche pour les situations où la conservation de la méthode HTTP est critique (par exemple, un formulaire doit rester une requête POST et ne pas se transformer en GET pendant une redirection).

En bref: le 302 est votre outil de travail pendant le développement. Le 301 est le tampon final «terminé».

Un piège supplémentaire: WordPress et les extensions de cache

Sur WordPress, le problème de cache du 301 se superpose au cache du serveur et des extensions. Une situation typique:

Vous modifiez une redirection dans l’extension Redirection, vous cliquez sur «enregistrer» et cela ne fonctionne pas. Vous videz le cache du navigateur, et l’ancienne page apparaît toujours. Que se passe-t-il? Une extension de cache (WP Rocket, LiteSpeed Cache, W3 Total Cache) a servi une version en cache de la page; le serveur n’a même jamais exécuté la règle de redirection.

Étapes pour déboguer les redirections sur WordPress:

• Videz le cache de l’extension de cache (chaque extension a son propre bouton «Purger tout le cache»).
• Désactivez la mise en cache pendant les tests (dans WP Rocket, c’est le Mode Développement).
• Videz le cache du navigateur (comme décrit ci-dessus).
• Seulement ensuite, testez la redirection.

Sur un site de test, nous gardons l’extension de cache désactivée jusqu’à ce que toutes les redirections soient complètement prêtes et nous ne l’activons qu’après le passage final de 302 à 301.

Cette courte vidéo en anglais montre visuellement la différence entre 301 et 302 en pratique et explique pourquoi le choix du code de redirection affecte le SEO:

⁉️🤔 Foire aux questions

Pourquoi le navigateur met-il en cache le 301 au lieu d’interroger le serveur à chaque fois?

La spécification HTTP définit le 301 comme «la ressource a déménagé de façon permanente». Interroger le serveur à chaque ouverture de l’URL contredirait le sens de «permanente» et créerait une charge inutile. La mise en cache de la redirection économise une requête HTTP par visiteur. À l’échelle de dizaines de milliers de visites, cela accélère sensiblement la navigation. Le navigateur met en cache le fait de la redirection elle-même (la paire «de → vers»), pas le contenu de la page. C’est un type de cache distinct appelé cache de redirection. Chrome le stocke dans le profil utilisateur; Firefox le stocke dans le fichier places.sqlite avec l’historique de navigation. C’est pourquoi vider le cache des images et des scripts ne réinitialise pas toujours les redirections; vous avez besoin d’un vidage complet ou d’effacer les données de site.

Peut-on empêcher le navigateur de mettre en cache le 301 côté serveur?

Formellement, non. Les navigateurs peuvent ignorer l’en-tête Cache-Control: no-store pour les redirections permanentes. La spécification n’oblige pas les navigateurs à respecter Cache-Control pour les 301/308, puisqu’une redirection permanente implique que la règle ne changera pas. Certaines versions de Chrome et Firefox respectent Cache-Control pour le 301, mais vous ne pouvez pas vous y fier en production; le comportement n’est pas garanti et varie selon les versions. La seule façon fiable d’«annuler» la mise en cache navigateur d’un 301 est d’utiliser initialement un 302 pendant les tests. Si un 301 est déjà en cache chez l’utilisateur, le serveur est impuissant.

En quoi le 302 diffère-t-il du 307 en pratique?

Les deux sont des redirections temporaires, et aucun des deux n’est mis en cache par le navigateur. La différence réside dans la gestion de la méthode HTTP. Avec le 302, le navigateur peut transformer une requête POST en GET pendant la redirection (cela s’est produit historiquement, et de nombreux navigateurs le font encore). Avec le 307, la méthode est garantie d’être conservée: POST reste POST, PUT reste PUT. Pour WordPress et pratiquement n’importe quel site, la différence est négligeable puisque les redirections concernent presque toujours des requêtes GET (ouverture de page). Le 307 n’est nécessaire que si des formulaires, des API ou des téléversements de fichiers transitent par une URL que vous redirigez temporairement.

Comment puis-je vérifier quelle redirection est en cache dans mon navigateur?

Ouvrez les DevTools (F12) → onglet Network, et cochez «Disable cache» (c’est OBLIGATOIRE, sinon le navigateur ne fera pas de requête au serveur et vous ne verrez pas la réponse actuelle). Ouvrez ensuite l’ancienne URL. Dans la colonne Status, vous verrez le code de réponse réel du serveur (301, 302, etc.) et l’en-tête Location avec l’URL de destination. Sans «Disable cache», les DevTools afficheront un statut 200 ou (disk cache), ce qui signifie que le navigateur a servi depuis le cache et que le serveur n’a pas été interrogé.

Faut-il conserver une redirection 301 pour toujours?

Google recommande de conserver les redirections permanentes pendant au moins un an après un déménagement. En pratique, si l’ancienne URL n’est plus promue, n’a pas de liens externes et n’est pas indexée, la redirection peut être supprimée après 6 à 12 mois. Cependant, si d’autres sites pointaient vers l’ancienne URL ou si elle est présente dans les index des moteurs de recherche, vous devriez conserver la redirection de façon permanente. Supprimer un 301 avec une règle en cache chez les utilisateurs ne résoudra pas le problème; leurs navigateurs continueront d’utiliser la paire en cache jusqu’à ce qu’ils vident le cache.

Faut-il avoir peur des redirections 301?

Non, si vous suivez la règle du «302 d’abord». Une redirection permanente est un outil fiable pour déplacer du contenu, changer de domaine et nettoyer les doublons. Les problèmes ne surviennent que lorsque le 301 est mis en place sans test.

Rappelez-vous le point clé: le 301 est une promesse faite au navigateur que «je ne changerai pas d’avis». Ne faites pas cette promesse tant que vous n’êtes pas certain. Dix minutes à tester une redirection 302 en navigation privée vous feront gagner des jours de nettoyage d’erreurs en cache pour votre audience réelle.