La redirection 301 ne fonctionne pas ? 6 causes courantes et solutions

Vous avez configuré une redirection de domaine, attendu la propagation, testé l’ancienne URL — et rien ne se passe. La page reste identique, renvoie une erreur ou boucle indéfiniment.

Les échecs de redirection sont frustrants, et ils vous coûtent bien plus que du temps. Chaque redirection cassée signifie du trafic perdu, des backlinks brisés et une mauvaise expérience pour quiconque clique sur un ancien lien. Pour les entreprises qui dépendent du référencement naturel, une redirection mal configurée peut faire perdre discrètement de la valeur SEO pendant des semaines avant que quelqu’un ne s’en aperçoive.

La bonne nouvelle : la plupart des échecs de redirection proviennent seulement de quelques causes. Ce guide passe en revue chacune d’elles, des problèmes DNS aux erreurs de configuration du serveur, avec des étapes concrètes pour diagnostiquer et corriger le problème.

#1 Le DNS n’a pas encore propagé#

Le problème : Vous avez pointé les enregistrements DNS de votre domaine vers le service de redirection ou le nouveau serveur, mais les visiteurs voient toujours l’ancien site.

Pourquoi cela arrive : Les changements DNS ne prennent pas effet instantanément. Chaque enregistrement DNS possède une valeur TTL (Time to Live) — généralement de 300 secondes (5 minutes) à 86 400 secondes (24 heures). Tant que l’ancien TTL n’a pas expiré partout dans le monde, les résolveurs DNS sur internet continuent de servir l’ancienne adresse IP.

Comment diagnostiquer :

• Exécutez dig example.com dans votre terminal et vérifiez la section ANSWER — l’adresse IP est-elle l’ancienne ou la nouvelle ?
• Utilisez un vérificateur mondial de propagation DNS comme whatsmydns.net pour voir l’état de la propagation dans différentes régions
• Vérifiez le TTL de votre domaine dans les paramètres de votre fournisseur DNS

Comment corriger :

• Réduisez le TTL avant le changement prévu et laissez d’abord expirer l’ancien TTL. Le réduire après que les résolveurs ont mis en cache l’ancien enregistrement ne raccourcit pas cette entrée de cache existante.
• Comparez la réponse DNS faisant autorité avec les réponses des résolveurs récursifs. Le délai dépend du TTL précédent et du fournisseur ; attendre un nombre fixe d’heures ne prouve pas que les enregistrements sont corrects.
• Si la propagation semble bloquée, vérifiez que vous avez mis à jour les enregistrements אצל le bon fournisseur DNS (celui vers lequel pointent vos serveurs de noms, pas nécessairement votre registraire de domaine)

#2 Erreurs de syntaxe .htaccess#

Le problème : Vous avez ajouté une règle de redirection à votre fichier .htaccess, mais le serveur renvoie une erreur interne 500, ignore complètement la règle ou l’applique incorrectement.

Pourquoi cela se produit : mod_rewrite d’Apache est puissant mais impitoyable. Un seul espace manquant, un indicateur incorrect ou une règle en conflit peut casser toute la configuration. Les erreurs courantes incluent :

• Absence de RewriteEngine On en haut du bloc de règles
• Utiliser http:// au lieu de https:// dans l’URL de destination
• Vérifiez la syntaxe de la directive que vous utilisez. Dans un modèle RewriteRule .htaccess par répertoire, Apache supprime le slash initial ; les règles dans d’autres contextes peuvent se comporter différemment.
• Règles conflictuelles qui se remplacent mutuellement en raison de l’ordre

Comment diagnostiquer :

• Consultez le journal d’erreurs de votre serveur — Apache consigne les numéros de ligne exacts pour les erreurs de syntaxe
• Renommez temporairement .htaccess en autre chose — si l’erreur disparaît, votre .htaccess est en cause

Comment corriger :

• Commencez par une règle minimale et testez avant d’ajouter de la complexité
• Syntaxe correcte pour une redirection 301 de base :

apacheRedirect 301 /old-page https://example.com/new-page

• Pour les redirections basées sur des regex avec mod_rewrite :

apacheRewriteEngine On
RewriteRule ^old-path/(.*)$ https://example.com/new-path/$1 [R=301,L]

• Si votre site fonctionne sur Nginx au lieu d’Apache, les fichiers .htaccess sont entièrement ignorés — vous devez ajouter les règles dans la configuration du bloc serveur à la place

#3 Chaîne ou boucle de redirection#

Le problème : La redirection démarre mais n’atteint jamais la destination — le navigateur affiche finalement « trop de redirections » ou la page met une éternité à charger.

Pourquoi cela se produit : Une chaîne de redirection se produit lorsque l’URL A redirige vers B, B redirige vers C, et ainsi de suite. Une boucle se produit lorsque la chaîne revient à une URL précédente. Les deux sont courantes lors des migrations de site web lorsque d’anciennes redirections et de nouvelles redirections se chevauchent sans nettoyage.

Comment diagnostiquer :

• Ouvrez Chrome DevTools → onglet Network → rechargez la page — examinez la chaîne de requêtes 3xx
• Si vous voyez la même URL apparaître deux fois dans la chaîne, c’est une boucle
• Entrez l’URL dans notre test de vitesse de redirection pour voir chaque saut, son code de statut et sa destination finale

Comment corriger :

• Cartographiez toutes vos règles de redirection actives — dans .htaccess, les plugins CMS, les règles en périphérie du CDN et l’outil de gestion des redirections
• Supprimez les règles intermédiaires qui ne sont plus nécessaires. Regroupez les chaînes en une seule redirection directe (A → D au lieu de A → B → C → D)
• Si vous utilisez WordPress, vérifiez tous les plugins actifs — les plugins de cache, de SEO et de sécurité peuvent tous ajouter des règles de redirection conflictuelles

#4 Fantômes du cache#

Le problème : Vous avez mis à jour ou supprimé une redirection, mais les visiteurs sont toujours redirigés vers l’ancienne destination.

Pourquoi cela se produit : Les navigateurs, les nœuds en périphérie du CDN et les caches au niveau du serveur mettent agressivement en cache les redirections 301. Une fois qu’un navigateur a vu une 301, il peut mémoriser cette redirection indéfiniment — même après que vous l’avez modifiée. Il en va de même pour les caches CDN comme Cloudflare, qui peuvent diffuser des réponses de redirection obsolètes depuis les nœuds en périphérie.

Comment diagnostiquer :

• Comparez un résultat en fenêtre privée avec une session normale et une requête en ligne de commande. Une différence suggère un état du navigateur ou un cache, mais ce n’est pas en soi un diagnostic complet.
• Utilisez curl -I https://example.com/old-page pour voir les en-têtes de réponse réels du serveur sans interférence du navigateur
• Vérifiez les en-têtes Cache-Control et Age dans la réponse

Comment corriger :

• Videz les images et fichiers mis en cache par votre navigateur, ou continuez les tests dans une fenêtre privée
• Purgez le cache de votre CDN pour l’ancienne URL ; la plupart des CDN permettent de purger une seule URL
• Pour les redirections futures, utilisez 302 (temporaire) pendant les tests, puis passez à 301 (permanente) uniquement lorsque vous êtes sûr que la destination est correcte
• Ajoutez des en-têtes de cache explicites : Cache-Control: no-cache, max-age=0 pour les redirections que vous prévoyez de modifier

#5 Problèmes de mélange HTTP/HTTPS#

Le problème : Votre cible de redirection utilise HTTPS, mais la redirection envoie le trafic vers la version HTTP, ou inversement. Les visiteurs voient un avertissement de certificat ou une page cassée.

Pourquoi cela se produit : C’est l’un des modes d’échec de redirection les plus souvent négligés. Vous avez configuré une redirection de http://old-domain.com vers http://new-domain.com, mais le nouveau domaine impose HTTPS via HSTS. Le navigateur effectue une redirection, puis est immédiatement redirigé à nouveau vers HTTPS — ou pire, la version HTTPS de l’ancien domaine possède un certificat expiré ou non مطابقé.

Comment diagnostiquer :

• Vérifiez à la fois les versions http:// et https:// de votre URL source
• Recherchez des avertissements de contenu mixte dans la console du navigateur
• Vérifiez si HSTS est appliqué (vérifiez l’en-tête de réponse Strict-Transport-Security)

Comment corriger :

• Redirigez toujours vers l’URL HTTPS complète : https://new-domain.com/page au lieu de simplement new-domain.com/page
• Assurez-vous que chaque domaine de la chaîne dispose d’un certificat SSL valide installé
• Si vous redirigez depuis un ancien domaine, assurez-vous que l’ancien domaine dispose également d’une couverture SSL — même s’il ne sert que des redirections
• Utilisez partout dans vos règles de redirection un protocole canonique unique (toujours HTTPS)

#6 Type de redirection incorrect#

Le problème : Votre redirection fonctionne, mais les moteurs de recherche ne transmettent pas d’autorité de lien, ou les visiteurs ne peuvent pas enregistrer correctement la destination dans leurs favoris.

Pourquoi cela se produit : Différents codes d’état HTTP indiquent aux navigateurs et aux moteurs de recherche différentes choses concernant la redirection :

• 301 (Déplacé définitivement) : Transfère la majeure partie de l’autorité des liens. À utiliser pour les déplacements permanents comme les changements de domaine ou la restructuration
• 302 (Trouvé) : Temporaire. Google conserve généralement l’ancienne URL indexée, donc les signaux de classement y restent. À utiliser uniquement pour des redirections temporaires comme des tests A/B ou des pages d’atterrissage saisonnières
• 307 (Redirection temporaire) : Similaire au 302 mais conserve la méthode HTTP. Utilisé pour des redirections temporaires d’API
• Meta refresh : une redirection HTML, pas HTTP. Google interprète un meta refresh instantané (0 seconde) comme permanent et un retardé comme temporaire, mais cela ne fonctionne qu’après le chargement de la page, donc utilisez une redirection côté serveur quand c’est possible

Comment diagnostiquer :

• Vérifiez le code d’état de la réponse à l’aide de curl -I https://example.com/old-page
• Recherchez l’en-tête Location et le code d’état 3xx dans la première ligne de la réponse

Comment corriger :

• Utilisez 301 ou 308 pour les déplacements permanents vers un remplacement pertinent. Si une page est supprimée sans remplacement approprié, un 404 ou un 410 peut être plus adapté qu’une redirection non pertinente.
• Utilisez 302 ou 307 uniquement pour des redirections réellement temporaires (promotions, pages de maintenance, tests A/B)
• Évitez les méta-rafraîchissements (<meta http-equiv="refresh">) pour les URLs importantes ; utilisez plutôt une vraie redirection HTTP 301
• Choisissez le code de statut selon que le déplacement est permanent ou temporaire, puis vérifiez le comportement. Ne supposez pas que chaque réponse temporaire entraîne une perte fixe de valeur SEO.

Comment prévenir les échecs de redirection#

Le cycle de diagnostic et de correction des problèmes de redirection prend du temps. Voici comment en éviter la plupart dès le départ :

• Testez avec curl avant le lancement : Exécutez curl -IL https://source-url.com pour vérifier toute la chaîne de redirection avant d’annoncer un changement d’URL
• Conservez une carte des redirections : Documentez chaque règle de redirection. Lorsque vous migrez ou restructurez, mettez à jour la carte. Cela évite les chaînes accidentelles et les règles orphelines
• Utilisez une plateforme dédiée à la gestion des redirections : Gérer les redirections via .htaccess, des plugins WordPress ou des fichiers de configuration du serveur fonctionne — jusqu’au moment où cela ne fonctionne plus. Lorsque vous avez des dizaines ou des centaines de redirections, l’approche manuelle génère des erreurs. Une plateforme dédiée vous offre un débogage visuel des chaînes de redirection, la gestion automatique de HTTPS, des analyses du trafic de redirection, l’importation et l’exportation en masse, ainsi que des journaux d’audit pour suivre les modifications.
• Définissez des TTL faibles avant d’effectuer des changements DNS : Réduisez votre TTL à 300 secondes au moins 24 heures avant toute mise à jour DNS planifiée
• Testez dans un environnement de préproduction : Ne déployez jamais des changements de redirection directement en production sans tester l’ensemble du parcours
• Associez chaque ancienne URL à sa nouvelle page la plus proche : tout envoyer vers la page d’accueil « fonctionne » techniquement, mais les visiteurs et les moteurs de recherche perdent la page qu’ils recherchaient

L’approche RedirHub : évitez les suppositions#

Des échecs de redirection peuvent se produire avec n’importe quelle configuration. Un service géré peut réduire la configuration serveur que vous exploitez, mais les enregistrements DNS, les prérequis des certificats, les réponses mises en cache et la disponibilité de la destination doivent toujours être surveillés.

RedirHub répond aux redirections depuis son propre réseau en périphérie, séparé de votre serveur web. Il n’y a aucun fichier .htaccess à casser et aucun serveur à redémarrer lorsque vous ajoutez une règle. Vous gérez les redirections dans un tableau de bord, le HTTPS est émis automatiquement avec des certificats SSL gratuits pour le domaine racine et www, et les migrations importantes peuvent être importées via un import CSV de redirections au lieu de règles rédigées à la main.

Voici comment cela se traduit par rapport aux causes ci-dessus :

• Configuration DNS : utilisez les valeurs requises dans Connect DNS. Les domaines racines utilisent les enregistrements A et TXT de vérification indiqués ; les sous-domaines pris en charge utilisent CNAME. Les entrées de cache DNS existantes doivent toujours expirer.
• Erreurs .htaccess : il n’y a aucune configuration serveur à modifier. Vous renseignez Redirect from, Redirect to et Redirect type, et What happens prévisualise où les URL d’exemple aboutiront avant l’enregistrement.
• Chaînes : chaque redirection se trouve dans une seule liste Links, vous pouvez donc pointer les anciennes URL directement vers la destination finale au lieu d’empiler des règles à plusieurs endroits.
• Mise en cache : les modifications prennent effet de notre côté dès que vous les enregistrez. Les navigateurs qui ont déjà mis en cache une ancienne redirection 301 peuvent encore la retenir ; testez donc les changements dans une fenêtre privée ou avec curl.
• HTTPS : les certificats sont émis et renouvelés automatiquement pour le domaine racine et www, de sorte que l’ancien domaine fonctionne aussi en https://.
• Codes d’état : choisissez 301, 302, 307 ou 308 pour chaque redirection, et consultez le code à côté de chaque URL d’exemple avant de la créer.

Si vous avez un seul site sur un serveur que vous contrôlez, corriger la règle là-bas est gratuit et rapide. Un service de redirection est rentable lorsque vous gérez de nombreux domaines ou une migration de site avec des milliers d’URL, où les règles maintenues manuellement sont sujettes aux chaînes de redirection et aux fautes de frappe. Les forfaits commencent à 49 $/mois (Core) avec un essai gratuit de 14 jours.

Liste de contrôle de référence rapide#

• Le DNS de l’ancien domaine pointe-t-il vers l’endroit où la redirection est configurée ? (dig ou un vérificateur DNS)
• curl -IL https://old-url affiche-t-il un 301 au premier saut et la bonne URL finale ?
• http://, https://, www et non-www redirigent-ils tous ?
• N’y a-t-il qu’un seul saut vers l’URL finale, sans boucle ?
• L’ancien domaine dispose-t-il d’un certificat valide ?
• Avez-vous testé dans une fenêtre privée pour écarter une redirection mise en cache ?
• Chaque ancienne page mène-t-elle à sa nouvelle page correspondante, et non à la page d’accueil ?

Bloqué(e) encore ? Parfois, le problème est au niveau de l’infrastructure — règles CDN en conflit, réécritures côté serveur qui écrasent les règles au niveau de l’application, ou paramètres DNS au niveau du registre. Si vous avez parcouru cette checklist et que la redirection ne fonctionne toujours pas, un outil visuel de diagnostic des redirections peut vous montrer exactement ce qui se passe à chaque étape.