Vous avez déjà vu ce message : « Cette page web a provoqué trop de redirections ». Souvent après une migration, un passage en HTTPS, ou une réécriture d'URL qu'on croyait propre. Et là, vous cliquez sur votre propre lien, l'onglet mouline, le navigateur abandonne. Le site est vivant pour Googlebot, cassé pour l'humain.
Ce que je vois le plus souvent, ce n'est pas une grosse erreur franche. C'est un empilement de petites règles ajoutées à six mois d'intervalle, chacune logique prise seule, toxique en groupe. Une règle dans le .htaccess, une dans le CMS, une dans le plugin de langue, une au niveau du CDN. Personne ne les relit ensemble. Et le jour où deux d'entre elles se répondent, on a une boucle.
Points clés à retenir
- Une boucle de redirection, c'est un cycle : une URL qui revient vers elle-même après plusieurs sauts, pas une simple chaîne.
- Le diagnostic passe par la trace brute des réponses HTTP, sans cache ni cookie, en notant à quel saut l'adresse répète.
- Les causes les plus fréquentes : HTTPS forcé en double, règle de slash final contradictoire, cache ou proxy mal configuré, redirection de langue qui renvoie vers la version d'origine.
- Un audit se fait en trois temps : crawl complet, filtrage des chaînes, test unitaire des cas suspects en ligne de commande.
- Le coût d'une boucle n'est pas seulement humain : elle consomme votre budget de crawl et peut retirer des pages de l'index.
- La prévention tient à une règle simple : une redirection ne doit jamais dépendre d'une condition qui peut redevenir vraie.
Auditer ses redirections : d'abord comprendre ce qu'est vraiment une boucle
Beaucoup d'articles mélangent deux choses très différentes. Il faut les séparer, sinon l'audit part dans le mur dès la première heure.
Boucle ou chaîne : la distinction qui change tout
Une chaîne de redirection, c'est A → B → C → D. Pénible, coûteux en performance, mais ça finit par aboutir. Une boucle, c'est A → B → A. Le navigateur ne peut pas aboutir, il tourne, puis il crache son erreur après une limite qu'il s'est fixée lui-même.
La différence n'est pas cosmétique. Sur une chaîne, vous pouvez laisser le problème en place trois semaines sans catastrophe. Sur une boucle, la page est inaccessible, point. J'ai vu une boutique en ligne perdre une catégorie entière pendant onze jours parce que personne n'avait cliqué sur le lien après une mise à jour de la structure d'URL. Onze jours. Le service marketing a mis ça sur le dos de la saisonnalité.
Le rôle des codes de statut dans le cycle
Un cycle peut se former avec presque n'importe quel code de la famille 3xx. Le plus classique associe un 301 (permanent) et un 302 (temporaire) qui se renvoient la balle. Mais on voit aussi des 307 et 308 s'ajouter au mélange dès qu'un outil de déploiement décide de forcer le protocole.
| Code | Comportement attendu | Piège fréquent en cas de boucle |
|---|---|---|
| 301 | Permanent, mis en cache fortement par le navigateur | Une fois en cache, la boucle persiste même après correction côté serveur |
| 302 | Temporaire, peu mis en cache | Utilisé pour un changement définitif, il crée des allers-retours avec un 301 existant |
| 307 / 308 | Préservent la méthode HTTP et le corps de la requête | Ajoutés automatiquement par le CDN ou le load balancer, invisibles dans le .htaccess |
Retenez ça : une boucle n'est pas toujours dans votre fichier de configuration. Elle peut vivre dans la couche que vous ne voyez pas.
La méthode d'audit pas-à-pas
Voici comment je procède, dans cet ordre. Changer l'ordre fait perdre du temps.
Étape 1 : crawler l'intégralité du site
Un crawl complet avec un outil type Screaming Frog ou une solution en ligne reste la base. L'objectif n'est pas de tout regarder, c'est d'obtenir la liste exhaustive des URL et de leurs réponses. Sur un site de dix mille pages, comptez une bonne heure selon la vitesse du serveur.
Une fois le crawl terminé, deux filtres sont indispensables :
- Redirect Chains : toutes les URLs qui passent par plus d'un saut avant d'arriver à destination.
- Redirect Loop : celles qui n'arrivent jamais. Sur Screaming Frog, elles remontent avec un statut d'erreur explicite.
Ne sautez pas l'export CSV. C'est en triant à la main qu'on repère les motifs. Sur un audit récent, j'ai trouvé quatre-vingts règles qui redirigeaient toutes vers la même page, chacune écrite par une personne différente à des moments différents. Personne ne l'avait jamais vu, parce que personne n'avait jamais trié la colonne « destination ».
Étape 2 : tester les cas suspects en ligne de commande
Le crawl vous donne des suspects. La ligne de commande vous donne la preuve. C'est ici que se joue l'information vraiment utile, celle que la plupart des guides oublient.
La commande de base :
curl -I -L --max-redirs 10 https://exemple.com/page
Décomposons. Le -I demande uniquement les en-têtes, ce qui évite de télécharger tout le contenu. Le -L suit les redirections. Le --max-redirs 10 plafonne le nombre de sauts : si la boucle existe, curl s'arrête et vous affiche chaque étape avant d'abandonner.
Sur une chaîne saine, vous verrez deux ou trois blocs de réponse, puis un HTTP/2 200. Sur une boucle, vous verrez la même URL réapparaître. Et là, vous notez à quel saut exact le cycle commence. C'est votre point de rupture.
Pour une vue encore plus propre, sans cache navigateur ni cookie résiduel :
curl -I -L --max-redirs 10 -H "Cache-Control: no-cache" -H "Cookie:" https://exemple.com/page
L'option pour vider le cookie est volontairement laissée vide. Elle sert à tester ce que voit un visiteur tout neuf, celui que Googlebot simule.
Étape 3 : vérifier dans l'onglet Réseau du navigateur
La ligne de commande ne dit pas tout. Elle ignore ce que fait le service worker, ni comment le JavaScript manipule l'historique. Pour ça, ouvrez l'onglet Réseau des outils de développement, cochez « Conserver le journal », puis rechargez en cochant « Désactiver le cache ». Vous verrez la cascade complète, y compris les redirections déclenchées côté client.
Le cas classique : une application monopage qui redirige vers une route, laquelle déclenche un contrôle d'authentification, qui renvoie vers la route d'origine. Le serveur n'a rien à voir. C'est du code front qui boucle. Aucun crawl ne le verra.
Les trois causes que je rencontre le plus souvent
Le HTTPS forcé en double
Vous avez une règle au niveau du serveur qui redirige tout le HTTP vers HTTPS. Puis un CDN qui applique la même politique. Puis un plugin qui refait le travail. Trois couches identiques. En théorie, la première s'applique et les autres ne trouvent rien à rediriger. En pratique, si une seule couche compare mal le protocole, elle envoie une requête déjà en HTTPS vers une règle qui la renvoie en HTTP. Boucle.
Le test est bête : appelez directement l'URL en HTTPS et regardez si vous recevez un 200 ou un 301 vers la même adresse. Si c'est un 301, le problème est là.
Le slash final contradictoire
Une règle ajoute un slash final. Une autre le retire. Elles se rencontrent sur chaque URL. C'est l'erreur la plus stupide et la plus répandue, parce que les deux règles ont souvent été écrites par la même personne à un an d'écart.
Sur exemple.com/page et exemple.com/page/, vous devez avoir une seule version canonique, et une seule règle qui y mène. Pas deux.
La redirection de langue qui renvoie à l'expéditeur
Un site multilingue détecte la langue du navigateur et redirige vers /fr/ ou /en/. Si la détection se base sur un cookie qui n'est jamais posé, ou sur un en-tête que le visiteur ne renvoie pas, la page d'accueil redirige vers la version française, qui redirige vers l'accueil, qui redirige à nouveau. J'ai eu ce cas précis sur un projet client : la détection reposait sur un cookie qui n'était écrit qu'après acceptation de la bannière de consentement. Avant clic, boucle infinie. Après clic, tout allait bien. Le bug n'était visible que pour les nouveaux visiteurs, c'est-à-dire ceux que le référencement amène.
La correction tenait en une ligne : une redirection de langue ne doit jamais s'appliquer à la page vers laquelle elle renvoie.
Ce qu'une boucle coûte réellement
On sous-estime presque toujours l'impact. Ce n'est pas juste une page qui ne s'affiche pas.
- Budget de crawl gaspillé : chaque passage de robot sur une boucle consomme des ressources sans rien rapporter. Sur un grand site, ça peut retarder la découverte de nouvelles pages de plusieurs jours.
- Pages retirées de l'index : une URL inaccessible de façon persistante finit par être exclue. Le trafic tombe. Souvent sans alerte, parce que rien ne casse techniquement.
- Perte d'équité de liens : les liens internes qui pointent vers la boucle n'apportent plus rien.
- Le pire : la normalisation silencieuse. Une page qui boucle depuis des mois peut avoir été considérée comme volontairement absente. La récupérer demande parfois une action manuelle pour re-demander l'indexation.
Un détail que peu de gens vérifient : une boucle corrigée côté serveur peut continuer à se manifester chez certains visiteurs. Le navigateur a mis en cache le 301 permanent. Il continuera à rediriger sans jamais interroger le serveur. Le test propre consiste à vider le cache ou à utiliser une fenêtre de navigation privée pour confirmer la correction.
Erreurs que je vois en audit et questions qu'on me pose
« Il y a eu trop de redirections » : que signifie ce message exactement ?
C'est le navigateur qui abandonne. Chaque navigateur fixe sa propre limite de sauts avant de couper court, et ce plafond n'est pas le même partout. Le message signifie une seule chose : la chaîne n'a jamais atteint une page finale. La cause est toujours un cycle, jamais un problème de vitesse. Retenez-le, parce que ça élimine d'emblée toute une série de fausses pistes (serveur lent, problème de réseau, panne d'hébergement).
« Répétition des redirections détectées » : c'est grave ?
Oui, plus qu'on ne le croit. Un robot d'indexation qui détecte ce signal arrête son exploration de l'URL. Il ne va pas insister. Le problème n'est pas tant qu'il ne voie pas la page, c'est qu'il note qu'il y a quelque chose d'anormal sur ce domaine. Multiplié sur plusieurs dizaines d'URL, ce signal finit par affecter la perception générale du site.
Le message ERR_CACHE_MISS après un formulaire, c'est lié ?
Pas directement. C'est une erreur distincte, mais on la confond souvent avec un problème de redirection parce qu'elle apparaît dans le même contexte : vous soumettez un formulaire, une redirection s'opère, puis vous rechargez la page et le navigateur réclame de renvoyer les données. Le message vous demande de confirmer le nouvel envoi du formulaire.
La bonne pratique : après soumission, redirigez vers une page de confirmation en GET. C'est le principe du « Post/Redirect/Get ». La redirection doit être un 303, pas un 302 ni un 301. Le 303 dit explicitement au navigateur de changer de méthode. Un 302 ordinaire peut laisser le doute et provoquer ce message au rechargement. Une seule ligne dans le code, et ce problème disparaît définitivement.
Trop de redirection HTTP : comment isoler la couche responsable ?
En testant les couches une par une, dans l'ordre inverse de la requête. Appelez directement l'origine du serveur, sans passer par le CDN. Si la boucle disparaît, elle est dans le CDN. Elle réapparaît derrière le CDN ? Elle est au niveau du serveur ou du CMS. Puis désactivez les plugins de réécriture d'URL un par un, en testant après chaque désactivation. C'est fastidieux, mais c'est la seule méthode fiable. Un test isolé prend deux minutes ; chercher à l'aveugle prend deux jours.
Comment ne plus jamais avoir à chercher
La prévention tient à une discipline, pas à un outil.
Ce que j'ai fini par imposer sur mes projets : une convention de nommage des règles. Chaque règle de redirection porte un commentaire qui indique sa date, son auteur et sa raison. Ça paraît infantile. Ça m'a fait gagner des heures. Quand une boucle apparaît six mois plus tard, on sait immédiatement qui a écrit quoi, et pourquoi.
La deuxième règle : une redirection ne doit jamais reposer sur une condition qui peut redevenir vraie. Si votre règle dit « si le visiteur n'est pas en HTTPS, le rediriger », et qu'un élément en amont casse ce test, la boucle est structurelle. La condition de sortie doit se baser sur un état définitif : l'URL finale, un drapeau qui ne se réinitialise pas.
Enfin, intégrez le crawl de redirections à votre routine de déploiement. Pas un audit annuel. Un crawl automatique après chaque mise en production, qui compare le rapport de la veille et signale les nouvelles chaînes. La plupart des outils de crawl proposent une comparaison entre deux exécutions. Ce simple écart entre deux runs attrape les régressions le jour même, au lieu de six mois plus tard.
Vous n'éviterez probablement pas toutes les boucles. Il en existera toujours une, quelque part, dans une couche que vous ne soupçonniez pas. La vraie question n'est pas de les empêcher. C'est de réduire le délai entre leur apparition et leur détection. Chaque jour gagné, c'est une catégorie qui reste indexée, un formulaire qui ne se bloque pas, un visiteur qui n'abandonne pas avant d'avoir vu votre contenu.
