WordPress no guarda menús ni widgets cómo solucionarlo

Por qué WordPress deja de guardar menús y widgets

Este fallo suele encajar en una mezcla de incidencias de administración, JavaScript, REST API, permisos, caché o conflictos de compatibilidad. En WordPress, tanto los menús como los widgets dependen del área de administración, de peticiones al servidor y, en muchos casos, de scripts cargados en el navegador. Si cualquiera de esas piezas falla, el cambio parece guardarse, pero no persiste o se revierte al recargar.

El problema es especialmente frecuente tras actualizaciones de núcleo, tema o plugins, al cambiar de editor de widgets, al activar optimizadores agresivos o al mover la web entre servidores. En ámbito general y también en España, la casuística varía según el hosting, la versión de PHP, la caché de servidor y reglas de seguridad que bloquean ciertas peticiones del panel.

• Puede afectar solo a menús, solo a widgets o a ambos, lo que ya orienta el diagnóstico.
• Un fallo en el panel no siempre implica corrupción de datos en la base de datos.
• Los cambios recientes suelen ser la pista más útil para acotar el origen.
• Si solo falla un usuario administrador, conviene revisar perfil, navegador y permisos.
• Si ocurre en varias instalaciones del mismo servidor, el foco suele estar en el entorno.

Diagnóstico inicial y señales útiles

Antes de tocar plugins o restaurar copias, conviene observar señales concretas. En este caso son relevantes los mensajes de error en el panel, botones que no responden, widgets que muestran guardado pero vuelven atrás, avisos del navegador en consola, errores 403 o 500, picos de CPU en el hosting, alertas del panel de salud del sitio y cualquier cambio reciente en tema, plugins, versiones de PHP o sistema de caché.

Las comprobaciones iniciales deben ser prudentes. Es razonable probar con otro navegador, en una ventana privada y con un usuario administrador distinto. También conviene verificar si el problema se reproduce en staging o solo en producción. Si el hosting ha enviado avisos de recursos, mod_security o bloqueos, esa información puede ahorrar mucho tiempo y evitar pruebas que empeoren la situación.

• Revise si aparecen errores 403, 404, 409, 500 o respuestas fallidas en la pestaña de red del navegador.
• Compruebe si el problema empezó tras actualizar WordPress, un plugin, el tema o la versión de PHP.
• Observe si Search Console o el hosting han emitido alertas, aunque el fallo sea interno del panel.
• Pruebe a guardar un menú simple o un widget de texto básico para ver si el fallo afecta a todo o solo a ciertos elementos.
• Evite borrar datos, reinstalar a ciegas o limpiar cachés sin documentar el estado previo y la hora de cada prueba.

Causas habituales y cómo confirmarlas

Las causas más comunes suelen ser conflictos de plugins o del tema, errores JavaScript en administración, bloqueos de REST API, límites de memoria o reglas de seguridad del servidor. También puede influir la migración desde otro entorno, una caché persistente mal invalidada o una base de datos con opciones dañadas o con autoload excesivo que ralentiza el guardado en el panel.

Para confirmar la causa no basta con sospechar. Lo correcto es aislar variables. Si al cambiar temporalmente a un tema por defecto el menú se guarda, el foco está en la plantilla o en sus funciones personalizadas. Si al desactivar un plugin concreto desaparece el error, hay conflicto o incompatibilidad. Si el navegador muestra un error de script, conviene seguir esa pista antes de tocar el servidor.

• Un error JavaScript puede impedir que el botón de guardar envíe la petición correctamente.
• Un plugin de optimización o seguridad puede bloquear llamadas del administrador por exceso de celo.
• Un tema con código en functions.php puede alterar ubicaciones de menú o áreas de widgets.
• La versión de PHP o sus límites pueden afectar a peticiones pesadas en el panel.
• La caché de objetos o de servidor puede mostrar un estado antiguo aunque el dato sí se haya guardado.

Seguridad, malware y spam

Aunque este caso suele relacionarse más con compatibilidad y administración que con una intrusión, la seguridad no debe descartarse. Si hay usuarios desconocidos, cambios en opciones sin explicación, redirecciones, inyecciones de código o archivos modificados fuera del ciclo normal de trabajo, el fallo de menús y widgets podría ser un síntoma adicional y no la avería principal.

Los vectores habituales incluyen plugins vulnerables, credenciales filtradas, permisos inseguros y scripts inyectados en el panel. La respuesta debe ser proporcionada: copia de seguridad, revisión de usuarios administradores, rotación de contraseñas, validación de integridad de archivos y hardening básico. Conviene evitar el alarmismo, pero también evitar seguir editando el sitio sin saber si hay alteración de código o sesiones comprometidas.

• Revise usuarios administradores, últimas conexiones y cuentas que no reconoce.
• Compruebe si existen plugins o temas anulados, abandonados o con historial de vulnerabilidades.
• Valide permisos de archivos y descarte escrituras indebidas en directorios sensibles.
• Haga copia antes de limpiar, cambiar credenciales o eliminar componentes sospechosos.
• Si detecta indicios reales de compromiso, documente fechas, IP y archivos afectados para no perder trazabilidad.

Rendimiento y estabilidad del panel

Guardar menús y widgets requiere un panel estable, respuestas rápidas del servidor y recursos suficientes. Si el administrador va lento, se queda pensando, expira la sesión o devuelve respuestas intermitentes, el fallo puede estar relacionado con memoria PHP, límites de ejecución, CPU saturada, consultas lentas a base de datos o procesos de caché que interfieren con el backend.

También conviene valorar el tamaño del menú y la complejidad de la página de widgets. Un menú muy grande, con muchas entradas, taxonomías o elementos personalizados, puede rozar límites como max_input_vars. Cuando eso ocurre, algunos ítems no se guardan o se pierden posiciones. Es una causa clásica y a menudo pasa desapercibida porque no siempre muestra un error visible.

• Revise memoria PHP, tiempo máximo de ejecución y max_input_vars si los menús son extensos.
• Compruebe si la administración carga scripts y peticiones sin errores ni esperas excesivas.
• Descarte una caché de objetos o de servidor que mantenga estados antiguos del backend.
• Observe si la base de datos responde con normalidad y sin bloqueos al guardar cambios.
• Considere desactivar temporalmente optimizaciones del panel para comprobar si influyen.

Plugins, temas y actualizaciones

En esta incidencia, la compatibilidad entre núcleo, plugins y tema es una de las primeras líneas de revisión. El editor de widgets moderno, los bloques en administración y ciertas personalizaciones del tema pueden entrar en conflicto con plugins que alteran el panel o con código heredado en functions.php. Tras una actualización, un cambio menor en scripts o hooks puede bastar para romper el guardado.

La buena práctica es trabajar con staging, llevar control de cambios y probar actualizaciones por fases. Si el problema apareció tras actualizar, no siempre conviene hacer rollback inmediato sin copia y sin anotar versiones. A veces basta con identificar el componente incompatible, aplicar un parche, cambiar una configuración o actualizar otro plugin dependiente que había quedado atrás.

• Compare versiones de WordPress, tema, plugins y PHP para detectar incompatibilidades claras.
• Pruebe en staging con un tema por defecto y luego active plugins uno a uno con registro de resultados.
• Revise personalizaciones en functions.php, child theme o plugins propios que afecten a menús y widgets.
• Evite actualizar en producción sin copia, changelog y una ventana de prueba controlada.
• Si el conflicto es reproducible, documente el orden exacto en que aparece para escalarlo al desarrollador o proveedor.

Hosting, DNS y entorno técnico en España

Aunque menús y widgets pertenecen al panel de WordPress, el problema puede estar condicionado por el servidor. En España es habitual encontrar proveedores con capas propias de caché, reglas WAF, paneles de control distintos, versiones de PHP configurables y límites de recursos específicos. Todo ello puede influir en cómo se procesan las peticiones de administración y en cómo se refleja el cambio después de guardar.

También conviene revisar DNS y SSL si la web ha cambiado de dominio, subdominio o entorno. Una mezcla de URL antiguas, certificados mal aplicados o forzados erróneos de HTTP y HTTPS puede generar sesiones inestables o peticiones bloqueadas. El correo transaccional no suele ser la causa directa aquí, pero sí puede servir para detectar avisos del sistema, alertas del hosting o mensajes de error que se estaban enviando y no se estaban recibiendo.

• Verifique versión de PHP, límites de recursos y logs de errores del servidor.
• Revise reglas de seguridad, mod_security, WAF o CDN si el guardado devuelve 403 o peticiones fallidas.
• Compruebe coherencia entre URL del sitio, SSL, redirecciones y administración segura.
• Analice si la caché de servidor o del proveedor está sirviendo contenido antiguo en el backend.
• Confirme que los DNS apuntan al entorno correcto tras migraciones o cambios de hosting en España.

Pruebas, accesos y documentación técnica

Para resolver con rapidez y sin perder tiempo, hace falta documentación mínima. No se trata de pedir más accesos de los necesarios, sino de reunir pruebas suficientes para reproducir el fallo y compararlo antes y después de cada cambio. Esto ayuda a mantener trazabilidad, evita intervenciones contradictorias y facilita volver atrás si una prueba no sale bien.

En una revisión técnica suelen ser muy útiles los accesos de administrador, hosting y, si existe, staging. Si no puede facilitarse todo, al menos conviene disponer de capturas, logs, horas de incidencia y listado de cambios recientes. Para este tipo de problema, la diferencia entre improvisar y documentar suele ser la diferencia entre resolver en horas o alargar la avería varios días.

• Trazabilidad de cambios recientes: registro de actualizaciones, lista de plugins, tema activo y changelog interno si lo hay.
• Evidencias técnicas: logs de PHP y servidor, capturas del error, URLs afectadas y respuesta de la consola del navegador.
• Copias de seguridad verificadas y, si es posible, export de base de datos antes de intervenir.
• Detalle de si el fallo se reproduce con otro usuario, otro navegador o en staging.
• Informes de seguridad o escaneos previos si hubo sospecha de malware, bloqueo o acceso indebido.

Plan de acción ordenado

La forma más segura de abordar esta incidencia es seguir un orden lógico. Primero contención y copia. Después diagnóstico con pruebas de bajo riesgo. A continuación corrección en entorno controlado y, por último, verificación y monitorización. Saltarse pasos puede hacer que el sitio vuelva a funcionar de forma aparente, pero sin saber realmente qué se corrigió ni si el problema regresará.

Si el sitio tiene tráfico, conviene minimizar la ventana de cambios y coordinar cualquier actuación con quien gestione marketing, contenidos o tienda. Un menú roto afecta a la captación, y un widget que no guarda puede ocultar llamadas a la acción, formularios o información crítica. Por eso el plan debe priorizar estabilidad, trazabilidad y reversibilidad.

• Haga copia verificable de archivos y base de datos antes de corregir nada.
• Reproduzca el fallo y documente el síntoma exacto, la hora y el entorno donde aparece.
• Aísle variables con pruebas controladas en staging o en una ventana de mantenimiento breve.
• Corrija la causa confirmada, no solo el efecto visible, y registre qué se ha cambiado.
• Verifique después con varios usuarios, navegadores y elementos reales, y mantenga monitorización posterior.

Si ya se ha tocado algo o hay urgencia

Es muy habitual que, antes de pedir ayuda, ya se haya instalado un plugin de seguridad, restaurado una copia parcial, cambiado de hosting, tocado functions.php, borrado un plugin crítico o intentado limpiar archivos a mano. Todo eso puede alterar la evidencia técnica y complicar el diagnóstico, sobre todo si no se guardó registro de lo que se hizo y en qué orden se hizo.

En situaciones de urgencia, la prioridad no es hacer más cambios, sino estabilizar y documentar. Si se ha restaurado solo la base de datos o solo los archivos, puede haber desajustes. Si se cambió de hosting, puede haberse arrastrado una configuración antigua. Si se editó functions.php, un solo fragmento puede explicar el fallo. Conviene pausar nuevas pruebas destructivas hasta revisar el estado real del sitio.

• No siga borrando plugins o editando archivos sin anotar exactamente qué ya se ha modificado.
• Si se restauró una copia parcial, confirme qué fecha y qué partes del sitio se recuperaron.
• Si se cambió de hosting, revise versiones, rutas, cachés, SSL y reglas de seguridad del nuevo entorno.
• Si se tocó functions.php o código del tema, compare con la versión anterior y retire cambios solo con copia previa.
• Si se intentó limpiar malware sin copia, preserve los archivos actuales y los logs antes de sobreescribir evidencias.

Preguntas frecuentes

Estas dudas suelen aparecer cuando el fallo no da un mensaje claro. Responderlas ayuda a decidir si el foco está en WordPress, en el navegador o en el servidor.

P: ¿Por qué WordPress dice que ha guardado el widget pero luego no aparece el cambio?

R: Suele deberse a caché, errores JavaScript, peticiones bloqueadas o conflicto con el tema o un plugin. También puede haberse guardado parcialmente y mostrarse una versión antigua del panel.

P: ¿Un menú muy grande puede dejar de guardarse?

R: Sí. Es una situación clásica cuando se alcanza el límite de max_input_vars u otros recursos del servidor. En esos casos algunas entradas del menú se pierden o no mantienen el orden.

P: ¿Conviene desactivar todos los plugins directamente?

R: Solo si hay copia, registro de cambios y preferiblemente en staging. Desactivar todo en producción sin orden puede afectar a funcionalidades críticas y dificultar la trazabilidad.

P: ¿Puede influir el navegador?

R: Sí. Extensiones, caché local, cookies corruptas o políticas del navegador pueden alterar el panel. Por eso conviene probar en otro navegador o en modo privado antes de tocar la web.

P: ¿Cuándo merece la pena pedir revisión técnica?

R: Cuando el fallo se repite, afecta a negocio, aparece tras cambios recientes o ya se han hecho varias pruebas sin una causa clara. Lo razonable es empezar por diagnóstico, copia y plan de corrección.