Boucles de redirection

TL;DR — Une boucle de redirection se produit lorsque vos redirections tournent en rond : la page A envoie vers la page B, qui renvoie aussitôt vers A. Rien ne se charge ; le navigateur abandonne et affiche « trop de redirections ». Pour les visiteurs, le site est hors service : corrigez cela avant toute autre chose.

Qu’est-ce qu’une boucle de redirection ?

Une boucle de redirection est un cycle dans lequel les cibles finissent par revenir à une URL précédente au lieu d’atteindre une ressource finale. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 RFC 9110: Redirection Google classe les boucles parmi les erreurs de redirection qui empêchent le traitement d’aboutir. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Google: Page indexing report Le retour de la même URL constitue un indice fort, mais pas une preuve automatique : l’authentification, le choix de langue ou de consentement et les cookies peuvent parfois modifier la réponse lors du passage suivant. En cas de doute, retestez exactement la même URL dans les mêmes conditions (session, cookies et langue) avant de conclure à une véritable boucle.

Une redirection est une règle qui envoie un visiteur d’une adresse à une autre. C’est normal lorsque vous déplacez une page et redirigez l’ancienne URL vers la nouvelle.

Une boucle de redirection apparaît lorsque ces règles se renvoient l’une vers l’autre sans jamais atteindre une page réelle. Dans le cas le plus simple :

• Vous consultez A, qui vous redirige vers B.
• B vous redirige vers A.
• A vous renvoie de nouveau vers B… indéfiniment.

La page ne se charge jamais. Après plusieurs redirections, le navigateur détecte le cycle et s’arrête sur une erreur. Chrome affiche ERR_TOO_MANY_REDIRECTS ; Firefox, Safari et Edge présentent leur propre version du message « la page n’est pas redirigée correctement » ou « trop de redirections ».

Pourquoi est-ce urgent ?

Commençons par ce que l’on sous-estime le plus : une boucle de redirection rend la page totalement inaccessible aux visiteurs. Il ne s’agit ni d’une page lente ni d’un problème SEO mineur, mais d’une panne pour quiconque consulte l’URL. Si elle touche tout le site, ce qui arrive notamment avec certains réglages SSL, l’ensemble du site reste indisponible jusqu’à la correction.

Les moteurs de recherche sont eux aussi touchés : Google ne peut pas indexer une page qu’il n’atteint jamais. Mais l’urgence reste l’indisponibilité pour les visiteurs.

Les premiers contrôles rapides

Certaines boucles se corrigent vite, d’autres non. Commencez ici :

1. Essayez une fenêtre privée. Si la boucle ne se produit que dans votre navigateur habituel mais pas en navigation privée, un cache ou un cookie local est probablement périmé : effacez les données du site. Si elle se reproduit aussi en navigation privée, le problème se situe côté serveur et vider le cache ne changera rien.
2. Venez-vous de modifier quelque chose ? Nouveau certificat SSL, service de sécurité ou CDN comme Cloudflare, nouvelle extension WordPress, modification de .htaccess ? Ce changement est très probablement en cause. L’annuler constitue souvent le correctif le plus rapide.
3. Le problème concerne-t-il uniquement HTTPS ? Si http:// fonctionne mais que https:// boucle, ou l’inverse, deux règles HTTPS sont presque certainement en conflit. L’onglet Avancé donne le correctif précis. Cette cause est particulièrement bien documentée lorsqu’un CDN se trouve devant le site.

Le bon correctif dépend de la cause de la boucle : il n’existe pas de réponse unique consistant à « vérifier les redirections ». Passez à l’onglet Avancé pour les causes, le diagnostic en ligne de commande et les correctifs propres à chaque plateforme, ou ouvrez l’onglet Arbres de décision pour rechercher la cause étape par étape.

TL;DR — Une boucle de redirection est un cycle (A → B → A, ou plus long) qui ne renvoie jamais de 200. Une chaîne est lente mais aboutit ; une boucle est rompue, si bien qu’augmenter la limite de sauts ne la corrige jamais. Le navigateur affiche ERR_TOO_MANY_REDIRECTS et Search Console la classe parmi quatre causes documentées d’« Erreur de redirection ». Elle nuit aux utilisateurs, aux robots d’exploration et à votre serveur. Une cause bien documentée est un désaccord de mode HTTPS/SSL entre le CDN ou proxy et l’origine ; d’autres incluent des règles www/non-www opposées, un conflit entre extension et serveur, ou un bug de slash final. Aucune cause n’est universellement la plus fréquente. Le correctif dépend toujours de la cause.

Une boucle est un cycle, pas une longue chaîne

Sa propriété essentielle est le routage cyclique, et non un nombre précis de sauts. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 RFC 9110: Redirection Le libellé de Search Console décrit le chemin de redirection en échec, pas la couche de configuration qui l’a créé. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Google: Page indexing report Une URL répétée est un indice fort, mais pas une preuve automatique : l’authentification, le consentement, la langue, les cookies ou les en-têtes peuvent varier. Confirmez le cycle dans des conditions matériellement équivalentes — même session, mêmes cookies, même langue — avant de modifier une règle.

Cette distinction explique tout le reste. Dans mon guide Ahrefs sur les redirections, je définis les boucles comme des suites infinies qui se produisent lorsqu’une URL se redirige vers elle-même ou qu’une URL de la chaîne renvoie vers une URL déjà rencontrée.

Une chaîne de redirections (A → B → C → D → destination) est un chemin simplement trop long. Elle finit par atteindre une page qui renvoie 200. Elle est lente et mérite d’être raccourcie, mais elle aboutit.

Une boucle est un cercle : A → B → A. Elle n’atteint jamais un 200, quel que soit le nombre de sauts suivis. « Augmenter la limite de redirections » ne constitue donc pas un correctif. La boucle ne casse pas parce que le navigateur manque de patience, mais parce qu’aucune destination n’existe. Il faut rompre le cycle.

Comment une boucle se manifeste

Dans le navigateur. Chrome affiche ERR_TOO_MANY_REDIRECTS. Firefox indique « La page n’est pas redirigée correctement » ; Safari et Edge affichent leur propre message signalant un trop grand nombre de redirections. La formulation change, pas la cause.

Dans Google Search Console. Une boucle fait partie des quatre causes documentées de l’état « Erreur de redirection » dans le rapport Indexation des pages. Les trois autres sont une chaîne trop longue, une URL de redirection qui dépasse la longueur maximale et une URL incorrecte ou vide dans la chaîne. Le rapport reflète la dernière exploration de Google, pas un verdict permanent en temps réel. Après correction, contrôlez de nouveau avec l’Inspection de l’URL. L’article consacré à l’état « Erreur de redirection » couvre les quatre causes ; celui-ci traite précisément des boucles.

Pour les robots et dans les journaux. Un robot pris dans une boucle continue à demander des URL qui le redirigent. Les robots bien conçus la détectent et s’arrêtent ; les autres peuvent provoquer le problème de charge décrit ci-dessous.

Trois parties subissent les boucles

Je présente les boucles comme un problème à trois faces, car elles ne coûtent pas seulement des positions : elles touchent les utilisateurs, les robots et votre infrastructure.

• Utilisateurs. La ressource visée devient inaccessible et le navigateur affiche « trop de redirections ». C’est avant tout une panne du site.
• Robots et moteurs de recherche. Ils sont piégés et gaspillent du budget d’exploration. Rien de l’autre côté du cycle ne peut être exploré, indexé ou classé. Ce n’est pas une pénalité : la page est simplement inaccessible et Google n’atteint aucune destination où consolider les signaux.
• Votre serveur. Les boucles gaspillent des ressources. Certains robots abandonnent, d’autres répètent les requêtes et créent une charge inutile. Une panne grave, voire un effet comparable à un DDoS auto-infligé, dépend du trafic, de la mise en cache, du repli des clients, de la capacité du serveur et de la limitation de débit. Ce n’est pas inhérent à toute boucle, mais le risque est réel sur un site très fréquenté ou fortement exploré sans protection.

Causes courantes

Il n’existe pas de cause universelle. Dans la pratique, une boucle provient de règles de canonicalisation contradictoires, réparties entre des couches qui ne partagent pas le même état. Deux systèmes pensent chacun connaître la bonne URL, mais se renvoient la requête. Les schémas à contrôler dépendent de votre pile technique, pas d’un classement fixe de fréquence.

Conflit HTTP/HTTPS entre le CDN et l’origine

Avec un proxy ou CDN comme Cloudflare, la connexion comporte deux segments : navigateur → CDN, puis CDN → origine. S’ils ne s’accordent pas sur HTTP ou HTTPS, la boucle se forme à cette frontière. La documentation de Cloudflare cite un mode de chiffrement SSL/TLS mal configuré, des réglages contradictoires dans Edge Certificates ou une règle de redirection erronée. Ces causes sont courantes dans Cloudflare, sans être nécessairement les plus fréquentes partout.

• Mode Flexible et origine qui impose HTTPS. En mode SSL Flexible, Cloudflare communique avec l’origine en HTTP, même si le visiteur utilise HTTPS. Si l’origine impose aussi HTTP → HTTPS via .htaccess, nginx ou une extension, le cycle se répète. Correctif : choisissez Full ou Full (strict) pour que le segment CDN→origine utilise aussi HTTPS. Full (strict) exige un certificat valide sur l’origine.
• Mode Full/Full (strict) et origine qui redirige HTTPS → HTTP. Une ancienne règle peut encore renvoyer HTTPS vers HTTP. Correctif : supprimez-la ; l’origine doit servir HTTPS directement.
• « Always Use HTTPS » en périphérie plus redirection HTTPS à l’origine. Imposer HTTPS à deux endroits, ou opposer HSTS à une redirection, peut produire la même boucle. Correctif : imposez HTTPS à un seul niveau.
• Règle de redirection mal configurée, par exemple une Page Rule, Bulk Redirect ou Transform Rule qui ramène une URL vers la forme qu’elle vient de quitter. Correctif : cherchez une règle périphérique qui contredit la canonicalisation de l’origine.

Règles www et non-www qui se renvoient mutuellement

Choisissez un seul hôte canonique : www.example.com ou example.com. Une boucle apparaît si une règle envoie example.com vers www.example.com tandis qu’une autre, souvent dans une extension, le CDN ou WordPress, renvoie www.example.com vers example.com. Correctif : laissez une seule règle, à un seul endroit, imposer le sens choisi.

Conflit entre une extension ou le CDN et le serveur d’origine

La boucle vit souvent entre les couches. Une extension WordPress qui impose SSL, ou les champs d’adresse du site, peut contredire une réécriture .htaccess ou une règle du CDN. Chaque couche paraît correcte isolément, mais elles ne partagent pas leur état. Un fichier .htaccess apparemment correct n’exclut donc pas un conflit ailleurs. Correctif : trouvez les deux règles qui accomplissent la même tâche à des endroits différents et supprimez-en une.

Conflit entre URL avec et sans slash final

Une règle qui ajoute un slash (/page → /page/) peut heurter une règle qui le retire (/page/ → /page). Correctif : choisissez une convention et ne redirigez que la forme incorrecte vers la bonne, jamais vers une forme qui renvoie en arrière.

Empilement de règles laissées par une migration

Les migrations créent souvent des boucles : passage de HTTP à HTTPS, consolidation de www, changement de domaine ou de CMS. Une nouvelle couche ajoutée sur d’anciennes règles non nettoyées peut les faire pointer l’une vers l’autre. Si la boucle semble surgir sans raison, cherchez les règles laissées par une migration.

Diagnostiquer une boucle

Il faut observer la boucle, pas la deviner.

Tracez-la en ligne de commande avec une vraie requête GET, pas avec HEAD seul. Envoyez le même type de requête qu’un visiteur ou un robot, puis relevez chaque code d’état et en-tête Location afin de voir tous les sauts :

# GET is curl's default method (no -I); -L follows redirects; --max-redirs caps how far
curl -sL --max-redirs 10 -D - -o /dev/null https://www.example.com/ | grep -i -E '^(HTTP/|location:)'
# A loop shows the same two (or few) URLs alternating and never a 200 —
# curl stops with "Maximum (10) redirects followed".

Pour afficher l’URL effective à chaque arrêt :

curl -sL --max-redirs 10 -o /dev/null -w '%{http_code} %{url_effective}\n' https://www.example.com/

Comparez ensuite avec une trace HEAD (curl -sIL --max-redirs 10 ...) comme contrôle secondaire, jamais comme preuve principale. HEAD et GET sont des méthodes différentes ; l’application peut les traiter différemment et HEAD manquer une redirection présente sur la vraie requête. Ne rejouez jamais une méthode dangereuse, telle qu’un POST de formulaire, uniquement pour tracer une boucle.

Si le même couple hôte/protocole se répète sans 200, vous avez trouvé la boucle. Les URL alternées révèlent la règle en conflit : protocole pour HTTP/HTTPS, hôte pour www/non-www, chemin pour le slash final. Attribuez ensuite chaque saut à sa couche — navigateur/HSTS, périphérie/TLS, proxy inverse, origine, application/CMS ou session/authentification — car deux couches sans état partagé s’opposent.

Autres pistes :

• Outils de développement du navigateur → Réseau. Observez l’empilement des requêtes et leurs en-têtes Location avant l’erreur.
• Test avec et sans CDN. Si l’origine jointe directement, sans Cloudflare, ne boucle pas, le conflit se situe entre le CDN et l’origine, probablement dans le mode SSL.
• Google Search Console. L’Inspection de l’URL et la catégorie « Erreur de redirection » indiquent les URL problématiques. Les outils d’inspection ne suivent pas les redirections : le résultat décrit l’URL exacte testée, pas l’autre côté de la boucle.
• Robot d’exploration à l’échelle du site, comme Ahrefs Site Audit ou Screaming Frog. Dans Ahrefs : explorez le site, ouvrez Redirects → Issues, cherchez « Redirect loop » puis affichez les URL touchées.

Corriger une boucle

Une fois la cause connue, demandez-vous si la dernière URL avant la fermeture du cycle est la destination finale souhaitée :

• Si oui : supprimez la redirection depuis cette URL finale et vérifiez que la ressource est accessible avec la bonne réponse sans redirection, généralement 200. Le statut dépend toutefois de la ressource : une page supprimée doit renvoyer son statut réel, pas un faux 200.
• Sinon : faites pointer la redirection cyclique directement vers la véritable destination finale.

Dans les deux cas, remplacez les liens internes vers une URL redirigée par des liens directs vers la destination finale.

Correctifs propres aux plateformes :

• Cloudflare : passez de Flexible à Full ou Full (strict) pour aligner CDN→origine sur navigateur→CDN. N’imposez pas HTTPS à la fois en périphérie (« Always Use HTTPS ») et à l’origine. Full (strict) exige un certificat valide.
• WordPress : dans Réglages → Général, les adresses de WordPress et du site doivent correspondre au protocole et à l’hôte canoniques. Supprimez toute extension SSL ou tout extrait FORCE_SSL_ADMIN/redirection dans wp-config.php ou le thème qui double la règle du serveur ou du CDN. Un .htaccess corrompu peut aussi boucler ; régénérez-le depuis Réglages → Permaliens.
• Apache (.htaccess) : les conditions de vos RewriteRule HTTPS et www doivent exclure la forme déjà correcte.
• nginx : un return 301 de canonicalisation HTTPS ou d’hôte ne doit pas s’appliquer à une requête déjà canonique.

Limites de sauts : le faux correctif

Le message « trop de redirections » incite parfois à relever max-redirs ou la limite d’une extension. Cela ne corrige jamais une vraie boucle. Contrairement à une longue chaîne, le problème n’est pas le nombre de sauts : le cycle ne se termine pas. Il faut le rompre.

Remarque sur Bing

Google nomme formellement la « boucle de redirection » parmi les quatre causes d’« Erreur de redirection ». Les conseils publics de Bing sont plus généraux : employer des 301 pour les déplacements permanents et éviter les chaînes inutiles. Cette recherche n’a pas trouvé de page Bing portant précisément ce titre, ce qui est une lacune de la recherche et non la preuve que cette documentation n’existe pas. Le cadre des quatre causes est donc propre à Google.

Concepts associés

La chaîne de redirections est le problème voisin : lorsqu’elle est trop longue, elle représente une autre des quatre causes, mais finit tout de même par aboutir. Une redirection 301 est permanente ; une 302 est temporaire. L’état Erreur de redirection de Search Console est le rapport dans lequel une boucle apparaît le plus souvent pour le SEO.

Résumé par l’IA

Version condensée de l’onglet Avancé :

• Une boucle est un cycle, pas une longue chaîne. A → B → A ne renvoie jamais de 200. Une chaîne finit par aboutir ; relever la limite de sauts ne répare donc pas une boucle.
• Deux manifestations : ERR_TOO_MANY_REDIRECTS dans le navigateur et l’une des quatre causes documentées de l’état « Erreur de redirection » dans Search Console.
• Trois victimes : les utilisateurs bloqués, les robots piégés qui gaspillent le budget d’exploration, et votre serveur qui consomme des ressources. La gravité de la charge dépend du trafic, du repli des clients et de la limitation de débit.
• Cause bien documentée : un désaccord HTTPS/SSL entre le CDN et l’origine, par exemple Cloudflare en Flexible alors que l’origine impose HTTPS. Les conflits www/non-www, extension/serveur, slash final et les migrations sont d’autres causes.
• Diagnostic avec une trace GET : relevez le statut et Location à chaque saut ; HEAD n’est qu’un contrôle secondaire. Complétez par l’onglet Réseau, un test avec et sans CDN, l’Inspection de l’URL et un robot d’exploration.
• Correctif : si la dernière URL avant le cycle est la destination voulue, retirez sa redirection et servez la bonne réponse ; sinon, redirigez directement vers la vraie destination. Corrigez aussi les liens internes.
• Cloudflare : Flexible → Full/Full (strict), sans imposer HTTPS à la fois au CDN et à l’origine. WordPress : alignez les adresses et supprimez la règle SSL en double.
• Les conseils de Bing sont plus généraux. L’absence de page dédiée dans cette recherche ne prouve pas qu’elle n’existe pas.

Documentation officielle

Documentation de première main provenant des moteurs de recherche et des fournisseurs d’infrastructure.

Google

• Rapport Indexation des pages — nomme la boucle parmi les quatre causes de l’état « Erreur de redirection » et recommande un outil de débogage tel que Lighthouse.
• Redirections et recherche Google — recommande une redirection permanente côté serveur lorsque c’est possible. Le terme « boucle » figure dans la documentation d’indexation ci-dessus.
• Déplacement de site avec changement d’URL — indique que Googlebot peut suivre jusqu’à 10 sauts, idéalement trois ou moins et moins de cinq. Cette recommandation concerne les chaînes, pas les boucles.
• Infrastructure d’exploration / codes HTTP — précise que les robots Google suivent par défaut jusqu’à 10 sauts et que les outils d’inspection de Google ne suivent pas les redirections.

Cloudflare (source primaire claire sur une cause bien documentée)

• ERR_TOO_MANY_REDIRECTS / Too many redirects — couvre les modes SSL/TLS mal configurés, les réglages Edge Certificates tels que « Always Use HTTPS » et les règles de redirection erronées, avec schémas et correctifs.

Bing / Microsoft

• Bing Webmaster Guidelines — conseils généraux : 301 pour un déplacement permanent et évitement des chaînes. Aucune page intitulée précisément « redirect loop » n’a été trouvée ici ; c’est une lacune de recherche, pas la preuve de son absence.

Citations des sources

Déclarations attribuées. Chaque lien pointe vers le passage cité lorsqu’il est disponible.

Patrick Stox — définition d’une boucle de redirection (Ahrefs)

• “Redirect loops are infinite loops of redirects that occur when a URL redirects to itself or when a URL in a redirect chain redirects back to a URL earlier in the chain.” (traduction) « Les boucles de redirection sont des suites infinies de redirections qui se produisent lorsqu’une URL se redirige vers elle-même ou qu’une URL d’une chaîne renvoie vers une URL antérieure de cette chaîne. » — Patrick Stox, dans son guide Ahrefs consacré aux redirections. Accéder à la citation

Patrick Stox — les trois parties touchées (Ahrefs)

• “They’re problematic for three reasons: For users – They cut off access to an intended resource and trigger a “too many redirects” error in the browser. For bots and search engines – They “trap” crawlers and waste the crawl budget. For servers - they waste your resources. Some bots will handle this well, others will not. They could potentially take down your server with a constant DDoS attack.” (traduction) « Elles posent problème pour trois raisons : elles bloquent l’accès des utilisateurs, piègent les robots et gaspillent le budget d’exploration, puis gaspillent les ressources des serveurs ; certains robots peuvent même contribuer à une charge constante comparable à un DDoS. » — Patrick Stox, dans l’article Ahrefs sur l’impact SEO des redirections. Accéder à la citation

Patrick Stox — corriger une boucle (Ahrefs)

• “The best way to fix a redirect loop depends on whether the last URL in the chain (before the loop) is the intended final destination. If it is, remove the redirect from the final URL. Then make sure the resource is accessible and returns a 200 status code. If it isn’t, change the looping redirect to the intended final destination.” (traduction) « Le bon correctif dépend de la dernière URL avant la boucle. Si c’est la destination voulue, retirez sa redirection et vérifiez qu’elle renvoie 200. Sinon, faites pointer la redirection cyclique vers la destination finale voulue. » — Patrick Stox, section Ahrefs sur la correction des boucles. Accéder à la citation

Google — la boucle comme cause d’« Erreur de redirection »

• “Google experienced one of the following redirect errors: A redirect chain that was too long. A redirect loop. A redirect URL that eventually exceeded the max URL length. A bad or empty URL in the redirect chain.” (traduction) « Google a rencontré l’une des erreurs suivantes : une chaîne trop longue, une boucle, une URL qui a fini par dépasser la longueur maximale, ou une URL incorrecte ou vide dans la chaîne. » — Google, aide sur le rapport Indexation des pages. Accéder à la citation

Quelle est la cause de ma boucle de redirection ?

Une boucle oppose toujours une règle à une autre ; il faut identifier lesquelles. Commencez par ouvrir l’URL dans une fenêtre privée et, si possible, tracez-la avec une requête GET — curl -sL --max-redirs 10 -D - -o /dev/null — afin de voir les URL qui alternent.

Quel correctif appliquer après avoir trouvé la boucle ?

Guide d’intervention : « La page boucle — ERR_TOO_MANY_REDIRECTS — que faire ? »

Ordre d’intervention sans panique pour une boucle active. Suivez ces étapes et arrêtez-vous lorsque la cause est corrigée. Pour les visiteurs, il s’agit d’une panne du site : restaurez d’abord l’accès, perfectionnez ensuite le SEO.

0. Délimiter le problème (2 minutes). Concerne-t-il une URL, une section ou tout le site ? Une boucle générale apparue après un changement SSL/CDN est urgente : passez à l’étape 3. Pour une seule URL, examinez plutôt les règles d’hôte ou de slash aux étapes 2 et 4.

1. Écarter le navigateur. Ouvrez l’URL en navigation privée. Si elle fonctionne, effacez le cache et les cookies du site. Si elle boucle aussi, le problème est côté serveur.

2. Tracer chaque saut avec une requête GET (pas HEAD seul).

curl -sL --max-redirs 10 -o /dev/null -w '%{http_code} %{url_effective}\n' https://www.example.com/

L’élément qui alterne indique la cause : protocole (http ⇄ https) → étape 3 ; hôte (www ⇄ sans www) ou slash → étape 4. La répétition d’une paire sans 200 confirme la boucle. HEAD (curl -sIL) n’est qu’un contrôle secondaire, car certaines applications traitent HEAD et GET différemment.

3. Si le protocole alterne, contrôler d’abord la couche SSL. Avec Cloudflare ou un autre CDN, il s’agit probablement d’un désaccord de mode SSL. Si Cloudflare utilise Flexible, passez à Full ou Full (strict). Vérifiez aussi que HTTPS n’est pas imposé à la fois par « Always Use HTTPS » et par l’origine, .htaccess ou une extension. Sans CDN, conservez une seule des deux règles HTTPS opposées à l’origine.

4. Si l’hôte ou le slash alterne, trouver les deux règles en double. Le conflit oppose des couches sans état partagé : extension et .htaccess, CDN et réglage d’adresse du CMS. Dans WordPress, contrôlez Réglages → Général et les extensions SSL. Supprimez une règle afin que seule la forme incorrecte soit redirigée une fois vers la bonne.

5. Appliquer le correctif structurel. Identifiez la dernière URL avant la fermeture du cycle. Si c’est la destination voulue, retirez sa redirection et servez 200. Sinon, pointez directement vers la vraie destination. Mettez ensuite à jour les liens internes.

6. Retester. Relancez la trace curl. Le résultat attendu est un seul 301 → 200 ou un 200 direct, sans alternance. Testez http:// et https://, avec www et sans www.

7. Vider les caches et revalider pour la recherche. Purgez le cache du CDN et des pages. Si Search Console signalait une « Erreur de redirection », utilisez Inspection de l’URL et Valider la correction. La réexploration prend des jours ou des semaines, mais l’accès des visiteurs est rétabli dès que l’étape 6 est propre.

8. Prévenir la prochaine boucle. Conservez une source unique pour les règles canoniques de protocole, d’hôte et de slash. Après toute modification SSL, CDN, extension ou migration, retracez vos URL essentielles.

Cadre du cycle, du propriétaire et de l’invariant

Avant de modifier les règles, je documente trois éléments :

1. Cycle : notez la séquence exacte, y compris protocole, hôte, chemin, requête et slash. Une boucle n’est prouvée que lorsqu’une URL se répète.
2. Propriétaire : attribuez chaque saut au navigateur/HSTS, au CDN, au répartiteur, au serveur web, à l’application ou à l’extension. Les en-têtes et frontières de configuration valent mieux qu’une supposition fondée sur l’erreur finale.
3. Invariant : choisissez l’état canonique commun à toutes les couches : un protocole, un hôte et un format de chemin. Chaque variante non canonique peut rediriger vers lui ; l’URL canonique doit renvoyer une réponse sans redirection.

Le correctif sûr supprime ou modifie la première règle contradictoire, puis retrace toutes les variantes d’entrée. Relever la limite de sauts ne fait que retarder le même cycle.

Outils pour mettre les cycles en évidence

• Redirect Chain Mapper : trace chaque saut et montre où un protocole, un hôte, un slash, un domaine ou un chemin se répète.
• Redirect Checker : contrôle rapidement les variantes HTTP, HTTPS, www et non-www après correction.
• Bulk HTTP Status Code Checker : valide un échantillon plus large et exporte les boucles ou chaînes restantes.
• HTTP Header Checker : inspecte les en-têtes et empreintes CDN qui permettent d’attribuer chaque saut.
• curl : curl -sSL --max-redirs 12 -D - -o /dev/null URL fournit une trace GET hors des cookies du navigateur. HEAD (-I) reste secondaire. Testez aussi une session neuve si l’authentification ou la langue intervient.
• Configuration du CDN, du serveur et de l’application : comparez chaque propriétaire de redirection à l’invariant canonique choisi avant de modifier une règle.

Ressources utiles

Mes articles associés

• Les types de redirections et leur impact SEO — mon guide complet, avec les trois parties touchées, la recherche de boucles dans Site Audit et la règle de correction à deux branches.
• Redirections 301 ou 302 pour le SEO — choix du type de redirection pour un déplacement permanent ou temporaire.
• Une migration de site exige plus qu’une liste de contrôle — planification des redirections de migration sans empiler des règles opposées.

Dans le secteur

• Too many redirects — documentation officielle Cloudflare sur les modes SSL, « Always Use HTTPS » et les règles en périphérie.
• Rapport Indexation des pages — page Google qui nomme la boucle parmi les quatre causes.
• Google Search Ignores Redirect Loops — compte rendu secondaire d’un tweet de John Mueller en 2019 ; le tweet original n’a pas été revérifié, donc utilisez-le comme contexte, pas comme citation confirmée.
• Trop de redirections : corriger les boucles et protéger le SEO — guide général couvrant WordPress et les erreurs de protocole.

Chiffres et faits à citer

• Une boucle nuit à trois parties. Mon guide Ahrefs décrit l’accès coupé pour les utilisateurs, les robots piégés et les ressources serveur gaspillées ; selon le trafic et la limitation de débit, des robots sans repli peuvent produire une charge de niveau DDoS. Source
• Une boucle est l’une des quatre causes documentées d’« Erreur de redirection » dans Search Console, avec une chaîne trop longue, une URL trop longue et une URL incorrecte ou vide. Source
• Un désaccord de mode SSL est une cause bien documentée. Cloudflare montre comment Flexible plus une origine qui impose HTTPS forme une boucle à la frontière CDN/origine. Il s’agit d’une famille courante dans son produit, pas d’une cause universellement dominante. Source

Testez vos connaissances : boucles de redirection

Cinq questions rapides sur la nature des boucles et leur correction. Choisissez une réponse, puis vérifiez-la.

Journal des modifications