Dépannage WordPress
Boucle de redirection WordPress : diagnostic sans perdre l’accès
Une boucle de redirection signifie que deux règles se renvoient la requête : HTTP vers HTTPS puis retour, domaine avec et sans www, connexion refusée par cookie ou canonicalisation répétée. Vider le cache ne suffit pas si les règles se contredisent.
Ce que ce symptôme signifie réellement
La chaîne de réponses 301/302 et leurs en-têtes Location montre les deux URL en conflit. Derrière un proxy ou Cloudflare, WordPress doit aussi recevoir correctement le protocole d’origine.
Une boucle limitée à wp-admin peut venir des cookies, d’une URL de site incohérente, d’une extension de sécurité ou d’une session, tandis qu’une boucle globale pointe souvent vers la couche serveur/CDN.
Avant toute modification : préserver les preuves et le retour arrière
Notez l’heure, l’URL, le message exact, le code HTTP et le dernier changement connu. Vérifiez ensuite qu’une sauvegarde récente couvre bien les fichiers et la base de données, qu’elle est lisible et qu’un retour arrière limité est possible. Une sauvegarde non testée ne suffit pas pour une intervention risquée.
- Ne transmettez jamais de mot de passe, clé privée, jeton, fichier
wp-config.phpou export de base dans un formulaire ou une capture. - Travaillez d’abord sur un staging ou une copie isolée lorsque le diagnostic exige une mise à jour, une modification de code ou une opération de base de données.
- Conservez les journaux et les fichiers suspects avant nettoyage : ils peuvent être nécessaires pour comprendre la cause ou vérifier l’étendue d’un incident.
Diagnostic : avancer du signal le plus fiable au test le moins intrusif
Capturez la chaîne sans suivre automatiquement les redirections, depuis l’origine et le domaine public. Notez protocole, hôte, chemin et cookies.
- Comparer
homeetsiteurlavec le domaine attendu, sans les modifier à l’aveugle. - Inspecter règles nginx/Apache, proxy, CDN et extension de redirection pour repérer la même canonicalisation à plusieurs niveaux.
- Tester une fenêtre privée et les cookies du domaine pour séparer session et règle serveur.
- Contrôler une URL publique, la connexion, l’administration et l’API REST.
Correction : appliquer une action ciblée et réversible
Choisissez une seule couche responsable de chaque redirection : protocole, hôte, ancien slug ou authentification.
- Corriger la détection HTTPS du proxy et les en-têtes de confiance uniquement pour les proxys connus.
- Aligner les URL WordPress avec le domaine final après sauvegarde et accès de secours vérifié.
- Retirer la règle dupliquée au niveau le plus approprié et tester la configuration avant rechargement serveur.
- Purger les caches ciblés et révoquer seulement les cookies/sessions nécessaires.
Contrôles après correction
Une page qui se recharge ne suffit pas à prouver que le problème est résolu. Contrôlez le parcours concerné, une page non connectée, l’administration, les erreurs console et réseau, les journaux serveur, le cache et les redirections. Vérifiez aussi les écrans mobile et desktop si le symptôme touchait le rendu.
- Une seule redirection vers l’URL finale puis HTTP 200.
- Connexion et déconnexion sans boucle sur plusieurs navigateurs.
- Canonical, sitemap et liens internes utilisent tous le même hôte/protocole.
Quand arrêter et demander une intervention
Si vous risquez de perdre l’administration ou si DNS/CDN/origine ne sont pas clairement identifiés, préparez un accès serveur et un rollback de configuration avant toute modification.