# Cookies bloqués à la connexion WordPress : causes et solutions

> « Les cookies sont bloqués ou ne sont pas reconnus par votre navigateur » : causes (URL, cache, sortie parasite) et correctifs pour vous reconnecter.

- Auteur : WordPress Développement
- Publié le : 2026-10-02
- Mis à jour le : 2026-10-02
- URL : https://www.wpmoderne.fr/erreurs-wordpress/cookies-bloques/

> WordPress n’a pas retrouvé son cookie de test au moment de la connexion. Cause n°1 : un navigateur qui bloque les cookies, ou une adresse (http/https, www) différente entre l’affichage du formulaire et son envoi. Testez en navigation privée.

Vous saisissez le bon identifiant et le bon mot de passe sur `wp-login.php`, et la page se recharge avec un bandeau rouge : « Erreur : les cookies sont bloqués ou ne sont pas reconnus par votre navigateur. Vous devez activer les cookies pour utiliser WordPress. » Parfois, le message est un peu différent : « les cookies sont bloqués en raison d’un retour inattendu ». L’erreur n’apparaît que sur la page de connexion, jamais sur le site public, mais elle vous empêche d’entrer dans l’administration.

Elle ne dit pas toujours la vérité : votre navigateur accepte souvent très bien les cookies. Dans la majorité des cas, WordPress n’a pas pu **poser ou relire** son cookie de test, à cause d’une adresse qui change en route, d’un cache, ou d’un fichier PHP qui a affiché du texte trop tôt. Voici comment distinguer ces situations et vous reconnecter.

## Ce que signifie cette erreur

À chaque affichage du formulaire, `wp-login.php` envoie au navigateur un cookie de test nommé `wordpress_test_cookie` (constante `TEST_COOKIE`, définie dans `wp-includes/default-constants.php`) avec la valeur « WP Cookie check ». Le cookie est posé pour le chemin `COOKIEPATH` et le domaine `COOKIE_DOMAIN` (vide par défaut, donc limité à l’hôte exact), avec l’attribut « secure » si l’URL de connexion est en HTTPS. Le formulaire contient aussi un champ caché `testcookie`.

À l’envoi du formulaire, WordPress vérifie d’abord vos identifiants (`wp_signon()`), puis, tant que le cookie de session `LOGGED_IN_COOKIE` n’est pas présent dans la requête, il applique deux contrôles dans `wp-login.php` :

- si des en-têtes HTTP ont déjà été envoyés (`headers_sent()`), les cookies de connexion ne peuvent plus être posés : WordPress affiche le message « les cookies sont bloqués en raison d’un retour inattendu » ;
- si le champ `testcookie` est présent mais que le cookie de test n’est pas revenu avec la requête, il affiche le message « les cookies sont bloqués ou ne sont pas reconnus par votre navigateur ».

Dans les deux cas, la connexion est refusée **même avec un mot de passe correct**. Le texte vient de WordPress, pas du navigateur : il est affiché par le cœur, quel que soit le navigateur utilisé.

## Diagnostic rapide

| Symptôme / constat | Cause probable | À vérifier |
| --- | --- | --- |
| L’erreur disparaît en navigation privée ou avec un autre navigateur | Extension de navigateur, réglage de confidentialité ou cookies obsolètes | Cookies du site, bloqueurs de publicité, paramètres du navigateur |
| Le message parle d’un « retour inattendu » | Du texte ou un espace a été envoyé avant les en-têtes (BOM, ligne vide, notice PHP) | Début de `wp-config.php`, `functions.php`, extensions ; journal d’erreurs |
| Vous arrivez sur le formulaire par `http://` ou sans `www`, alors que le site est en HTTPS ou avec `www` | Cookie posé pour un hôte ou un schéma, formulaire envoyé vers un autre | `siteurl` et `home`, redirections, constantes `WP_HOME` et `WP_SITEURL` |
| Le cookie de test n’apparaît pas dans les en-têtes de `wp-login.php` | Cache de page, CDN ou proxy qui retire `Set-Cookie` | Règles d’exclusion du cache pour `wp-login.php` et `wp-admin` |
| Le problème est apparu après un changement de domaine ou une migration | Constante `COOKIE_DOMAIN` ou adresses du site incohérentes | `wp-config.php`, réglages Général, base de données |

## Les causes les plus fréquentes

1. Des adresses incohérentes : le formulaire est affiché sur `http://exemple.fr`, envoyé vers `https://www.exemple.fr`, et le cookie de test, lié à un autre hôte ou marqué « secure », ne revient pas.
2. Du contenu envoyé avant les en-têtes : un BOM UTF-8, une ligne vide avant `<?php` ou après un `?>` final, un `echo` oublié, une notice ou un avertissement PHP affiché à l’écran.
3. Un cache de page, un CDN ou un proxy qui met en cache `wp-login.php` ou supprime l’en-tête `Set-Cookie`.
4. Un navigateur ou une extension de navigateur qui bloque les cookies du site (réglages de confidentialité, mode strict, bloqueur de traqueurs).
5. Une constante `COOKIE_DOMAIN`, `COOKIEPATH` ou `COOKIEHASH` mal renseignée dans `wp-config.php`, souvent héritée d’un ancien domaine.
6. Une extension de sécurité ou de connexion personnalisée qui modifie la page de connexion ou les cookies.

## Solutions pas à pas

### 1. Tester en navigation privée et vider les cookies

À essayer en premier : ouvrez une fenêtre de navigation privée sans extension et connectez-vous. Si cela fonctionne, supprimez les cookies du site (ou tous les cookies si nécessaire) dans les réglages du navigateur, désactivez ponctuellement vos bloqueurs de publicité, puis réessayez. Vérifiez aussi que votre navigateur n’est pas réglé pour refuser les cookies tiers ou tous les cookies. WordPress renvoie vers sa documentation officielle, qui détaille l’activation des cookies navigateur par navigateur.

### 2. Utiliser la bonne adresse, de bout en bout

Saisissez l’adresse exacte du site, avec son schéma et son nom d’hôte définitifs (par exemple `https://www.exemple.fr/wp-login.php`). Si l’erreur disparaît, le problème est une redirection manquante ou des adresses incohérentes. Contrôlez les deux réglages en base :

```
wp option get siteurl
wp option get home
```

Les deux doivent utiliser le même schéma et le même hôte que celui visé par vos visiteurs. Si vous n’avez plus accès à l’administration, vous pouvez les imposer dans `wp-config.php`, avant la ligne « That's all, stop editing! » :

```
define( 'WP_HOME', 'https://www.exemple.fr' );
define( 'WP_SITEURL', 'https://www.exemple.fr' );
```

Ces constantes remplacent les valeurs enregistrées en base. Ajoutez ensuite, si ce n’est pas fait, une redirection vers l’adresse canonique côté serveur, comme expliqué dans notre fiche sur les [boucles de redirection](https://www.wpmoderne.fr/erreurs-wordpress/trop-de-redirections/), et corrigez les ressources en HTTP avec la fiche sur le [contenu mixte et le passage en HTTPS](https://www.wpmoderne.fr/erreurs-wordpress/contenu-mixte-ssl/).

### 3. Supprimer toute sortie avant les en-têtes

À appliquer si le message mentionne un « retour inattendu », ou si vous venez de modifier un fichier PHP. Activez la journalisation sans affichage dans `wp-config.php` pour repérer le fichier fautif :

```
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
```

Consultez ensuite `wp-content/debug.log` : une ligne « Cannot modify header information - headers already sent by (output started at …) » donne le fichier et la ligne qui ont produit la sortie. La fiche [headers already sent](https://www.wpmoderne.fr/erreurs-wordpress/headers-already-sent/) détaille cette erreur. Quelques contrôles rapides en ligne de commande :

```
head -c 3 wp-config.php | xxd        # "efbbbf" = BOM UTF-8 à supprimer
tail -c 30 wp-config.php | xxd      # un ?> suivi de lignes vides est une cause classique
```

Enregistrez le fichier en « UTF-8 sans BOM », supprimez les `?>` de fin de fichier et les lignes vides avant `<?php`. Notre article sur la [ligne vide avant <?php dans functions.php](https://www.wpmoderne.fr/themes/ligne-vide-avant-php-functions-redirection-ignoree/) montre le cas typique, et celui sur l’[encodage fautif d’un fichier .mo](https://www.wpmoderne.fr/themes/encodage-fautif-fichier-mo-sortie-parasite/) une cause moins évidente. Désactivez ensuite le débogage.

### 4. Exclure la connexion du cache

Vérifiez que le cookie de test est bien envoyé :

```
curl -sI https://www.exemple.fr/wp-login.php | grep -i set-cookie
```

Vous devez voir une ligne `wordpress_test_cookie=WP%20Cookie%20check`. Si elle manque, une couche de cache la supprime. Excluez `wp-login.php` et `/wp-admin/` de votre extension de cache, de votre CDN et de votre cache serveur. Exemple pour un cache FastCGI nginx :

```
set $skip_cache 0;
if ($request_uri ~* "/wp-login.php|/wp-admin/") {
    set $skip_cache 1;
}
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;
```

Sous Apache avec un cache de page en PHP, l’exclusion se configure dans l’extension elle-même. Purgez ensuite tous les caches. L’article sur les [pages jamais mises en cache à cause d’un cookie](https://www.wpmoderne.fr/performance/pages-jamais-mises-en-cache-cookie-oublie/) explique comment les cookies interagissent avec le cache de page.

### 5. Contrôler les constantes de cookie

Ouvrez `wp-config.php` et cherchez `COOKIE_DOMAIN`, `COOKIEPATH`, `SITECOOKIEPATH` et `COOKIEHASH`. Sur un site classique, aucune n’est nécessaire : WordPress les calcule à partir de l’adresse du site. Une valeur laissée par un ancien domaine empêche le navigateur de renvoyer le cookie. Commentez la ligne concernée, rechargez la page de connexion et réessayez. Sur un multisite en sous-domaines, `COOKIE_DOMAIN` est géré par le cœur (`wp-includes/ms-default-constants.php`) ; ne la redéfinissez que si vous savez pourquoi.

### 6. Désactiver les extensions sans accès à l’administration

Si rien ne change, une extension perturbe peut-être la connexion. Par SFTP, renommez le dossier `wp-content/plugins` en `plugins_off`, tentez la connexion, puis remettez le nom d’origine et réactivez les extensions une à une. Avec WP-CLI :

```
wp plugin deactivate --all
# après la connexion, réactivez une par une :
wp plugin activate nom-de-l-extension
```

Notez la liste des extensions actives avant de tout désactiver (`wp plugin list --status=active`).

## Prévenir l’erreur

- Fixez une adresse canonique unique (HTTPS, avec ou sans `www`) et redirigez tout le reste vers elle côté serveur.
- N’ajoutez jamais de `?>` de fermeture en fin de fichier PHP et enregistrez vos fichiers en UTF-8 sans BOM.
- Excluez systématiquement `wp-login.php` et `/wp-admin/` de tous les niveaux de cache, y compris CDN.
- Après une migration, vérifiez `siteurl`, `home` et les constantes de cookie de `wp-config.php`.
- Gardez le débogage en journal, sans affichage à l’écran, pour qu’un avertissement PHP ne casse pas les en-têtes.

## FAQ