# La publication a échoué : réponse JSON invalide dans WordPress

> « La publication a échoué. La réponse n’est pas une réponse JSON valide. » : lisez la réponse REST, régénérez les permaliens et traquez la sortie parasite.

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

> Le serveur a renvoyé autre chose que du JSON à l’éditeur : page 404, bloc du pare-feu ou texte parasite (notice PHP, BOM). Lisez la réponse dans l’onglet Réseau (F12) puis régénérez les permaliens ou supprimez la sortie parasite.

Vous cliquez sur « Publier » ou « Mettre à jour » dans l’éditeur de blocs, et une bannière rouge apparaît en bas ou en haut de l’écran : « La publication a échoué. La réponse n’est pas une réponse JSON valide. ». Sur un contenu déjà publié, le début devient « La mise à jour a échoué. ». Votre texte n’est pas perdu pour autant : il reste dans l’éditeur tant que vous ne fermez pas l’onglet. L’erreur apparaît dans l’administration, dans l’éditeur de blocs, mais aussi dans les réglages ou les écrans modernes qui communiquent avec l’API REST.

## Ce que signifie cette erreur

L’éditeur de blocs n’enregistre pas vos contenus par un formulaire classique : il envoie une requête à l’API REST de WordPress (par exemple vers `/wp-json/wp/v2/posts/123`) grâce à la bibliothèque JavaScript `api-fetch` et attend en retour du JSON. Lorsque la réponse arrive mais que le navigateur n’arrive pas à la lire comme du JSON, la bibliothèque produit l’erreur interne de code `invalid_json` avec le message « La réponse n’est pas une réponse JSON valide. » (fichier `wp-includes/js/dist/api-fetch.js`). L’éditeur (`wp-includes/js/dist/editor.js`) fait précéder ce message de « La publication a échoué. », « La mise à jour a échoué. » ou « La planification a échoué. » selon l’état du contenu ; il ne l’ajoute que s’il ne contient pas de HTML, ce qui explique que certaines pannes n’affichent que la première phrase.

Autrement dit, le serveur a bien répondu, mais pas avec du JSON propre. Ce qui est renvoyé à la place est presque toujours du HTML : page 404 ou 403 du serveur, page d’erreur de WordPress (« Il y a eu une erreur critique sur ce site »), page de connexion, page de maintenance, ou JSON précédé de texte parasite. Ce texte parasite est typiquement un avertissement PHP (`Warning`, `Notice`, `Deprecated`), un espace, une ligne vide ou un caractère invisible (BOM) émis avant la réponse.

## Diagnostic rapide

| Symptôme / constat | Cause probable | À vérifier |
| --- | --- | --- |
| La réponse de la requête contient « Warning » ou « Notice » avant l’accolade ouvrante | Sortie parasite de PHP (affichage des erreurs, espace avant `<?php`, BOM) | Onglet « Réseau » du navigateur, `WP_DEBUG_DISPLAY`, fichiers modifiés récemment |
| La réponse est une page 404 du site ou du serveur | Permaliens ou règles de réécriture cassés, `.htaccess` manquant | Réglages, Permaliens ; `/wp-json/` dans le navigateur |
| La réponse est une page 403 (« Forbidden ») ou une page de pare-feu | ModSecurity, extension de sécurité, règle CDN qui bloque la requête | Journaux du pare-feu, règle déclenchée |
| La réponse est la page d’accueil ou la page de connexion | Redirection http/https ou `www`, API REST protégée par une extension | Réglages généraux, extensions de sécurité |
| La réponse est une page « erreur critique » ou 500 | Erreur fatale PHP pendant l’enregistrement | `wp-content/debug.log`, journaux PHP |

## Les causes les plus fréquentes

1. Des permaliens ou des règles de réécriture à régénérer : l’adresse `/wp-json/` renvoie une page 404 au lieu de JSON.
2. Une extension ou un thème qui produit du texte avant la réponse (avertissement PHP affiché, espace après un `?>` final, fichier enregistré avec un BOM, `echo` oublié).
3. Un pare-feu applicatif, une extension de sécurité ou un CDN qui bloque les requêtes REST ou certains contenus (code, balises, mots jugés suspects).
4. Une redirection entre http et https ou entre `www` et sans `www` qui renvoie une page HTML à la place de la réponse REST.
5. Une extension qui désactive ou restreint l’API REST pour les utilisateurs connectés.
6. Une erreur fatale PHP, un délai dépassé (504) ou un corps de requête trop gros (413) pendant l’enregistrement.

## Solutions pas à pas

### 1. Sauvegarder le contenu et lire la vraie réponse

Avant toute manipulation, copiez votre contenu (Ctrl+A puis Ctrl+C dans l’éditeur, ou menu « Éditeur de code »). Ouvrez ensuite les outils de développement du navigateur (F12), onglet « Réseau », filtrez sur « wp-json » ou « rest_route », puis cliquez à nouveau sur « Mettre à jour ». Sélectionnez la requête en erreur : le statut HTTP et l’onglet « Réponse » vous disent exactement ce que le serveur a renvoyé. Tout le diagnostic découle de cette observation. En ligne de commande, vous pouvez aussi tester la racine de l’API :

```
curl -i https://www.exemple.fr/wp-json/
curl -s https://www.exemple.fr/wp-json/ | head -c 300
```

Une réponse correcte commence par `{"name":`. Tout caractère situé avant l’accolade est le texte parasite recherché.

### 2. Régénérer les permaliens

Si la réponse est une page 404, ouvrez Réglages, Permaliens, et cliquez sur « Enregistrer les modifications » sans rien changer. WordPress réécrit alors ses règles. Sans accès à l’administration, utilisez WP-CLI :

```
wp rewrite flush --hard
```

Si le fichier `.htaccess` est absent ou incomplet (Apache), il doit contenir le bloc standard :

```
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
```

Sous nginx, la règle équivalente se place dans le bloc `server` :

```
location / {
    try_files $uri $uri/ /index.php?$args;
}
```

Vérification : `https://www.exemple.fr/wp-json/` doit afficher du JSON. Si ce n’est pas le cas, `https://www.exemple.fr/?rest_route=/` doit le faire : dans ce cas, seuls les permaliens ou le serveur sont en cause.

### 3. Trouver la sortie parasite

Si la réponse contient du texte avant le JSON, commencez par masquer l’affichage des erreurs tout en les journalisant, dans `wp-config.php`, avant la ligne « That's all, stop editing! » :

```
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
```

Réessayez de publier, puis lisez `wp-content/debug.log` : chaque avertissement indique le fichier et la ligne en cause. Corrigez-le ou mettez l’extension concernée à jour. Pour un espace ou un BOM, recherchez les fichiers PHP qui commencent par un caractère invisible ou qui contiennent un `?>` final suivi d’une ligne vide :

```
grep -rl $'\xEF\xBB\xBF' wp-content/themes wp-content/plugins --include=*.php
```

Enregistrez le fichier fautif en « UTF-8 sans BOM » et supprimez toute ligne vide avant `<?php` et après un `?>` final. Notre article sur la [ligne vide avant le PHP de functions.php](https://www.wpmoderne.fr/themes/ligne-vide-avant-php-functions-redirection-ignoree/) illustre ce piège. Pensez à désactiver ensuite `WP_DEBUG` en production et à lire [nos bons réflexes avec debug.log](https://www.wpmoderne.fr/tips/wp-debug-log-bons-reflexes-debogage-wordpress/).

### 4. Isoler l’extension ou le thème fautif

Désactivez toutes les extensions, puis réactivez-les une à une en testant après chacune. Sans accès à l’administration, renommez le dossier `wp-content/plugins` ou utilisez WP-CLI :

```
wp plugin deactivate --all
wp plugin activate nom-de-l-extension
```

Si l’erreur persiste, basculez temporairement sur un thème par défaut (`wp theme activate twentytwentyfive`, si ce thème est installé). Si le problème disparaît, la sortie parasite vient du thème ou d’une extension, et la solution 3 vous aide à la localiser.

### 5. Débloquer le pare-feu, le CDN ou l’extension de sécurité

Si la réponse est une page 403 ou une page de challenge, cherchez dans les journaux du pare-feu (ModSecurity, extension de sécurité, règle du CDN) la règle déclenchée à l’heure de l’échec. Autorisez les requêtes vers `/wp-json/` pour les utilisateurs connectés, ou ajoutez une exception pour la règle précise. Évitez de désactiver tout le pare-feu : une exception ciblée suffit.

### 6. Corriger les adresses et les redirections

Vérifiez, dans Réglages, Général, que « Adresse WordPress (URL) » et « Adresse web (URL du site) » correspondent à l’URL utilisée dans le navigateur (même protocole, même `www`). Une requête REST qui subit une redirection vers une autre adresse peut aboutir à du HTML. Si le navigateur signale aussi trop de redirections, consultez la fiche sur la [boucle de redirection ERR_TOO_MANY_REDIRECTS](https://www.wpmoderne.fr/erreurs-wordpress/trop-de-redirections/).

Dans Outils, Santé du site, les tests « L’API REST a rencontré une erreur » ou « L’API REST a rencontré un résultat inattendu » confirment que le problème dépasse l’éditeur.

## Prévenir l’erreur

- Gardez `WP_DEBUG_DISPLAY` à `false` en production, et journalisez les erreurs dans `debug.log` plutôt que de les afficher.
- Ne laissez pas de balise `?>` de fermeture à la fin des fichiers PHP : elle n’est pas obligatoire et évite les espaces parasites.
- Testez l’éditeur après chaque mise à jour d’extension de sécurité ou de cache sur un site de préproduction.
- Centralisez vos journaux PHP et serveur, comme dans notre article sur les [journaux nginx et PHP de WordPress](https://www.wpmoderne.fr/hebergement/centraliser-logs-nginx-php-wordpress-diagnostiquer/).
- Documentez les exceptions du pare-feu pour `/wp-json/` afin de les retrouver après une migration.

## FAQ