¿Qué es el Error 400 (Bad Request)?

El código 400 pertenece a la familia de errores 4xx, reservada para fallos que se originan en el cliente. Según la especificación vigente, RFC 9110, el servidor responde con 400 cuando la petición tiene "sintaxis malformada, un formato de mensaje inválido o un enrutamiento engañoso". En la práctica eso cubre desde una URL con caracteres sin codificar hasta un formulario que envía un JSON roto o una cookie que supera el tamaño que el servidor acepta.

No hay un único causante. Un enlace interno generado con una plantilla defectuosa, un parámetro de búsqueda con comillas sin escapar o una cabecera de idioma corrupta pueden disparar el mismo código. Por eso el 400 rara vez llega solo: suele aparecer en lotes, ligado a un cambio reciente en la generación de URLs, un plugin o una integración con terceros.

La confusión más habitual es tratarlo como un primo del 404, pero el parecido es solo de apariencia. El 404 significa que el servidor entendió la petición, buscó el recurso y no lo encontró. El 400 significa que la petición ni siquiera llegó a esa fase: se descartó antes.

El 400 comparte familia con otros códigos que se confunden con facilidad. La tabla resume dónde se origina cada fallo y qué lo dispara habitualmente.

La diferencia que más pesa para el SEO es la de los primeros frente al 404: el 400 y el 500 hablan de un fallo en el proceso de la petición, mientras que el 404 confirma que el proceso terminó y el recurso simplemente no está ahí.

Cuando un navegador o un rastreador envía una petición, el servidor la procesa en fases. Primero valida la sintaxis: la URL, las cabeceras, las cookies, el cuerpo si lo hay. Solo si esa validación pasa, la petición avanza a la fase de enrutamiento, donde el servidor decide qué recurso corresponde. El 400 se genera en la primera fase. El servidor detecta algo que no puede interpretar y corta el proceso antes de intentar localizar ningún recurso.

HTTP/1.1 400 Bad Request
Content-Type: text/html; charset=UTF-8
Date: Sat, 08 Aug 2026 10:15:32 GMT

Esa diferencia con el 404 (que sí llega a la fase de enrutamiento) y con el 500 (que falla más adelante, dentro de la lógica de la aplicación) tiene consecuencias prácticas. Un 400 casi nunca se arregla creando una página o una redirección, porque todavía no hay ninguna página involucrada. Lo que hay que corregir es cómo se construye la petición.

En una web, las causas más frecuentes son técnicas y silenciosas. Una migración que cambia la codificación de caracteres en las URLs internas, un sistema de filtros de e-commerce que genera parámetros con espacios sin codificar, o una integración de analítica que añade una cabecera demasiado larga. Googlebot y cualquier otro rastreador reciben el mismo 400 que un usuario, y lo registran igual: como un fallo de la petición, no del contenido.

Un 400 aislado apenas afecta al posicionamiento. El problema aparece cuando se repite en un patrón de URLs, porque entonces el rastreo se reparte peor. Google no procesa el contenido de una URL que devuelve 400: sus sistemas informan a la siguiente fase que el contenido no existe, igual que con el resto de errores 4xx salvo el 429. Si esa URL estaba indexada, sale del índice con el tiempo.

La dificultad añadida es que Search Console no separa el 400 del resto de errores de cliente. En el informe de estadísticas de rastreo, un 400 puro cae dentro de la categoría genérica "Otro error de cliente (4xx)", junto con códigos que no tienen nada que ver, como el 406 o el 411. Quien solo mira ese informe puede no darse cuenta de cuántas de esas URLs son en realidad 400 hasta que cruza los datos con los logs del servidor.

Ahí está la decisión que depende de este código: si el volumen de 400 crece tras un cambio técnico, conviene revisarlo antes de que el rastreo se reduzca sobre esas rutas y arrastre con ellas enlaces internos que sí aportaban valor.

• Revisar los logs del servidor filtrando por código 400, porque Search Console los agrupa dentro de "Otro error de cliente (4xx)" y no los distingue del resto.
• Validar la codificación de caracteres de las URLs generadas dinámicamente (filtros, buscadores internos, parámetros de campaña) antes de publicarlas como enlaces internos.
• Probar los formularios y endpoints con datos límite: campos vacíos, caracteres especiales, cuerpos muy grandes, para ver si el servidor responde 400 donde debería validar de otra forma.
• Comprobar los límites de tamaño de cabeceras y cookies del servidor tras instalar nuevas herramientas de analítica o marketing, una causa habitual y poco visible.
• Auditar las cadenas de redirección después de una migración, porque un parámetro mal codificado en un salto intermedio puede convertir una redirección válida en un 400.
• Diferenciar en el código de la aplicación un 400 real (petición mal formada) de un 404 (recurso no encontrado); tratarlos igual complica cualquier diagnóstico posterior.

• Confundir el 400 con el 404 en el código de la aplicación y devolver el mismo código para dos problemas distintos.
• Ignorar la categoría "Otro error de cliente (4xx)" de Search Console por parecer poco relevante, cuando puede esconder cientos de URLs con parámetros rotos.
• Dejar sin corregir la codificación de URLs tras una migración, dando por hecho que solo afecta a un puñado de páginas.
• Fiarse solo del muestreo de Search Console en lugar de revisar los logs completos del servidor, que muestran el volumen real.
• Configurar validaciones de cabecera o cookie demasiado estrictas que acaban bloqueando peticiones legítimas de rastreadores o de usuarios reales.