WordPress : résoudre l'erreur de boucle de redirection (redirect loop)

Si vous administrez un site WordPress, vous avez peut-être déjà rencontré cette erreur frustrante : votre navigateur vous indique qu'il détecte une boucle de redirection, et impossible d'accéder à votre site. Cette situation, connue sous le nom de "redirect loop error", peut avoir plusieurs origines. Heureusement, les solutions existent et sont généralement simples à mettre en œuvre.

Dans cet article, je vais vous expliquer ce qu'est exactement cette erreur, pourquoi elle se produit, et surtout comment la résoudre efficacement. Que vous soyez débutant ou administrateur expérimenté, vous trouverez ici les clés pour débloquer votre site WordPress.

Qu'est-ce que l'erreur "redirect loop" ?

Une boucle de redirection se produit lorsque votre serveur web envoie le navigateur d'une page A vers une page B, qui elle-même redirige vers la page A, créant ainsi un cycle infini. Le navigateur, après plusieurs tentatives, abandonne et affiche un message d'erreur du type "Cette page ne fonctionne pas" ou "Trop de redirections".

Concrètement, votre serveur web se retrouve piégé dans une boucle sans fin, incapable d'afficher la moindre page de votre site WordPress. C'est particulièrement problématique car même l'accès au tableau de bord d'administration devient impossible via l'interface web classique.

Les causes principales de cette erreur

Plusieurs facteurs peuvent déclencher une boucle de redirection sur WordPress. Identifier la cause est essentiel pour appliquer la bonne solution.

Les cookies du navigateur corrompus

Parfois, le problème ne vient pas de WordPress lui-même, mais de votre navigateur. Des cookies obsolètes ou corrompus peuvent créer un conflit qui simule une boucle de redirection. C'est la cause la plus simple, mais aussi la plus facile à vérifier et corriger.

Modification des permissions fichiers

Sur un serveur Linux, les droits d'accès (chmod) et les propriétaires de fichiers (chown) sont cruciaux pour le bon fonctionnement de WordPress. Si vous avez récemment modifié ces permissions, soit manuellement, soit via un script de déploiement, WordPress peut perdre l'accès à certains fichiers essentiels, provoquant des comportements erratiques incluant des boucles de redirection.

Migration de nom de domaine

Lors d'un changement de nom de domaine, WordPress continue de référencer l'ancien domaine dans ses permaliens et ses paramètres internes. Le résultat ? Le navigateur tente d'accéder au nouveau domaine, mais WordPress le redirige vers l'ancien, qui lui-même redirige vers le nouveau... et voilà la boucle installée.

WordPress derrière un reverse proxy

C'est probablement la cause la plus technique. Quand WordPress fonctionne derrière un reverse proxy (Nginx, Traefik, HAProxy) qui gère le SSL/TLS, la communication entre le proxy et WordPress se fait souvent en HTTP non chiffré. WordPress détecte cette connexion HTTP et tente de forcer une redirection HTTPS, mais le proxy intercepte cette redirection et la renvoie... créant notre fameuse boucle.

Solutions étape par étape

Étape 1 : Vérifier les cookies du navigateur

Commencez toujours par la solution la plus simple. Avant de toucher à votre serveur, vérifiez si le problème est généralisé ou spécifique à votre navigateur.

Pour tester :

Ouvrez une fenêtre de navigation privée (Ctrl+Shift+N sur Chrome, Ctrl+Shift+P sur Firefox)
Accédez à votre site WordPress
Si le site fonctionne en navigation privée, le problème vient bien de vos cookies

Pour corriger :

Effacez les cookies et le cache de votre navigateur pour votre domaine
Fermez et rouvrez votre navigateur
Testez à nouveau l'accès

Si cette manipulation résout votre problème, vous pouvez vous arrêter là. Sinon, passons aux solutions côté serveur.

Étape 2 : Corriger les permissions Linux

Si vous avez un accès SSH à votre serveur, cette solution s'applique principalement aux installations Linux (Ubuntu, Debian, CentOS, etc.).

Identifier l'utilisateur du serveur web :

Avant de modifier les permissions, vous devez connaître l'utilisateur qui exécute votre serveur web.

Pour Apache :

ps aux | grep httpd
# ou
ps aux | grep apache2

Pour Nginx :

ps aux | grep nginx

L'utilisateur apparaît dans la première colonne. C'est généralement www-data sur Ubuntu/Debian, ou apache sur CentOS/RHEL.

Réappliquer le propriétaire correct :

cd /var/www/html
sudo chown -R www-data:www-data *

Remplacez www-data par l'utilisateur identifié précédemment, et /var/www/html par le chemin réel de votre installation WordPress.

Restaurer les bonnes permissions :

# Permissions de base pour tous les fichiers
sudo find /var/www/html -type f -exec chmod 644 {} \;

# Permissions pour les répertoires
sudo find /var/www/html -type d -exec chmod 755 {} \;

# Permissions spécifiques WordPress
sudo chmod 755 /var/www/html/wp-admin
sudo chmod 755 /var/www/html/wp-includes
sudo chmod 755 /var/www/html/wp-content

Ces permissions suivent le principe de moindre privilège : les fichiers sont lisibles par tous mais modifiables uniquement par le propriétaire, tandis que les répertoires sont exécutables (nécessaire pour y naviguer).

Étape 3 : Résoudre un changement de domaine

En pleine migration vers un nouveau domaine ? WordPress a besoin de savoir où il se trouve maintenant.

Éditer le fichier wp-config.php :

cd /var/www/html
sudo nano wp-config.php

Cherchez la ligne contenant require_once(ABSPATH . 'wp-settings.php'); et ajoutez juste avant :

define('WP_HOME', 'https://votre-nouveau-domaine.fr');
define('WP_SITEURL', 'https://votre-nouveau-domaine.fr');

Important : Remplacez votre-nouveau-domaine.fr par votre domaine réel. Conservez le protocole https:// si vous utilisez SSL.

Sauvegardez le fichier (Ctrl+O puis Entrée sur nano, puis Ctrl+X pour quitter). Testez immédiatement votre site. Il devrait maintenant être accessible.

Note : Cette solution force WordPress à utiliser le nouveau domaine. Une fois votre site accessible, pensez à mettre à jour les URLs dans la base de données avec un plugin comme "Better Search Replace" ou via WP-CLI pour une solution plus propre et permanente.

Étape 4 : Configurer WordPress derrière un proxy

C'est la situation la plus technique, mais très courante dans les architectures modernes (Docker, Kubernetes, infrastructure cloud).

Le problème en détail : Votre reverse proxy (Nginx, Traefik, HAProxy) termine le SSL et communique en HTTP avec WordPress. WordPress détecte cette connexion HTTP, vérifie sa configuration SSL, et tente de rediriger vers HTTPS. Mais comme le proxy a déjà géré SSL côté client, on obtient une boucle.

La solution : Indiquer à WordPress que même s'il reçoit du HTTP, le client final utilise bien HTTPS.

Éditez votre wp-config.php :

sudo nano /var/www/html/wp-config.php

Juste avant la ligne require_once(ABSPATH . 'wp-settings.php');, ajoutez :

// Forcer HTTPS pour l'admin
define('FORCE_SSL_ADMIN', true);

// Détecter le proxy et forcer HTTPS
if (!empty($_SERVER['HTTP_X_FORWARDED_HOST']) || !empty($_SERVER['HTTP_X_FORWARDED_FOR'])) {
    $_SERVER['HTTPS'] = 'on';
}

Cette configuration détecte les en-têtes HTTP standard envoyés par les reverse proxies (X-Forwarded-For, X-Forwarded-Host) et indique à WordPress que la connexion client est sécurisée.

Configuration côté proxy :

Assurez-vous également que votre reverse proxy envoie bien ces en-têtes. Pour Nginx, votre configuration devrait inclure :

location / {
    proxy_pass http://wordpress;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Host $host;
}

Vérification et tests

Après avoir appliqué une des solutions ci-dessus :

Effacez le cache de votre navigateur (Ctrl+Shift+Delete)
Testez en navigation privée pour éviter les interférences de cookies

Vérifiez les logs de votre serveur web pour identifier d'éventuelles erreurs résiduelles :

# Apache
sudo tail -f /var/log/apache2/error.log

# Nginx
sudo tail -f /var/log/nginx/error.log

Testez plusieurs pages : page d'accueil, articles, dashboard admin

Prévention des boucles de redirection

Quelques bonnes pratiques pour éviter de revivre ce cauchemar :

Sauvegardez wp-config.php avant toute modification majeure
Utilisez un plugin de maintenance lors des migrations
Documentez votre architecture (présence d'un proxy, configuration SSL, etc.)
Testez sur un environnement de staging avant de toucher à la production
Conservez une copie de sauvegarde de votre base de données avant les migrations

Quand rien ne fonctionne

Si après avoir testé toutes ces solutions votre site reste inaccessible, voici quelques pistes avancées :

Désactivez tous les plugins en renommant le dossier wp-content/plugins via FTP/SSH
Passez au thème par défaut (Twenty Twenty-Four) en renommant votre dossier de thème actif
Vérifiez la table wp_options dans votre base de données : les champs siteurl et home doivent contenir le bon domaine
Consultez les logs PHP : /var/log/php-fpm/error.log ou selon votre configuration

Si vraiment vous êtes bloqué, la restauration depuis une sauvegarde reste la solution de dernier recours. C'est pourquoi j'insiste toujours : sauvegardez régulièrement !

Conclusion

Les boucles de redirection WordPress peuvent sembler intimidantes, mais comme vous l'avez vu, les causes sont identifiables et les solutions accessibles. Dans la majorité des cas, il s'agit d'un simple problème de cookies, de permissions fichiers, ou de configuration suite à une migration.

Retenez cette approche méthodique : commencez par les solutions simples (cookies), puis progressez vers les solutions serveur (permissions, configuration). Et surtout, n'oubliez jamais de sauvegarder avant d'intervenir sur un site en production.

Vous avez rencontré cette erreur dans un contexte différent ? N'hésitez pas à documenter votre cas et votre solution, cela pourra aider d'autres administrateurs WordPress confrontés au même problème.

Knowledge