Editor de bloques no carga en WordPress: cómo solucionarlo

En pocas palabras: Si el editor de bloques (Gutenberg) no carga, en la mayoría de los casos hay un conflicto con un plugin o el tema, o una REST API que no devuelve JSON en /wp-json/. Desactivá los plugins, guardá los Enlaces permanentes y revisá la consola del navegador.

Cuando el editor de bloques no carga y la pantalla queda en blanco, en la mayoría de los casos la causa es un conflicto con un plugin o con el tema, o una REST API que no responde. Desactivá los plugins, guardá los enlaces permanentes en Ajustes > Enlaces permanentes y revisá la consola del navegador.

El editor de bloques (Gutenberg) es el editor visual de WordPress para crear entradas y páginas con bloques. Corre en tu navegador con JavaScript y le pide y le manda datos al servidor por la REST API, que responde en formato JSON. Si un plugin, el tema, la caché, un firewall o el propio servidor rompe alguna de esas piezas, el editor queda en blanco, cargando sin parar o tira un error al guardar.

¿Cómo ver el error real del editor de bloques en la consola del navegador?

Abrí las herramientas de desarrollo con F12, entrá a la pestaña Consola para ver los errores de JavaScript y a la pestaña Red para ver qué devuelven las llamadas a /wp-json/. Como regla práctica (mía, no de la documentación oficial): un 403 apunta a un firewall, un 404 a los enlaces permanentes y un 500 a un error de PHP. Con eso elegís por dónde arrancar.

1. Abrí el editor que falla y apretá F12 antes de que cargue.
2. Recargá con la pestaña Red abierta y escribí «wp-json» en el filtro. Fijate el código de estado de cada llamada.
3. Probá en una ventana de incógnito o en otro navegador. Si ahí carga, el culpable es una extensión o la caché local.
4. Copiá el primer error en rojo de la Consola. Ese suele ser el origen; los demás vienen de rebote.

Si la consola está limpia y la pantalla sigue en blanco, el error probablemente esté del lado de PHP. Ahí entra el debug.log, más abajo.

Error «La respuesta no es una respuesta JSON válida»: cómo comprobar la REST API

Abrí tudominio.com/wp-json/ en el navegador. Si ves texto en formato JSON, la REST API responde. Si ves una página HTML, un 404, una redirección o un bloqueo, ahí está el problema: el mensaje significa que el editor esperaba JSON y recibió otra cosa.

Síntomas

Editás una entrada, tocás Actualizar y aparece este cartel (en inglés, según la guía de Themeisle, «Updating Failed. The Response is Not a Valid JSON Response.»):

Error al actualizar. La respuesta no es una respuesta JSON válida.

También puede aparecer en el editor que no abre. Ojo: en sitios en español el texto puede variar un poco según la traducción instalada. Relacionado: mejorar las Core Web Vitals en Gutenberg.

Causa

Según Themeisle, el editor de bloques se comunica con el servidor en segundo plano por la REST API y espera JSON. Si la respuesta falta o llega mal formada (un error del servidor, una solicitud bloqueada), muestra ese mensaje en lugar de guardar. La misma guía lista como causas los enlaces permanentes rotos, un .htaccess incorrecto, URLs mal cargadas en Ajustes > Generales, contenido mixto HTTP/HTTPS, plugins de seguridad y reglas de ModSecurity.

La documentación oficial de Salud del sitio suma tres pistas más: una solicitud de loopback fallida, una sesión PHP activa (que interfiere con la REST API y con los loopback) y la falta del módulo json_last_error.

Esto último pasa menos de lo que parece. ¿Es lo primero que revisaría? No. Pero tarda un minuto y descarta causas.

Solución paso a paso

1. Verificá /wp-json/. Si tenés enlaces permanentes «simples», probá tudominio.com/?rest_route=/. Resultado esperado: un bloque de texto JSON.
2. Entrá a Herramientas > Salud del sitio y leé los problemas críticos. Fijate loopback, sesiones PHP y módulos faltantes.
3. Guardá los enlaces permanentes. En Ajustes > Enlaces permanentes tocá Guardar cambios sin modificar nada. Es el arreglo más barato y, según Themeisle, la configuración errónea de enlaces es una de las causas más comunes de este error.
4. Regenerá el .htaccess (solo Apache). Hacé backup, renombrá el archivo a .htaccess_old por FTP y volvé a guardar los enlaces para que WordPress cree uno nuevo. En Nginx no existe .htaccess y la regla va en la configuración del servidor.
5. Revisá Ajustes > Generales. «Dirección de WordPress» y «Dirección del sitio» tienen que apuntar al dominio correcto y, si tenés SSL, empezar con https. Ojo: si instalaste WordPress en una subcarpeta, es normal que difieran.
6. Buscá contenido mixto. Un recurso cargado por HTTP dentro de una página HTTPS puede ser bloqueado por el navegador, y si es la llamada a la REST API el editor se queda sin respuesta.
7. Descartá firewall y plugins de seguridad. Desactivá el plugin un rato y probá. Si el bloqueo viene del servidor, pasá a la sección de soporte.

Si tenés que revisar el .htaccess a mano, estas son las reglas estándar que muestra el handbook de errores comunes:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Los temas de seguridad (reglas de firewall, hardening) los tratamos en el blog hermano seguridadenwordpress.com. Acá solo nos importa que un bloqueo mal configurado puede romper el editor.

Cómo prevenirlo

Después de migrar el sitio, cambiar de dominio o pasar a HTTPS, guardá los enlaces permanentes y verificá /wp-json/ antes de dar el trabajo por terminado.

¿Por qué el editor de bloques no carga por un conflicto de plugins o del tema?

Un plugin o un tema con código roto o desactualizado puede tirar un error de PHP, imprimir texto donde no debe o pisar una respuesta de la REST API, y el editor se queda sin datos. La documentación oficial lo pone entre las causas de la pantalla en blanco. El diagnóstico es mecánico: apagás todo, probás y reactivás de a uno.

Síntomas

Ponele que actualizás el plugin de tu builder favorito, abrís una página y el editor queda en blanco, entonces probás otro navegador, vaciás la caché, reiniciás la compu, culpás al hosting y a las tres horas descubrís que era un plugin abandonado hace rato que chocaba con la versión nueva. Eso es un conflicto típico: el problema empezó después de instalar, actualizar o activar algo, y el resto del sitio quizás anda perfecto.

A veces el WordPress directamente muestra este texto:

There has been a critical error on this website. Please check your site admin email inbox for instructions.

Causa

El handbook de errores comunes menciona como causas habituales los conflictos entre plugins, la incompatibilidad con el tema, una versión de PHP incompatible, el límite de memoria y los archivos corruptos. No encontré en las fuentes una versión puntual de WordPress o Gutenberg asociada a este problema, así que no te voy a inventar una.

Solución paso a paso

1. Hacé un backup primero. Desactivar plugins puede romper configuraciones, como advierte Themeisle.
2. Desactivá todos los plugins. En Plugins > Activos, seleccioná todos y elegí Acciones en lote > Desactivar.
3. Probá el editor. Si carga, uno de los plugins es el culpable.
4. Reactivá de a uno (o en grupos chicos) probando el editor después de cada paso, hasta que vuelva a fallar.
5. Si no podés entrar al admin, conectate por FTP o por el administrador de archivos y renombrá la carpeta wp-content/plugins a plugins_old. Eso desactiva todo. Después devolvele el nombre original y reactivá desde el panel.
6. Probá un tema por defecto. Activá uno de los que trae WordPress. Sin acceso al admin, renombrá la carpeta del tema activo dentro de /wp-content/themes/.

Una vez que encontrás al responsable, actualizalo, revisá si tiene versión nueva o buscá un reemplazo. No dejes el plugin roto activo «porque anda todo menos eso». Sobre eso hablamos en nuestra guía completa sobre Gutenberg y FSE.

Cómo prevenirlo

Actualizá primero en un entorno de prueba (staging) y sacá backup antes de tocar plugins que modifican el editor, como builders o extensiones de bloques.

¿Cómo borrar la caché de WordPress y del navegador?

Vaciá la caché y las cookies del navegador, purgá la caché del plugin de caché, la del servidor y la del CDN si usás uno. Si el editor se rompió justo después de actualizar, un JavaScript o CSS viejo puede estar mezclándose con archivos nuevos del core. Es una inferencia razonable, no algo que la documentación diga puntualmente del editor.

Síntomas

El editor se rompió tras actualizar WordPress o un plugin, anda en incógnito pero no en tu navegador habitual, o hiciste un cambio y no lo ves reflejado. El handbook tiene una sección para ese último caso: «You Make Changes and Nothing Happens».

Causa

El navegador guarda archivos para cargar más rápido, y si no considera significativo el cambio, sigue usando la copia local, según el handbook. Sumale las capas de caché del servidor y del CDN. Y las optimizaciones de minificación o diferido de JavaScript (en el plugin de caché o en un CDN como Cloudflare) son sospechosas habituales cuando un script del editor deja de ejecutarse; acá hablo por lógica, no porque lo digan las fuentes.

Solución paso a paso

1. Vaciá la caché del navegador o cerrá la pestaña y reabrí el enlace.
2. Purgá la caché del plugin de caché desde su panel.
3. Purgá la caché del servidor y del CDN si el hosting o el CDN tienen su propio botón.
4. Desactivá un rato la minificación y la combinación de JS en el plugin de caché y en el CDN, y probá el editor.

Si con eso carga, volvé a activar las opciones de a una para ver cuál rompe, y excluí el admin (wp-admin) de la optimización.

Cómo prevenirlo

Purgá todas las cachés después de cada actualización grande y excluí wp-admin de la minificación y del cacheo. Más contexto en sumar más bloques sin un page builder.

¿Cómo activar WP_DEBUG y leer el archivo debug.log?

Editá wp-config.php y agregá WP_DEBUG en true, WP_DEBUG_LOG en true y WP_DEBUG_DISPLAY en false, antes de la línea «That’s all, stop editing!». El error queda guardado en wp-content/debug.log sin mostrarse a los visitantes. Es el método que describe el handbook de depuración.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Si sospechás de un script del core, sumá define( 'SCRIPT_DEBUG', true ); para forzar las versiones sin minificar de los JS y CSS. Reproducí el error en el editor y abrí wp-content/debug.log por FTP: la última línea con «Fatal error» suele nombrar el archivo del plugin o tema responsable.

Ahora bien, apagá todo al terminar. La pantalla de Salud del sitio marca como problema crítico mostrar errores a los visitantes o dejar el log en un archivo potencialmente público, porque puede contener información sensible. Poné WP_DEBUG en false y borrá el log.

¿Cómo aumentar el límite de memoria de PHP en WordPress?

Si debug.log muestra «Allowed memory size exhausted», subí WP_MEMORY_LIMIT en wp-config.php o pedile a tu proveedor que aumente el límite de PHP. El handbook explica que ese error aparece cuando la instalación no tiene memoria suficiente para lo que le pedís.

Síntomas

El editor se cuelga con entradas pesadas, o el log registra este error (PHP agrega los bytes detrás):

Allowed memory size exhausted

También puede aparecer «Maximum execution time exceeded» si el proceso tarda demasiado.

Causa

Según el handbook, el sitio hace más de lo que el servidor puede manejar, algo común en hosting compartido con memoria limitada. Muchos plugins pesados activos al mismo tiempo lo agravan.

Solución paso a paso

1. Subí el límite en wp-config.php, antes de la línea de «stop editing».
2. Si no alcanza, editá php.ini o pedile al hosting que lo haga; no es un archivo de WordPress.
3. Revisá la versión de PHP en Herramientas > Salud del sitio, que marca como crítico un PHP desactualizado.
4. Para el tiempo de ejecución, subí max_execution_time en php.ini o pedíselo al proveedor.

define( 'WP_MEMORY_LIMIT', '256M' );

El 256M es un valor de ejemplo que aparece en guías de terceros, no una recomendación oficial. Algunos hostings fijan un tope y pisan lo que pongas en wp-config.php. Te puede servir nuestra cobertura de la comparativa entre WordPress y Gutenberg.

Cómo prevenirlo

Desinstalá los plugins que no usás y mantené PHP al día.

¿Conviene volver al editor clásico si el editor de bloques falla?

Sirve como parche si tenés que publicar ya: el plugin Classic Editor, del repositorio de WordPress, te devuelve la pantalla anterior. Pero no arregla la causa, y mi inferencia es que si la REST API está rota el problema te va a aparecer en otros lados. Usalo para zafar el día, no para quedarte.

Tabla de diagnóstico rápido del editor de bloques

Síntoma	Causa probable	Solución rápida	Fuente
Error JSON al guardar	Enlaces permanentes o .htaccess	Guardar enlaces; regenerar .htaccess	Themeisle
/wp-json/ devuelve 404 o HTML	Reescritura de URLs rota	Probar ?rest_route=/ y regenerar reglas	Themeisle, handbook
403 en llamadas a /wp-json/	Plugin de seguridad o ModSecurity	Desactivar el plugin; consultar al hosting	Themeisle
Pantalla en blanco tras actualizar	Plugin o tema en conflicto	Desactivar plugins; tema por defecto	Handbook
Mensaje de error crítico	Error fatal de PHP	Activar WP_DEBUG y leer debug.log	Handbook
«Allowed memory size exhausted»	Límite de memoria bajo	Subir WP_MEMORY_LIMIT o pedirlo al hosting	Handbook
Anda en incógnito, no en tu navegador	Caché o extensión	Vaciar caché; desactivar extensiones	Handbook

¿Cuándo contactar al soporte del hosting?

Escribile al hosting cuando la causa parece estar en el servidor: reglas de firewall o ModSecurity que bloquean /wp-json/, límites de memoria o tiempo que no podés cambiar, versión de PHP, permisos de archivos o módulos PHP faltantes. En ModSecurity, Themeisle recomienda mirar los logs del servidor y pedirle al proveedor que habilite una excepción, porque muchos hosts ya conocen el problema.

Llevá datos concretos al ticket:

• Captura de la consola y de la pestaña Red, con la llamada a /wp-json/ y su código de estado.
• El contenido de debug.log con las líneas del error, sin datos sensibles.
• La información exportada de Herramientas > Salud del sitio > Info, que tiene un botón para copiar todo al portapapeles.
• Qué probaste ya: plugins desactivados, tema por defecto, enlaces permanentes guardados.

Si el problema es de WordPress o de un plugin, abrí un hilo en los foros oficiales de soporte, o en el repositorio de Gutenberg en GitHub si sospechás un bug del editor. Y si querés un hosting con soporte en español, mirá el hosting WordPress de Donweb: explicar un 403 en tu idioma ahorra rondas de tickets.

Preguntas Frecuentes

¿Por qué el editor de bloques de WordPress no carga y queda en blanco?

Casi siempre por un conflicto de plugin o tema, una REST API bloqueada, un error de PHP o la caché. Revisá la consola del navegador y activá WP_DEBUG para ver cuál de las cuatro es.

¿Qué significa «Error al actualizar. La respuesta no es una respuesta JSON válida»?

Significa que el editor pidió datos a la REST API y recibió algo que no es JSON, como una página de error, una redirección o un bloqueo. Guardá los enlaces permanentes y revisá /wp-json/.

¿Cómo verifico si la REST API de WordPress funciona?

Abrí tudominio.com/wp-json/ en el navegador: si responde con texto JSON, funciona. Con enlaces simples probá tudominio.com/?rest_route=/ y revisá también Herramientas > Salud del sitio.

¿Cómo saber qué plugin rompe el editor de Gutenberg?

Desactivá todos los plugins, comprobá que el editor carga y reactivalos de a uno probando cada vez. El que lo vuelve a romper es el responsable.

¿Cómo activar el modo debug en WordPress para ver el error del editor?

Poné WP_DEBUG y WP_DEBUG_LOG en true y WP_DEBUG_DISPLAY en false en wp-config.php. Los errores quedan en wp-content/debug.log; desactivalo al terminar.

Conclusión

Si el editor de bloques no carga, empezá por la consola, después guardá los enlaces permanentes, y recién ahí desactivá plugins. La documentación oficial pone los conflictos de plugins y temas entre las causas principales de la pantalla en blanco, y Themeisle señala los enlaces permanentes entre las más comunes del error JSON.

Si nada de eso funcionó, activá WP_DEBUG, leé debug.log y llevá esa evidencia al soporte de tu hosting. Y no te quedes en el editor clásico: es un parche, no una solución.

Fuentes

• Common WordPress errors – handbook oficial de Administración Avanzada
• Debugging in WordPress – cómo activar WP_DEBUG y el log
• Site Health screen – documentación oficial de Salud del sitio
• Themeisle – guía para el error de respuesta JSON no válida