Corriger une boucle de redirection WordPress

Le problème

Si vous avez déjà vu votre navigateur afficher “Cette page ne fonctionne pas” puis “a redirigé un trop grand nombre de fois”, vous êtes face à une boucle de redirection. Sur WordPress 6.9.4, je la croise surtout après une migration HTTPS, un changement de domaine, ou l’activation d’un plugin de cache/sécurité.

Messages typiques (selon navigateur) :

ERR_TOO_MANY_REDIRECTS
The page isn’t redirecting properly
Cette page a redirigé un trop grand nombre de fois

Où ça apparaît :

Front-end (le site public) : le cas le plus courant.
Admin (/wp-admin) : plus stressant, mais souvent récupérable.
REST API / AJAX : vous voyez des 301/302 en boucle dans la console réseau du navigateur, ou des erreurs côté builder (Elementor/Divi/Avada) qui “chargent sans fin”.

Circonstances typiques :

Après avoir activé “Forcer HTTPS” dans un plugin (ou dans Cloudflare) alors que le serveur ne le “voit” pas.
Après avoir modifié “Adresse web de WordPress (URL)” / “Adresse web du site (URL)” dans Réglages.
Après une migration (nouveau domaine, sous-domaine, passage de www à sans www).
Après avoir ajouté une redirection dans .htaccess ou la config Nginx.

À qui s’adresse ce guide : si vous débutez sur WordPress (ou si vous administrez un site client), vous allez apprendre à identifier la source exacte de la boucle (WordPress, plugin, thème, serveur, proxy/CDN), puis à la corriger proprement sans casser le site. À la fin, vous saurez aussi vérifier que le correctif tient dans le temps (cache, cookies, règles de réécriture, HTTPS).

Résumé rapide

Une boucle de redirection vient presque toujours d’un désaccord entre WordPress (home/siteurl), le serveur (HTTP/HTTPS), et/ou un plugin (cache/sécurité/SEO).
Commencez par tester en navigation privée et vider les caches (plugin + CDN + navigateur) : ça évite de diagnostiquer un faux problème.
Si vous ne pouvez plus accéder à l’admin, corrigez home/siteurl via wp-config.php (temporaire) ou la base de données (phpMyAdmin).
Si la boucle arrive après un snippet, cherchez une redirection sur le mauvais hook (init / template_redirect) ou une condition trop large.
Sur sites derrière Cloudflare / reverse proxy, la cause n°1 est un HTTPS non détecté (header X-Forwarded-Proto ignoré).
Quand vous corrigez : testez /, /wp-admin, une page, un article, et l’API /wp-json/.

Les symptômes

Une boucle de redirection ne ressemble pas toujours à “ERR_TOO_MANY_REDIRECTS”. Voici les signes que je vois le plus sur WordPress 6.9.4.

Le site ne charge jamais et le navigateur propose de supprimer les cookies.
/wp-admin renvoie vers /wp-login.php, puis revient à /wp-admin, en boucle.
Vous êtes “déconnecté” à chaque page : cookies de session invalidés par un changement de domaine/HTTPS.
Dans DevTools > Réseau : une série de réponses 301/302 alternant entre http:// et https://, ou entre www et non-www.
Elementor/Divi/Avada : l’éditeur affiche une prévisualisation blanche ou “chargement” infini, alors que le front semble parfois accessible.
REST API : appels à /wp-json/ qui redirigent vers la home ou vers /wp-login.php.
Erreur serveur : parfois un 500 si la boucle déclenche une limite interne (rare, mais je l’ai vu avec certaines règles Nginx mal écrites).

Tableau de diagnostic rapide

Symptôme	Cause probable	Vérification	Solution
HTTP ↔ HTTPS en boucle	HTTPS forcé à un endroit, non reconnu à un autre (proxy/CDN)	DevTools : alternance http/https	Solution 1 + Solution 3 (headers proxy)
www ↔ non-www	URL WordPress ≠ redirection serveur	Comparer Réglages + règles serveur	Solution 1 (aligner home/siteurl)
/wp-admin renvoie vers /wp-login	Cookies invalides, URL incohérente, plugin sécurité	Navigation privée + désactiver plugin	Solution 1 + “Si ça ne marche toujours pas”
Seulement sur certaines pages	Règles de réécriture / plugin SEO / redirection 404	Tester permaliens, logs redirections	Solution 3 (rewrite) + vérif plugin
Uniquement en admin builder	Redirection sur REST/AJAX, mixed content, cache agressif	Console + réseau sur /wp-json/	Désactiver cache, corriger HTTPS détecté

Pourquoi ça arrive

Explication simple (débutant)

Une redirection, c’est quand le serveur dit au navigateur : “ne restez pas ici, allez plutôt à cette autre adresse”. Une boucle arrive quand deux règles se contredisent :

WordPress pense que l’URL officielle est http://exemple.com, mais le serveur force https://exemple.com.
Le serveur force www.exemple.com, mais WordPress est configuré sur exemple.com.
Un plugin redirige les visiteurs vers une page, mais une autre règle les renvoie en arrière.

Explication technique (intermédiaire/pro)

WordPress génère des URLs et des redirections à plusieurs endroits : canonical redirects, login/admin redirects, forçage de schéma (http/https) selon is_ssl(), et selon home_url()/site_url(). Si l’environnement (Apache/Nginx, reverse proxy, CDN) ne fournit pas des variables cohérentes ($_SERVER['HTTPS'], port 443, X-Forwarded-Proto), is_ssl() peut se tromper et déclencher des redirections en chaîne.

Causes classées du plus fréquent au plus rare :

URL WordPress mal réglées (home/siteurl) après migration.
HTTPS forcé à un endroit (plugin/CDN) mais pas reconnu côté PHP (proxy).
Règles .htaccess / Nginx en double (deux redirections qui se contredisent).
Plugin SEO / cache / sécurité qui force une canonical URL, ou redirige les non-connectés.
Code personnalisé (snippet) qui redirige trop tôt ou sans condition.
Cookies / domaine (COOKIE_DOMAIN, multisite, sous-domaines) incohérents.

Prérequis avant de commencer

Sauvegarde : fichiers + base de données. Si vous n’avez pas de staging, faites au minimum une export DB.
Ne modifiez jamais le core (fichiers WordPress). On corrige via configuration, thème enfant, plugin, ou serveur.
Versions : WordPress 6.9.4, PHP recommandé 8.1+. Si vous êtes en dessous, attendez-vous à des comportements bizarres avec certains plugins modernes.
Accès : FTP/SFTP ou gestionnaire de fichiers, et idéalement accès à la base (phpMyAdmin) ou WP-CLI.
Outils utiles :
- Query Monitor (logs, requêtes, hooks, erreurs).
- Health Check & Troubleshooting (désactiver plugins “pour vous” sans impacter les visiteurs).
- La doc debug officielle : Debugging in WordPress.

Si vous êtes bloqué hors de l’admin, commencez par les solutions qui se font via fichiers/DB (Solution 1 et Solution 3).

Solution 1 : corriger l’URL du site (home/siteurl) et le HTTPS

Quand je dépanne une boucle, je vérifie presque toujours en premier que WordPress et le serveur parlent de la même URL canonique. C’est la cause n°1.

1) Vérifier les URLs (si vous avez accès à l’admin)

Allez dans Réglages > Général :

Adresse web de WordPress (URL) = siteurl
Adresse web du site (URL) = home

Les deux doivent être cohérentes (même domaine, même schéma http/https, même www ou non-www). Si vous êtes en HTTPS, les deux doivent commencer par https://.

2) Si vous n’avez plus accès à l’admin : fix temporaire via wp-config.php

Sauvegardez avant de modifier. Ouvrez wp-config.php à la racine du site (même niveau que wp-settings.php), et ajoutez ces lignes au-dessus de /* That's all, stop editing! */.

Exemple de code “AVANT” (cassé) : rien ne force l’URL, WordPress lit une valeur erronée en base.

Code “APRÈS” (corrigé) :

<?php
// ... votre wp-config.php

// Sauvegardez avant de modifier ce fichier.
// Fix temporaire : force les URLs WordPress pour casser une boucle de redirection.
define( 'WP_HOME', 'https://exemple.com' );
define( 'WP_SITEURL', 'https://exemple.com' );

// Si vous êtes derrière un proxy/CDN qui termine le HTTPS (Cloudflare, LB, etc.),
// ces lignes peuvent aider WordPress à détecter correctement HTTPS.
// À activer seulement si votre hébergeur/proxy envoie X-Forwarded-Proto=https.
if ( ! empty( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https' ) {
	$_SERVER['HTTPS'] = 'on';
}

// ... fin du fichier

Pourquoi ça corrige : WordPress n’utilise plus les valeurs home/siteurl de la base. Il génère donc des URLs cohérentes, ce qui stoppe la redirection “ping-pong” (http ↔ https, www ↔ non-www).

À retenir

WP_HOME = URL du site (front).
WP_SITEURL = URL du WordPress (souvent identique, sauf cas WordPress dans un sous-dossier).
Ce fix est pratique pour reprendre la main, mais je préfère ensuite remettre les valeurs en base (propre) et retirer ces constantes.

3) Fix durable via base de données (phpMyAdmin)

Dans phpMyAdmin, table wp_options (préfixe parfois différent), trouvez :

option_name = home
option_name = siteurl

Corrigez les deux valeurs avec l’URL finale (ex. https://exemple.com).

Si vous avez WP-CLI, c’est plus sûr (moins d’erreurs de saisie) :

# Remplacez exemple.com par votre domaine
wp option get home
wp option get siteurl

wp option update home 'https://exemple.com'
wp option update siteurl 'https://exemple.com'

4) Cas fréquent : “HTTPS partout” mais WordPress se croit en HTTP

J’ai souvent vu ce problème sur des sites derrière Cloudflare (mode “Flexible”) ou derrière un load balancer. Le navigateur est en HTTPS, mais PHP voit une requête HTTP entre le proxy et le serveur. Résultat : WordPress tente de “corriger” et redirige, le proxy re-corrige, et vous bouclez.

Sur Cloudflare, évitez “Flexible” pour WordPress. Préférez “Full (strict)” si possible.
Assurez-vous que le serveur reçoit un header X-Forwarded-Proto: https et que WordPress peut l’utiliser (snippet ci-dessus).

Référence utile : la détection SSL côté WordPress s’appuie sur des variables serveur. Vous pouvez lire la doc sur les URLs : home_url() et site_url().

Solution 2 : corriger une redirection mal codée (hook, condition, priorité)

La deuxième cause que je rencontre : un snippet copié d’un ancien tutoriel, collé dans functions.php (ou un plugin de snippets), qui redirige trop tôt, ou redirige tout le monde… y compris la page de destination.

Définitions rapides :

Hook : point d’accroche dans WordPress où vous pouvez exécuter votre code.
Action : hook qui exécute du code (ex. template_redirect).
Filtre : hook qui modifie une valeur (ex. the_content).

Où se trouve le code en cause

Thème enfant : /wp-content/themes/votre-theme-enfant/functions.php
Plugin custom : recommandé si c’est un comportement “site”, pas “design”.
mu-plugin : /wp-content/mu-plugins/ (chargé automatiquement). Pratique pour des correctifs de prod.
Plugin de snippets : parfois il continue d’exécuter un snippet même si le thème change.

Exemple “AVANT” (cassé) : redirection globale vers /connexion

Ce snippet est typique : il veut forcer les visiteurs non connectés à aller sur une page de connexion. Mais il oublie d’exclure la page cible, et il tourne en boucle.

<?php
// functions.php (exemple cassé)
// Objectif : rediriger les non-connectés vers /connexion
add_action( 'init', function () {
	if ( ! is_user_logged_in() ) {
		wp_redirect( home_url( '/connexion/' ) );
		exit;
	}
} );

Pourquoi c’est cassé :

init est souvent trop tôt : WordPress n’a pas toujours résolu la requête (page courante). Les conditions comme is_page() peuvent être fausses.
La redirection s’applique aussi quand vous êtes déjà sur /connexion/. Donc : /connexion/ → /connexion/ → boucle.
Ça peut casser l’admin, le REST, l’AJAX, les endpoints Elementor/Divi.

Exemple “APRÈS” (corrigé) : hook correct + exclusions + statut 302

Collez ce code dans un plugin custom (idéal) ou dans functions.php du thème enfant. Sauvegardez avant.

<?php
/**
 * Redirection des visiteurs non connectés vers une page de connexion.
 * Version corrigée : évite les boucles et n'impacte pas l'admin / REST / AJAX.
 *
 * Où coller : plugin custom (recommandé) ou functions.php du thème enfant.
 */

add_action( 'template_redirect', function () {
	// Ne jamais toucher à l'admin.
	if ( is_admin() ) {
		return;
	}

	// Ne jamais rediriger pendant des requêtes AJAX (admin-ajax.php).
	if ( wp_doing_ajax() ) {
		return;
	}

	// Ne jamais rediriger l'API REST (sinon Elementor/Divi/Avada peuvent casser).
	if ( defined( 'REST_REQUEST' ) && REST_REQUEST ) {
		return;
	}

	// Si l'utilisateur est connecté, on ne fait rien.
	if ( is_user_logged_in() ) {
		return;
	}

	// IMPORTANT : template_redirect arrive après la résolution de la requête.
	// On peut donc utiliser des conditions fiables.
	$login_url = home_url( '/connexion/' );

	// Éviter la boucle : si on est déjà sur la page de connexion, on ne redirige pas.
	if ( is_page() ) {
		$current_id = get_queried_object_id();
		$login_id   = url_to_postid( $login_url );

		if ( $login_id && $current_id === $login_id ) {
			return;
		}
	}

	// Redirection temporaire (302) : pratique tant que vous testez.
	wp_safe_redirect( $login_url, 302 );
	exit;
}, 10 );

Pourquoi ça marche

template_redirect est le bon hook pour rediriger selon la page demandée (WordPress a “compris” la requête).
wp_safe_redirect() limite les redirections vers des hôtes autorisés (meilleur pour la sécurité que wp_redirect() si vous manipulez des URLs).
On exclut admin/AJAX/REST : c’est ce qui évite les éditeurs qui chargent en boucle.

Cas réel : redirection HTTPS codée en dur (souvent copiée d’un vieux blog)

Un autre snippet cassant : forcer HTTPS via code, alors que le serveur (ou Cloudflare) le fait déjà. Deux forçages = boucle.

AVANT (cassé) :

<?php
// functions.php (cassé) : force HTTPS sans vérifier le contexte proxy
add_action( 'template_redirect', function () {
	if ( ! is_ssl() ) {
		wp_redirect( 'https://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'] );
		exit;
	}
} );

APRÈS (corrigé) : supprimez ce code et forcez HTTPS au serveur ou au CDN, puis corrigez la détection proxy (Solution 1 / Solution 3). Si vous devez absolument le faire côté WP (je l’évite), au minimum :

<?php
// À n'utiliser que si vous comprenez votre infra. Sinon : redirection serveur.
add_action( 'template_redirect', function () {
	// Si un proxy indique HTTPS, on ne force pas une redirection.
	if ( ! empty( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https' ) {
		return;
	}

	if ( ! is_ssl() ) {
		$target = 'https://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'];
		wp_safe_redirect( $target, 301 );
		exit;
	}
}, 1 );

Note : la priorité 1 fait tourner le code tôt sur template_redirect. J’ai déjà vu des priorités trop tardives entrer en conflit avec des canonical redirects.

Solution 3 : proxy/CDN/cache/rewrite rules (cas avancés serveur)

Si vos URLs WordPress sont correctes et que vous n’avez pas de snippet de redirection, regardez côté serveur. Les boucles viennent souvent de “deux chefs” : Apache/Nginx + plugin + CDN, chacun forçant sa version de l’URL.

1) Désactiver temporairement les plugins de cache/sécurité (sans admin)

Via FTP/SFTP, renommez le dossier du plugin problématique. Exemple :

# Exemple (à faire via FTP/SFTP en renommant)
wp-content/plugins/wordfence/  →  wordfence.disabled/
wp-content/plugins/wp-rocket/  →  wp-rocket.disabled/

WordPress désactive automatiquement un plugin si son dossier disparaît. C’est une méthode fiable quand /wp-admin boucle.

Ensuite, videz :

Cache du plugin (quand vous récupérez l’admin)
Cache serveur (si votre hébergeur en a un)
Cache CDN (Cloudflare, etc.)
Cache navigateur (ou test en navigation privée)

2) Règles .htaccess : doubles redirections (www + https)

Sur Apache, je vois souvent deux blocs séparés : un pour HTTPS, un pour www, dans un ordre qui crée un ping-pong. Exemple simplifié :

AVANT (cassé) :

# .htaccess (exemple cassé)
RewriteEngine On

# Force HTTPS
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# Force www (mais peut renvoyer vers HTTP selon certaines configs)
RewriteCond %{HTTP_HOST} !^www. [NC]
RewriteRule ^ http://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

APRÈS (corrigé) : une seule redirection canonique qui fixe www + https (ou l’inverse), en une étape.

# .htaccess (exemple corrigé : force https + non-www)
RewriteEngine On

# Si vous voulez NON-www + HTTPS
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www.(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [L,R=301]

Adaptez selon votre choix : le but est qu’il n’existe qu’une seule “forme” officielle.

3) Nginx : redirection mal ciblée

Sur Nginx, une boucle arrive si vous avez un return 301 dans un bloc qui match aussi la destination. Je ne peux pas donner votre config exacte, mais la règle générale : un serveur HTTP (port 80) redirige vers HTTPS, et le serveur HTTPS sert le site sans re-rediriger.

Test utile (depuis votre machine) :

curl -I http://exemple.com/
curl -I https://exemple.com/
curl -I https://www.exemple.com/

Vous voulez voir :

HTTP → 301 → HTTPS
HTTPS → 200 (ou 301 vers la version canonique www/non-www)
Pas de chaîne infinie de 301/302

4) Reverse proxy / CDN : headers HTTPS

Si un proxy termine le SSL, votre serveur doit transmettre l’info à PHP. Selon l’infra, ce sera X-Forwarded-Proto, parfois X-Forwarded-Ssl. Côté WordPress, le snippet de Solution 1 peut suffire.

Si vous êtes développeur et que vous voulez vérifier ce que PHP reçoit, créez temporairement un fichier debug-headers.php à la racine (puis supprimez-le) :

<?php
// Fichier temporaire : supprimez-le après diagnostic (risque d'exposition d'infos).
header( 'Content-Type: text/plain; charset=utf-8' );

$keys = [
	'HTTPS',
	'HTTP_X_FORWARDED_PROTO',
	'HTTP_X_FORWARDED_SSL',
	'SERVER_PORT',
	'HTTP_HOST',
	'REQUEST_URI',
];

foreach ( $keys as $k ) {
	echo $k . ': ' . ( isset( $_SERVER[ $k ] ) ? $_SERVER[ $k ] : '(absent)' ) . "n";
}

Risque sécurité : ce fichier expose des infos d’environnement. Ne le laissez jamais en production.

Vérifications après correction

Une fois la boucle stoppée, vérifiez tout de suite ces points. Sinon, vous allez croire que “c’est revenu”, alors que c’est juste un cache ou un cookie.

Test en navigation privée (cookies propres).
Front page : / doit charger.
Une page + un article : vérifiez permaliens.
Admin : /wp-admin/ doit afficher le tableau de bord (ou la page de login une seule fois).
REST : ouvrez https://exemple.com/wp-json/ : vous devez obtenir du JSON, pas une redirection vers la home.
Builders :
- Elementor : ouvrez l’éditeur, vérifiez que l’aperçu charge.
- Divi 5 : testez le Visual Builder, surveillez les requêtes réseau.
- Avada : testez Fusion Builder, et une sauvegarde de page.

Si vous avez modifié les permaliens ou migré, allez dans Réglages > Permaliens puis cliquez Enregistrer (sans rien changer). Ça régénère les règles de réécriture.

Si ça ne marche toujours pas

Voici une procédure que j’applique quand la boucle est “invisible” (parfois uniquement pour certains utilisateurs, ou seulement sur mobile).

Étape 1 : isoler cache et cookies

Testez en navigation privée.
Supprimez les cookies du domaine.
Désactivez temporairement le cache (plugin + CDN).

Étape 2 : vérifier la chaîne exacte de redirections

Avec curl :

curl -I -L --max-redirs 15 https://exemple.com/

Si vous voyez 15 redirections, notez les URLs qui alternent (http/https, www/non-www, /wp-login.php, etc.). C’est l’indice principal.

Étape 3 : désactiver les plugins sans casser le site (Health Check)

Si vous avez accès à l’admin : utilisez Health Check & Troubleshooting en mode dépannage. Il désactive les plugins uniquement pour votre session. C’est parfait pour repérer un plugin qui redirige.

Étape 4 : activer les logs WordPress (WP_DEBUG)

Dans wp-config.php (temporairement), activez :

<?php
// Debug temporaire (à désactiver après).
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Le fichier wp-content/debug.log peut révéler un plugin qui déclenche des warnings, ou un fatal qui coupe un flux (parfois masqué par une redirection). Doc officielle : Debugging in WordPress.

Étape 5 : vérifier la santé du site (Site Health)

Dans l’admin : Outils > Santé du site. Recherchez :

Problèmes de boucle avec “HTTPS” (configuration incohérente)
Plugins de cache/sécurité signalés
Erreurs REST API

Étape 6 : vérifier les constantes et cookies (cas plus rare)

Dans wp-config.php, cherchez des constantes qui peuvent perturber :

COOKIE_DOMAIN (souvent copiée d’un multisite ou d’un ancien domaine)
FORCE_SSL_ADMIN (utile, mais peut révéler un souci proxy)

Si COOKIE_DOMAIN est défini et incorrect, vous pouvez être déconnecté et boucler sur login.

Pièges et erreurs courantes

Symptôme / erreur	Cause probable	Solution recommandée
Vous collez un snippet dans le mauvais fichier	Code mis dans `wp-config.php` au lieu de `functions.php` (ou l’inverse)	Respecter l’emplacement : config dans `wp-config.php`, logique front dans thème enfant/plugin
Erreur après ajout de code : écran blanc / 500	Point-virgule manquant, parenthèse oubliée	Revenir en arrière via FTP, valider la syntaxe PHP (PHP 8.1+ est strict)
Boucle uniquement en admin	Plugin sécurité, cookies, URL admin incohérente	Désactiver plugin via FTP, corriger `home/siteurl`, supprimer cookies
Hook inadapté (`init`)	Conditions `is_page()` fausses, redirection trop tôt	Utiliser `template_redirect` et ajouter des exclusions
Vous testez sur production sans sauvegarde	Stress + retour arrière difficile	Staging, backup, et méthode “fix temporaire” via `WP_HOME`/`WP_SITEURL`
Conflit cache : “ça revient”	Cache CDN/plugin/navigateur conserve des 301	Purger partout + test navigation privée
Permaliens cassés après correction	Rewrite rules non régénérées	Réglages > Permaliens > Enregistrer
Ancien tutoriel force HTTPS en PHP	Double redirection (serveur + WP)	Garder un seul endroit qui force HTTPS (serveur/CDN idéalement)

Variante / alternative

Méthode sans code (orientée débutant)

Réglez les URLs dans Réglages > Général (ou via DB si admin inaccessible).
Désactivez temporairement les plugins de cache/sécurité/SEO (renommer le dossier).
Sur Cloudflare : évitez “Flexible”, purgez le cache, vérifiez les règles “Always Use HTTPS” et “Forwarding URL”.

Méthode plus avancée (développeur)

WP-CLI est votre meilleur ami pour diagnostiquer sans navigateur :

# Vérifier URLs
wp option get home
wp option get siteurl

# Lister plugins actifs
wp plugin list --status=active

# Désactiver tous les plugins (test)
wp plugin deactivate --all

# Réactiver un par un
wp plugin activate nom-du-plugin

Si vous êtes sur un hébergement où WP-CLI est disponible, c’est souvent la façon la plus rapide de repérer un plugin qui force une redirection.

Éviter ce problème à l’avenir

Décidez d’une URL canonique (https + www ou https + non-www) et forcez-la à un seul endroit (serveur/CDN). Évitez de cumuler serveur + plugin + snippet.
Après une migration : corrigez home/siteurl en premier, puis seulement ensuite les redirections.
Évitez les snippets “magiques” copiés d’articles anciens. Beaucoup datent de PHP 5/7 et ne tiennent pas compte des proxies modernes.
Utilisez un thème enfant pour les modifications de code, ou mieux : un plugin custom. Ainsi, une mise à jour de thème (Avada, Divi, etc.) ne supprime pas vos correctifs.
Surveillez les redirections après installation d’un plugin SEO/sécurité. Certains ajoutent des “canonical redirects” ou des règles de login.

Si vous devez écrire une redirection personnalisée, gardez ces règles :

Hook : template_redirect (pas init).
Exclusions : admin, AJAX, REST.
Évitez de rediriger vers l’URL courante.
Préférez wp_safe_redirect().

Ressources

Questions fréquentes

Est-ce que supprimer les cookies suffit ?

Parfois, oui, surtout si la boucle concerne /wp-admin et que vous avez changé de domaine, de www, ou de HTTPS. Mais si la chaîne de redirection alterne http/https, le vrai problème est généralement la configuration (home/siteurl, proxy, règles serveur).

Pourquoi ça marche sur mon ordinateur mais pas sur celui d’un client ?

Le cache et les cookies. Un 301 peut être mémorisé par le navigateur, et un plugin/CDN peut servir des réponses différentes selon la région. Testez en navigation privée et purgez le CDN.

Divi 5 / Elementor / Avada peuvent-ils “causer” une boucle ?

Rarement directement. En revanche, ces builders dépendent fortement de l’API REST et d’appels AJAX. Une redirection qui touche /wp-json/ ou admin-ajax.php peut donner l’impression que “le builder est cassé”, alors que c’est une boucle côté redirection.

Dois-je forcer HTTPS via un plugin WordPress ?

Je l’évite quand c’est possible. Le plus stable est de forcer HTTPS au niveau serveur (ou CDN) et de garder WordPress configuré en https://. Les plugins “forcer SSL” sont pratiques, mais sur une infra proxy/CDN ils déclenchent souvent des boucles si la détection SSL est incohérente.

Quelle est la différence entre WP_HOME/WP_SITEURL et home/siteurl en base ?

WP_HOME et WP_SITEURL dans wp-config.php écrasent les valeurs en base. C’est idéal pour reprendre la main quand l’admin boucle. Ensuite, remettez des valeurs propres en base et retirez les constantes si vous voulez revenir à une configuration standard.

J’ai corrigé l’URL, mais j’ai encore des redirections 301 en cache. Que faire ?

Purger le cache du plugin, du serveur, du CDN, puis tester en navigation privée. Si possible, testez aussi avec curl -I pour voir la réalité côté serveur, sans cache navigateur.

Est-ce que “Enregistrer les permaliens” peut corriger une boucle ?

Ça corrige surtout des erreurs 404 et des routes cassées. Mais après une migration, des règles de réécriture incohérentes peuvent déclencher des redirections bizarres sur certaines URLs. Donc oui : c’est une vérification utile après avoir stabilisé les URLs.

Je suis en multisite : est-ce différent ?

Oui, les boucles peuvent venir de la configuration domaine/sous-domaine et des constantes multisite. Si vous êtes en multisite, commencez quand même par aligner les URLs et vérifier proxy/HTTPS, puis vérifiez les réglages réseau et les domaines mappés.

Une boucle peut-elle venir d’un fichier robots.txt ou d’un sitemap ?

Indirectement : un plugin SEO peut rediriger des URLs “non canoniques” (avec slash, sans slash, paramètres). Mais le robots.txt lui-même ne déclenche pas une boucle. Regardez plutôt les règles de redirection (plugin SEO, serveur, CDN).