Evaluación inicial sin contraseñas Presupuesto antes de intervenir Especialista responsable de principio a fin

Errors & Diagnosis

WordPress: «La respuesta no es una respuesta JSON válida»: cómo localizar la capa que falla

El error JSON del editor de bloques generalmente significa que la petición REST devolvió HTML, una redirección o una página de error. Rastrea la respuesta antes de cambiar los enlaces permanentes.

Qué importa primero: El editor esperaba JSON de la API REST de WordPress, pero recibió algo más. La evidencia útil es el estado de la petición fallida, el cuerpo de la respuesta y la URL final.

Qué indica realmente este síntoma

Este mensaje resume alrededor de un petición REST fallida. Puede ser causado por rutas, autenticación, un cortafuegos, salida de PHP, URLs incoherentes del sitio o un error del servidor, y cada causa deja una respuesta diferente.

Recopila pruebas antes de cambiar nada

  • Abre las herramientas del desarrollador del navegador e Identifica la petición a /wp-json/ que falla.
  • Registra su estado HTTP, el cuerpo de la respuesta, cadena de redireccionamiento y método de petición.
  • Compara la dirección del sitio y la dirección de WordPress, incluidos el protocolo y el servidor.
  • Comprueba los registros de PHP, del servidor web y de seguridad en la misma fecha y hora.

Causas más habituales

  • Fallo de reescritura: La ruta REST no llega a index.php, a menudo después de un cambio de migración o de regla de servidor.
  • Salida HTML inesperada: Se devuelve un aviso de PHP, una página de acceso, respuesta de mantenimiento o bloqueo del WAF en lugar de JSON.
  • Autenticación o fallo de nonce: Cookies, páginas de editor en caché o una capa de seguridad pueden invalidar la solicitud.
  • Desajuste URL: HTTP/HTTPS o el discrepancia entre www y sin www puede redirigir la solicitud API lejos de su origen esperado.

Secuencia segura de diagnóstico y reparación

  1. Solicita la URL REST que falla directamente y confirma si devuelve JSON o HTML.
  2. Corrige la capa evidenciada por la respuesta: reglas de reescritura, configuración URL, error de PHP o regla de firewall específica.
  3. Vacía las cachés de página, objetos, navegador y CDN para que el editor reciba un nonce nuevo y ruta.
  4. Repite la misma acción de guardar mientras observa el panel de red y el servidor logs.

Cómo distinguir entre las causas probables

No trates Fallo de reescritura y Salida HTML inesperada como causas equivalentes. La ruta REST no llega a index.php, a menudo después de un cambio de migración o de regla de servidor. En cambio, se devuelve un aviso de PHP, una página de acceso, respuesta de mantenimiento o bloqueo del WAF en lugar de JSON. Para distinguirlas, usa estas dos comprobaciones: Abre las herramientas del desarrollador del navegador e Identifica la petición a /wp-json/ que falla; y registra su estado HTTP, el cuerpo de la respuesta, cadena de redireccionamiento y método de petición. Con esos datos podrás decidir si conviene aplicar la primera acción controlada —Solicita la URL REST que falla directamente y confirma si devuelve JSON o HTML— o si debes conservar el estado actual y ampliar la investigación.

En un sitio de WordPress en producción, repite la petición que falla mientras compruebas una página que funciona correctamente y el área de administración. Un fallo aislado en una ruta requiere un rollback más acotado que un problema que afecta a PHP, la base de datos o todas las peticiones. Documenta la fecha y hora exactas, la URL o transacción afectada, el último estado correcto conocido y cada cambio realizado durante el diagnóstico. Ese registro permite distinguir una reparación reproducible de una desaparición temporal del síntoma.

Qué no debes hacer

No desactives el cortafuegos de la API REST ni la plugin de seguridad de forma global. Identifica la ruta o regla bloqueada exacta y Mantén activa la protección no relacionada.

Cómo verificar la reparación

  • El editor guarda y actualiza el mismo entrada dos veces sin errores.
  • La petición REST devuelve el JSON válido con el código de éxito esperado.
  • En la respuesta no aparece ningún aviso de PHP, redirección o bloqueo del WAF.

Que el síntoma visible desaparezca no es suficiente. Cierra la incidencia solo cuando la acción original que fallaba, el recorrido de negocio relacionado y los registros relevantes confirmen que el problema ha desaparecido.

ANTES DE ENVIAR LA SOLICITUD

Preguntas frecuentes.

¿Pedís contraseñas en el formulario?+

No. El formulario público nunca solicita accesos. Los datos seguros se piden únicamente después de aprobar el alcance y el presupuesto.

¿Quién revisa la incidencia?+

La solicitud llega a Jordi Ensenyat, fundador de Code Barcelona y especialista WordPress con más de 15 años de experiencia.

¿Se cambia algo antes del presupuesto?+

No. Primero se revisan los síntomas visibles y se define el alcance. La intervención empieza tras la aprobación y con una vía de vuelta preparada.

¿Trabajáis con webs en inglés y fuera de España?+

Sí. WP Repair atiende incidencias WordPress y WooCommerce en inglés y español, con servicio remoto.

Evaluar mi incidencia