ERR_TOO_MANY_REDIRECTS : comment corriger cette erreur (tous les navigateurs)

Qu'est-ce que ERR_TOO_MANY_REDIRECTS ?

ERR_TOO_MANY_REDIRECTS signifie que la page a renvoyé votre navigateur vers une autre adresse plus de 20 fois sans jamais se charger : une boucle de redirection. Chrome affiche « Cette page ne fonctionne pas » et « example.com vous a redirigé à de trop nombreuses reprises. », Edge affiche le même code d'erreur, Firefox indique « La page n’est pas redirigée correctement » et Safari « Safari ne parvient pas à ouvrir la page » (sur iPhone : « Safari ne peut pas ouvrir la page car il y a eu trop de redirections »).

Si vous visitez le site, supprimez les cookies de ce site et rechargez la page : quand le site fonctionne pour tout le monde sauf vous, un cookie obsolète est la cause habituelle. Si c'est votre site, la boucle vient presque toujours de HTTPS (ou www) forcé à deux endroits à la fois, le plus souvent le mode Flexible SSL de Cloudflare plus une redirection HTTPS sur le serveur.

La limite est la même partout parce que le Fetch Standard qu'appliquent les navigateurs l'impose : « If request's redirect count is 20, then return a network error. » (au bout de 20 redirections, la requête échoue avec une erreur réseau). La boucle elle-même se compose généralement de deux réponses 301 ou 302 qui pointent l'une vers l'autre : l'URL A vous envoie vers l'URL B, l'URL B vous renvoie vers A, et le navigateur arrête de compter à 20.

Quelles sont les causes des boucles de redirection ?

Les boucles de redirection se produisent lorsque deux règles de redirection ou plus entrent en conflit. Le serveur envoie le navigateur vers une URL, et cette URL renvoie le navigateur en arrière. Voici les causes les plus courantes :

• Mauvaise configuration SSL/HTTPS — La cause la plus fréquente. Votre serveur force la redirection HTTP vers HTTPS, mais votre CDN ou répartiteur de charge se connecte à l'origine en HTTP, créant une boucle : CDN → HTTP → le serveur redirige vers HTTPS → le CDN supprime HTTPS → HTTP → boucle
• Cloudflare Flexible SSL — Le mode Flexible SSL de Cloudflare envoie les requêtes à votre serveur d'origine en HTTP. Si votre origine possède également une redirection HTTP vers HTTPS, cela crée une boucle infinie entre Cloudflare et votre serveur
• Règles .htaccess conflictuelles — Plusieurs règles de redirection dans .htaccess qui se contredisent, comme une règle forçant www et une autre forçant sans www simultanément
• URLs WordPress non concordantes — L'adresse WordPress (URL) et l'adresse du site (URL) dans Réglages > Général ne correspondent pas, ou l'une utilise HTTP tandis que l'autre utilise HTTPS
• Cookies obsolètes du navigateur — D'anciens cookies contenant des instructions de redirection ou des données de session qui forcent le navigateur vers une URL qui n'existe plus ou a été déplacée
• Redirections en cache du CDN ou proxy — Votre CDN a mis en cache une ancienne redirection 301 qui entre maintenant en conflit avec la configuration actuelle de votre serveur
• Conflits de configuration serveur — Des fichiers de configuration Nginx ou Apache avec des blocs de redirection concurrents, comme une redirection à la fois dans le bloc serveur et dans .htaccess
• Boucles de connexion dans les applications web — une page de connexion qui redirige les visiteurs déconnectés vers elle-même, ou un cookie de session que le navigateur refuse d'enregistrer (OAuth, Supabase Auth, NextAuth). Voir la correction 8

Comment diagnostiquer une boucle de redirection

Avant d'essayer des corrections, identifiez la chaîne de redirection exacte. Cela vous indique précisément quelles URLs sont impliquées et quelles règles de redirection causent la boucle.

Méthode 1 : utiliser curl pour tracer les redirections

Le moyen le plus rapide de visualiser une chaîne de redirection est d'utiliser curl dans votre terminal. L'option -I récupère uniquement les en-têtes, -L suit les redirections et --max-redirs limite le nombre de redirections à suivre :

# Trace redirect chain (limit to 10 hops)
curl -ILs --max-redirs 10 https://example.com 2>&1 | grep -i 'HTTP/\|location:'

# Example output showing a redirect loop:
# HTTP/2 301
# location: http://example.com/
# HTTP/1.1 301 Moved Permanently
# Location: https://example.com/
# HTTP/2 301
# location: http://example.com/
# (repeats...)

Si vous voyez les mêmes deux URLs alterner dans les en-têtes Location, vous avez confirmé une boucle de redirection. Notez les codes de statut : 301 est une redirection permanente que les navigateurs mettent en cache, 302 une redirection temporaire qui n'est pas mise en cache, sauf si la réponse l'indique.

Regardez le schéma de chaque en-tête Location : une boucle entre les versions http:// et https:// d'une même URL est le cas le plus courant, et elle désigne directement un réglage SSL.

Méthode 2 : onglet réseau des DevTools du navigateur

Vous pouvez également tracer les redirections visuellement dans Chrome DevTools :

• Étape 1 — Ouvrez Chrome DevTools avec F12 ou Ctrl+Shift+I (Mac : Cmd+Option+I)
• Étape 2 — Allez dans l'onglet Network et cochez Preserve log (cela conserve les entrées entre les redirections)
• Étape 3 — Chargez la page qui déclenche l'erreur
• Étape 4 — Observez la séquence de requêtes. Chaque redirection apparaît comme une entrée distincte avec le statut 301 ou 302. La colonne Location indique où chaque redirection pointe

L'onglet Network affiche la chaîne de redirection complète par ordre chronologique. Vous verrez le schéma : généralement deux ou trois URLs se répétant en boucle. Utilisez le Vérificateur d'en-têtes HTTP de DNS Robot pour inspecter les en-têtes de réponse en dehors du cache de votre navigateur.

Méthode 3 : vérificateur de redirections en ligne

Si vous n'avez pas de terminal, collez l'URL dans le Vérificateur de redirections de DNS Robot. Il suit chaque saut depuis notre serveur, affiche chaque code de statut et chaque en-tête Location, et signale quand la chaîne revient sur elle-même. Il fonctionne sans les cookies de votre navigateur : il vous dit donc tout de suite si la boucle vient du site ou de votre navigateur.

Correction 1 : vider les cookies et le cache du navigateur

Commencez par la correction la plus simple. Les cookies obsolètes ou les redirections en cache dans votre navigateur peuvent provoquer des boucles même lorsque la configuration du serveur est correcte. C'est particulièrement courant après la migration d'un site de HTTP vers HTTPS : les anciens cookies peuvent encore référencer des URLs HTTP.

Vider les cookies dans Chrome

Videz les cookies du site concerné plutôt que tous les cookies : cela préserve vos connexions sur les autres sites :

• Étape 1 — Cliquez sur l'icône du cadenas (ou l'icône de réglage) dans la barre d'adresse à côté de l'URL
• Étape 2 — Cliquez sur Paramètres des sites
• Étape 3 — Cliquez sur Supprimer les données pour supprimer les cookies et les données en cache de ce site uniquement
• Étape 4 — Rechargez la page

# Chrome keyboard shortcut to open Delete browsing data:
# Windows/Linux: Ctrl + Shift + Delete
# macOS: Cmd + Shift + Delete

Ou effacez tout pour tous les sites : appuyez sur Ctrl+Shift+Delete (Mac : Cmd+Shift+Delete) pour ouvrir Supprimer les données de navigation, cochez Cookies et autres données des sites et Images et fichiers en cache, choisissez Depuis le début, puis cliquez sur Supprimer les données.

Vider les cookies dans Firefox et Safari

Firefox : Appuyez sur Ctrl+Shift+Delete (Mac : Cmd+Shift+Delete), cochez Cookies et données de sites et Fichiers et pages mis en cache temporairement, définissez la période sur tout et cliquez sur Effacer.

Safari : allez dans Safari > Réglages > Confidentialité > Gérer les données de sites web, recherchez le domaine concerné, sélectionnez-le et cliquez sur Supprimer. Ensuite, videz le cache avec Cmd+Option+E.

Si la suppression des cookies corrige l'erreur, une règle de redirection a récemment changé sur le serveur et votre navigateur conservait l'ancien état. Les visiteurs avec une session neuve ne verront peut-être jamais l'erreur.

Gmail, Google Drive ou accounts.google.com « vous a redirigé à de trop nombreuses reprises »

Quand Chrome affiche « Cette page ne fonctionne pas » avec « accounts.google.com vous a redirigé à de trop nombreuses reprises. » et le lien « Essayez de supprimer vos cookies. », ou que le message cite mail.google.com ou drive.google.com, la boucle se joue entre les pages de connexion de Google et les cookies de votre navigateur, pas sur un site en panne. La connexion Google ne fonctionne que si le navigateur conserve les cookies de Google : tout ce qui les bloque ou les réécrit vous fait tourner en rond :

• Supprimez uniquement les cookies de Google — ouvrez chrome://settings/content/all (Tous les sites), recherchez google.com, supprimez ses données et reconnectez-vous. Comme l'indique l'aide de Google, vous devrez ensuite vous reconnecter à votre compte Google dans ce navigateur
• Autorisez les cookies pour Google — retirez google.com de toute liste de sites non autorisés à utiliser des cookies et, si vous bloquez les cookies tiers, ajoutez [*.]google.com aux Sites autorisés à utiliser des cookies tiers (Chrome : Paramètres → Confidentialité et sécurité → Cookies tiers)
• Déconnectez-vous de tous les comptes, puis connectez-vous avec un seul — plusieurs comptes connectés en même temps, ou un compte professionnel qui confie la connexion à la page de connexion de l'entreprise, peuvent rebondir de l'un à l'autre
• Désactivez les extensions de cookies et de confidentialité — les extensions qui suppriment ou réécrivent les cookies pendant la connexion sont un déclencheur fréquent. Chrome laisse les extensions désactivées en navigation privée tant que vous ne les y autorisez pas : essayez donc d'abord une fenêtre de navigation privée

Correction 2 : vérifier la configuration SSL/HTTPS

La mauvaise configuration SSL est la cause numéro 1 des boucles de redirection. Le scénario le plus courant est un conflit entre votre CDN/proxy et votre serveur d'origine sur l'utilisation de HTTP ou HTTPS.

Voici ce qui se passe généralement : votre CDN se connecte à l'origine en HTTP (car il gère la terminaison SSL), mais l'origine possède une redirection HTTP vers HTTPS. L'origine renvoie le CDN vers HTTPS, le CDN supprime HTTPS et renvoie du HTTP : boucle infinie.

Un certificat défectueux derrière la même configuration provoque une autre erreur ; voir ERR_SSL_PROTOCOL_ERROR et « Votre connexion n'est pas privée ».

• Vérifiez votre certificat SSL — Utilisez le Vérificateur de certificat SSL de DNS Robot pour vérifier que votre certificat est valide, non expiré et couvre le bon domaine
• Faites correspondre les protocoles — Si votre CDN gère la terminaison SSL, supprimez la redirection HTTP vers HTTPS sur votre origine, ou configurez le CDN pour se connecter à l'origine en HTTPS
• Vérifiez les paramètres de HTTPS forcé — Si vous avez à la fois une redirection au niveau du serveur (Nginx/Apache) ET une redirection au niveau du CDN pour forcer HTTPS, supprimez-en une
• Vérifiez l'en-tête X-Forwarded-Proto — Derrière un proxy, votre origine doit vérifier cet en-tête au lieu du protocole de connexion brut pour déterminer si la requête originale était en HTTPS

Correction 3 : corriger les boucles de redirection Cloudflare

Cloudflare est le déclencheur le plus courant, car son mode de chiffrement détermine s'il joint votre serveur en HTTP ou en HTTPS. La page de dépannage de Cloudflare (mise à jour en septembre 2026) liste cinq réglages qui créent une boucle, chacun face à un comportement de votre serveur d'origine :

La correction habituelle d'une boucle de redirection Cloudflare : changez votre mode de chiffrement SSL/TLS de Flexible à Full ou Full (Strict). Cela indique à Cloudflare de se connecter à votre origine en HTTPS, éliminant ainsi la boucle HTTP vers HTTPS.

Correction Cloudflare étape par étape

• Étape 1 — Connectez-vous au tableau de bord Cloudflare
• Étape 2 — Sélectionnez votre domaine
• Étape 3 — Allez dans SSL/TLS > Overview
• Étape 4 — Passez le mode de chiffrement à Full (strict) si votre origine a un certificat valide (un certificat Cloudflare Origin CA gratuit compte), ou à Full uniquement s'il est auto-signé
• Étape 5 — Allez dans SSL/TLS > Edge Certificates et vérifiez si Always Use HTTPS est activé. Si votre origine redirige déjà vers HTTPS, désactivez cette option pour éviter une double redirection
• Étape 6 — Vérifiez les Page Rules et Redirect Rules pour d'éventuelles redirections d'URL conflictuelles
• Étape 7 — Purgez le cache Cloudflare : allez dans Caching > Configuration > Purge Everything

Correction 4 : corriger les règles de redirection .htaccess (Apache)

Sur les serveurs Apache, .htaccess est l'emplacement le plus courant pour les règles de redirection et l'endroit où les boucles de redirection naissent le plus souvent. Des règles conflictuelles, des redirections en double ou des conditions manquantes peuvent toutes créer des boucles.

• Recherchez les redirections HTTPS en double — Si votre panneau d'hébergement (cPanel, Plesk) force HTTPS, supprimez la redirection manuelle dans .htaccess
• Vérifiez les conditions RewriteCond — Chaque RewriteRule qui redirige doit avoir un RewriteCond qui empêche son déclenchement sur les URLs déjà conformes. Sans cela, la règle s'exécute à chaque requête, y compris celle déjà redirigée
• Attention au drapeau [L] — Le drapeau [L] signifie 'dernière règle' mais uniquement pour le passage en cours. Si un autre .htaccess existe dans un sous-répertoire, il s'exécute à nouveau. Utilisez [END] sur Apache 2.4+ à la place
• Vérifiez les en-têtes de proxy — Derrière un CDN, utilisez %{HTTP:X-Forwarded-Proto} au lieu de %{HTTPS} pour détecter le protocole d'origine

# Correct HTTPS redirect behind Cloudflare/CDN:
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

Si vous ne savez pas quelle règle cause la boucle, renommez temporairement .htaccess en .htaccess.bak et testez si le site se charge. Si c'est le cas, le problème se trouve dans votre fichier .htaccess. Réactivez les règles une par une jusqu'à trouver celle qui pose problème.

Correction 5 : corriger les boucles de redirection WordPress

Les boucles de redirection WordPress proviennent généralement de trois sources : des URLs non concordantes dans les Réglages, des conflits de plugins ou des valeurs incorrectes dans wp-config.php. Si vous ne pouvez pas accéder au tableau de bord WordPress à cause de la boucle de redirection, vous devrez corriger le problème directement via la base de données ou les fichiers de configuration.

Vérifier les paramètres d'URL WordPress

WordPress possède deux paramètres d'URL qui doivent correspondre : Adresse web de WordPress (URL) et Adresse web du site (URL) dans Réglages > Général. Si l'une utilise http:// et l'autre https://, ou si l'une inclut www. et l'autre non, vous obtiendrez une boucle de redirection.

Si vous ne pouvez pas accéder au tableau de bord, définissez les URLs directement dans wp-config.php :

// Add these lines to wp-config.php (above "That's all, stop editing!"):
define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');

// If behind a reverse proxy (Cloudflare, Nginx proxy):
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

Désactiver les plugins pour trouver les conflits

Les plugins de redirection et de cache sont souvent en cause. Des plugins comme Redirection, Yoast SEO, Really Simple SSL, WP Super Cache et W3 Total Cache peuvent ajouter des règles de redirection qui entrent en conflit avec la configuration de votre serveur ou CDN.

Si vous ne pouvez pas accéder au tableau de bord, désactivez tous les plugins via FTP ou SSH :

# Rename the plugins folder to disable all plugins at once:
cd /var/www/html/wp-content/
mv plugins plugins.bak

# If the site loads, rename it back and disable plugins one by one:
mv plugins.bak plugins
# Then rename individual plugin folders to find the culprit:
mv plugins/really-simple-ssl plugins/really-simple-ssl.bak

Si la désactivation des plugins corrige l'erreur, réactivez-les un par un pour identifier le plugin fautif. Les coupables les plus courants sont les plugins SSL qui ajoutent des redirections HTTP vers HTTPS alors que votre serveur ou CDN gère déjà cette tâche.

Correction 6 : corriger les redirections au niveau serveur (Nginx et Apache)

Les fichiers de configuration serveur peuvent contenir des règles de redirection qui entrent en conflit avec les redirections au niveau applicatif (WordPress, .htaccess) ou les paramètres du CDN.

Nginx : rechercher les conflits de redirection

Les boucles de redirection Nginx surviennent généralement lorsque le bloc serveur HTTP redirige vers HTTPS, mais quelque chose dans le bloc HTTPS redirige vers HTTP. Vérifiez la configuration de votre site :

# Correct Nginx HTTPS redirect (separate server blocks):
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;
    # SSL certificate configuration here
    # DO NOT add another redirect to HTTPS here
}

# If behind Cloudflare/proxy, check real protocol:
server {
    listen 80;
    server_name example.com;
    if ($http_x_forwarded_proto != 'https') {
        return 301 https://example.com$request_uri;
    }
}

Exécutez nginx -t après chaque modification pour détecter les erreurs de syntaxe, puis systemctl reload nginx pour appliquer le changement sans interruption de service.

Apache : vérifier les redirections VirtualHost

Sous Apache, vérifiez à la fois la configuration VirtualHost et .htaccess. Une redirection dans la configuration VirtualHost plus une redirection dans .htaccess crée une double redirection qui peut boucler :

# Check Apache config for redirect rules:
grep -r 'Redirect\|RewriteRule' /etc/apache2/sites-enabled/
grep -r 'Redirect\|RewriteRule' /etc/httpd/conf.d/

# Check .htaccess:
cat /var/www/html/.htaccess | grep -i 'rewrite\|redirect'

Supprimez les redirections en double : ne conservez la redirection qu'à un seul endroit. La bonne pratique est de gérer les redirections HTTPS dans la configuration VirtualHost (pas dans .htaccess) car les règles VirtualHost sont traitées une fois par requête tandis que .htaccess est traité à chaque requête.

Correction 7 : dépannage spécifique au navigateur

Si l'erreur n'apparaît que dans un seul navigateur, il s'agit probablement d'une redirection en cache ou d'un conflit d'extension plutôt que d'un problème serveur.

Chrome : effacer le HSTS et le pool de sockets

Chrome met en cache les politiques HSTS (HTTP Strict Transport Security) qui forcent HTTPS. Si un site a précédemment envoyé un en-tête HSTS mais n'utilise plus correctement HTTPS, Chrome continuera à rediriger vers HTTPS même après avoir vidé les cookies.

• Effacer le cache HSTS — Allez à chrome://net-internals/#hsts, entrez le domaine dans Delete domain security policies et cliquez sur Delete
• Vider les pools de sockets — Allez à chrome://net-internals/#sockets et cliquez sur Flush socket pools pour effacer toute connexion en cache
• Effacer le cache DNS — Allez à chrome://net-internals/#dns et cliquez sur Clear host cache (d'autres méthodes dans comment vider le cache DNS)
• Tester en Navigation privée — Ouvrez une fenêtre de Navigation privée (Ctrl+Shift+N) et testez l'URL. Si cela fonctionne en Navigation privée mais pas en mode normal, une redirection en cache ou une extension est la cause

Corrections pour Firefox et Safari

Firefox : Tapez about:config dans la barre d'adresse, recherchez network.http.redirection-limit et vérifiez qu'il vaut 20 (la valeur par défaut). Une valeur plus basse, définie à la main ou par une stratégie d'entreprise, fait échouer les redirections plus tôt. Essayez aussi de supprimer les données du site : Paramètres > Vie privée et sécurité > Gérer les données > recherchez le domaine > Supprimer les sites sélectionnés.

Safari : sur Mac, Safari affiche « Safari ne parvient pas à ouvrir la page » avec « Trop de redirections sont survenues en tentant d’ouvrir “example.com”. » ; sur iPhone et iPad, « Safari ne peut pas ouvrir la page car il y a eu trop de redirections ». La console du Web Inspector indique « Load cannot follow more than 20 redirections » (le chargement ne peut pas suivre plus de 20 redirections ; ce message de WebKit n'est pas traduit). Allez dans Safari > Réglages > Confidentialité > Gérer les données de sites web, trouvez le domaine et cliquez sur Supprimer. Si la boucle persiste, testez une fenêtre privée : si elle boucle aussi, le site est mal configuré.

Correction 8 : boucles de redirection à la connexion dans les applications web

Dans une application web, la boucle vient souvent de votre propre code : une page qui exige un utilisateur connecté redirige vers /login, et quelque chose renvoie aussitôt /login (ou le callback de connexion) en arrière. La console du navigateur l'affiche sous la forme net::ERR_TOO_MANY_REDIRECTS sur la requête en échec.

• La page de connexion est protégée elle aussi — un middleware d'authentification qui s'exécute sur toutes les routes redirige aussi /login et la route de callback vers /login. Excluez-les de la vérification
• Le cookie de session n'est jamais conservé — un cookie défini avec SameSite=None doit aussi être Secure, sinon le navigateur l'ignore ; un cookie défini pour le mauvais domaine n'est jamais renvoyé. Dans les deux cas, chaque requête semble toujours déconnectée
• L'URL de callback ne correspond pas — le fournisseur (Google, GitHub, Supabase Auth) envoie les utilisateurs vers un callback que votre application ne gère pas, et cette route redirige de nouveau vers la connexion
• HTTP ou HTTPS derrière un proxy — l'application construit ses URLs de redirection en http:// parce qu'elle ignore X-Forwarded-Proto : la boucle de la correction 2, une couche plus haut

// Next.js: proxy.ts (middleware.ts before Next.js 16).
// Never run the sign-in check on the sign-in pages themselves.
export const config = {
  matcher: ["/((?!login|auth/callback|_next/static|_next/image|favicon.ico).*)"],
};

Testez la correction avec le Vérificateur de redirections ou curl -IL en étant déconnecté : une chaîne saine se termine sur la page de connexion avec un 200, pas sur une nouvelle redirection.

Comment prévenir les boucles de redirection

Une fois l'erreur corrigée, suivez ces bonnes pratiques pour éviter que les boucles de redirection ne se reproduisent :

• Redirigez à un seul endroit — Choisissez une seule couche pour votre redirection HTTPS : le CDN, le serveur web ou l'application. Ne redirigez jamais à plusieurs niveaux simultanément
• Utilisez 302 pendant les tests — Pendant le débogage, utilisez des redirections 302 (temporaires) au lieu de 301 (permanentes). Les navigateurs mettent en cache les 301 de manière agressive, rendant les tests difficiles. Passez à 301 une fois que vous confirmez que la redirection fonctionne correctement
• Testez toujours avec curl — Après avoir ajouté une règle de redirection, exécutez curl -ILs https://votresite.com | grep -i 'HTTP/\|location:' pour vérifier que la chaîne de redirection se termine par une réponse 200
• Surveillez avec des outils — Utilisez régulièrement le Vérificateur d'en-têtes HTTP de DNS Robot pour vérifier que votre site renvoie une réponse 200 propre sans redirections inattendues
• Documentez vos redirections — Tenez un registre de toutes les règles de redirection dans la configuration serveur, .htaccess, les règles CDN et les paramètres applicatifs. Quand plusieurs membres de l'équipe gèrent un site, les redirections non documentées sont la cause numéro 1 des boucles
• Purgez le cache CDN après les modifications — Après avoir modifié une règle de redirection, purgez immédiatement le cache de votre CDN. Les anciennes 301 en cache peuvent persister pendant des jours

Une chaîne saine comporte un ou deux sauts au maximum (par exemple HTTP → HTTPS → 200 OK). Trois ou plus signalent généralement une redirection dont vous n'avez plus besoin.

Impact SEO des boucles de redirection

Les boucles de redirection font sortir les pages de la recherche. Selon la documentation de Google sur l'exploration, ses robots suivent jusqu'à 10 redirections ; une boucle n'atteint jamais le contenu, donc la Search Console signale une erreur de redirection et l'URL sort de l'index jusqu'à ce que la boucle soit corrigée.

Les longues chaînes coûtent même quand elles aboutissent : chaque saut est une requête de plus que le navigateur et Googlebot doivent faire avant que la page puisse se charger. Faites donc pointer liens et redirections directement vers l'URL finale.

• Perte d'indexation — Les pages prises dans des boucles de redirection ne sont pas indexées et disparaissent complètement des résultats de recherche
• Gaspillage du budget de crawl — Googlebot dépense son budget de crawl limité à suivre des redirections au lieu d'explorer du contenu réel
• Pages plus lentes — chaque saut ajoute une requête et un aller-retour avant le chargement du moindre contenu, et un saut vers un autre hôte exige en plus une nouvelle connexion