Solucionar el error de REST API en WordPress

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.