Cómo solucionar un error 400 Bad Request en WordPress (Causas y soluciones)

Puntos clave

• Un error 400 Bad Request suele afectar a una acción concreta, no a todo el sitio de WordPress.
• La mayoría de los errores 400 en WordPress están causados por URLs, cookies, caché o problemas de petición relacionados con plugins.
• Seguir un enfoque de solución de problemas por capas ayuda a aislar el origen exacto más rápidamente.
• Las actualizaciones adecuadas, las pruebas y la configuración del servidor reducen las posibilidades de que se repitan errores 400.

Puede que estés abriendo el panel de administración de WordPress, enviando un formulario o cargando una página que funcionaba momentos antes. La página no se carga. No aparece ninguna advertencia. Sólo un error 400 Bad Request sin explicación.

El mensaje en sí ofrece poco contexto. No sugiere un sitio roto o una interrupción del servidor. En WordPress, el problema suele estar relacionado con los datos del navegador, los archivos almacenados en caché, los plugins, las URL o el tamaño de la solicitud, más que con algo fundamentalmente erróneo en el sitio.

Esa diferencia importa. Desplaza el problema de «algo falla» a «algo concreto está fallando». Una vez que lo ves así, resulta más fácil acotar los pasos a seguir.

¿Qué es un error 400 de solicitud errónea?

Una parte del sitio funciona. Otra no.

Las páginas pueden seguir cargándose, pero una sola acción sigue fallando. El área de administración no se abre. Un formulario nunca se envía. Una acción de guardar se detiene sin respuesta.

Esa acción fallida es la que desencadena el error 400 Solicitud errónea.

En WordPress, las acciones cotidianas envían peticiones al servidor. El inicio de sesión, el envío de formularios, la carga de pantallas de administración y la actividad en segundo plano de los plugins entran en esta categoría. Cuando una solicitud llega de una forma que el servidor no acepta, se rechaza antes de que se cargue nada.

¿El error 400 Bad Request es del lado del cliente o del lado del servidor?

La mayoría de las veces, empieza en el lado del cliente.

Eso incluye:

• cookies del navegador o datos almacenados en caché
• URLs malformadas
• solicitudes sobredimensionadas

El servidor aplica las normas, pero la propia solicitud suele desencadenar el rechazo. En raras ocasiones, las reglas a nivel de servidor o la configuración de seguridad desempeñan un papel, que trataremos más adelante.

Variaciones comunes del error 400 Bad Request que puedes ver

Puedes encontrarte con versiones ligeramente diferentes del mismo error, como por ejemplo

• 400 Petición errónea
• 400 Petición errónea – URL no válida
• 400 Petición errónea – Encabezado de petición o cookie demasiado grande

La redacción cambia, pero la cuestión subyacente es la misma. Una solicitud llegó al servidor y fue rechazada.

¿Por qué se produce el error 400 Bad Request en WordPress?

Un error 400 de solicitud errónea en WordPress rara vez apunta a un fallo completo del sitio. En la mayoría de los casos, el sitio sigue cargando, pero una acción específica sigue fallando. Esto suele significar que el servidor no acepta una única solicitud.

Las razones que se exponen a continuación cubren las formas más comunes que se dan en WordPress.

#1 URLs de WordPress no válidas o malformadas

Las URL pueden fallar silenciosamente.

Los caracteres adicionales, la codificación incorrecta o los enlaces copiados con parámetros añadidos pueden causar problemas. Esto suele ocurrir con las URL de inicio de sesión, los enlaces de redirección o las páginas de administración marcadas.

Cuando WordPress envía una URL que el servidor no reconoce como válida, la petición se detiene inmediatamente.

#2 Caché o Cookies del Navegador Corruptas

WordPress depende en gran medida de las cookies del navegador, especialmente para las sesiones de inicio de sesión.

Con el tiempo, las cookies y los datos almacenados en caché pueden desincronizarse. Por eso el error puede aparecer en un navegador pero no en otro, o desaparecer en modo privado.

Borrar los datos del navegador suele cambiar el comportamiento de inmediato, lo que es una señal clara de que se trata de datos almacenados.

#3 Problemas con la autenticación de WordPress o la cookie de sesión

Las acciones de inicio de sesión dependen de que las cookies de sesión sigan siendo válidas.

Si las cookies de autenticación crecen demasiado o se vuelven incoherentes, WordPress puede enviar peticiones que el servidor se niega a procesar. Esto suele afectar más a las páginas de administración, a los envíos de formularios y a las acciones de guardar que a las páginas públicas.

El sitio se ve bien, pero las peticiones autenticadas fallan.

#4 Conflictos de plugins o temas

Los plugins y los temas envían peticiones constantemente en segundo plano.

Los plugins de seguridad, las herramientas de almacenamiento en caché, los creadores de formularios y los plugins de optimización interactúan con las peticiones más que la mayoría. Un solo plugin que envíe datos malformados o inesperados es suficiente para provocar un error 400 de solicitud errónea.

Los temas pueden causar problemas similares a través de scripts del lado del administrador o llamadas AJAX, especialmente durante las actualizaciones o personalizaciones.

#5 Se han superado los límites de tamaño de carga de archivos

Las subidas no siempre fallan con elegancia.

Las imágenes, vídeos u otros archivos de gran tamaño pueden superar los límites del servidor sin mostrar una advertencia clara. La subida llega al servidor, pero la solicitud es rechazada antes de que se complete el procesamiento.

Otras partes del sitio siguen funcionando, lo que hace que el problema sea más difícil de detectar.

#6 Problemas de resolución DNS o de datos DNS en caché

Los problemas de DNS no ocurren a menudo, pero pueden ser confusos cuando ocurren.

Los registros DNS desactualizados o las búsquedas en caché pueden enviar solicitudes al destino equivocado. Esto aparece a veces tras cambios de dominio, actualizaciones de DNS o ajustes de configuración de CDN.

Cuando esto ocurre, las peticiones fallan antes de que WordPress pueda responder adecuadamente.

#7 Cabeceras de solicitud incorrectas o errores de la API REST

Algunas funciones de WordPress se basan en peticiones estructuradas.

Las llamadas a la API REST, las solicitudes AJAX o las integraciones que envían cabeceras mal formadas o JSON no válido pueden provocar un error 400. Estos problemas suelen surgir durante las actualizaciones de los plugins, el desarrollo personalizado o las integraciones de terceros.

El error aparece aunque el sitio en sí parezca normal.

#8 Raros problemas de configuración a nivel de servidor o de seguridad

En algunos casos, la solicitud en sí está bien, pero las reglas del servidor se interponen.

Los cortafuegos de aplicaciones web, las reglas de ModSecurity o las políticas de seguridad estrictas pueden bloquear peticiones que parezcan inusuales. Estas situaciones son menos comunes, pero más difíciles de diagnosticar sin acceso al servidor.

#9 Cómo ayuda esto a acotar la solución

Cada causa apunta a una solución diferente. Tratarlas como un problema genérico ralentiza las cosas. Identificar qué patrón coincide con lo que estás viendo hace que la resolución de problemas sea más rápida y predecible.

Ahí es donde entran los arreglos.

Cómo solucionar un error 400 Bad Request en WordPress

Un error 400 Petición errónea suele indicar que ha fallado una única petición, no una interrupción en todo el sitio. La solución suele consistir en corregir los datos almacenados, las URL o las respuestas almacenadas en caché.

Empieza por lo básico. La mayoría de los casos se resuelven pronto.

Paso 1 – Comprueba las URL de tu sitio WordPress

Las URLs incorrectas del sitio pueden interrumpir las peticiones de administración antes de que WordPress se cargue completamente.

WordPress utiliza dos direcciones principales:

• Dirección de WordPress (URL)
• Dirección del sitio (URL)

Ambos deben coincidir con el dominio exacto utilizado en el navegador. Incluso pequeñas incoherencias pueden provocar errores 400 durante el inicio de sesión, las redirecciones o las acciones de guardar.

Desde el panel de control, ve a Configuración → General y revisa ambos campos.

Deberían hacerlo:

• Empieza con http:// o https://
• No contienen caracteres ni espacios adicionales
• Coincide exactamente con el dominio activo

Si el área de administración es inaccesible, define las URL manualmente en wp-config.php o actualízalas directamente en la base de datos. En muchos sitios, sólo con eso se restablece el acceso.

Ten cuidado con las URL copiadas. Los caracteres ocultos de correos electrónicos o documentos pueden provocar fallos silenciosos. Si algo te parece mal, escribe la dirección manualmente.

Paso 2 – Borra la caché y las cookies del navegador

Si el error aparece en un navegador pero no en otro, es probable que estén implicados los datos almacenados del navegador.

Las sesiones de administración de WordPress dependen de las cookies. Cuando esas cookies se desincronizan, el navegador sigue enviando peticiones que el servidor se niega a procesar.

Despejado:

• Cookies vinculadas al dominio de tu sitio web
• Archivos en caché relacionados con WordPress

No necesitas reiniciar completamente el navegador.

Una forma rápida de confirmarlo es abrir la misma página en una ventana privada o de incógnito. Si funciona allí, el problema son las cookies o la caché.

Las páginas de administración lo provocan más a menudo porque envían más cookies que las páginas públicas. Los plugins de seguridad, los creadores de páginas y las herramientas de optimización aumentan el tamaño de la solicitud, lo que incrementa la probabilidad de rechazo.

Paso 3 – Borrar la caché de WordPress y CDN

Cuando los datos del navegador no son la causa, las respuestas en caché del servidor son el siguiente lugar donde buscar.

La caché de WordPress puede existir en varias capas:

• Plugins de caché
• Caché de objetos
• Caché CDN
• Caché a nivel de alojamiento

Borra todas las cachés activas, no sólo las URL individuales. Las purgas parciales suelen dejar cabeceras o redireccionamientos problemáticos.

Si el sitio se ejecuta detrás de una CDN, purga también toda la caché de la CDN. Los datos de solicitud almacenados en caché a nivel de red pueden seguir provocando errores 400 incluso después de borrar la caché de WordPress.

En plataformas gestionadas como Cloudways, utiliza el panel de control del alojamiento para vaciar la caché de la aplicación o del servidor antes de volver a probar.

Paso 4 – Desactiva todos los plugins de WordPress

Los plugins cambian la forma en que WordPress envía las peticiones.

Desactiva todos los plugins y vuelve a intentar la acción que estaba fallando.

Si no puedes acceder al área de administración, cambia el nombre de la carpeta de plugins mediante FTP o un gestor de archivos. WordPress se cargará sin plugins.

Si el error desaparece, reactiva los plugins uno a uno hasta que vuelva a aparecer. El plugin activado justo antes de que reaparezca el error es el origen.

Paso 5 – Cambiar a un tema predeterminado de WordPress

Los temas pueden afectar al comportamiento del lado del administrador.

• Cambia temporalmente a untema predeterminado de WordPress, como Twenty Twenty-Five, y vuelve a intentar la misma acción.

Si ya no aparece el error, se trata del tema activo.

Paso 6 – Comprueba los límites de tamaño de subida de archivos

Las subidas pueden fallar sin errores visibles.

Los archivos grandes pueden bloquearse antes de que WordPress los gestione, mientras el resto del sitio sigue funcionando.

Compruébalo:

• subir_tamaño_max_archivos
• tamaño_máx_post

Ambos valores deben ser compatibles con el archivo que se sube.

Paso 7 – Purgar la caché DNS

Comprueba el DNS sólo si algo ha cambiado recientemente.

• Actualización del dominio
• Migración de servidores
• CDN añadido o modificado

Borra la caché DNS de tu máquina local.

Recarga la página y vuelve a intentar la misma acción.

Si el sitio se trasladó a un nuevo servidor, confirma que el dominio se resuelve a la IP correcta.

Paso 8 – Regenerar el archivo .htaccess de WordPress

Un archivo .htaccess roto puede bloquear las peticiones antes de que se ejecute WordPress.

Esto suele ocurrir después:

• Cambios en los plugins
• Actualizaciones de URL
• Ediciones manuales

Desde el panel de control, ve a Configuración → Enlaces permanentes y haz clic en Guardar cambios sin modificar nada.

WordPress regenerará el archivo.

Si no se puede acceder al área de administración, sustituye manualmente el archivo .htaccess por una versión predeterminada de WordPress y, una vez restablecido el acceso, guarda los enlaces permanentes.

Recarga la página y vuelve a intentar la acción que falló.

Paso 9 – Comprueba la API REST y las peticiones AJAX

Algunos errores sólo aparecen durante las solicitudes en segundo plano.

Esto incluye

• Admin ahorra
• Envío de formularios
• Actualizaciones de la configuración del plugin
• Acciones del editor

Si el error aparece durante una acción concreta, comprueba si depende de llamadas a la API REST o AJAX.

Las cargas útiles malformadas, el JSON no válido o las cabeceras inesperadas pueden hacer que esas peticiones fallen mientras el resto del sitio sigue funcionando.

Si el problema comenzó tras una actualización de un plugin o un cambio personalizado, céntrate primero en ello.

Solución avanzada de problemas de errores persistentes 400 de solicitud errónea

Cuando las correcciones básicas no resuelven el problema, éste suele estar más profundo en la cadena de peticiones.

Estos casos suelen implicar reglas del servidor, capas de seguridad o límites de petición que no son visibles desde el panel de control de WordPress.

Comprueba los registros del servidor y de la aplicación

Los registros proporcionan contexto cuando el navegador no lo hace.

Busca 400 errores en:

• Registros de acceso al servidor web
• Registros de errores
• Registros a nivel de aplicación

Los fallos repetidos vinculados a puntos finales específicos, tipos de solicitud o marcas de tiempo suelen apuntar rápidamente al origen.

Si tienes un alojamiento gestionado, normalmente se puede acceder a los registros desde el panel de control del alojamiento.

Revisar las cabeceras de solicitud y los límites de tamaño de las cookies

Algunos servidores imponen límites estrictos a las cabeceras y a las cookies.

Cuando se superan esos límites, las peticiones se rechazan antes de que WordPress las procese. Esto suele afectar a los usuarios registrados y a las acciones de los administradores.

Las cookies de gran tamaño, especialmente las procedentes de scripts de seguridad o de seguimiento, son un desencadenante habitual.

Desactivar temporalmente el Cortafuegos de Aplicaciones Web o las Reglas de Seguridad

Las capas de seguridad pueden bloquear solicitudes válidas.

Los cortafuegos de aplicaciones web o las reglas de ModSecurity pueden marcar ciertas peticiones como sospechosas, aunque sean legítimas.

Desactivar temporalmente estas protecciones puede ayudar a confirmar si están implicadas. Si el error desaparece, ajusta las reglas en lugar de dejar desactivada la protección.

Comprueba la configuración de la CDN y las reglas de caché

Las CDN pueden almacenar en caché algo más que páginas.

Las cabeceras almacenadas en caché, los redireccionamientos o las reglas de petición pueden seguir provocando errores 400 incluso después de realizar cambios en el servidor de origen.

Borra la caché de la CDN y revisa cualquier regla personalizada que modifique las peticiones antes de que lleguen a WordPress.

Confirma la versión de PHP y la compatibilidad con la pila del servidor

Las incompatibilidades a nivel de servidor pueden aparecer como fallos en las peticiones.

Compruébalo:

• Versión PHP
• Configuración del servidor web
• Actualizaciones recientes del servidor

Esto es más común después de actualizaciones o migraciones, especialmente cuando aún se utilizan plugins o temas antiguos.

Cuando el error 400 Bad Request no está causado por WordPress

No todos los errores 400 empiezan dentro de WordPress.

Si el código del sitio es correcto y el error persiste en todos los navegadores, dispositivos o usuarios, el problema suele estar fuera de la aplicación.

Problemas a nivel de alojamiento o de configuración del servidor

Algunos errores 400 se originan en la capa del servidor.

Los límites de solicitudes, las restricciones de tamaño de los encabezados o las reglas estrictas de análisis pueden rechazar solicitudes antes de que se llegue a WordPress. Esto puede ocurrir después:

• Migraciones de servidores
• Cambios en la pila
• Fortalecimiento de la seguridad

Si varios sitios de WordPress en el mismo servidor muestran un comportamiento similar, debe revisarse la configuración del alojamiento.

Problemas con el proveedor de DNS o el servicio CDN

Los servicios DNS y CDN se sitúan delante de WordPress.

Si devuelven información de enrutamiento incorrecta o aplican reglas de solicitud restrictivas, es posible que las solicitudes válidas nunca lleguen al servidor de origen.

Esto es más probable después:

• Actualizaciones de registros DNS
• Incorporación CDN
• Cambios de regla o caché

En estos casos, el error puede parecer incoherente o depender de la ubicación.

Fallos de la API de terceros o de servicios externos

Algunas acciones de WordPress dependen de servicios externos.

Las pasarelas de pago, los gestores de formularios, las herramientas de análisis y los proveedores de autenticación envían y reciben peticiones fuera de tu servidor. Si estos servicios devuelven respuestas malformadas o rechazan solicitudes, WordPress puede mostrar un error 400.

Estos problemas suelen afectar a acciones concretas y no a todo el sitio.

Cómo el alojamiento gestionado de WordPress ayuda a reducir estos errores

El alojamiento gestionado reduce la exposición a muchos de estos problemas.

La gestión de las peticiones, el almacenamiento en caché, las reglas de seguridad y las actualizaciones del servidor se ajustan a los patrones de tráfico de WordPress. Cuando algo va mal, los registros y controles están centralizados en lugar de dispersos por capas.

Esto no elimina por completo los 400 errores, pero acorta el tiempo dedicado a aislarlos.

Cómo evitar los errores 400 Bad Request en WordPress

La mayoría de los errores 400 proceden de pequeños desajustes que se acumulan con el tiempo. La prevención tiene menos que ver con una configuración y más con mantener previsible la gestión de las solicitudes.

1. Mantén actualizados el núcleo, los temas y los plugins de WordPress

Es más probable que el código obsoleto envíe peticiones que WordPress ya no espera.

Las actualizaciones suelen incluir correcciones en la gestión de las peticiones, la autenticación y la compatibilidad con reglas PHP o del servidor más recientes. Retrasarlas aumenta la posibilidad de fallos silenciosos.

Aplica las actualizaciones con regularidad, especialmente después de cambios en el servidor o en PHP.

2. Limitar el tamaño de las cookies y los scripts de terceros

Las galletas crecen en silencio.

Las herramientas de seguridad, los scripts de análisis, los rastreadores de anuncios y los servicios integrados añaden datos a las solicitudes. Con el tiempo, las cabeceras pueden superar los límites del servidor sin ninguna advertencia visible.

Revisa los plugins instalados y elimina todo lo innecesario, sobre todo las herramientas que se cargan en las páginas de administración.

3. Probar los cambios en un entorno de ensayo

Los pequeños cambios pueden tener amplios efectos.

Las actualizaciones de plugins, las ediciones de temas y los cambios de configuración deben probarse en la fase de ensayo antes de llegar a la de producción. Aquí es donde suelen surgir primero los problemas relacionados con las solicitudes.

Detectarlas a tiempo evita tener que depurarlas en un sitio activo.

4. Supervisa los registros y los errores de forma proactiva

La mayoría de los 400 errores dejan rastro.

Los registros del servidor, de la aplicación y de seguridad suelen mostrar fallos repetidos mucho antes de que los usuarios informen de ellos. Revisar los registros periódicamente ayuda a detectar patrones a tiempo.

Esto es especialmente útil tras actualizaciones o cambios de infraestructura.

5. Utiliza una plataforma de alojamiento gestionado de rendimiento optimizado

La gestión de las solicitudes mejora cuando la pila está ajustada para WordPress.

Las plataformas gestionadas manejan las capas de caché, las reglas de seguridad y las actualizaciones del servidor de forma que se alinean con la forma en que WordPress envía las peticiones. Eso reduce la fricción entre la aplicación y el servidor.

No elimina todos los riesgos, pero reduce la base de referencia.

Reflexiones finales

Un error 400 Bad Request raramente significa que WordPress esté roto.

Suele apuntar a que una solicitud falla debido a datos almacenados, desajustes de configuración o límites de solicitud. Cuando se aborda metódicamente, a menudo se encuentra la causa antes de lo esperado.

Empieza por las URL, los datos del navegador y el almacenamiento en caché. Avanza hacia los plugins, los temas y las capas del servidor sólo cuando sea necesario. Esta estructura mantiene la resolución de problemas centrada en lugar de reactiva.

Una infraestructura fiable ayuda, pero un aislamiento claro importa más. Cuando cada capa se comprueba en orden, incluso los errores imprecisos se vuelven predecibles y solucionables.