Cómo diagnosticar cuando el menú móvil de Astra no se despliega en WordPress aunque el botón hamburguesa aparezca

Introducción

Cuando un sitio WordPress usa el tema Astra, es habitual que el menú principal se muestre de una forma en escritorio y de otra en móviles. En pantallas pequeñas, el menú suele quedar oculto tras un botón hamburguesa. El usuario pulsa ese botón y espera que se despliegue el menú lateral, el menú fuera del lienzo o el menú móvil configurado en la cabecera.

El problema aparece cuando el botón hamburguesa se ve correctamente, pero al pulsarlo no ocurre nada. No se abre el menú, no aparece ningún panel, no cambia la navegación y el administrador empieza a revisar menús, plugins, caché, cabeceras y consola del navegador sin una ruta clara.

Este artículo explica cómo diagnosticar de forma ordenada un fallo de menú móvil en WordPress con Astra. El objetivo no es cambiar opciones a ciegas, sino separar las posibles causas: asignación de menús, configuración de cabecera, CSS, JavaScript, plugins, caché, errores de tema, personalizaciones y estado interno de la instalación.

Usaremos como ejemplo un dominio ficticio, miempresa.com, para mantener el análisis limpio y reutilizable en cualquier sitio.

Índice

• Cómo funciona el menú móvil de Astra
• Síntomas habituales cuando el menú no se despliega
• Primeras comprobaciones en WordPress
• Diferenciar si el fallo es de menú, CSS, JavaScript o plantilla
• Diagnóstico con DevTools del navegador
• Comprobaciones JavaScript útiles
• Comprobaciones con WP-CLI
• Plugins, caché y conflictos habituales
• Cabecera, Header Builder y menú fuera del lienzo
• Errores habituales durante el diagnóstico
• Procedimiento recomendado de resolución
• Buenas prácticas para evitar el problema
• Preguntas frecuentes

Cómo funciona el menú móvil de Astra

El menú móvil de Astra no es simplemente una lista de enlaces que aparece y desaparece. Intervienen varias capas: WordPress, las ubicaciones de menú, la cabecera del tema, el marcado HTML, el CSS responsive y el JavaScript encargado de abrir o cerrar el panel.

En una instalación típica, WordPress almacena los menús creados desde Apariencia > Menús. Astra toma uno de esos menús y lo coloca en una ubicación concreta, por ejemplo menú principal, menú secundario o menú fuera del lienzo. Después, según el ancho de pantalla, el tema decide si muestra el menú horizontal de escritorio o el botón hamburguesa para móvil.

Cuando el usuario pulsa la hamburguesa, Astra debe ejecutar JavaScript. Ese JavaScript cambia clases CSS, atributos de accesibilidad como aria-expanded y, en algunos casos, el estado visible del contenedor de navegación.

Por tanto, el menú móvil puede fallar aunque visualmente parezca correcto. Que el botón aparezca no significa necesariamente que el menú esté bien inicializado. Solo indica que la parte visual responsive está activa.

Elementos que suelen intervenir

• Un menú creado en WordPress.
• Una ubicación de menú asignada en Astra.
• Una cabecera configurada para escritorio, tablet y móvil.
• Un botón de apertura, normalmente con clases como menu-toggle o similares.
• Un contenedor de navegación donde se encuentran los enlaces.
• JavaScript de Astra cargado correctamente.
• CSS responsive que oculta o muestra los elementos adecuados.

Síntomas habituales cuando el menú no se despliega

Antes de tocar nada, conviene describir exactamente el síntoma. Dos problemas que parecen iguales pueden tener causas completamente distintas.

No aparece el botón hamburguesa

Si el botón hamburguesa no aparece en móvil, el problema suele estar en la configuración de la cabecera, en el breakpoint responsive o en una plantilla que elimina la cabecera. También puede deberse a CSS personalizado que oculta el botón.

El botón aparece, pero no hace nada

Este es uno de los casos más incómodos. El botón existe, pero al pulsarlo no se abre el menú. Aquí el problema suele estar en el JavaScript, en la relación entre el botón y el contenedor, en la configuración del menú móvil o en algún conflicto que impide registrar el evento de clic.

El botón abre un panel vacío

Si el panel se abre pero no aparecen enlaces, el problema suele ser una ubicación de menú sin asignar, un menú vacío o una configuración incorrecta del menú fuera del lienzo.

El menú funciona en unas páginas y en otras no

Si el fallo solo ocurre en algunas páginas, hay que revisar plantillas especiales, páginas tipo landing, cabeceras transparentes, constructores visuales, formularios incrustados y scripts propios de esa página.

El menú funciona como visitante, pero falla como administrador

En este caso hay que sospechar de la barra de administración, scripts cargados solo para usuarios conectados, plugins de historial, editores visuales o herramientas de personalización.

Primeras comprobaciones en WordPress

La revisión debe empezar por WordPress, no por la consola del navegador. Si las ubicaciones de menú están mal asignadas, cualquier análisis posterior será confuso.

Revisar ubicaciones de menú

Accede a Apariencia > Menús > Gestionar ubicaciones. En Astra suelen aparecer ubicaciones como menú principal, menú secundario, menú fuera del lienzo, menú de cuenta conectada y menú de pie de página.

Para un sitio sencillo, lo habitual es tener al menos:

• Menú principal: asignado al menú principal visible en escritorio.
• Menú fuera del lienzo o menú móvil: asignado al menú que se abrirá en dispositivos pequeños.

Si no sabes qué menú usar en móvil, puedes asignar el mismo menú principal también a la ubicación móvil. Es una forma sencilla de descartar que el problema sea un menú vacío.

Revisar que el menú tenga elementos

Entra en el menú asignado y comprueba que contiene enlaces reales: Inicio, Servicios, Blog, Contacto u otras páginas. Un menú asignado pero vacío no solucionará nada.

Guardar cambios aunque parezca correcto

Cuando se importa una web, se cambia de tema o se migra desde un entorno sandbox a producción, puede haber estados guardados a medias. Conviene entrar en las ubicaciones, confirmar las asignaciones y pulsar Guardar cambios.

Diferenciar si el fallo es de menú, CSS, JavaScript o plantilla

Un diagnóstico profesional consiste en separar capas. No basta con decir “no funciona el menú”. Hay que determinar qué capa falla.

Fallo de configuración

El menú no está asignado, el menú móvil está vacío o la cabecera no tiene configurado un elemento de navegación para móvil.

Fallo de CSS

El menú se abre internamente, pero no se ve. Puede estar oculto por display:none, visibility:hidden, opacity:0, un z-index insuficiente o un contenedor con overflow:hidden.

Fallo de JavaScript

El botón se muestra, pero el clic no cambia el estado del menú. Puede deberse a errores JavaScript, scripts diferidos incorrectamente, minificación agresiva, snippets personalizados o falta de inicialización del tema.

Fallo de plantilla

Algunas plantillas eliminan la cabecera normal. Esto ocurre en páginas de aterrizaje, plantillas canvas, páginas creadas con constructores visuales o diseños importados desde plantillas externas.

Diagnóstico con DevTools del navegador

Las herramientas de desarrollo del navegador son esenciales, pero deben usarse con orden. De lo contrario, es fácil perder mucho tiempo ejecutando comandos sin interpretar bien los resultados.

Usar siempre la página pública

Las pruebas deben hacerse en la página pública de https://miempresa.com, no dentro de /wp-admin. Si se analiza la pantalla de administración, los scripts cargados no son los mismos.

Probar primero como administrador

Si el fallo se ha observado estando conectado como administrador, conviene empezar igual. Después puede repetirse en una ventana de incógnito como visitante. Comparar ambos resultados ayuda a saber si el problema afecta a todos o solo a usuarios conectados.

Revisar la consola

Abre DevTools, entra en Console, recarga la página y pulsa el botón hamburguesa. Los errores rojos son importantes, pero no todos son causa del fallo. Un aviso de política de permisos de geolocalización, por ejemplo, puede ser molesto pero no necesariamente bloquea el menú.

Revisar Network correctamente

En Network, marca Disable cache, recarga la página y filtra por términos como astra, main o navigation. Hazlo en el front-end, no en la pantalla de temas del administrador. Si lo haces en themes.php, estarás viendo recursos del panel de WordPress, no de la web pública.

Comprobaciones JavaScript útiles

Cuando el botón hamburguesa aparece pero no abre, algunas comprobaciones rápidas pueden orientar el diagnóstico.

Comprobar si Astra y jQuery cargan

En la consola del navegador, en la página pública, puedes ejecutar:

typeof astra

typeof jQuery

Si typeof astra devuelve object, hay código de Astra cargado. Si typeof jQuery devuelve function, jQuery está disponible. Si alguno devuelve undefined, hay que revisar carga de scripts, caché, optimización o plantilla.

Comprobar si existe el botón

document.querySelector('.menu-toggle')

Si devuelve un elemento <button>, el botón existe en el DOM. Si devuelve null, el selector no existe o el botón tiene otra clase.

Comprobar el atributo aria-expanded

document.querySelector('.menu-toggle').getAttribute('aria-expanded')

Antes de pulsar, lo normal es que devuelva false. Después de pulsar, debería cambiar a true si el botón abre el menú. Si sigue en false, el clic no está ejecutando correctamente la lógica de apertura.

Comprobar si existe el contenedor de navegación

document.querySelector('.main-header-bar-navigation')

Si existe el botón pero no existe el contenedor de navegación, la cabecera está generando una estructura incompleta. Si ambos existen, el problema está en la relación entre el botón, el contenedor y el JavaScript que cambia el estado.

Evitar errores de consola por selectores mal escritos

Un error muy habitual es escribir:

document.querySelector('menu-toggle')

Eso busca una etiqueta HTML llamada <menu-toggle>. Para buscar una clase CSS hay que usar punto:

document.querySelector('.menu-toggle')

Otro error frecuente es escribir mal document, jQuery o el nombre exacto de una clase. Estos errores no diagnostican la web; solo generan ruido.

Comprobaciones con WP-CLI

WP-CLI permite revisar el estado real de temas y plugins sin depender de la interfaz gráfica. En un servidor Linux con WordPress instalado en /var/www/miempresa.com, los comandos deben ejecutarse con el usuario correcto del servidor web.

Listar temas

sudo -u www-data wp theme list --path=/var/www/miempresa.com

Este comando permite saber qué tema está activo, qué versión tiene y si hay actualizaciones disponibles. Si Astra está activo pero hay una versión pendiente, conviene actualizarlo antes de seguir.

Actualizar Astra

sudo -u www-data wp theme update astra --path=/var/www/miempresa.com

Actualizar el tema puede resolver errores de archivos antiguos o inconsistencias internas. No debe ser la única estrategia de diagnóstico, pero sí una comprobación razonable.

Reinstalar Astra sin borrar contenido

sudo -u www-data wp theme install astra --force --path=/var/www/miempresa.com

Este comando sustituye los archivos del tema por una copia limpia. No borra páginas, entradas ni menús. Aun así, conviene tener copia de seguridad antes de actuar sobre una web en producción.

Listar plugins

sudo -u www-data wp plugin list --path=/var/www/miempresa.com

El listado de plugins permite detectar plugins de caché, optimización, scripts personalizados, constructores visuales o plugins de menú que puedan estar interfiriendo.

Desactivar plugins de forma controlada

sudo -u www-data wp plugin deactivate nombre-del-plugin --path=/var/www/miempresa.com

No conviene desactivar todo sin plan. Es mejor desactivar primero plugins de optimización, caché, snippets, formularios externos o constructores visuales. Después se prueba el menú y se reactiva lo que no sea culpable.

Vaciar caché de WordPress

sudo -u www-data wp cache flush --path=/var/www/miempresa.com

Este comando limpia la caché interna de WordPress. No siempre limpia cachés de servidor, CDN, navegador o plugins especializados, pero es una acción segura y útil durante pruebas.

Plugins, caché y conflictos habituales

Cuando un menú móvil no abre, los plugins más sospechosos suelen ser los que modifican scripts, cabecera, formularios, caché o interfaz.

Plugins de optimización

Plugins que minifican, combinan, difieren o retrasan JavaScript pueden impedir que Astra inicialice correctamente el menú. Si se usa uno, conviene desactivar temporalmente opciones como:

• Combinar JavaScript.
• Diferir JavaScript.
• Retrasar JavaScript hasta interacción.
• Minificar JavaScript.
• Eliminar scripts no usados.

Plugins de snippets

Herramientas como WPCode, Insert Headers and Footers u otros plugins de fragmentos pueden insertar scripts en la cabecera o el pie. Un fragmento mal pegado puede introducir un error como Unexpected token '<', típico cuando se mete HTML dentro de un bloque JavaScript o se pega un script incompleto.

Plugins de formularios externos

Formularios embebidos desde servicios externos pueden cargar scripts propios. Si el error solo aparece en la página de contacto, hay que revisar el bloque HTML del formulario y el script incrustado.

Plugins de sliders

Un slider no suele romper el menú por sí mismo, pero puede generar capas superpuestas, capturar clics o crear conflictos de z-index. Si el fallo solo ocurre en la portada y la portada tiene slider, es razonable probar sin él.

Plugins de cookies

Los plugins de consentimiento pueden bloquear scripts hasta que el usuario acepte cookies. Si bloquean por error scripts necesarios para la navegación, el menú puede no abrir. Hay que revisar la configuración de bloqueo de scripts y categorías.

Cabecera, Header Builder y menú fuera del lienzo

Astra ha tenido distintas formas de configurar la cabecera según versión y evolución del tema. En algunas instalaciones se habla de Header Builder; en otras, la configuración aparece simplemente bajo Apariencia > Personalizar > Cabecera.

No confundir Menús con Cabecera

Apariencia > Menús sirve para crear y asignar menús. Pero la cabecera de Astra decide dónde se muestran esos menús, en qué dispositivos y con qué comportamiento. Un menú puede estar correctamente asignado y aun así la cabecera puede no estar bien configurada.

Revisar la vista móvil

En el personalizador, cambia a vista móvil. No basta con mirar escritorio. En móvil debe verse claramente si el elemento de navegación aparece como menú principal, botón hamburguesa, menú fuera del lienzo o desplegable.

Menú fuera del lienzo

El menú fuera del lienzo es un panel que aparece desde un lateral o como capa separada. Si el botón hamburguesa aparece pero no abre, una posibilidad es que la configuración entre botón, menú principal y menú fuera del lienzo esté incoherente.

Probar un menú desplegable simple

Cuando el modo fuera del lienzo da problemas, una prueba razonable es cambiar temporalmente el comportamiento móvil a un menú desplegable sencillo. Si el desplegable funciona, el problema está en el modo off-canvas. Si tampoco funciona, el fallo es más general.

Publicar cambios

Algunas modificaciones del personalizador no se aplican hasta pulsar Publicar. Si se hacen cambios y solo se observa la vista previa, el comportamiento real puede no quedar reflejado en la página pública.

Configuración interna y opciones de base de datos

Parte de la configuración del tema se guarda en opciones de WordPress. En Astra puede existir una opción como theme_mods_astra, que contiene ajustes del tema y ubicaciones de menú.

Consultar theme_mods_astra

sudo -u www-data wp option get theme_mods_astra --format=json --path=/var/www/miempresa.com

Este comando puede mostrar ubicaciones de menús y otros ajustes. Sin embargo, hay que interpretarlo con cuidado. Que la opción tenga pocos datos no significa automáticamente que esté corrupta. Algunas versiones del tema pueden guardar ajustes en más lugares o reconstruir valores por defecto dinámicamente.

No borrar opciones sin copia

Un comando como este es delicado:

sudo -u www-data wp option delete theme_mods_astra --path=/var/www/miempresa.com

Eliminaría la configuración del tema almacenada en esa opción. Puede afectar cabecera, pie, colores, tipografías, anchos, blog y otros ajustes. No debe ejecutarse como prueba rápida en producción sin copia de seguridad y sin entender el impacto.

Errores habituales durante el diagnóstico

Este tipo de incidencia puede convertirse en una pérdida de tiempo si no se mantiene una metodología clara.

Mirar la pantalla equivocada

Analizar recursos de /wp-admin/themes.php no sirve para saber qué scripts carga la portada pública. Hay que abrir https://miempresa.com y diagnosticar ahí.

Asumir que todo error rojo es la causa

Un error de consola puede ser relevante o no. Hay que comprobar si aparece antes de pulsar el menú, si aparece solo en una página o si realmente impide la ejecución del código de Astra.

Desactivar plugins sin registrar resultados

Desactivar plugins puede ser útil, pero debe hacerse con orden. Si se desactiva todo, se prueba y luego se reactiva todo sin documentar, se pierde información.

Confundir selector CSS con etiqueta HTML

document.querySelector('menu-toggle') no es lo mismo que document.querySelector('.menu-toggle'). El punto indica que se busca una clase CSS.

Borrar configuración del tema demasiado pronto

Resetear opciones del tema puede arreglar un problema, pero también puede destruir una configuración visual que luego habrá que reconstruir. Debe ser una medida final, no inicial.

Procedimiento recomendado de resolución

Cuando el menú móvil de Astra no se despliega, este orden de trabajo reduce el riesgo y evita vueltas innecesarias.

Fase 1: identificar el síntoma exacto

1. Comprobar si aparece el botón hamburguesa.
2. Comprobar si al pulsar cambia algo visualmente.
3. Comprobar si ocurre en todas las páginas o solo en una.
4. Comprobar si ocurre como visitante y como administrador.

Fase 2: revisar WordPress

1. Revisar ubicaciones de menú.
2. Revisar que los menús tengan elementos.
3. Revisar la cabecera en vista móvil.
4. Guardar cambios.

Fase 3: revisar navegador

1. Revisar consola en la página pública.
2. Comprobar si cargan Astra y jQuery.
3. Comprobar si existe el botón.
4. Comprobar si existe el contenedor de navegación.
5. Comprobar si aria-expanded cambia al pulsar.

Fase 4: aislar plugins

1. Desactivar primero plugins de caché y optimización.
2. Después plugins de snippets.
3. Después formularios, sliders o constructores visuales.
4. Probar después de cada cambio.

Fase 5: revisar tema

1. Actualizar Astra.
2. Reinstalar Astra si se sospecha de archivos dañados.
3. Probar temporalmente un tema estándar para descartar un problema general de WordPress.
4. Revisar si hay tema hijo o modificaciones en archivos del tema.

Fase 6: actuar con prudencia

Si nada funciona, no conviene seguir tocando opciones sin copia. En una web de producción, lo correcto es clonar el sitio a un sandbox y reproducir el fallo allí. Después se aplican cambios de forma controlada.

Buenas prácticas para evitar el problema

Los problemas de menú móvil suelen aparecer después de importaciones, migraciones, cambios de tema, instalación de plantillas o activación de optimizadores. Algunas prácticas reducen mucho el riesgo.

Trabajar primero en sandbox

Los cambios de cabecera, tema y estructura visual deberían probarse en un entorno de pruebas. Después se migran a producción de forma controlada.

No editar archivos del tema directamente

Si es necesario añadir código, debe hacerse mediante un tema hijo o un plugin específico. Editar archivos de Astra directamente complica actualizaciones y diagnósticos.

Documentar snippets

Todo fragmento añadido a cabecera o pie debe tener descripción, fecha y motivo. Un script pegado hace meses puede convertirse en el origen de un fallo difícil de rastrear.

Evitar optimizaciones agresivas al principio

Antes de activar minificación, defer, delay o eliminación de scripts, hay que comprobar que la navegación, formularios, sliders y elementos interactivos funcionan correctamente.

Actualizar con control

Mantener Astra y WordPress actualizados es importante, pero conviene hacer copia previa y revisar la web después de actualizar.

Preguntas frecuentes