Une page WordPress affiche soudainement « 400 Bad Request » après l’envoi d’un formulaire, l’ouverture de l’éditeur ou un appel REST. Pour corriger une WordPress erreur 400, identifiez la requête rejetée, videz les cookies du domaine, contrôlez l’URL et les paramètres, puis remontez la chaîne du navigateur jusqu’à WordPress, au proxy et au serveur. Le code 400 signifie que le serveur ne peut pas comprendre la demande reçue. Il ne prouve pas que le site est hors ligne.

Le symptôme est parfois trompeur. La page d’accueil fonctionne, mais l’administration refuse une seule action. Un import échoue alors qu’un simple article se publie. La méthode fiable consiste à conserver l’URL complète, la méthode HTTP, les en-têtes et le corps de réponse, puis à reproduire avec une requête minimale.

Que signifie exactement une WordPress erreur 400 ?

Le statut HTTP 400 correspond à une requête mal formée ou impossible à traiter. La spécification HTTP le distingue d’une authentification manquante, d’une ressource absente ou d’une panne interne. Dans WordPress, le refus peut venir du navigateur, d’un CDN, d’un pare feu, de PHP, d’une extension ou d’une route REST personnalisée.

Le même code peut donc cacher des causes très différentes. Un cookie trop volumineux provoque souvent une réponse 400 du serveur web. Une URL mal encodée peut être bloquée par Apache ou Nginx. Un paramètre inattendu peut être refusé par WordPress. Une règle ModSecurity peut interpréter un contenu légitime comme une attaque. Le texte affiché et les en-têtes sont plus instructifs que le nombre seul.

Commencez par noter quatre éléments, l’adresse exacte, l’action déclenchée, le navigateur utilisé et l’heure. Si la réponse vient d’un proxy, le HTML peut contenir son nom ou un identifiant de requête. Si elle vient de WordPress, le corps est souvent JSON pour la REST API ou une page générée par le thème.

curl -i -sS --max-time 20 
  'https://exemple.fr/wp-json/wp/v2/posts?per_page=1'

# Comparer la page et la route REST
curl -sS -D - -o /dev/null https://exemple.fr/
curl -sS -D - -o /dev/null https://exemple.fr/wp-json/

Écarter les cookies et l’état du navigateur

La première correction est simple et réversible. Ouvrez l’URL en navigation privée. Si l’action fonctionne, supprimez les cookies du seul domaine WordPress, puis reconnectez vous. Ne supprimez pas toute l’historique par réflexe. Un cookie de session ou de préférence trop gros peut dépasser la limite acceptée par le serveur. Plusieurs sous domaines peuvent aussi envoyer des cookies qui ne sont pas nécessaires à l’administration.

Testez ensuite un autre navigateur et désactivez temporairement les extensions qui modifient les requêtes. Les bloqueurs, extensions de traduction et outils de développement peuvent ajouter des en-têtes ou réécrire une URL. Dans les outils réseau du navigateur, exportez la requête fautive uniquement après avoir retiré les cookies et jetons secrets.

Si la navigation privée échoue aussi, la cause se situe probablement dans l’URL, le serveur ou WordPress. Si elle réussit, inspectez la taille et le domaine des cookies. Un administrateur peut vérifier la réponse sans divulguer la valeur des cookies dans un ticket de support.

Vérifier l’URL, les paramètres et l’encodage

Une URL construite par concaténation est une source fréquente de 400. Les espaces, accents, crochets, caractères Unicode et valeurs JSON doivent être encodés selon le contexte. Utilisez une fonction d’encodage prévue pour les paramètres, pas un remplacement manuel des espaces. Vérifiez aussi qu’une URL copiée ne contient pas un retour à la ligne ou deux points d’interrogation.

from urllib.parse import urlencode

params = {
    "s": "erreur WordPress",
    "per_page": 10,
    "_fields": "id,link,title"
}
url = "https://exemple.fr/wp-json/wp/v2/search?" + urlencode(params)
print(url)

Dans la REST API WordPress, réduisez la requête à un paramètre à la fois. Retirez d’abord les filtres, puis remettez les paramètres un par un. Une route qui répond à /wp-json/wp/v2/posts mais pas à votre URL complète révèle souvent un filtre mal nommé, une valeur vide ou une extension qui durcit la validation.

curl -i -sS 
  'https://exemple.fr/wp-json/wp/v2/posts?per_page=1'

# Ajouter un filtre encodé proprement
curl -i -sS --get 'https://exemple.fr/wp-json/wp/v2/search' 
  --data-urlencode 'search=erreur WordPress' 
  --data 'per_page=5'

Ne transmettez jamais un mot de passe ou un jeton dans l’URL. Les URL apparaissent dans les journaux, l’historique et parfois les outils d’analyse. Utilisez l’en-tête d’autorisation adapté au client et à l’intégration.

Diagnostiquer un formulaire ou l’éditeur WordPress

Si l’erreur apparaît au moment d’enregistrer un article, distinguez le formulaire classique de l’éditeur de blocs. Ouvrez les outils réseau, relancez une seule fois l’action et repérez la requête qui reçoit 400. Une erreur sur admin-ajax.php n’a pas le même traitement qu’une erreur sur wp-json/wp/v2/posts.

Un contenu particulier peut déclencher une règle de sécurité. Faites une copie du texte dans un éditeur local, testez un article très court, puis réintroduisez les éléments par groupes. Les balises HTML, les chaînes longues, les blocs de code et certains motifs peuvent être filtrés par le WAF avant même que WordPress ne voie la demande.

Le nonce ne doit pas être confondu avec une erreur 400 générique. Un nonce expiré produit souvent une erreur WordPress structurée et se corrige en rechargeant l’éditeur. Si le même compte obtient 400 dans tous les navigateurs, regardez plutôt le serveur, le proxy ou l’extension qui traite la requête.

# Vérifier le statut et le type de réponse d'une route
curl -sS -D /tmp/headers.txt -o /tmp/body.txt 
  -H 'Accept: application/json' 
  'https://exemple.fr/wp-json/wp/v2/posts?per_page=1'
head -n 12 /tmp/headers.txt
head -c 800 /tmp/body.txt

Inspecter Apache, Nginx, LiteSpeed et le pare feu

Une page 400 produite par le serveur web arrive avant WordPress. Elle peut être liée à une ligne de requête invalide, à des en-têtes trop grands, à une URL refusée ou à une règle de sécurité. Comparez l’en-tête Server, le type de contenu et la structure de la page. Un identifiant de requête ou une signature de fournisseur aide le support à retrouver l’événement.

Sur Apache, vérifiez les journaux d’erreur et les règles de réécriture. Sur Nginx ou LiteSpeed, cherchez les limites de taille des en-têtes, les règles de proxy et les erreurs de parsing. Sur un hébergement mutualisé, demandez au support de confirmer la règle à l’heure exacte plutôt que de modifier des paramètres non accessibles.

Un WAF peut bloquer un paramètre qui ressemble à une injection. Ne désactivez pas la sécurité pour tout le site. Testez une exception étroite sur la route et le flux concernés, avec une durée limitée, puis confirmez que les journaux montrent bien la cause. Une règle trop large sur l’administration protège mal et perturbe les utilisateurs légitimes.

# Informations utiles à transmettre au support
printf 'Date UTC : '; date -u
printf 'URL : '; printf '%sn' 'https://exemple.fr/route-a-tester'
printf 'Statut : '; head -n 1 /tmp/headers.txt
grep -iE 'server|request-id|content-type|location' /tmp/headers.txt

Contrôler les extensions et les routes REST

Une extension de sécurité, de cache, de formulaire ou de SEO peut valider les requêtes avant leur traitement. Une extension récemment mise à jour est un indice, mais pas une preuve. Consultez ses journaux, son changelog et sa documentation. Reproduisez sur une copie de test lorsque c’est possible.

Pour isoler la cause sans couper la protection devant les visiteurs, utilisez le mode dépannage de WordPress sur votre session d’administrateur. Si l’erreur disparaît, réactivez les extensions une par une. Ne laissez pas le site en mode diagnostic après le test. Une extension peut également enregistrer une route REST personnalisée dont le code rejette un paramètre ou une méthode.

add_action('rest_api_init', function () {
    register_rest_route('mon-site/v1', '/rapport', [
        'methods'  => 'GET',
        'callback' => 'mon_lire_rapport',
        'permission_callback' => function () {
            return current_user_can('read');
        },
    ]);
});

function mon_lire_rapport(WP_REST_Request $request) {
    $format = $request->get_param('format');
    if ($format !== null && !in_array($format, ['court', 'complet'], true)) {
        return new WP_Error(
            'format_invalide',
            'Le format demandé est inconnu.',
            ['status' => 400]
        );
    }
    return rest_ensure_response(['ok' => true]);
}

Une erreur 400 explicite dans une route personnalisée est préférable à un écran blanc. Retournez un code stable, un message compréhensible et un statut cohérent. N’incluez pas de trace PHP, de chemin serveur ou de secret dans la réponse publique.

Activer le débogage sans exposer les erreurs

Si la réponse semble venir de WordPress, activez temporairement la journalisation dans un environnement maîtrisé. Le journal doit rester inaccessible au public. La documentation officielle recommande de ne pas afficher les erreurs sur un site en production. Après le test, désactivez le mode ou retirez les traces devenues inutiles.

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

Reproduisez une seule fois, puis cherchez l’heure correspondante dans wp-content/debug.log et dans les journaux du serveur. Un 400 sans entrée WordPress confirme généralement que la requête a été bloquée avant le cœur. Une exception, un avertissement ou une erreur de validation pointe vers le code ou l’extension concernés.

Ne copiez pas un journal complet dans un forum public. Retirez les adresses, chemins, identifiants, URL privées et valeurs de formulaire. Pour un diagnostic plus large, notre guide sur le mode debug WordPress détaille la méthode et les précautions.

Ne pas confondre 400 avec les autres erreurs WordPress

Le code 400 concerne la demande reçue. Une erreur 401 concerne l’authentification, une 403 le refus d’autorisation et une 404 la ressource introuvable. Une 408 indique que le serveur a attendu trop longtemps la demande. Une 413 signifie que le corps est trop volumineux. Une 429 correspond à une limitation de rythme. Une 500 indique une erreur interne.

Cette distinction guide le premier geste. Pour un délai de lecture, consultez notre guide WordPress erreur 408. Pour un upload trop grand, voyez WordPress erreur 413. Pour une limitation de requêtes, le guide WordPress erreur 429 explique Retry-After et la reprise progressive.

Les statuts peuvent se mélanger dans une chaîne de proxy. Relevez toujours le premier refus observé, l’URL et l’en-tête du serveur. Augmenter la mémoire PHP ne corrigera pas un cookie trop grand. Vider le cache ne corrigera pas une règle WAF qui bloque une route.

Checklist de résolution rapide

Commencez par reproduire l’erreur en navigation privée. Contrôlez l’URL et encodez les paramètres. Comparez la page d’accueil, la racine REST et la route fautive. Inspectez la réponse avec curl -i. Identifiez la couche qui répond. Consultez les journaux du CDN, du WAF et du serveur. Testez un contenu minimal. Désactivez une extension uniquement en mode dépannage. Activez le journal WordPress sans afficher les erreurs. Corrigez la cause puis retestez une seule fois.

Après correction, surveillez les mêmes routes pendant quelques heures. Vérifiez les actions d’administration, les formulaires, les imports et les intégrations externes. Si le site est hébergé par un tiers, fournissez une heure UTC, une URL, un statut, un identifiant de requête et un extrait non sensible. Cette préparation évite les échanges vagues et accélère le diagnostic.

Si les données sont comprises mais refusées par une validation, consultez aussi WordPress erreur 422, le guide consacré à Unprocessable Content.

FAQ sur WordPress erreur 400

Pourquoi WordPress affiche t il 400 Bad Request ?

La requête reçue est mal formée, trop grande ou refusée par une règle située dans le navigateur, le serveur web, un proxy, un pare feu, une extension ou WordPress lui même.

Vider les cookies corrige t il une erreur 400 ?

Oui, lorsque des cookies du domaine sont trop volumineux, invalides ou incohérents. Testez d’abord la navigation privée, puis supprimez uniquement les cookies du site concerné.

Comment savoir si l’erreur vient de la REST API ?

Repérez la requête dans les outils réseau du navigateur ou reproduisez la route avec curl -i. Une réponse JSON sur /wp-json/ oriente vers WordPress ou une extension, tandis qu’une page HTML de proxy oriente vers une couche en amont.

Faut il modifier le fichier .htaccess ?

Pas avant d’avoir identifié une règle responsable. Sauvegardez le fichier, faites une modification ciblée et vérifiez la syntaxe. Une règle de réécriture incorrecte peut créer de nouvelles erreurs.

Une WordPress erreur 400 empêche t elle le référencement ?

Une erreur ponctuelle sur une action d’administration ne touche pas forcément l’exploration. Si les robots reçoivent 400 sur des pages publiques, corrigez rapidement le problème et contrôlez les journaux d’exploration.

Sources et références

N
· Développeur WordPress & fullstack · Expert IA

Natsou développe sur WordPress depuis plus de 10 ans. Développeur fullstack et expert en intelligence artificielle, il conçoit, débogue et sécurise des sites en production et automatise les workflows d'agence. Sur WP Admin Lab, il partage des procédures testées en conditions réelles : diagnostics reproductibles, correctifs vérifiés et retours de terrain, sans jargon inutile.

mastodon