Trop de redirections après le passage de WordPress à HTTPS

Ce que signifie cette erreur et comment la reconnaître

• Le site fonctionnait en HTTP avant la migration vers HTTPS, puis a commencé à afficher « trop de redirections ».
• Le navigateur bascule sans cesse entre HTTP et HTTPS ou demande répétitivement la même adresse HTTPS.
• L’ensemble du site peut être inaccessible, ou seuls /wp-admin, la page de connexion ou certains chemins peuvent être en boucle.
• L’ouverture de l’adresse HTTP peut produire une redirection HTTPS attendue, suivie de redirections répétées au lieu d’une réponse normale.
• La navigation privée ou un autre appareil peut se comporter différemment en raison de redirections, cookies ou données de site mis en cache.

Causes principales, classées par probabilité

1. Les paramètres d’URL de WordPress utilisent encore HTTP. Si WordPress Address (URL) ou Site Address (URL) est toujours en HTTP alors qu’une autre couche impose HTTPS, WordPress peut rediriger vers un protocole en conflit avec la politique du serveur.
2. L’application de HTTPS existe à plusieurs niveaux. Un plugin de sécurité, une logique dans wp-config.php, une règle .htaccess ou Nginx, un réglage de l’hébergeur et une règle du proxy peuvent se chevaucher ou reposer sur des hypothèses différentes concernant le protocole de la requête.
3. Un CDN ou un reverse proxy termine TLS. Le visiteur se connecte en HTTPS tandis que la connexion vers l’origine s’effectue en HTTP. Si le protocole d’origine est absent, incorrect ou insuffisamment fiable, WordPress peut continuer à considérer la requête comme non sécurisée.
4. Un plugin ou un thème redirige un chemin spécifique. Les plugins de connexion, d’administration, d’URL canoniques, de sécurité et d’adhésion peuvent affecter uniquement /wp-login.php, /wp-admin ou certaines pages.
5. Une redirection mise en cache ou un cookie du navigateur obsolète masque la correction. Il est moins probable que cela soit la cause initiale, mais cela peut donner l’impression qu’une configuration corrigée ne fonctionne toujours pas.
6. D’anciennes références HTTP subsistent dans le contenu ou la configuration. Elles provoquent normalement des avertissements de contenu mixte ou une redirection supplémentaire, et non une boucle de redirection sur tout le site ; examinez-les après avoir corrigé la chaîne principale.

Comment corriger le problème

1. Inspecter la chaîne de redirections

Utilisez une fenêtre de navigation privée pour effectuer une première vérification. Si vous disposez d’un accès shell, définissez une variable shell correspondant à l’adresse HTTPS réelle du site concerné et exécutez cette requête en lecture seule :

SITE_URL='the actual HTTPS site address'
curl -IL "$SITE_URL"

Notez chaque code d’état et chaque en-tête Location:. Une alternance entre HTTP et HTTPS indique généralement un conflit de détection du protocole ou de règles de redirection. La répétition de la même adresse HTTPS indique plutôt une redirection canonique, liée à un plugin, à un proxy ou mise en cache. N’incluez pas d’identifiants, de cookies ni d’en-têtes d’autorisation.

2. Vérifier les deux paramètres d’URL de WordPress

Si le tableau de bord est accessible, ouvrez Settings → General et vérifiez que WordPress Address (URL) et Site Address (URL) utilisent la même origine HTTPS prévue, y compris tout sous-répertoire nécessaire.

Si la boucle bloque le tableau de bord, un administrateur autorisé disposant d’un accès SFTP ou à la base de données peut définir temporairement les valeurs dans wp-config.php :

define( 'WP_HOME', 'the actual canonical HTTPS address' );
define( 'WP_SITEURL', 'the actual canonical HTTPS address' );

Sauvegardez d’abord le fichier et effectuez une seule modification contrôlée. Tant qu’elles sont définies, ces constantes remplacent les champs correspondants du tableau de bord ; supprimez-les ou gérez-les volontairement après les tests.

3. Déterminer où TLS se termine

Déterminez si le navigateur se connecte directement au serveur web ou passe par un CDN, un load balancer ou un reverse proxy. Lorsqu’un proxy termine TLS, l’origine peut recevoir une connexion HTTP même si le visiteur a utilisé HTTPS.

Demandez à l’administrateur de l’hébergeur ou du proxy de confirmer que le protocole d’origine est transmis de manière cohérente et que WordPress est configuré pour ne le reconnaître que lorsqu’il provient du proxy de confiance prévu. Ne faites pas aveuglément confiance à X-Forwarded-Proto envoyé par des clients arbitraires ; un en-tête transmis non validé peut créer des problèmes de sécurité.

4. Réduire l’application de HTTPS à un seul niveau choisi

Répertoriez chaque emplacement susceptible de rediriger HTTP vers HTTPS :

• Règles du CDN ou du load balancer
• Réglages SSL du panneau d’hébergement
• Configuration Apache .htaccess ou Nginx
• Plugins de sécurité ou SSL
• Code personnalisé dans wp-config.php ou le thème

Conservez l’application de la règle au niveau adapté à l’architecture d’hébergement, généralement au niveau edge ou du serveur web, et désactivez les redirections contradictoires au niveau de l’application. Sauvegardez la configuration et obtenez l’autorisation d’un administrateur avant de modifier les règles du serveur. Validez la configuration avant tout rechargement ou redémarrage approuvé ; ne redémarrez pas un serveur web de production comme première étape de diagnostic.

5. Tester séparément les chemins de connexion et d’administration

Si le site public fonctionne mais que /wp-admin ou la connexion est en boucle, examinez les plugins de sécurité, de connexion, d’URL canoniques et de cache récemment modifiés, en suivant une procédure de maintenance approuvée. Un conflit de plugin est plus probable lorsqu’un seul chemin est en boucle. Si un plugin doit être désactivé pour les tests, notez la modification, préservez les contrôles d’accès et réactivez-le ou remplacez-le après le test.

6. Purger les caches et retester

Après avoir consigné le comportement initial et effectué une correction contrôlée, effacez les données de site du navigateur et purgez les caches de pages ou d’objets de WordPress, ainsi que ceux de l’hébergeur et du CDN. Retestez l’adresse HTTP, la page d’accueil HTTPS, la page de connexion et une page interne représentative. Une réponse 301 ou 302 mise en cache peut persister après la correction de la configuration active.

7. Mettre à jour les références HTTP restantes

Une fois la chaîne de redirections corrigée, sauvegardez la base de données avant de modifier les URL enregistrées. Utilisez un outil de migration WordPress fiable ou une recherche-remplacement avec WP-CLI, en commençant par une simulation (dry run), et utilisez un outil qui gère les données WordPress sérialisées. Remplacez uniquement l’ancienne origine du site par l’origine HTTPS ; ne remplacez pas globalement toutes les valeurs http://, car les URL de sites tiers et les ressources externes volontairement utilisées peuvent ne pas appartenir au site.

Prévention et vérification du correctif

• Notez l’origine HTTPS canonique du site et mettez à jour les deux paramètres d’URL de WordPress pendant la migration.
• Choisissez un emplacement documenté pour la redirection HTTP vers HTTPS et examinez les autres niveaux avant d’activer un plugin de forçage SSL.
• Documentez si un CDN ou un reverse proxy termine TLS et comment l’origine apprend le protocole initial.
• Testez la page d’accueil, une page interne, la connexion et le tableau de bord après chaque modification de la configuration HTTPS.
• Sauvegardez la configuration et la base de données avant de modifier wp-config.php, les règles de réécriture ou les URL enregistrées.
• Une fois les redirections fonctionnelles, effectuez une migration ciblée des URL vers HTTPS et recherchez les références de contenu mixte.

Questions fréquentes