400Code HTTP 400 : Bad Request et diagnostic SEO

Le 400 est un fourre-tout : la RFC 9110 le décrit comme une erreur perçue du client. Il peut être produit par plusieurs couches : proxy, pare-feu applicatif, serveur web, framework ou application. Il se distingue du 404 : ici, ce n’est pas la ressource qui manque, c’est la requête qui est illisible.

Collez l’URL, trouvez la cause

L’inspecteur repère les défauts qui font rejeter une requête : encodage, caractères interdits, longueur, poids des cookies. L’analyse se fait dans votre navigateur, rien n’est envoyé. Les seuils sont des ordres de grandeur : ils varient selon le serveur, le CDN et le pare-feu.

Causes fréquentes d’une erreur 400

URL mal encodée

Caractères non encodés, espaces, séquence « % » incomplète, paramètres inattendus ou valeurs non conformes. Les facettes et filtres mal cadrés en produisent beaucoup.

Cookies trop lourds

Trop nombreux, trop volumineux ou corrompus (tracking, tests A/B, sessions), ils font dépasser la limite d’en-têtes. Beaucoup de serveurs rejettent alors la requête au parsing ; effacer les cookies du domaine confirme la piste.

Corps invalide

JSON mal formé, champ manquant, type incorrect ou dépassement de taille (client_max_body_size, par exemple), sur un endpoint d’API ou un formulaire strict.

Pare-feu ou validation stricte

Un WAF ou une règle de sécurité peut rejeter une requête jugée suspecte en 400 plutôt qu’en 403, selon sa configuration.

Appel WordPress mal formé

Sous WordPress, admin-ajax.php répond 400 sans paramètre action ou avec une action non déclarée : des 400 sur cette adresse viennent d’un script d’extension ou de thème qui l’appelle mal.^[5]

Diagnostic rapide d’un code 400

1. 01Qualifier le périmètre : URL isolée, motif récurrent (paramètres), endpoint d’API ou volume massif ? Priorisez par fréquence et par URL stratégique.
2. 02Reproduire avec curl -I : sans cookies, puis avec. Si la requête passe sans, les cookies sont en cause.
3. 03Lire les journaux du serveur : URL complète, query string, user-agent, referer, taille de la requête. Le motif exact du rejet y figure presque toujours. Voir l’analyse de logs.
4. 04Retrouver la source du lien : un crawl du site montre quelle page, quel script ou quel balisage produit l’URL mal formée. Un 400 « SEO » est presque toujours une URL générée, pas une saisie manuelle.
5. 05Vérifier le CDN et le WAF : ils peuvent rejeter une requête avant qu’elle n’atteigne le serveur, et n’apparaissent alors pas dans ses journaux.

Vous voyez une erreur 400 en tant que visiteur

Si l’erreur disparaît en navigation privée, la cause est un cookie, une extension ou le cache du navigateur ; si elle persiste partout, le problème vient du site.

• Vérifiez l’adresse saisie : un espace ou un « % » incomplet suffit à la rendre invalide.
• Supprimez les cookies du site concerné, puis rechargez : des cookies trop lourds ou corrompus sont une cause fréquente.
• Testez en navigation privée, avec un autre navigateur ou depuis un autre réseau, pour écarter une extension ou un filtre local.
• Prévenez l’exploitant du site si l’erreur persiste : adresse exacte et heure.

Exemple de réponse HTTP 400

HTTP/1.1 400 Bad Request
Content-Type: text/html; charset=UTF-8
Connection: close

• Les en-têtes Server, Via ou X-Cache indiquent si la réponse vient du serveur ou d’un proxy.
• Une page d’erreur personnalisée doit conserver le statut 400, pas répondre 200.
• Comparez la réponse avec et sans cookies : c’est le test le plus rapide.

Le message dépend du serveur. Nginx complète « 400 Bad Request » par « Request Header Or Cookie Too Large » quand les en-têtes ou les cookies dépassent la limite ; Apache indique « Size of a request header field exceeds server limit ».^[4]

400 ou un autre code ?

Le 400 est un fourre-tout. Quand un code plus précis existe, il aide à diagnostiquer. Le 404 dit que la ressource n’existe pas ; le 422, que la requête est bien formée mais que ses données ne peuvent pas être traitées (validation métier).

Impact SEO du code 400

Indexation

Une URL en 400 n’est pas indexée, et si elle l’était avant, elle finit par sortir de l’index. Google la traite comme une erreur côté client, comme les autres 4xx hors 429 : pas de sanction pour le site, mais une page perdue si elle devait exister.^[3]

Exploration

Des liens internes vers des URL mal formées font consommer des requêtes à Googlebot pour rien. Le problème devient visible quand le volume est important, par exemple avec des paramètres ou des facettes mal maîtrisés. Voir budget de crawl.

Cause côté site

Si Googlebot reçoit des 400 sur de vraies pages, c’est le site qui fabrique des URL invalides : paramètres, liens de tracking, scripts. Les journaux repèrent le motif, la source se corrige à la racine.

Reste le piège du soft 404 : une page qui affiche un message d’erreur ou un contenu vide mais répond 200. Le statut doit refléter la réalité : une requête invalide appelle un 400, pas un 200.

Bonnes pratiques SEO pour gérer un 400

• Réduire les paramètres inutiles et cadrer les facettes (noindex, canonical, règles de crawl).
• Normaliser l’encodage des URL et valider en amont, côté front ou middleware.
• Limiter le volume et la taille des cookies : tracking, tests A/B, scripts tiers.^[4]
• Surveiller les journaux et les croiser avec la Search Console (pages exclues, exploration) : les 4xx autres que 401, 403 et 404 y sont regroupées sous « Bloquée en raison d’un autre problème de type 4xx ».
• Ne pas rediriger une URL en 400 : corriger le lien qui la produit. Une redirection masquerait la cause sans la régler.

Un 400 isolé sur une requête manifestement invalide est normal. Un 400 récurrent sur des URL générées par le site est un signal à traiter.

Questions fréquentes sur le code 400

Sources

1. 1RFC 9110 : 400 Bad Request · IETF
2. 2MDN : le statut 400 Bad Request · Mozilla
3. 3Google Search Central : comment Google traite les codes HTTP
4. 4Apache : LimitRequestFieldSize · Nginx : large_client_header_buffers
5. 5WordPress : le fichier admin-ajax.php