El editor de bloques se queda en blanco, carga sin terminar, rompe un bloque o rechaza el guardado justo cuando necesitas publicar. Desactivar plugins a ciegas en producción puede empeorar la incidencia: perderás funciones visibles para los visitantes y el fallo puede seguir ahí si intervienen la caché, JavaScript, los nonces o la REST API.
Índice
Anuncio
Diagnostica el fallo según el síntoma
Identifica el síntoma, guarda una copia y prueba la capa afectada antes de modificar plugins o actualizaciones.
Distingue la pantalla blanca de la carga infinita
Una pantalla blanca suele apuntar a un error PHP, memoria agotada o JavaScript que no llega a cargar. Una carga infinita suele indicar una petición bloqueada, una sesión caducada o una respuesta de la API REST que no devuelve JSON válido.
Clasifica los fallos de bloque y guardado
Si aparece “Este bloque ha encontrado un error”, abre el menú de tres puntos del bloque y copia su contenido antes de pulsar “Intentar recuperación”. Si el error dice que la actualización ha fallado, no cierres la pestaña: copia el texto en un documento local, apunta la URL de la entrada y revisa las peticiones de guardado.
Localiza la capa que rompe el editor
Revisa caché, scripts, tema y recursos antes de culpar al bloque.
Separa core, plugin y tema
Antes de actualizar para corregir un conflicto de plugins, anota las versiones de WordPress, PHP, el tema activo y las extensiones relacionadas con los bloques afectados. Comprueba en la ficha del plugin y en el registro de cambios si declara compatibilidad con tu versión de WordPress y con PHP: una extensión actualizada puede requerir una versión de PHP superior, mientras que otra sin mantenimiento puede fallar tras una actualización del núcleo.
En staging, actualiza primero WordPress o PHP según recomiende el hosting, prueba el editor y después actualiza un plugin cada vez. Si el error empezó tras una actualización concreta, volver temporalmente a la versión anterior en una copia permite confirmar la causa sin degradar toda la instalación.
Descarta caché y JavaScript alterado
Vacía las cuatro capas en este orden: caché del plugin, caché del servidor, CDN y caché del navegador. Después abre una ventana privada y prueba de nuevo; si persiste, desactiva temporalmente solo las opciones de combinar, minificar, diferir o retrasar JavaScript, porque pueden cambiar el orden que necesita el editor.
Anuncio
Obtén pruebas sin exponer la web
Abre la consola y la red del navegador para saber qué petición falla sin mostrar datos técnicos a visitantes.
Lee errores de consola sin adivinar
En Chrome, Edge o Firefox, pulsa F12, abre la consola y recarga el editor. Busca el primer mensaje rojo, copia el texto completo, el archivo y la línea señalada; un error como Uncaught TypeError, wp-element, React o wp-data suele apuntar a código de bloques, minificación o versiones incompatibles.
Comprueba network, REST y el registro PHP
Abre “Network” o “Red”, recarga y filtra por wp-json: un 401 suele ser sesión o permisos, un 403 firewall, un 429 límite de peticiones y un 500 error del servidor. Prueba también https://tudominio.es/wp-json/; debe devolver JSON, no HTML ni una página bloqueada. Para registrar PHP sin mostrar errores, añade estas líneas antes de /* That's all, stop editing! */ en wp-config.php:
php define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false ); @ini_set( 'display_errors', 0 );
Reproduce una vez el fallo, revisa wp-content/debug.log y retira las líneas al terminar, porque el archivo puede crecer y contener rutas internas o datos técnicos.
Si el problema solo ocurre en un ordenador o navegador, prueba el editor en una ventana privada y después en otro navegador con las extensiones desactivadas. Bloqueadores de anuncios, herramientas de privacidad, gestores de scripts, extensiones de traducción o antivirus web pueden bloquear peticiones a wp-json, modificar JavaScript o eliminar cookies necesarias para el nonce de WordPress. Revisa también la consola del navegador: mensajes como ERR_BLOCKED_BY_CLIENT suelen indicar una extensión local y no un fallo del servidor.
Si al usar un perfil limpio el editor funciona, reactiva las extensiones una a una y excluye el dominio de WordPress únicamente en la herramienta que haya causado el bloqueo.
Repara REST API, nonce y guardado
Restaura la comunicación del editor con el servidor antes de editar más contenido.
Renueva sesión, enlaces y permisos
Cierra sesión, borra las cookies del dominio y vuelve a entrar con el usuario afectado. Después ve a Ajustes > Enlaces permanentes y pulsa “Guardar cambios” sin modificar la estructura; confirma además que el rol del usuario puede editar o publicar la entrada y, si falla un patrón sincronizado, que también puede editar ese elemento compartido.
Pide una revisión concreta al hosting
Si Network devuelve 403, indica al hosting la URL de wp-json, la hora con zona horaria y el código recibido, y pide revisión de ModSecurity, WAF, reglas anti-bot y registros del servidor. Si devuelve 500, solicita el error PHP asociado y consulta el límite de memoria; no abras el firewall por completo, porque una excepción amplia puede exponer la administración.
Aísla conflictos sin tocar producción
Usa Health Check o staging para probar extensiones sin afectar a los visitantes.
Elige health check o staging
| Método | Impacto visitante | Tiempo habitual | Coste orientativo en España | Mejor uso |
|---|---|---|---|---|
| Health Check | Ninguno | 10 a 30 minutos | 0 € | Aislar plugin o tema para un administrador |
| Staging del hosting | Ninguno | 30 a 90 minutos | Incluido o con suplemento según plan | Actualizar, probar WooCommerce, CDN y tema |
Sigue un orden que puedas revertir
Haz una copia verificable de archivos y base de datos MySQL. En Health Check, activa el modo de resolución, abre la entrada afectada y desactiva primero el plugin de caché u optimización solo en tu sesión; después prueba extensiones no esenciales, bloques, formularios o WooCommerce, cambia al tema predeterminado si persiste y reactiva un componente cada vez anotando el resultado.
Anuncio
Recupera bloques, patrones y revisiones
Guarda el contenido y usa revisiones antes de convertir o eliminar un bloque inválido.
Repara sin borrar la evidencia
Abre el menú del bloque, elige “Copiar” o guarda el texto visible en un documento local. Comprueba si dependía de un shortcode, formulario o bloque de WooCommerce; si la extensión fue eliminada, reactívala en staging con una versión compatible antes de convertirlo a HTML normal, porque la recuperación automática puede eliminar atributos propios.
Restaura patrones y versiones anteriores
Los antiguos bloques reutilizables se gestionan como patrones sincronizados: modificar uno cambia todas sus apariciones. Revisa las revisiones de la entrada, compara la versión anterior al fallo y restaura primero en una copia o staging; después prueba la vista previa sin caché en escritorio y móvil antes de tocar de nuevo el contenido.
Preguntas comunes
¿Por qué Gutenberg se queda cargando sin parar?
Gutenberg suele cargar sin parar cuando falla JavaScript, la API REST, un nonce o una petición bloqueada. Abre Network, busca wp-json y revisa si aparece un código 401, 403, 429 o 500 antes de desactivar plugins.
¿Cómo arreglo el error de actualización fallida?
El error de actualización fallida se revisa comprobando REST API, cookies, permisos y reglas de seguridad. Guarda el texto primero, vuelve a iniciar sesión y prueba /wp-json/; si devuelve 403 o 500, pide al hosting el registro de esa hora.
¿Un bloque inválido significa que he perdido el contenido?
Un bloque inválido no significa por sí solo que el contenido se haya perdido. Copia el bloque, revisa las revisiones y confirma si dependía de un plugin, shortcode o patrón sincronizado antes de recuperarlo.
¿Puedo desactivar plugins para probar Gutenberg?
Puedes probar plugins con Health Check o staging sin afectar a los visitantes. Desactivarlos directamente en producción puede romper formularios, pagos o caché, y no elimina los archivos que una CDN conserva entre 5 y 30 minutos.
¿Cómo activo WP_DEBUG sin mostrar errores en la web pública?
Activa WP_DEBUG_LOG y desactiva WP_DEBUG_DISPLAY en wp-config.php. Así WordPress escribe errores PHP en wp-content/debug.log sin enseñar rutas o datos técnicos en la web pública.
- Identifica el síntoma antes de tocar plugins, temas o actualizaciones.
- Comprueba consola, Network y `debug.log` privado para localizar la capa rota.
- Vacía caché de plugin, servidor, CDN y navegador cuando el fallo implique scripts.
- Aísla conflictos con Health Check o staging y reactiva un elemento cada vez.
- Recupera bloques desde copias y revisiones antes de convertir o borrar contenido.
- Reparte Gutenberg y constructores sin contenido huérfano
- Gutenberg rinde más cuando evitas estos bloques y plugins
Josu Barrios
Somos especialistas en mantenimiento WordPress para empresas, profesionales y tiendas online. Contamos con experiencia en seguridad web, optimización de rendimiento, actualizaciones, copias de seguridad y resolución de incidencias técnicas, ayudando a que cada sitio funcione de forma rápida, estable y protegida. Nuestro enfoque combina soporte técnico profesional, buenas prácticas de seguridad y seguimiento continuo para ofrecer un servicio fiable, transparente y orientado a resultados reales.