Vous publiez une page, chargez une image ou ouvrez l’API REST, puis WordPress affiche soudain « 406 Not Acceptable ». Pour corriger une WordPress erreur 406, inspectez d’abord les en-têtes Accept et Accept-Language, puis testez la négociation de contenu, le cache, le WAF et les règles du serveur. Le code 406 signifie que le serveur comprend la requête, mais ne trouve pas de représentation acceptable pour le client. Il ne faut donc pas commencer par réinstaller WordPress ou augmenter la mémoire PHP.
Le symptôme peut être déroutant. La page fonctionne dans Chrome, mais échoue dans une extension, une commande curl ou l’éditeur de blocs. Dans d’autres cas, seule une URL contenant des caractères particuliers est refusée. Ce guide permet de déterminer si le 406 vient du cœur WordPress, d’un plugin, d’Apache, de LiteSpeed, de Nginx ou d’un pare-feu applicatif.
Que signifie une WordPress erreur 406 ?
Le statut HTTP 406, appelé Not Acceptable, appartient à la famille des réponses d’erreur côté client. La requête est syntaxiquement exploitable, mais le serveur ne peut pas fournir une réponse correspondant aux critères annoncés par le client. Ces critères sont souvent transmis dans Accept, qui décrit les types de contenu souhaités, ou dans des en-têtes de langue et d’encodage.
Un navigateur envoie généralement une liste assez large, par exemple du HTML, du XHTML et des images. Une intégration stricte peut au contraire demander seulement un format que la route ne produit pas. Le serveur peut alors répondre 406. La documentation HTTP précise toutefois que les applications et les protections peuvent aussi employer ce statut pour signaler un contenu rejeté.
Dans WordPress, un 406 peut apparaître sur une page publique, une requête /wp-json/, l’administration ou un formulaire. L’emplacement du refus est essentiel. Si le journal PHP ne voit aucun appel, le serveur ou le WAF répond probablement avant WordPress. Si une erreur JSON contient un message WordPress, examinez plutôt la route et le plugin.
Commencer par relever la requête exacte
Ne rechargez pas la page en boucle. Ouvrez les outils de développement, onglet Réseau, reproduisez le problème une fois et sauvegardez l’URL, la méthode, le statut et les en-têtes. Contrôlez aussi si la réponse est du HTML généré par un pare-feu ou du JSON produit par la REST API.
curl -i -sS --max-time 20
-H 'Accept: text/html'
'https://exemple.fr/page-a-tester/'Refaites ensuite le test en demandant le format réellement attendu. Pour une API, application/json est plus logique que text/html. Pour une page, text/html doit normalement être accepté. Cette comparaison permet de repérer rapidement une négociation trop stricte.
curl -i -sS --max-time 20
-H 'Accept: application/json'
'https://exemple.fr/wp-json/wp/v2/posts?per_page=1'Ne publiez jamais les cookies, les jetons, les nonces ou les en-têtes d’authentification dans un ticket ou une capture d’écran. Un diagnostic utile conserve l’URL et le statut, mais masque les données de session.
Vérifier l’en-tête Accept et la négociation de contenu
La cause la plus littérale d’un 406 est un en-tête Accept incompatible avec la réponse. Par exemple, un client qui envoie uniquement application/xml ne doit pas s’attendre à recevoir une page HTML. Une bibliothèque peut ajouter cet en-tête automatiquement, sans que le développeur l’ait écrit dans son code.
Comparez le résultat avec une requête sans en-tête personnalisé, puis avec un en-tête large. Si la page redevient accessible, corrigez le client plutôt que le serveur. Dans JavaScript, évitez de demander un format que l’endpoint ne documente pas.
const response = await fetch('/wp-json/wp/v2/posts', {
headers: { Accept: 'application/json' }
});
if (!response.ok) {
throw new Error(`HTTP ${response.status}`);
}
const data = await response.json();Les valeurs avec un facteur de préférence, comme text/html;q=0, peuvent exclure explicitement un format. Les valeurs */* et q sont utiles pour comprendre le choix du serveur. Vérifiez aussi Accept-Encoding si un proxy annonce un encodage que la chaîne de diffusion ne sait pas produire.
Une page WordPress standard ne demande généralement aucune configuration spéciale de négociation. Si le problème survient uniquement avec un outil tiers, conservez le serveur tel quel et ajustez l’en-tête envoyé par cet outil.
Tester Accept-Language et Accept-Encoding
Un 406 ne concerne pas uniquement le type MIME. La langue et l’encodage peuvent également entrer dans la sélection de la représentation. Une règle serveur trop restrictive peut refuser une langue non disponible, ou un proxy peut demander Brotli alors que la chaîne amont ne le fournit pas correctement.
curl -i -sS
-H 'Accept: text/html'
-H 'Accept-Language: fr-FR,fr;q=0.9'
-H 'Accept-Encoding: gzip'
'https://exemple.fr/'Comparez ce résultat à un appel avec les en-têtes par défaut. Si une langue précise échoue, recherchez les directives de négociation dans la configuration Apache ou le proxy. Si seul un encodage échoue, désactivez temporairement la compression sur la route de test, uniquement pour confirmer l’hypothèse.
Le réglage de la langue WordPress, dans Réglages puis Général, n’est pas la même chose que l’en-tête HTTP envoyé par un navigateur. Changer la langue du tableau de bord ne corrige donc pas automatiquement une règle serveur mal configurée.
Inspecter Apache, LiteSpeed et le fichier .htaccess
Sur un hébergement mutualisé, Apache ou LiteSpeed peut produire le 406 avant l’exécution de PHP. Cherchez les directives liées à la négociation, aux types MIME, aux encodages et aux modules de sécurité. Une règle ajoutée récemment dans .htaccess est un indice important.
Ne remplacez pas tout le fichier par un exemple trouvé sur un forum. Faites une copie locale, identifiez la ligne responsable et retirez seulement la modification récente. Le bloc standard des permaliens WordPress ne suffit normalement pas à provoquer un 406.
# Exemple de bloc de test, à adapter à l’hébergement
<IfModule mod_headers.c>
Header unset Accept-Charset
</IfModule>Ce bloc n’est pas une recette universelle. Il sert à illustrer le principe d’une règle d’en-tête. Si votre hébergeur interdit mod_headers ou si LiteSpeed interprète différemment la directive, la configuration peut être ignorée ou déclencher une erreur 500. Testez avec prudence et supprimez tout essai qui n’est pas nécessaire.
Le module Apache de négociation peut également choisir une ressource différente lorsqu’une URL correspond à plusieurs variantes. Une configuration MultiViews mal adaptée aux permaliens peut produire des comportements inattendus. Désactivez cette option uniquement si elle est réellement active et après avoir vérifié la documentation de l’hébergeur.
Contrôler Nginx, le proxy et le CDN
Avec Nginx, un reverse proxy ou un CDN, il faut localiser la première couche qui renvoie le statut. Comparez les en-têtes Server, Via, Age et l’identifiant de requête. Un cache peut continuer à servir une ancienne réponse après la correction de la configuration.
curl -sS -D headers.txt -o body.html
'https://exemple.fr/page-a-tester/'
grep -iE 'HTTP/|server|via|age|request-id|content-type' headers.txtSi la réponse contient une page de blocage du CDN et aucun indice WordPress, purgez uniquement l’URL concernée, puis vérifiez la règle de contenu. Une purge globale est rarement nécessaire. Contrôlez aussi que le proxy ne remplace pas l’en-tête Accept ou ne transmet pas une valeur vide.
Dans une architecture avec cache de page, testez une URL avec un paramètre de diagnostic seulement si le cache le permet. Ne laissez pas un paramètre de contournement indexable. Le but est de comparer deux réponses, pas de créer une nouvelle version publique de chaque page.
Isoler le WAF et les plugins de sécurité
Les WAF et certains plugins de sécurité utilisent 406 comme réponse à un motif considéré comme suspect. Une URL contenant des crochets, des opérateurs SQL, du HTML ou une longue chaîne encodée peut déclencher une règle. Ce n’est pas la preuve que la requête est malveillante. C’est un signal de faux positif ou de contenu à examiner.
Consultez le journal du pare-feu à l’heure exacte du test. Cherchez l’identifiant de règle, la route et le paramètre bloqué. Désactivez temporairement une règle précise dans un environnement contrôlé, puis rejouez un test minimal. Ne coupez pas toute la protection du domaine pour faire disparaître le message.
Si le blocage provient d’un plugin, utilisez son mode dépannage ou désactivez-le uniquement pour votre session d’administrateur lorsque cette fonction existe. Réactivez-le ensuite et créez une exception limitée à l’URL, au paramètre et au motif nécessaires. Notre guide sur la sécurité WordPress et le WAF détaille cette logique de réduction du risque.
Après toute exception, vérifiez que les journaux continuent de signaler les autres attaques. Une exception globale sur wp-json ou sur tout le domaine affaiblit inutilement la protection.
Quand le problème touche la REST API WordPress
Une requête REST doit annoncer le format qu’elle attend et respecter la route documentée. Commencez par un appel GET public et minimal. Si celui-ci répond correctement, ajoutez ensuite l’authentification, les paramètres et le corps JSON un par un.
curl -i -sS
-H 'Accept: application/json'
'https://exemple.fr/wp-json/wp/v2/posts?per_page=1'Un 406 sur une création ou une modification peut être produit par une extension qui filtre le contenu, par un WAF ou par un client qui demande le mauvais type. Contrôlez le champ Content-Type pour le corps envoyé et Accept pour la réponse. Ce sont deux informations différentes.
Ne confondez pas 406 avec les erreurs d’authentification et de permissions. Pour approfondir les routes, les droits et les méthodes, consultez notre guide REST API 403 et notre diagnostic REST API 401.
Comparer avec les autres erreurs HTTP
Le code observé évite de partir dans la mauvaise direction. Une erreur 400 indique en général une requête mal formée. Une 401 concerne l’authentification. Une 403 refuse l’autorisation. Une 404 signale une route ou une ressource absente. Une 405 indique que la méthode HTTP n’est pas autorisée. Une 406 concerne la représentation demandée. Une 500 révèle une erreur interne.
Si le serveur refuse uniquement POST, vérifiez plutôt la méthode autorisée avec ce guide sur l’erreur 405 WordPress. Si l’appel met du temps avant de tomber, notre dossier sur WordPress erreur 504 suit une autre piste. Cette distinction est importante pour ne pas modifier le WAF lorsque le vrai problème est une route incorrecte.
Checklist de correction sans casser le site
Notez l’URL, l’heure et le client qui échoue. Reproduisez avec curl et un en-tête Accept adapté. Comparez avec le navigateur. Lisez les en-têtes et le corps de réponse. Vérifiez les journaux Apache, LiteSpeed, Nginx, CDN et WAF. Isolez un plugin de sécurité. Contrôlez la route REST et ses méthodes. Purgez seulement le cache concerné. Corrigez la règle identifiée. Rejouez enfin le test depuis deux clients différents.
Après la réparation, testez une page publique, la connexion à l’administration, l’éditeur de blocs et les routes REST utilisées par vos intégrations. Vérifiez aussi une URL avec des caractères accentués, un formulaire normal et une image. Gardez une note de la cause, de la règle modifiée et de la date. Cette trace est précieuse lors d’une mise à jour d’hébergement ou de plugin.
Un 406 persistant sans trace dans WordPress doit être transmis à l’hébergeur avec une heure UTC, une URL de test et les en-têtes non sensibles. Demandez quelle couche génère le statut avant de demander une désactivation générale du pare-feu.
FAQ sur WordPress erreur 406
Pourquoi WordPress renvoie-t-il une erreur 406 ?
Le serveur ne trouve pas de représentation correspondant aux critères du client, ou une couche de sécurité rejette le contenu. Vérifiez d’abord les en-têtes Accept et les journaux du WAF.
Une erreur 406 vient-elle forcément de WordPress ?
Non. Apache, LiteSpeed, Nginx, un CDN ou un plugin de sécurité peut répondre avant que WordPress ne soit exécuté.
Comment tester une erreur 406 avec curl ?
Reproduisez l’URL avec curl -i, puis comparez un en-tête Accept: text/html avec Accept: application/json selon la route. Observez le serveur et le corps de réponse.
Faut-il désactiver le pare-feu pour corriger un 406 ?
Non. Identifiez la règle responsable et créez au besoin une exception limitée. Une désactivation globale augmente le risque et masque la cause.
Une erreur 406 bloque-t-elle le référencement ?
Oui, si les pages publiques renvoient ce statut aux robots. Contrôlez une URL publique avec curl et les outils pour webmasters après la correction.
Commentaires (0)
Laisser un commentaire
Les commentaires sont modérés. Questions WordPress, cybersécurité ou dev web bienvenues.