ERR_TOO_MANY_REDIRECTS : votre site tourne en boucle, que faire ?Trop de redirections : trouver entre quelles adresses le site tourne, puis couper la boucle.

1. Testez en navigation privée : si le site s'ouvre, supprimez simplement les cookies du site.
2. Suivez la chaîne avec la commande curl.exe -I -L (curl sur Mac) : elle montre par quelles adresses passe le site.
3. Derrière Cloudflare, passez en Full (strict), avec un certificat valide sur le serveur, jamais en Flexible.
4. Alignez l'adresse de WordPress (Réglages, puis Général, ou WP_HOME et WP_SITEURL) sur celle qu'impose le serveur : https, avec ou sans www.
5. Une seule redirection vers https, à un seul endroit : .htaccess, hébergeur, extension ou Cloudflare.
6. Désactivez les extensions suspectes en renommant leur dossier, puis videz tous les caches.

Dans ce guide

• Les messages de l'erreur, selon le navigateur
• Les causes, de la plus fréquente à la plus rare
• La marche à suivre, dans l'ordre
• Ce que nous ferions à votre place
• Questions fréquentes

• Chrome : « Cette page ne fonctionne pas », puis « votresite.fr vous a redirigé à de trop nombreuses reprises. », la suggestion « Essayez de supprimer vos cookies » et, en dessous, le code ERR_TOO_MANY_REDIRECTS. Edge, Opera et Brave, construits sur la même base que Chrome, affichent le même code avec une formulation proche.
• Firefox : une page qui annonce que la page n'est pas redirigée correctement, parce que le serveur redirige la demande d'une façon qui n'aboutira jamais, avec cette piste : « La cause de ce problème peut être la désactivation ou le refus des cookies. »
• Safari : un message qui dit qu'il ne peut pas ouvrir la page, parce que trop de redirections se sont produites.
• Dans la Search Console de Google : le rapport sur l'indexation des pages range ces adresses sous « Erreur liée à des redirections », qui regroupe notamment la « Boucle de redirection » et la « Chaîne de redirection trop longue ».

Regardez aussi où la boucle apparaît : sur tout le site, seulement dans l'administration (/wp-admin), sur une seule page, ou seulement quand on tape l'adresse avec ou sans www. Ce détail oriente déjà vers la cause.

À ne pas confondre : une boucle à l'intérieur du serveur, quand les règles de réécriture du fichier .htaccess se renvoient la demande, ne donne pas ce message mais une erreur 500, avec Request exceeded the limit of 10 internal redirects dans le journal du serveur. Et si le navigateur dit qu'il ne peut pas établir de connexion sécurisée, c'est une autre panne : ERR_SSL_PROTOCOL_ERROR.

1. Cloudflare en mode Flexible, et un serveur qui force le https. En mode Flexible, le visiteur arrive chez Cloudflare en https, mais Cloudflare va chercher la page sur votre serveur en http. Le serveur, réglé pour tout envoyer vers https, répond d'aller en https ; Cloudflare transmet, le navigateur redemande la même adresse, et ainsi de suite. C'est la première cause que cite Cloudflare. Elle apparaît souvent juste après l'ajout du site à Cloudflare, ou après l'activation du https chez l'hébergeur ou dans une extension.
2. Une adresse de site qui ne correspond pas au serveur. WordPress renvoie toujours vers la version de l'adresse enregistrée dans Réglages, puis Général, avec ou sans www. Si le serveur ou Cloudflare impose l'autre version, chacun renvoie vers la sienne. Pour le choix entre http et https, WordPress ne redirige pas les pages de lui-même ; mais une adresse en https:// lui fait imposer le https à l'administration, certaines extensions s'appuient sur cette adresse pour rediriger, et une adresse différente de celle que vous tapez peut empêcher la connexion de tenir. Fréquent après un passage en https, un changement de domaine ou un déménagement.
3. Deux redirections qui se contredisent. Le https et le www peuvent être imposés à quatre endroits : le fichier .htaccess, une option de l'hébergeur (la redirection forcée vers HTTPS de cPanel ou de Plesk), une extension comme Really Simple Security (anciennement Really Simple SSL), et Cloudflare (Always Use HTTPS, règles de redirection). Tant qu'elles vont dans le même sens, tout marche ; dès que l'une renvoie vers http, ou vers l'autre version du www, la boucle est là.
4. Une extension de redirection, de langues ou de cache. Une règle qui envoie une page vers elle-même, ou une page A vers une page B et B vers A, dans une extension de redirection ou de référencement ; une extension de langues réglée pour un autre type d'adresse ; un cache qui a gardé une ancienne redirection et la ressert.
5. Les cookies ou la mémoire du navigateur, quand un seul navigateur est touché : des cookies abîmés, ou une ancienne redirection permanente (301), que les navigateurs gardent longtemps en mémoire.
6. PrestaShop ou Joomla mal accordés au https : le domaine de la boutique ou le domaine SSL de PrestaShop différent de l'adresse réelle, le SSL activé avant que le certificat fonctionne ; l'option de Joomla qui force le HTTPS, en plus d'une règle du serveur.
7. Plus rarement, des redirections que personne n'a posées, dans le .htaccess ou le code du site : vers des sites inconnus, seulement depuis Google ou sur téléphone, avec des fichiers que vous n'avez pas mis. C'est une intrusion repérée : suivez notre guide du site WordPress piraté.

1. Testez en navigation privée, puis effacez les cookies du site

Ouvrez une fenêtre de navigation privée (Ctrl + Maj + N dans Chrome et Edge, Ctrl + Maj + P dans Firefox, Cmd + Maj + N dans Safari) et tapez l'adresse du site. Essayez aussi sur un téléphone en 4G, sans le Wi-Fi. Si le site s'ouvre, le problème est dans votre navigateur : supprimez les cookies et les données de ce site seulement (dans Chrome, cliquez sur l'icône à gauche de l'adresse, puis sur les cookies et données des sites, ouvrez la gestion des données et supprimez celles de votre site), puis rechargez. Si l'erreur apparaît partout, la boucle est sur le site : continuez. Gardez ce réflexe pour la suite : après chaque correction, fermez toutes vos fenêtres de navigation privée et testez dans une fenêtre neuve, car une fenêtre restée ouverte, comme votre navigateur habituel, peut garder en mémoire l'ancienne redirection. La commande de l'étape 2, elle, ne garde rien en mémoire.

2. Suivez la chaîne de redirections

C'est l'étape qui dit où chercher. Sans rien installer, un outil en ligne de vérification des redirections donne la liste des adresses par lesquelles passe le site. Plus précis encore, la commande curl, présente sur Windows 10 et 11 comme sur Mac : sur Windows, ouvrez PowerShell (menu Démarrer, tapez PowerShell) ; sur Mac, ouvrez Terminal. Tapez cette commande avec l'adresse de votre site, puis Entrée :

curl.exe -I -L --max-redirs 10 http://votresite.fr/

Sur Mac, écrivez curl au lieu de curl.exe. La commande demande la page sans la télécharger, suit les redirections et s'arrête au bout de dix. Pour chaque étape, elle affiche une ligne qui commence par HTTP, avec le code (301, 302, 307 ou 308 pour une redirection), puis une ligne location: qui donne l'adresse suivante. Si elle s'arrête sur un message qui parle du nombre maximal de redirections, la boucle est confirmée. Recommencez avec https://, puis avec et sans www. Deux indices de plus : des lignes server: cloudflare et cf-ray veulent dire que le site passe par Cloudflare ; une ligne x-redirect-by: WordPress veut dire que la redirection vient du site lui-même, de WordPress ou de l'une de ses extensions, et non du serveur ni de Cloudflare ; le plus souvent, c'est WordPress qui renvoie vers la version avec ou sans www de son adresse.

3. Derrière Cloudflare, passez en Full (strict)

Vérifiez d'abord que le serveur a un certificat valide pour le domaine : dans l'espace de l'hébergeur, rubrique SSL ou Let's Encrypt, ou en le demandant au support. Sinon, faites-en installer un : celui de l'hébergeur, souvent gratuit, ou un certificat d'origine délivré par Cloudflare. Puis, dans le tableau de bord de Cloudflare, choisissez le domaine, ouvrez SSL/TLS, puis la vue d'ensemble (Overview), et cliquez sur Configure. Si le mode est sur Automatic SSL/TLS, passez au réglage personnalisé (Custom SSL/TLS) ; choisissez Full (strict) et enregistrez. Attendez une minute, puis testez en navigation privée. Sans certificat valide sur le serveur, Full (strict) donne une erreur 525 ou 526 : voyez notre guide des erreurs Cloudflare. Ne restez pas en Flexible : la liaison entre Cloudflare et votre serveur n'y est pas chiffrée. En attendant le certificat, et seulement en attendant, la boucle s'arrête aussi si le serveur cesse de forcer le https.

Ce même réglage explique une boucle limitée à l'administration : si l'adresse de WordPress est en https://, ou si wp-config.php met FORCE_SSL_ADMIN à true, WordPress impose le https à /wp-admin, et en mode Flexible il ne voit jamais arriver de visite en https. Ne retirez pas cette ligne : passez en Full (strict).

4. Accordez Always Use HTTPS et les règles de Cloudflare avec le serveur

Toujours dans Cloudflare, ouvrez SSL/TLS, puis Edge Certificates. Always Use HTTPS renvoie toute visite en http vers https : gardez-le, à condition que rien sur le serveur ne renvoie vers http. HSTS, sur la même page, impose aussi le https aux navigateurs ; avec un mode de chiffrement sur Off, il crée la même boucle. Ouvrez ensuite Rules : les règles de redirection (Redirect Rules), et les Page Rules s'il en reste. Une règle qui envoie vers www alors que WordPress ou le serveur envoie vers la version sans www, ou deux règles qui se renvoient l'une à l'autre, suffisent à créer la boucle. Pour chaque redirection (vers https, vers la version avec ou sans www), choisissez un seul endroit : Cloudflare ou le serveur.

5. Mettez la bonne adresse dans WordPress

Dans l'administration, ouvrez Réglages, puis Général. « Adresse web de WordPress (URL) » et « Adresse web du site (URL) » doivent donner l'adresse exacte du site, en https://, et dans la même version, avec ou sans www, que celle qu'imposent le serveur et Cloudflare. Enregistrez, puis testez en navigation privée. Si l'administration ne s'ouvre plus, ouvrez wp-config.php à la racine du site, par FTP ou avec le gestionnaire de fichiers de l'hébergeur, après en avoir téléchargé une copie : une faute de frappe dans ce fichier peut arrêter tout le site, et la copie permet de revenir en arrière en une seconde. Vérifiez qu'il ne contient pas déjà WP_HOME ou WP_SITEURL : s'ils y sont, corrigez l'adresse dans ces lignes au lieu d'en ajouter deux autres, car c'est la première définition qui compte. Sinon, ajoutez ces deux lignes au-dessus de la ligne qui demande de ne plus rien modifier (« That's all, stop editing » dans la version anglaise) :

define( 'WP_HOME', 'https://votresite.fr' );
define( 'WP_SITEURL', 'https://votresite.fr' );

Si votre site s'ouvre dans un sous-dossier (votresite.fr/blog), ajoutez ce dossier aux deux lignes. Si seuls les fichiers de WordPress sont rangés dans un sous-dossier alors que le site s'ouvre à la racine, seule WP_SITEURL se termine par ce dossier. Ces deux lignes l'emportent sur les réglages : tant qu'elles restent, les deux champs de Réglages, Général ne sont plus modifiables. Si votre hébergeur place devant le site un autre relais que Cloudflare, un cache ou un répartiteur de charge, WordPress peut ne pas savoir que la visite est en https : la documentation de WordPress prévoit une ligne à ajouter dans wp-config.php pour ce cas, que l'hébergeur vous confirmera.

6. Ne gardez qu'une redirection vers https, à un seul endroit

Ouvrez le fichier .htaccess, à la racine du site, après en avoir téléchargé une copie. C'est un fichier caché : dans FileZilla, menu Serveur, puis « Forcer l'affichage des fichiers cachés » ; dans le gestionnaire de fichiers de cPanel, Paramètres, puis « Afficher les fichiers cachés ». Cherchez, au-dessus du bloc # BEGIN WordPress, les règles qui parlent de HTTPS, de www ou de R=301 : un bloc # BEGIN Really Simple Security Redirect, des lignes RewriteCond %{HTTPS} off, une redirection posée par l'outil de redirections de l'hébergeur. Regardez aussi ses options : sous cPanel, la page Domaines et sa colonne Force HTTPS Redirect ; sous Plesk, dans les paramètres d'hébergement du domaine, la redirection permanente de HTTP vers HTTPS. N'en gardez qu'une, ou aucune derrière Cloudflare si Always Use HTTPS s'en charge déjà.

Le plus simple pour repartir propre : repérez d'abord, dans le fichier actuel, les blocs posés par l'hébergeur, comme celui qui commence par # php -- BEGIN cPanel-generated handler : il fixe la version de PHP du site. Renommez ensuite .htaccess en .htaccess.off, puis, dans l'administration, ouvrez Réglages, puis Permaliens, et cliquez sur « Enregistrer les modifications » sans rien changer : WordPress récrit son propre bloc. Si l'administration ne s'ouvre pas, créez un nouveau fichier .htaccess avec ce bloc :

# BEGIN WordPress
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

Recopiez-y aussitôt, tel quel, le bloc de l'hébergeur s'il y en avait un : sans lui, le site peut repartir avec une autre version de PHP. Reprenez ensuite, une à une, les autres règles utiles de l'ancien fichier, en testant en navigation privée après chacune. Celle qui ramène la boucle est à retirer, ou à remplacer par le réglage équivalent de l'hébergeur ou de Cloudflare.

7. Désactivez les extensions suspectes en renommant leur dossier

Par FTP ou avec le gestionnaire de fichiers, ouvrez wp-content/plugins. Commencez par les suspectes : l'extension de SSL (le dossier de Really Simple Security s'appelle really-simple-ssl), de redirection, de langues (WPML, Polylang, TranslatePress), de cache ou de sécurité. Renommez son dossier en ajoutant .off à la fin : WordPress la désactive. Si le site revient, vous tenez la coupable ; sinon, redonnez-lui son nom et passez à la suivante. Sans piste, renommez le dossier plugins entier, ouvrez la page Extensions pour que WordPress les désactive toutes, redonnez au dossier son nom, puis réactivez-les une à une, en testant après chacune. Après avoir désactivé Really Simple Security de cette façon, retirez aussi son bloc du .htaccess (étape 6), sans quoi sa redirection continue. Pour une seule page en boucle, regardez dans l'extension de redirection ou de référencement les règles qui la concernent : une page envoyée vers elle-même, ou deux pages qui se renvoient l'une à l'autre.

8. Videz tous les caches

Une redirection corrigée peut encore être servie par un cache. Videz celui de l'extension de cache (son bouton pour tout vider, ou le contenu du dossier wp-content/cache par FTP), celui de l'hébergeur s'il en propose un, puis celui de Cloudflare (Caching, puis Configuration, et la purge du cache). Testez ensuite en navigation privée : les navigateurs gardent longtemps en mémoire les redirections permanentes, et le vôtre peut encore vous montrer une boucle déjà réparée.

9. PrestaShop et Joomla : le domaine et l'option SSL

Sous PrestaShop 8 ou 9, ouvrez Paramètres de la boutique, puis Trafic et SEO : le domaine de la boutique et le domaine SSL doivent contenir exactement le nom de domaine du site, sans https:// ni barre oblique (par exemple www.votresite.fr), avec ou sans www comme le reste. Puis, dans les paramètres généraux de la boutique, n'activez le SSL (et, là où l'option existe, le SSL sur toutes les pages) qu'une fois le https en état de marche. Sans accès au back-office, ouvrez phpMyAdmin et exportez d'abord la base, pour pouvoir revenir en arrière. Dans la table ps_shop_url (le préfixe peut différer), vérifiez que les colonnes domain et domain_ssl contiennent ce même nom de domaine, sans https:// ni barre oblique ; si la boucle est apparue juste après l'activation du SSL, mettez PS_SSL_ENABLED et PS_SSL_ENABLED_EVERYWHERE à 0 dans la table ps_configuration, le temps de faire fonctionner le https, puis réactivez-les. Videz ensuite le contenu des dossiers var/cache/prod et var/cache/dev. Sous Joomla, l'option qui force le HTTPS se trouve dans la configuration globale, onglet Serveur ; sans accès à l'administration, téléchargez une copie du fichier configuration.php, à la racine du site, puis remettez à 0 la valeur de $force_ssl dans ce fichier.

10. Rien de tout cela ? L'hébergeur, avec la chaîne

Envoyez au support de l'hébergeur la liste donnée par la commande de l'étape 2, l'heure du test et ce que vous avez déjà essayé. Une redirection peut être posée dans la configuration du serveur lui-même, hors de votre portée : lui seul peut la voir et la retirer.

• Erreur 520, 521 ou 522 de Cloudflare. Le serveur qui héberge le site refuse la connexion, tarde trop ou répond de façon inattendue.
• Certificat de sécurité expiré ou invalide (SSL). « Votre connexion n'est pas privée », NET::ERR_CERT_DATE_INVALID et les autres alertes du navigateur.
• ERR_SSL_PROTOCOL_ERROR, connexion sécurisée impossible. « Ce site ne peut pas fournir de connexion sécurisée » : HTTPS pas en place sur le serveur, ou l'appareil du visiteur.
• Erreur 500 WordPress. « Internal Server Error » : le fichier .htaccess, une extension, la version de PHP ou la mémoire.
• Erreur 404, page introuvable. Toutes les pages sauf l'accueil (permaliens, .htaccess), ou une page déplacée sans redirection.

Toutes les erreurs, classées par message : Erreurs de site, trouver la cause et réparer. Des signes d'intrusion (redirections, pages inconnues, fichiers que vous n'avez pas mis) : suivez plutôt notre guide site WordPress piraté, que faire dans la première heure.

Rédigé par l'équipe Boost de WS Agency, qui maintient et protège des sites WordPress, PrestaShop et Joomla. Publié le 30 octobre 2026. Manipulations et documentations vérifiées le 30 octobre 2026 ; elles valent pour WordPress 6 et 7, et pour PrestaShop 8 et 9 quand ils sont cités.

• Cloudflare, ERR_TOO_MANY_REDIRECTS (mode Flexible, Always Use HTTPS, HSTS, règles de redirection).
• Cloudflare, les modes de chiffrement (Automatic SSL/TLS par défaut, Flexible sans chiffrement jusqu'au serveur, Full ou Full (strict) recommandés).
• WordPress, changer l'adresse du site (WP_HOME et WP_SITEURL) et HTTPS (FORCE_SSL_ADMIN, boucle sans fin derrière un relais).
• WordPress, le fichier .htaccess (bloc par défaut) et wp_redirect (en-tête X-Redirect-By).
• PrestaShop 8, paramètres généraux (activer le SSL, puis le SSL sur toutes les pages) et l'adresse de la boutique (un nom de domaine, sans http:// ni barre oblique).
• Google Search Central, erreurs HTTP et réseau (10 redirections suivies au plus) ; Search Console, rapport sur l'indexation des pages (erreur liée à des redirections).

Une erreur, une information à compléter, un droit de réponse ? Écrivez à contact@wsagency.fr : nous corrigeons, et nous indiquons ici ce qui a changé et quand.