ERR_TOO_MANY_REDIRECTS : boucle de redirection WordPress

ERR_TOO_MANY_REDIRECTS

En anglais : ERR_TOO_MANY_REDIRECTS

Votre navigateur affiche une page d’erreur grise au lieu de votre site : « Cette page ne fonctionne pas », suivi de « … vous a redirigé à de trop nombreuses reprises », dans Chrome et Edge, avec le code ERR_TOO_MANY_REDIRECTS ; « La page n’est pas redirigée correctement » dans Firefox. Le problème peut toucher tout le site, seulement l’administration (wp-login.php et wp-admin) ou quelques URL précises. Il ne s’agit pas d’une erreur de WordPress mais d’un symptôme : deux règles de redirection se renvoient la visiteuse ou le visiteur indéfiniment, et le navigateur finit par abandonner.

Ce que signifie cette erreur

Une redirection est une réponse HTTP 301 ou 302 accompagnée d’un en-tête Location. Le navigateur suit la chaîne, mais s’arrête à une vingtaine de sauts environ. Si l’URL A renvoie vers B et que B renvoie vers A, la limite est atteinte en une fraction de seconde. WordPress, le serveur web (Apache, nginx), une extension, un CDN ou un proxy peuvent chacun émettre une redirection : la boucle naît presque toujours d’un désaccord entre deux de ces acteurs sur l’adresse « correcte » du site (http ou https, avec ou sans www, avec ou sans barre oblique finale).

Côté WordPress, trois mécanismes entrent en jeu. La fonction redirect_canonical() de wp-includes/canonical.php compare l’URL demandée à l’adresse enregistrée dans les options home et siteurl et redirige en 301 si elles diffèrent. Le fichier wp-login.php redirige vers HTTPS quand force_ssl_admin() est vrai et que is_ssl() est faux. Or force_ssl_admin() est activée automatiquement lorsque l’option siteurl commence par https (wp-includes/default-constants.php), et is_ssl() (wp-includes/load.php) ne regarde que la variable serveur HTTPS ou le port 443. Derrière un proxy ou un CDN qui parle en HTTP à votre serveur, WordPress croit donc que la requête n’est pas sécurisée, redirige vers HTTPS, le proxy retransmet en HTTP, et la boucle est lancée.

Diagnostic rapide

Symptôme / constat	Cause probable	À vérifier
Boucle sur tout le site après le passage à HTTPS ou l’activation de Cloudflare	Mode SSL « Flexible » ou proxy qui ne transmet pas le protocole d’origine	Mode SSL du CDN, en-tête X-Forwarded-Proto, options home et siteurl
Boucle uniquement sur /wp-admin ou /wp-login.php	FORCE_SSL_ADMIN actif alors que WordPress ne détecte pas HTTPS, ou cookie corrompu	wp-config.php, test en navigation privée
Boucle après une migration ou un changement de domaine	Options home et siteurl différentes de l’URL réellement servie	Réglages généraux, ou wp option get home
Boucle après modification de .htaccess ou de la configuration nginx	Règle de redirection en double (www, https, barre finale)	Contenu de .htaccess, blocs server nginx
Boucle après l’installation d’une extension de redirection ou de SEO	Extension qui redirige en conflit avec le serveur ou le thème	Désactivation des extensions, en-tête X-Redirect-By

Les causes les plus fréquentes

1. Un CDN ou un proxy inverse (Cloudflare en mode « Flexible », reverse proxy nginx, load balancer) qui transmet les requêtes en HTTP alors que le site impose HTTPS.
2. Des options home et siteurl incohérentes entre elles ou avec l’adresse réellement utilisée (http contre https, www contre sans www).
3. Une règle de redirection HTTPS ou www dans .htaccess, la configuration nginx ou le panneau de l’hébergeur qui s’ajoute à celle de WordPress ou d’une extension.
4. Une extension de redirection, de sécurité, de cache ou de SEO mal configurée, ou deux extensions qui font la même chose.
5. Des cookies obsolètes ou corrompus, qui provoquent une boucle entre wp-login.php et wp-admin.
6. Un .htaccess ou des règles de réécriture personnalisées cassées après une mise à jour ou une migration.

Solutions pas à pas

1. Écarter le navigateur et les cookies

Ouvrez le site dans une fenêtre de navigation privée ou depuis un autre navigateur. Si la page s’affiche, supprimez les cookies et le cache de ce site depuis les paramètres de confidentialité du navigateur, puis reconnectez-vous. Si l’erreur persiste partout, elle vient du serveur.

2. Lire la chaîne de redirections

Plutôt que de deviner, regardez ce que le serveur répond réellement. Avec curl, limitez le nombre de sauts pour voir la boucle sans attendre :

curl -sIL --max-redirs 6 https://www.exemple.fr/ | grep -iE '^(HTTP|location|x-redirect-by|server)'

Lisez la suite des URL de l’en-tête Location. Si elle alterne entre http://… et https://…, c’est un problème de protocole ; entre www et sans www, un problème de domaine. L’en-tête X-Redirect-By: WordPress prouve que la redirection est émise par wp_redirect(), donc par WordPress ou une extension ; son absence désigne le serveur web, l’hébergeur ou le CDN. Une fois la limite atteinte, curl indique Maximum (6) redirects followed.

3. Faire reconnaître HTTPS à WordPress derrière un proxy ou un CDN

Si votre site passe par Cloudflare ou un reverse proxy, commencez par régler le mode de chiffrement du CDN sur « Full » ou « Full (strict) » plutôt que « Flexible » : notre retour d’expérience sur la boucle de redirections avec Cloudflare détaille ce cas. Si le proxy est de confiance et transmet l’en-tête X-Forwarded-Proto, ajoutez ceci dans wp-config.php, avant la ligne require_once ABSPATH . 'wp-settings.php'; :

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && 'https' === $_SERVER['HTTP_X_FORWARDED_PROTO'] ) {
    $_SERVER['HTTPS'] = 'on';
}

Si le proxy est un nginx placé devant Apache, il doit envoyer l’en-tête :

proxy_set_header X-Forwarded-Proto $scheme;

4. Corriger les adresses du site

Si vous accédez à l’administration, vérifiez Réglages, Général : « Adresse WordPress (URL) » et « Adresse web (URL du site) » doivent utiliser le même protocole et le même domaine que celui servi. Sans accès, forcez-les dans wp-config.php :

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

Ces constantes priment sur les valeurs de la base. Vous pouvez aussi corriger la base elle-même, après sauvegarde, avec WP-CLI ou en SQL (adaptez le préfixe de table) :

wp option update home 'https://www.exemple.fr'
wp option update siteurl 'https://www.exemple.fr'

UPDATE wp_options SET option_value = 'https://www.exemple.fr' WHERE option_name IN ('home', 'siteurl');

5. Nettoyer les règles du serveur

Faites une copie de .htaccess, puis remplacez son contenu par le bloc standard de WordPress :

# BEGIN WordPress
<IfModule mod_rewrite.c>
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]
</IfModule>
# END WordPress

Si le site revient, réintroduisez vos règles une à une. Pour imposer HTTPS sans créer de boucle derrière un proxy, testez aussi l’en-tête transmis :

RewriteCond %{HTTPS} !=on
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Sous nginx, la redirection vers HTTPS doit vivre dans un bloc server distinct qui écoute le port 80, et le bloc HTTPS ne doit pas contenir de return 301 vers lui-même :

server {
    listen 80;
    server_name exemple.fr www.exemple.fr;
    return 301 https://www.exemple.fr$request_uri;
}

6. Désactiver les extensions de redirection

Renommez le dossier wp-content/plugins en plugins-off par SFTP, ou utilisez WP-CLI, puis testez à nouveau :

wp plugin deactivate --all

Si la boucle disparaît, réactivez les extensions une à une pour trouver la coupable (sécurité, cache, SEO, redirections, multilingue). Notre article sur la règle de réécriture qui casse l’URL canonique montre un cas d’interférence avec redirect_canonical().

Prévenir l’erreur

• Après un passage à HTTPS ou un changement de domaine, suivez une checklist complète, comme notre checklist de migration WordPress.
• N’empilez qu’un seul mécanisme de redirection HTTPS ou www : serveur, CDN ou extension, mais pas les trois.
• Vérifiez avec curl -IL toute nouvelle règle de redirection avant de la déployer en production.
• Documentez le chemin complet d’une requête (CDN, proxy, serveur web, PHP) et le protocole vu par chaque maillon.
• Conservez une sauvegarde de .htaccess et de wp-config.php avant chaque modification.

FAQ