Solucionar el error de REST API en WordPress
Guía para solucionar el error de REST API en WordPress en España: causas, riesgos y pasos de diagnóstico y corrección sin empeorar la incidencia
El error de REST API en WordPress suele parecer un aviso menor, pero en la práctica afecta a funciones críticas: el editor de bloques, la edición rápida, la carga de contenidos, integraciones con plugins, y en algunos casos procesos de WooCommerce o automatizaciones. Cuando la API REST falla, el sitio puede seguir “viéndose”, pero su operativa se degrada, aumenta el riesgo de cambios incompletos y se resiente la captación, la reputación y la productividad del equipo.
El objetivo de esta guía es ayudarle a prevenir y resolver el problema con un enfoque ordenado: qué revisar primero, qué pruebas conviene guardar y qué hacer si ya se han realizado cambios en actualizaciones, plugins o hosting. Por transparencia, el análisis depende del acceso disponible, de los registros, de los cambios recientes y de la configuración concreta; antes de actuar conviene una revisión técnica previa y práctica, especialmente en España, donde algunos bloqueos pueden variar según proveedor, WAF o políticas de seguridad del alojamiento.
Fuentes consultadas
Índice
- 1. Qué implica el error de REST API en WordPress
- 2. Diagnóstico inicial y señales útiles
- 3. Causas habituales y cómo confirmarlas
- 4. Seguridad, bloqueos y abuso de la API
- 5. Rendimiento, timeouts y estabilidad
- 6. Plugins, temas y actualizaciones: conflictos típicos
- 7. Hosting, DNS y SSL en España: puntos de fricción
- 8. Pruebas, accesos y evidencias para trazabilidad
- 9. Plan de acción ordenado para resolverlo
- 10. Si ya se ha tocado algo o hay urgencia
- 11. Preguntas frecuentes
Qué implica el error de REST API en WordPress
La REST API es el canal estándar con el que WordPress intercambia datos en formato JSON entre el navegador, el núcleo y muchos plugins. El editor de bloques (Gutenberg) la usa para cargar y guardar entradas, recuperar taxonomías, buscar medios o validar permisos. Por eso, cuando aparece el aviso de “La respuesta no es una respuesta JSON válida” o “La REST API encontró un error”, no es solo un mensaje: indica que una ruta de /wp-json/ no está respondiendo como se espera.
En términos de negocio, el impacto suele ser silencioso. Se traduce en publicaciones que no se guardan, cambios que se pierden, errores intermitentes en formularios o integraciones, y más tiempo de soporte interno. Además, si el fallo se debe a un bloqueo de seguridad o a un error 500, puede ser un síntoma de un problema mayor que conviene acotar antes de seguir tocando el sitio.
- La API REST se consume desde el navegador y desde integraciones, por lo que los fallos pueden ser intermitentes y dependientes de sesión.
- El error puede ser de aplicación (WordPress), de servidor (PHP, reglas, WAF) o de red (SSL, proxy, caché).
- Los códigos HTTP orientan: 401 o 403 suelen ser permisos o bloqueo; 404 suele ser reescritura o ruta; 500 suele ser error interno.
- El editor de bloques es un “canario en la mina”: si falla, suele haber un problema de respuesta JSON o de autenticación.
- La prevención pasa por cambios controlados, staging y trazabilidad, no por “probar cosas” en producción.
Qué ocurre en la práctica: muchas incidencias empiezan tras una actualización o un cambio de seguridad del hosting. El sitio carga, pero al editar aparece un aviso de REST API y el equipo intenta desactivar plugins al azar. Sin registros ni un orden, se alarga el tiempo de caída funcional y se pierde evidencia útil.
Diagnóstico inicial y señales útiles
Antes de cambiar nada, conviene confirmar el síntoma exacto y capturar señales verificables. El error de REST API no es un diagnóstico en sí mismo, sino un resultado. Su objetivo en esta fase es responder a tres preguntas: qué endpoint falla, con qué código HTTP, y desde cuándo ocurre. Con esa base, podrá decidir si el problema es de permisos, reescritura, seguridad o estabilidad.
Haga comprobaciones prudentes que no empeoren la incidencia: evite limpiar cachés agresivas si no sabe qué capa está implicada, no restaure copias sin confirmar el alcance, y no cambie múltiples variables a la vez. Si puede, reproduzca el fallo en una ventana privada del navegador y anote el momento exacto para correlacionarlo con logs.
- Revise el mensaje exacto en el escritorio: “respuesta no válida JSON”, “REST API encontró un error” o fallos al guardar en el editor.
- Abra la URL https://su-dominio.tld/wp-json/ y compruebe si devuelve JSON (no HTML) y si el navegador muestra un error claro.
- Use las herramientas del navegador (pestaña Red) para ver la petición que falla, el código HTTP (401, 403, 404, 500, 502, 504) y el endpoint concreto.
- Compruebe cambios recientes: actualizaciones de WordPress, tema, plugins, versión de PHP, reglas de seguridad, CDN o caché de servidor.
- Busque señales externas: alertas en Google Search Console, avisos del hosting sobre recursos, o incidencias de SSL y certificados.
Qué ocurre en la práctica: el endpoint /wp-json/wp/v2/ puede fallar solo para usuarios autenticados, mientras que /wp-json/ responde. Esto suele apuntar a permisos, cookies, WAF o a un plugin que intercepta la autenticación.
Causas habituales y cómo confirmarlas
Las causas más frecuentes del error de REST API se agrupan en cuatro bloques: reescritura de URLs (permalinks), bloqueos de seguridad (WAF, reglas), errores PHP que rompen la respuesta JSON, y conflictos de plugins o temas que alteran cabeceras o contenido. Confirmarlas requiere observar el tipo de respuesta: si devuelve HTML, un aviso PHP o un login inesperado, la API no está entregando JSON limpio.
Para confirmar, busque evidencias: el código HTTP, el contenido real de la respuesta, y si el fallo aparece solo con usuarios autenticados. En WordPress, un simple “warning” de PHP puede convertir una respuesta JSON válida en inválida. Por eso, la depuración controlada y los logs son más útiles que los cambios a ciegas.
- Permalinks y reescritura: un 404 en rutas REST suele relacionarse con reglas de reescritura o configuración del servidor.
- Respuesta contaminada: si el endpoint devuelve HTML, un banner, un aviso o un “maintenance mode”, el JSON queda invalidado.
- Errores PHP: un 500 o un JSON roto suele correlacionar con errores en logs, memoria insuficiente o incompatibilidades.
- Autenticación y cookies: 401 o 403 pueden venir de plugins de seguridad, cabeceras, o políticas del servidor.
- Cachés y proxies: una capa de caché mal configurada puede servir una página cacheada en lugar del JSON.
Qué ocurre en la práctica: es habitual que un plugin añada salida (por ejemplo, espacios o avisos) antes de enviar JSON. El navegador lo muestra como “respuesta no válida JSON”, pero el origen real está en un error PHP o en una salida inesperada que solo aparece con ciertas rutas.
Seguridad, bloqueos y abuso de la API
La API REST es un objetivo habitual de abuso porque expone rutas estandarizadas y se usa intensamente. Un error 403 o 401 puede ser un bloqueo legítimo por reglas de seguridad, un WAF, o un plugin que endurece el acceso. También puede ser un síntoma de compromiso si aparecen usuarios desconocidos, cambios no autorizados o picos de peticiones a /wp-json/. Conviene distinguir entre “bloqueo preventivo” y “incidencia de seguridad”.
Sin alarmismo, trate la seguridad como una hipótesis a validar. Si sospecha de malware o de abuso, priorice la contención y la preservación de evidencia: copias, logs y listado de cambios. Evite “limpiezas” rápidas sin copia, porque pueden eliminar rastros útiles y dejar puertas traseras activas.
- Síntomas compatibles: 403 intermitente, bloqueos al guardar, redirecciones extrañas, usuarios admin no reconocidos, o cambios en archivos sin registro.
- Vectores habituales: plugins vulnerables sin actualizar, credenciales filtradas, permisos de archivos inseguros, inyecciones en base de datos o archivos del tema.
- Medidas razonables: copia completa antes de actuar, rotación de contraseñas (WordPress, FTP/SFTP, panel, base de datos), y revisión de usuarios y roles.
- Hardening básico: limitar intentos de acceso, desactivar XML-RPC si no se usa, y revisar permisos de escritura donde no sean necesarios.
- Consulte avisos públicos: revise alertas y recomendaciones de organismos como INCIBE para contextualizar riesgos y campañas activas.
Qué ocurre en la práctica: en algunos entornos, el WAF bloquea patrones que parecen “ataques” pero son peticiones legítimas del editor. El resultado es un 403 a endpoints REST. La solución suele pasar por ajustar reglas o exclusiones de forma mínima y documentada, no por desactivar toda la protección.
Rendimiento, timeouts y estabilidad
No todos los errores de REST API son de permisos. En sitios con carga, recursos limitados o procesos pesados, la API puede fallar por timeouts o por errores 502, 503 o 504. También puede ocurrir que el servidor responda, pero tarde tanto que el navegador lo interprete como fallo. En WordPress, endpoints como búsquedas, guardados o consultas complejas pueden disparar consumo de CPU o consultas lentas.
El objetivo aquí es separar “fallo funcional” de “falta de capacidad”. Si el problema coincide con picos de tráfico, tareas programadas (WP-Cron), importaciones o backups, es probable que la REST API sea la primera en mostrar síntomas. La corrección suele implicar optimización, límites adecuados y reducción de carga, además de revisar plugins que ejecutan lógica pesada en cada petición.
- Observe si el fallo coincide con picos de CPU, memoria o procesos PHP en el panel del hosting o en monitorización.
- Revise si hay tareas automáticas simultáneas: copias, escaneos de seguridad, regeneración de miniaturas o importaciones.
- Compruebe la versión de PHP y límites (memoria, max execution time) y si han cambiado recientemente.
- Valide si la respuesta REST devuelve 504 o 502, lo que suele apuntar a proxy, PHP-FPM o backend saturado.
- Reduzca variables: desactive temporalmente tareas pesadas en horas críticas y verifique si el error desaparece.
Qué ocurre en la práctica: un escaneo de seguridad o una copia programada puede coincidir con ediciones en el editor. El guardado dispara una petición REST y, si el servidor está al límite, la petición expira. El usuario lo percibe como “REST API error”, aunque el origen sea capacidad o concurrencia.
Plugins, temas y actualizaciones: conflictos típicos
Los conflictos de plugins o temas son una causa recurrente del error de REST API, especialmente tras actualizaciones. Un plugin puede interceptar autenticación, modificar cabeceras, forzar redirecciones, minificar scripts de forma agresiva o añadir salida que rompe el JSON. Un tema puede incluir funciones que imprimen contenido en momentos inadecuados. La clave es aislar el cambio que introdujo el fallo.
La buena práctica es trabajar con staging, control de cambios y ventanas de mantenimiento. En producción, si necesita aislar un conflicto, hágalo con método: copie primero, documente, y cambie una variable cada vez. Si el sitio es crítico, coordine el diagnóstico para minimizar tiempos de caída y evitar que el equipo edite contenidos mientras se prueba.
- Revise el historial de actualizaciones: núcleo, plugins y tema, y si el error empezó justo después de una de ellas.
- Pruebe en staging: reproduzca el fallo y desactive plugins por grupos para identificar el conflicto sin afectar a usuarios.
- Atención a plugins de caché, seguridad, optimización y “minify”: son los que más suelen interferir con REST y con el editor.
- Compruebe compatibilidades: versión de WordPress, PHP y dependencias del plugin, y si hay incidencias reportadas por el desarrollador.
- Gestione el cambio: cuando identifique el causante, valore rollback controlado, alternativa compatible o ajuste de configuración documentado.
Qué ocurre en la práctica: tras actualizar un plugin de seguridad, se endurecen reglas y se bloquean endpoints REST usados por el editor. El sitio “funciona”, pero editar falla. La solución suele ser ajustar la configuración del plugin o excluir rutas específicas, siempre con criterio y registrando el cambio.
Hosting, DNS y SSL en España: puntos de fricción
En muchos casos, el error de REST API no se origina en WordPress, sino en la capa de servidor. En España, el comportamiento puede variar según el proveedor de hosting, el tipo de servidor (Apache o Nginx), si hay proxy inverso, WAF, reglas ModSecurity, caché a nivel de servidor o limitaciones de recursos. También influyen el DNS, el SSL y la forma en que se gestionan redirecciones entre www y no-www, o entre HTTP y HTTPS.
Un síntoma típico es que /wp-json/ responda con una redirección inesperada, un desafío de seguridad o una página HTML del servidor. Otro caso frecuente es que el certificado SSL esté mal encadenado o que haya contenido mixto que afecte a peticiones autenticadas. Si usa CDN o proxy, confirme qué capa está respondiendo realmente.
- DNS y redirecciones: asegure coherencia entre dominio principal, www, HTTPS y reglas de redirección para evitar bucles o cambios de origen.
- SSL: verifique que el certificado es válido y que no hay errores de conexión que afecten a peticiones REST autenticadas.
- Cachés de servidor y proxy: confirme que no se cachean respuestas de /wp-json/ de forma incorrecta, especialmente para usuarios logueados.
- PHP y límites: revise versión de PHP, memoria y límites de ejecución; cambios automáticos del hosting pueden introducir incompatibilidades.
- Reglas de seguridad: si hay WAF o ModSecurity, solicite al proveedor los eventos de bloqueo asociados a la ruta REST y ajuste con mínima exposición.
Qué ocurre en la práctica: un cambio de configuración del servidor puede endurecer reglas y empezar a bloquear peticiones POST a endpoints REST. El equipo lo nota al guardar entradas. El proveedor puede ver en logs del WAF qué regla dispara el bloqueo, algo que desde WordPress no siempre es visible.
Pruebas, accesos y evidencias para trazabilidad
Para resolver el error de REST API con rapidez, necesita trazabilidad. Eso significa poder responder con datos a “qué cambió”, “qué falla exactamente” y “dónde se rompe la cadena”. En un entorno profesional, la diferencia entre una incidencia de 30 minutos y una de varios días suele estar en disponer de accesos adecuados y evidencias técnicas mínimas.
Si trabaja con un tercero o con soporte del hosting, prepare un paquete de pruebas. En España, algunos proveedores piden ejemplos concretos de URL, hora del fallo y cabeceras para localizar bloqueos en WAF o en logs. Cuanto más preciso sea, menos iteraciones necesitará.
- Trazabilidad de cambios recientes: registro de actualizaciones (núcleo, plugins, tema), lista de plugins activos y versiones, y revisión de changelog del plugin sospechoso.
- Evidencias técnicas: capturas de la pestaña Red con el endpoint fallido, código HTTP y respuesta, y listado de URLs afectadas (por ejemplo, /wp-json/wp/v2/posts).
- Logs: acceso a debug.log si se habilita depuración controlada, y logs del servidor o del WAF si el hosting los facilita.
- Copias de seguridad: confirmación de última copia completa (archivos y base de datos) y posibilidad de restauración en staging.
- Accesos mínimos: administrador de WordPress, SFTP/SSH si procede, panel del hosting, y acceso a DNS si se sospechan redirecciones o SSL.
Qué ocurre en la práctica: sin la hora exacta del fallo y sin el endpoint concreto, el hosting no puede correlacionar eventos del WAF. Con una captura del 403 y el timestamp, suelen localizar la regla y proponer un ajuste específico, reduciendo el riesgo de abrir demasiado la seguridad.
Plan de acción ordenado para resolver el error de REST API
Un plan ordenado minimiza tiempos de caída y evita perder evidencia. La idea es contener, asegurar una copia, diagnosticar con datos, aplicar una corrección mínima y verificar. Si el sitio es corporativo o tienda, priorice restaurar la operativa del editor y las funciones críticas antes de optimizaciones secundarias.
Aplique el principio de “una variable cada vez”. Si cambia hosting, versión de PHP y plugins a la vez, será difícil saber qué resolvió o qué empeoró el problema. Documente cada paso, con hora y resultado, para poder revertir con seguridad.
- Contención: confirme alcance (solo editor, solo usuarios logueados, todo el sitio) y evite cambios simultáneos por varios usuarios.
- Copia: realice una copia completa antes de tocar plugins, reglas o archivos, y si es posible prepare un staging.
- Confirmación del endpoint: identifique la ruta REST que falla y el código HTTP, y guarde capturas y respuestas.
- Aislamiento: pruebe desactivar temporalmente el plugin más sospechoso (caché, seguridad, optimización) en staging o en una ventana controlada.
- Corrección mínima: ajuste permalinks, reglas o configuración del plugin, o corrija el error PHP que contamina el JSON.
Qué ocurre en la práctica: en muchos casos, regenerar reglas de enlaces permanentes y corregir una redirección mal aplicada resuelve 404 en /wp-json/. En otros, el problema es un 403 por WAF y la solución real está en el proveedor, no en WordPress.
Si ya se ha tocado algo o hay urgencia
Cuando ya se han hecho cambios, el reto es recuperar control y trazabilidad. Es frecuente que, ante el error de REST API, se instale un plugin de seguridad, se restaure una copia parcial o se edite functions.php. En urgencias, se toman decisiones rápidas que pueden ocultar el origen real o introducir efectos secundarios. Su prioridad debe ser estabilizar y reconstruir una línea temporal de cambios.
Si el sitio está en producción y afecta a negocio, limite el número de acciones y documente. Si no dispone de copia completa previa, extreme la cautela: antes de “limpiar” o borrar, haga una copia del estado actual para poder analizar y, si es necesario, volver atrás. En entornos con proveedores distintos, el comportamiento puede variar por configuración del servicio, por lo que conviene coordinarse con soporte del hosting.
- Se instaló un plugin de seguridad: revise si bloquea REST o endurece autenticación; pruebe desactivar solo sus reglas o módulos relacionados.
- Se restauró una copia parcial: valide coherencia entre archivos y base de datos; una desincronización puede romper endpoints o permisos.
- Se cambió de hosting: compruebe DNS, SSL, redirecciones y reglas de reescritura; el mismo WordPress puede comportarse distinto.
- Se tocó functions.php: busque errores de sintaxis o salida inesperada; un aviso PHP puede invalidar JSON.
- Se borró un plugin crítico o se intentó limpiar malware sin copia: detenga cambios, haga copia del estado actual y recupere evidencias antes de continuar.
Qué ocurre en la práctica: tras varios intentos, el problema original queda enmascarado por nuevos cambios. Volver a un punto estable en staging y comparar con producción suele ser más eficiente que seguir probando en vivo, porque permite aislar el factor que rompe la respuesta JSON.
Preguntas frecuentes
Estas dudas aparecen con frecuencia cuando el editor muestra errores de REST API o cuando integraciones dejan de funcionar. Las respuestas son generales y deben adaptarse a su hosting y configuración.
P: ¿Cómo sé si el problema es de WordPress o del servidor?
R: Si el endpoint /wp-json/ devuelve HTML, redirecciones o un 403, suele haber una capa de servidor o seguridad implicada. Si devuelve JSON pero ciertos endpoints fallan con 500, suele apuntar a PHP, plugins o tema. Los logs y el código HTTP son la pista principal.
P: ¿Es seguro desactivar la REST API para “arreglar” el error?
R: No suele ser recomendable. La REST API es necesaria para el editor de bloques y para muchas funciones. Bloquearla puede ocultar el síntoma, pero empeorar la operativa. Es preferible corregir la causa, por ejemplo un bloqueo del WAF o un error PHP.
P: ¿Qué significa “La respuesta no es una respuesta JSON válida”?
R: Significa que WordPress esperaba JSON, pero recibió otra cosa: HTML, un aviso PHP, una página de error del servidor o una redirección. La solución pasa por identificar qué está contaminando la respuesta y en qué endpoint ocurre.
P: ¿Regenerar enlaces permanentes puede solucionar el error?
R: En casos de 404 o rutas REST que no se resuelven, sí puede ayudar, porque fuerza a WordPress a reescribir reglas. No obstante, si el error es 403 o 500, normalmente la causa está en seguridad, permisos, plugins o errores del servidor.
P: ¿Puede afectar a WooCommerce o a formularios?
R: Puede afectar a cualquier plugin que use endpoints REST o peticiones AJAX relacionadas. En tiendas, además, un entorno inestable puede generar fallos al gestionar productos o pedidos desde el panel. Conviene validar flujos críticos tras corregir el problema.
Resumen accionable
- Confirme el endpoint que falla y el código HTTP desde el navegador (Red) y guarde capturas.
- Compruebe si /wp-json/ devuelve JSON o HTML, y si el fallo ocurre solo con sesión iniciada.
- Revise cambios recientes: actualizaciones, versión de PHP, reglas de seguridad, caché, CDN o migraciones.
- Haga copia completa (archivos y base de datos) antes de desactivar plugins o tocar reglas.
- Registre una línea temporal: cuándo empezó, qué se cambió y qué pruebas se hicieron.
- Aísle conflictos en staging: desactive por grupos plugins de caché, seguridad y optimización.
- Busque errores PHP en logs y corrija avisos que puedan contaminar la respuesta JSON.
- Si hay 403, coordine con el hosting para revisar WAF o ModSecurity con hora y URL exactas.
- Verifique DNS, SSL y redirecciones para evitar respuestas inesperadas en endpoints REST.
- Tras corregir, valide guardado en editor, endpoints críticos y monitorice para detectar recurrencias.
Aviso: este contenido es informativo y general, no sustituye una revisión técnica individualizada. La solución práctica depende del entorno, del acceso disponible, de los cambios recientes y de la configuración.
Si lo desea, en reparawordpress.com podemos realizar una revisión técnica o auditoría con enfoque preventivo y realista. Lo habitual es empezar por diagnóstico, copia y un plan de corrección priorizado para reducir riesgos y tiempos de caída.
¿Necesitas orientación personalizada?
Te ayudamos a entender tus opciones y el siguiente paso.