ERR_TOO_MANY_REDIRECTS WordPress : la corriger

Votre site tourne en rond — et le navigateur abandonne

ERR_TOO_MANY_REDIRECTS. Chrome, Firefox, Safari : peu importe le navigateur, le message est le même. Le serveur renvoie le visiteur vers une URL, qui renvoie vers une autre, qui renvoie vers la première. Le navigateur compte les boucles, arrive à son seuil (souvent 20), et déclare forfait.

Résultat : site inaccessible, visiteurs perdus, Google qui ne peut plus crawler. La bonne nouvelle : dans 90 % des cas, la cause est identifiable en moins de dix minutes. Ce guide va dans l’ordre, du diagnostic le plus simple au plus technique.

Pourquoi ça arrive : les 5 causes principales

• URLs siteurl / home incohérentes dans la base de données — l’une pointe en http://, l’autre en https://, ou les deux contiennent le mauvais domaine.
• Forçage HTTPS dans WordPress (wp-config.php ou plugin) sans certificat SSL valide côté serveur, ce qui crée une boucle HTTP → HTTPS → HTTP.
• Cloudflare en mode SSL “Flexible” : Cloudflare parle HTTPS à votre navigateur, mais HTTP à votre serveur. Si WordPress force HTTPS, la requête rebondit indéfiniment.
• Plugin de redirection ou plugin de cache qui applique des règles contradictoires (ex. redirection www → non-www ET non-www → www simultanément).
• .htaccess corrompu ou mal configuré avec des règles de redirection qui se contredisent.

Solution 1 — Vider les cookies et le cache navigateur (30 secondes)

Avant tout diagnostic serveur, testez en navigation privée. Si le site s’affiche, le problème est dans le cache de votre navigateur.

1. Chrome : Ctrl+Shift+Del → cochez “Cookies et autres données des sites” + “Images et fichiers en cache” → Effacer les données.
2. Testez ensuite en navigation privée (Ctrl+Shift+N).
3. Si ça passe, videz aussi le cache de votre plugin (WP Rocket, W3 Total Cache, LiteSpeed Cache) depuis le tableau de bord WordPress.

Si le problème persiste en navigation privée, passez à la suite.

Solution 2 — Corriger les URLs siteurl et home dans WordPress

C’est la cause n°1. Les deux options pour corriger :

Via wp-config.php (sans accès au back-office)

Ajoutez ces deux lignes avant la ligne /* C'est tout, arrêtez la modification ! */ :

define('WP_HOME', 'https://votredomaine.com');
define('WP_SITEURL', 'https://votredomaine.com');

Ces constantes écrasent la base de données au runtime. Elles doivent être identiques, avec le bon protocole (https:// si vous avez un certificat valide, http:// sinon).

Via phpMyAdmin

1. Accédez à votre base de données → table wp_options.
2. Filtrez sur option_name = 'siteurl' et option_name = 'home'.
3. Les deux doivent pointer vers la même URL, avec le même protocole.
4. Corrigez puis sauvegardez.

Solution 3 — Régler Cloudflare SSL en mode “Full” ou “Full (strict)”

Le mode SSL Flexible de Cloudflare est la bête noire des sites WordPress avec HTTPS. Voici ce qui se passe :

Navigateur → HTTPS → Cloudflare → HTTP → Serveur
Serveur voit du HTTP, répond HTTP
WordPress force HTTPS → renvoie vers HTTPS
Cloudflare reçoit HTTPS, renvoie HTTP au serveur
→ boucle infinie

Correction :

1. Dashboard Cloudflare → votre domaine → SSL/TLS.
2. Passez le mode de Flexible à Full (si votre certificat est auto-signé) ou Full (strict) (si votre certificat est valide — Let’s Encrypt, par exemple).
3. Videz le cache Cloudflare : Caching → Configuration → Purge Everything.

Si vous n’êtes pas encore sur HTTPS et que Cloudflare est en Flexible, retirez temporairement tout forçage HTTPS dans WordPress avant de migrer proprement. La configuration DNS et SSL sur un domaine personnalisé suit la même logique, même sur d’autres hébergeurs.

Solution 4 — Désactiver les plugins en masse (sans accès au back-office)

Si vous ne pouvez pas vous connecter au tableau de bord, désactivez tous les plugins via FTP ou le gestionnaire de fichiers de votre hébergeur :

1. Accédez à wp-content/plugins/.
2. Renommez le dossier plugins en plugins_disabled.
3. Testez le site.
4. Si la boucle disparaît, renommez en plugins, puis entrez dans WordPress et réactivez les plugins un par un pour identifier le coupable.

Les suspects habituels : Really Simple SSL, WP Force SSL, Redirection, Yoast SEO (quand ses redirections canoniques entrent en conflit), les plugins de cache avec redirection www activée.

Pour un rollback propre après une mise à jour qui a tout cassé, la méthode est détaillée dans cet article sur les plugins cassés après MAJ.

Solution 5 — Nettoyer ou régénérer le .htaccess

Un .htaccess cassé peut provoquer des redirections circulaires, surtout si quelqu’un y a ajouté manuellement des règles HTTP→HTTPS en plus d’un plugin qui fait la même chose.

1. Via FTP, renommez .htaccess en .htaccess_old.
2. Créez un nouveau fichier .htaccess avec le contenu WordPress par défaut :

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

3. Testez. Si ça passe, le .htaccess précédent contenait des règles contradictoires.
4. Pour le régénérer proprement depuis WordPress : Réglages → Permaliens → Enregistrer les modifications (sans rien changer).

Solution 6 — Supprimer la constante FORCE_SSL_ADMIN si mal placée

Dans certains wp-config.php, on trouve :

define('FORCE_SSL_ADMIN', true);

Si votre hébergeur ne termine pas le SSL au niveau du serveur mais via un proxy (Cloudflare Flexible, load balancer…), cette constante peut créer une boucle sur la page de connexion /wp-admin/. Commentez-la temporairement pour tester :

// define('FORCE_SSL_ADMIN', true);

Tableau récapitulatif : cause → diagnostic → correction

Quand passer la main à un pro

Si après ces six étapes la boucle persiste, le problème est probablement dans la configuration de votre hébergeur (terminaison SSL, load balancer, reverse proxy) — une couche que WordPress ne contrôle pas. C’est le moment de contacter le support hébergeur avec les logs d’accès en main, ou de faire intervenir quelqu’un qui peut lire ces logs et tracer la redirection incriminée requête par requête.

Un site sous maintenance active ne devrait jamais tomber sur ce genre de boucle sans alertes préventives : la plupart se déclenchent juste après une modification de configuration ou une mise à jour — exactement le moment où un œil humain doit être présent.