Guía para decidir mejor

El editor de WordPress no guarda cambios: qué comprobar

Observa el código de respuesta del guardado antes de tocar plugins o permisos.

Cuando el editor de WordPress no guarda cambios, evita repetir «Actualizar» hasta saber si la petición falló, quedó en curso o sí se guardó en otro borrador. El editor de bloques utiliza la API REST, pero el problema también puede venir de permisos de usuario, conexión, límites PHP, plugins, WAF o base de datos. Una prueba controlada distingue estas causas.

Protege el contenido y reproduce el fallo

Copia el texto recién escrito a un lugar seguro antes de recargar. Anota tipo de contenido, URL, usuario y hora. Intenta guardar una entrada de prueba sin publicarla y comprueba si otros usuarios autorizados pueden hacerlo. Si solo falla un bloque o un contenido, revisa su validación y tamaño; si fallan todas las entradas, mira la respuesta del servidor. No desactives extensiones en una tienda activa para probar sin ventana y copia.

Lee la respuesta de la petición

Abre las herramientas de red del navegador, guarda una edición mínima y localiza la solicitud a /wp-json/ o a la ruta usada por el editor. Un 401/403 sugiere sesión, permisos o firewall; un 404 puede señalar reescritura; un 500 requiere log PHP; una espera larga puede ser recurso, base de datos o servicio externo. No pegues el cuerpo de la petición en foros: puede incluir contenido privado. La documentación oficial de la API REST explica por qué el editor depende de esa interfaz.

Ejemplo de diagnóstico: la página pública sigue bien, pero guardar una entrada devuelve 403 y el WAF registra una regla a esa hora. Una excepción acotada podría resolver un falso positivo; aumentar memoria no lo hará. Si la petición devuelve 500 y el log señala un plugin, reproduce en staging y prueba su reversión. Si el navegador anuncia bloque inválido, conserva el contenido y sigue las opciones de recuperación de bloques antes de convertirlo a HTML.

Revisa permisos y almacenamiento

Verifica que el usuario puede editar ese tipo de contenido, que la sesión no expiró y que la base de datos acepta escrituras. Una cuota de disco agotada, una tabla dañada o un plugin de seguridad pueden afectar a guardados de formas distintas. Si todos los guardados fallan tras cambiar de servidor, compara rutas REST, reglas de proxy y logs. Para un 403 general o un 500, sigue las comprobaciones específicas sin atribuirlo automáticamente al hosting.

Valida la solución

Guarda, recarga y confirma que el cambio persistió en la base y en la vista pública prevista; prueba también un segundo contenido y una cuenta con rol adecuado. Comprueba que no quedó una revisión pendiente ni se publicaron datos de prueba. Para solicitar asistencia técnica, comparte código HTTP, hora y ruta saneada, no el texto privado ni la contraseña.