Passer au contenu 
J'explique de manière concise et claire comment tu peux obtenir un Boucle de redirection WordPress les analyser proprement et y mettre fin de manière fiable. Je te montre des solutions prêtes à l'emploi pour les conflits SSL, les règles .htaccess erronées, les URL de site incorrectes, les problèmes de cache/cookies, les problèmes de plugins et les paramètres de serveur - y compris les tests et la prévention.
Points centraux
La liste suivante résume les gestes essentiels avant que je n'explique les étapes en détail.
- Cause limiter rapidement : SSL, .htaccess, URLs, plugins, cache
- Standard-Vérifier les règles : .htaccess et wp-config.php
- HTTPS définir correctement : Certificat, Contenu mixte, HSTS
- Plugins désactiver à titre d'essai : par tableau de bord ou FTP
- Prévention mettre en place : sauvegardes, documentation, surveillance
Que signifie concrètement une boucle de redirection ?
A Boucle de redirection se produit lorsque l'URL A saute à l'URL B et que B revient à A - ou lorsque plusieurs sauts conduisent à la fin à l'adresse de départ. Le navigateur s'interrompt alors avec ERR_TOO_MANY_REDIRECTS et bloque l'appel. Je reconnais souvent la boucle au fait que le login charge à nouveau le formulaire de login après une saisie correcte. Pour les visiteurs, cela ressemble à une ronde sans fin, pour les moteurs de recherche à une erreur technique. Cela coûte de la confiance, empêche les connexions au backend et consomme de précieux budgets d'exploration.
Principales causes des boucles dans WordPress
Je trouve les déclencheurs les plus fréquents dans faux des URL WordPress, des règles .htaccess agressives, des doubles forçages SSL ou des redirections de plugins chaotiques. Les anciens cookies et le cache dur du navigateur envoient également les demandes dans l'erreur. Après un changement de domaine ou une conversion HTTPS, les erreurs se multiplient car http et https se mélangent. Dans le cas de thèmes avec leurs propres redirections ou plugins de sécurité, les règles peuvent se bloquer mutuellement. Dans de rares cas, les logiciels malveillants mettent en place des redirections ciblées afin de bloquer les administrateurs.
Tests rapides dans le navigateur : Cookies et cache
Je commence par un Client-parce qu'il permet d'y voir clair en quelques minutes. Je supprime les cookies et le cache complet pour le domaine concerné. Une fenêtre privée permet d'exclure les anciennes sessions. Si la connexion fonctionne, le problème vient des données locales et non du serveur. Si l'erreur persiste, je m'attaque au niveau du serveur et de WordPress.
Vérifier .htaccess et réinitialiser par défaut
Je sécurise les .htaccess et les réinitialise à la norme WordPress à titre d'essai. J'élimine ainsi les redirections conflictuelles issues d'expériences précédentes ou de règles SEO.
# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteRule ^index\p$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress
Si tout fonctionne ensuite, j'ajoute des redirections supplémentaires étape par étape. Pour des conditions propres, je renvoie à Redirections htaccess avec des exemples pratiques. Important : ne jamais forcer deux fois http→https - une seule fois au niveau du serveur suffit.
Aligner les URL WordPress dans les préférences et le fichier wp-config.php
Ecarts entre WP_HOME et WP_SITEURL déclenchent souvent des boucles sans fin, surtout après des déménagements de domaines. Je vérifie d'abord Paramètres > Général. Si le backend n'est pas accessible, je fixe brièvement les valeurs dans le wp-config.php :
define( 'WP_HOME', 'https://deinedomain.de' ) ;
define( 'WP_SITEURL', 'https://deinedomain.de' ) ;
En cas de problème Admin-SSL, je débloque temporairement l'accès avec :
define('FORCE_SSL_ADMIN', false) ;
Dès que je suis dans le tableau de bord, je mets des URL correctes et je supprime les constantes. Les adresses uniformes évitent les nouvelles boucles.
Résoudre proprement les conflits HTTPS/SSL
Les conflits surviennent lorsque SSL est forcé côté serveur et qu'en plus un plugin définit des redirections. Je teste d'abord si le certificat est valable et si HSTS ou les en-têtes de proxy ne perturbent pas la reconnaissance. Ensuite, je veille à ce que le https soit forcé à un endroit précis, de préférence au niveau du serveur. J'élimine systématiquement les erreurs de contenu mixte et les chaînes de redirection erronées. Pour la conversion concrète, ce guide m'aide à Conversion HTTPS dans WordPress.
Limiter les plugins et les thèmes comme source d'erreur
J'ai mis en place des Plugins en particulier les outils de redirection, de référencement et de sécurité. Si je ne peux pas accéder au backend, je renomme par FTP le dossier wp-content/plugins en plugins.old. Ensuite, j'active chaque plugin individuellement dans le tableau de bord jusqu'à ce que l'erreur réapparaisse. Un passage à un thème standard comme Twenty Twenty-Four permet également de voir si le thème contribue à des règles. Je trouve ainsi rapidement la cause et rétablis une configuration sans conflit.
Mettre fin aux boucles de connexion : Cookies, sessions, sécurité
Si le login ne fonctionne pas malgré une Données je vérifie le domaine du cookie, le chemin et le drapeau https. Je vide les caches à tous les niveaux : Navigateur, cache WordPress, cache d'objets, CDN. Pour les plug-ins de sécurité, je contrôle les règles qui redirigent les URL d'administration ou limitent les connexions. Je définis temporairement des valeurs par défaut claires pour le diagnostic et rétablis ensuite la sécurité petit à petit. Objectif : une session stable sans double redirection.
Définir correctement le reverse proxy, le CDN et les en-têtes de serveur
Derrière un Proxy les applications confondent facilement http et https lorsque l'en-tête Forwarded ou X-Forwarded Protocol est manquant ou mal reçu. Je vérifie les configurations Nginx/Apache, les paramètres de l'équilibreur de charge et les redirections CDN. Il est important que WordPress reconnaisse correctement l'URL client réelle. Pour les configurations avec proxy en amont, ce guide m'aide à Mettre en place un reverse proxy. J'évite ainsi des règles contradictoires entre le serveur, le CDN et le plugin.
Les logiciels malveillants comme dernière source de suspicion
Si, malgré toutes les corrections, la boucle ne se laisse pas interrompre pas je scanne l'installation à la recherche de codes malveillants. Je compare les fichiers de base avec les originaux, je vérifie les nouveaux administrateurs et les tâches Cron. Je démasque les redirections dans les en-têtes, les fichiers de modèles ou via JavaScript en recherchant window.location, meta refresh ou d'obscures chaînes Base64. Après le nettoyage, je redéfinis les mots de passe et je fais une nouvelle sauvegarde. La sécurité contre la réinfection permet d'économiser beaucoup de temps par la suite.
Prophylaxie et surveillance au quotidien
J'évite les boucles en Modifications gérer les redirections de manière centralisée et les tester dans un environnement de staging avant les déploiements en direct. J'effectue des sauvegardes automatisées et je tiens à jour les plugins et les thèmes. Après un changement de domaine, je contrôle les URL de site, le SSL et les chaînes de redirection. Un petit monitoring me signale à temps les sauts de code d'état. Le tableau suivant aide à établir un diagnostic rapide en cours d'utilisation.
| Symptôme | Cause possible | Action directe | Outil de contrôle |
|---|---|---|---|
| ERR_TOO_MANY_REDIRECTS | Double forçage https | Utiliser un seul endroit pour les redirections | Contrôle de l'en-tête HTTP, Curl |
| Le login revient en arrière | Conflit cookie/session | Supprimer les cookies, vider le cache | Fenêtre privée, DevTools |
| La page d'accueil ne se charge pas | Boucle .htaccess | Activer le .htaccess standard | Logs du serveur, diff |
| Erreur uniquement sous proxy | En-tête de protocole incorrect | Définir correctement le protocole X-Forwarded | Configuration du proxy, suivi des en-têtes |
| Soudain à partir du classement | Chaînes de redirection | Réduire les chaînes, 301 correct | Crawler, Grenouille hurlante |
Suivre les redirections avec précision : Trace d'en-tête et Curl
Avant de tourner les configurations, je dessine les chaîne exacte après . Dans les DevTools (onglet réseau), tu peux voir chaque saut avec le code d'état et l'en-tête de localisation. Dans le shell, cela suffit souvent :
curl -IL https://deinedomain.de
# ou détaillé avec affichage de chaque redirection
curl -IL --max-redirs 20 https://deinedomain.de
Je fais attention aux modèles comme http→https→http (va-et-vient) ou www↔non-www. Un 302 qui suit un 301 est également suspect. Si la première requête redirige déjà vers /wp-login.php, la cause se trouve généralement dans le plugin/thème ou les cookies ; si cela se produit globalement, c'est souvent .htaccess ou le serveur.
Utiliser les logs du serveur et de WordPress de manière ciblée
Les logs font gagner des heures. J'active le journal de débogage dans le fichier wp-config.php sans l'afficher aux visiteurs :
define('WP_DEBUG', true) ;
define('WP_DEBUG_LOG', true) ;
define('WP_DEBUG_DISPLAY', false) ;
@ini_set('display_errors', 0) ;
Ensuite, je vérifie /wp-content/debug.log à la recherche d'indices (par exemple "Cannot modify header information" avant une redirection). En parallèle, je consulte les logs du serveur web. Pour Apache : access.log et error.log, pour Nginx : access.log avec statut 301/302. Un coup d'œil dans l'agent utilisateur permet de savoir si seuls les bots ou tous les utilisateurs sont concernés.
WP-CLI : sauvetage rapide par console
Si le tableau de bord n'est pas accessible, je résous beaucoup de choses par WP-CLI:
# Vérifier et définir les URLs
wp option get home
wp option get siteurl
wp option update home 'https://deinedomain.de'
wp option update siteurl 'https://deinedomain.de'
# "Sauvegarder" les permaliens une fois
wp rewrite flush --hard
# Vider les caches
wp cache flush
wp transient delete --all
# Désactiver les plugins en masse / tester de façon ciblée
wp plugin deactivate --all
wp plugin activate classic-editor
Ainsi, je peux revenir au système sans risque, trouver les fautifs et n'activer que ce qui est vraiment nécessaire.
www, slash et canonisation sans boucle
Souvent, les boucles résultent de petites incohérenceswww vs. non-www, slash manquant/supplémentaire ou protocole mixte. J'opte pour une variante et je ne mets que a Chaîne de règles. Exemple non-www→www dans Apache (sans double forçage https) :
RewriteEngine On
# Transférer uniquement si l'hôte n'est pas déjà www
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.%{HTTP_HOST}/$1 [L,R=301]
Avec Nginx, je mets en place une redirection serveur-bloc claire et j'évite les règles mixtes dans PHP/plugins. Important : d'abord la canonicalisation (www/Slash), puis https - et seulement vers a poste.
Propre derrière le proxy/CDN : reconnaître correctement HTTPS
Si WordPress se trouve derrière un load-balancer ou un CDN, il arrive souvent que seul le http arrive au backend, bien que le client utilise le https. WordPress reconnaît alors mal is_ssl() et génère des boucles. Je corrige les variables du serveur au plus tôt dans le fichier wp-config.php :
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
$_SERVER['HTTPS'] = 'on' ;
}
En outre, je définis les en-têtes X-Forwarded-Proto et Forwarded proprement sur le proxy. J'utilise HSTS avec parcimonie : Si HSTS est actif, il peut pas de http, sinon le navigateur se bloque. Je n'utilise le Preload que lorsque tous les sous-domaines sont stables en https.
Désamorcer les pièges de la connexion et des cookies
Les cookies mal définis sont une source fréquente. En règle générale, je place pas de COOKIE_DOMAIN. Si elle a été définie une fois, je la change à titre d'essai :
define('COOKIE_DOMAIN', false) ;
Je vérifie également que l'indicateur de cookie admin "Secure" est activé sous https et que le chemin d'accès est "/". En cas de problèmes persistants, je supprime les sessions côté serveur (par ex. redémarrer php-fpm) et je vide le cache d'objets/les redis afin que les anciens nonces n'aient plus d'effet.
Particularités du multisite et du mapping de domaines
À l'adresse suivante : Multisite-Des mappings différents conduisent rapidement à une boucle : Mode sous-domaine vs. répertoire, protocoles différents ou un ancien plugin de mappage de domaine avec ses propres redirections. Je vérifie les tables de blog et de site, je fais correspondre les protocoles et les hôtes et je désactive brièvement les redirections automatiques du changement de langue. Un login "Super Admin" dans le blog principal aide à voir les redirections réseau de manière centralisée. Important : une seule instance décide du domaine canonique.
WooCommerce, multilinguisme et "Hide Login
Les boutiques et les sites multilingues possèdent des logiques de redirection supplémentaires : pages SSL forcées (caisse/compte), redirection linguistique selon Accept-Language ou fonctions "Hide Login" dans les plugins de sécurité. Pour le diagnostic, je désactive la redirection automatique de la langue et autorise /wp-login.php temporairement sans détour. Dans WooCommerce, je sécurise "Seulement ces pages sur SSL" soit proprement côté serveur, soit complètement dans tout le système, afin d'éviter les états mixtes.
Coordonner le cache d'objet, l'opcode et le cache d'extrémité
Plusieurs couches de mise en cache peuvent se mutuellement renforcer : opcode PHP (OPcache), cache d'objets (Redis/Memcached), cache de pages de plugins et CDN-Edge. Je les vide dans l'ordre, afin qu'aucune couche ne renvoie d'anciennes redirections. Après des modifications de règles, j'invalide complètement le cache Edge. Ce n'est qu'après cela qu'un test est significatif.
Les pièges typiques de Nginx
Avec Nginx, des boucles apparaissent lorsque les blocs location font double emploi ou lorsque /index.php réside en interne et en externe. J'utilise une seule configuration propre : d'abord la redirection des blocs du serveur (www/https), puis un try_files clair sur /index.php. J'évite systématiquement les mélanges de add_header Refresh et 301/302.
Liste de contrôle : la cause en 10 minutes
- Supprimer les cookies/cache localement, tester en mode incognito
- curl -IL et voir la chaîne
- Réinitialiser .htaccess/Nginx au chemin par défaut
- Faire correspondre WP_HOME/WP_SITEURL (via WP-CLI si nécessaire)
- Une seule instance impose le https (serveur préféré)
- Désactiver les plugins/thèmes, les activer progressivement
- Définir correctement l'en-tête du proxy, vérifier is_ssl()
- Vider le cache d'objet/de page/de bordure
- Vérifier les logs : debug.log, access/error.log
- Caractéristiques particulières : Multisite, Woo, Langues, Hide-Login
Des images d'erreurs au-delà des boucles classiques
Tous les 301/302 ne sont pas de vraies boucles - mais Erreurs d'aiguillage coûtent également. Un 301 vers 404 signale aux moteurs de recherche "cette ressource est ici pour toujours", mais renvoie du vide. Ou un 302 au lieu d'un 301 empêche la consolidation permanente des signaux. Je garde la chaîne à un ou deux niveaux maximum, je mets 301 pour les cas permanents, 302 pour les cas temporaires et j'évite les pertes de chaînes de requête en transmettant correctement les indicateurs QSA ou args.
Déploiements stables et documentation
Afin d'éviter les boucles, je documente chaque règleQui fait quoi et où - et pourquoi ? J'utilise un environnement de staging, j'y fais passer les changements de règles, je consigne les en-têtes et les temps et je distribue ensuite des réglages de serveur et de plugin identiques en production. Un bref contrôle post-déploiement (page d'accueil, connexion, caisse, langue) permet d'éviter les pannes.
Conclusion en bref
Je résous une Boucle de redirection systématiquement : vérifier les cookies, rétablir le .htaccess par défaut, aligner les URL WP, définir proprement le SSL, isoler les plugins/thèmes et livrer correctement les en-têtes du serveur. Avec ces étapes, la boucle se termine généralement en peu de temps. Ensuite, je sécurise l'installation, je documente les redirections et je tiens les mises à jour à jour. Ainsi, le login reste accessible, les visiteurs atterrissent sur les bonnes pages et les moteurs de recherche explorent sans perte de temps. En procédant de manière structurée, on évite les répétitions - et on économise ses nerfs.
