Code HTTP 400 : Bad Request et diagnostic SEO

Qu’est-ce que le code HTTP 400 Bad Request ?

Le code 400 indique que la requête envoyée au serveur est mal formée ou non conforme aux règles attendues. La ressource n’est pas “introuvable” (comme une 404) : c’est la requête qui est invalide (URL, paramètres, en-têtes, cookies ou corps).

Dans une architecture moderne, un 400 peut être généré par plusieurs couches : reverse proxy, WAF, serveur web (Nginx/Apache), framework applicatif, gateway API ou application elle-même (validation stricte).

Exemple de réponse HTTP 400

Exemple typique d’en-têtes renvoyés lors d’une requête invalide :

HTTP/1.1 400 Bad Request
Date: Fri, 07 Dec 2024 10:30:00 GMT
Server: nginx/1.18.0
Content-Type: text/html; charset=UTF-8
Connection: keep-alive

Causes fréquentes d’un code HTTP 400

🔗 URL mal encodée / paramètres invalides

Caractères non encodés, espaces, caractères réservés, query string incohérente, paramètres inattendus ou valeurs non conformes (ex. format date / ID). Les facettes et filtres mal cadrés sont une source fréquente de 400.

🍪 Cookies trop volumineux ou corrompus

Des cookies invalides, trop nombreux ou trop volumineux (tracking, A/B test, sessions) peuvent casser la requête. Certains reverse proxies rejettent alors la requête au parsing.

📦 Body invalide (API / formulaires)

JSON mal formé, champ manquant, type incorrect, dépassement de taille (client_max_body_size, etc.). Cas classique : endpoint REST strict ou validation framework.

🛡️ WAF / validation stricte

Un WAF ou une règle de sécurité peut rejeter une requête (patterns “suspects”, injection, headers non conformes) et renvoyer un 400 plutôt qu’un 403, selon la configuration.

Différences : 400 vs 404 vs 422

• 400 : requête invalide / mal formée (URL/params/headers/cookies/body).
• 404 : ressource non trouvée (URL valide syntaxiquement, ressource absente).
• 422 : requête valide, mais données non traitables au niveau métier.

Cette distinction est utile en SEO et en debug : elle conditionne le traitement des URLs, la priorisation des fixes et l’analyse de logs.

Impact SEO d’un code HTTP 400

📉 Crawl et budget de crawl

Googlebot considère un 400 comme une requête invalide et ne va pas insister. Le risque SEO apparaît quand le volume est important (ex. paramètres/facettes) : le crawl est gaspillé, les signaux d’exploration se dégradent et l’exploration des pages stratégiques peut être retardée.

🔎 Indexation et “soft 400”

Une URL en 400 n’est pas indexable. Le risque est plutôt le soft 400 : pages renvoyées en 200 avec un contenu vide/dégradé (ou message d’erreur) que Google peut classifier comme non pertinente.

📝 Logs : le vrai point de contrôle

Les 400 sont utiles pour repérer les générateurs d’URLs invalides (maillage, scripts, tracking, filtres). Analysez les patterns (paramètres, encodage, referers) et corrigez la source.

Bonnes pratiques SEO pour gérer un 400

• Réduire les paramètres inutiles et cadrer les facettes (noindex, canonicals, règles).
• Normaliser l’encodage des URLs et valider en amont (front / middleware).
• Limiter le volume et la taille des cookies (tagging, AB tests, scripts).
• Surveiller les logs et corréler avec Search Console (exploration / pages exclues).
• Ne pas transformer des erreurs applicatives en 400 (qualité d’observabilité).

Codes HTTP associés à connaître

FAQ : Questions fréquentes sur le code HTTP 400