Introducción
Los temas modernos de WordPress suelen mostrar el menú principal de una forma en ordenadores y de otra en teléfonos móviles. En pantallas pequeñas, la navegación normalmente queda oculta tras un botón hamburguesa que abre un menú desplegable, un panel lateral o una navegación fuera del lienzo.
El problema aparece cuando el botón hamburguesa se ve correctamente, pero al pulsarlo no ocurre nada. No se abre el menú, no aparece el panel lateral, no cambian los enlaces visibles y el administrador empieza a revisar plugins, caché, cabeceras, menús y consola del navegador sin una ruta clara.
Este fallo no es exclusivo de un tema concreto. Puede aparecer en sitios que utilizan Astra, Blocksy, Kadence, GeneratePress, Neve, OceanWP, Hello Elementor y otros temas modernos con cabeceras adaptables. También puede producirse en cabeceras creadas con el editor de bloques, Elementor, Bricks, Beaver Builder u otros constructores visuales.
Este artículo explica cómo diagnosticar de forma ordenada un menú móvil de WordPress que no se despliega. El objetivo no es cambiar opciones a ciegas, sino separar las posibles causas: asignación de menús, configuración de la cabecera, CSS, JavaScript, plugins, caché, optimización, plantillas especiales, personalizaciones y estado interno de la instalación.
Usaremos como ejemplo un dominio ficticio, miempresa.com, para mantener el procedimiento limpio y reutilizable en cualquier sitio WordPress.
Índice
- Cómo funcionan los menús móviles en los temas modernos
- Temas y sistemas de cabecera a los que se aplica
- Tipos de menú y ubicaciones habituales en WordPress
- Síntomas habituales cuando el menú no se despliega
- Primeras comprobaciones en WordPress
- Diferenciar si el fallo es de configuración, CSS, JavaScript o plantilla
- Diagnóstico con DevTools del navegador
- Comprobaciones JavaScript útiles
- Comprobaciones CSS y problemas de superposición
- Comprobaciones con WP-CLI
- Plugins, caché y conflictos habituales
- Constructores de cabecera, menús desplegables y paneles laterales
- Menús creados con el editor del sitio y bloques
- Configuración interna y opciones de base de datos
- Errores habituales durante el diagnóstico
- Procedimiento recomendado de resolución
- Buenas prácticas para evitar el problema
- Preguntas frecuentes
Temas y sistemas de cabecera a los que se aplica
El procedimiento descrito en este artículo puede utilizarse en numerosos temas y sistemas de construcción de cabeceras. Los nombres exactos de las opciones, clases CSS y ubicaciones pueden cambiar, pero las capas que deben diagnosticarse son básicamente las mismas.
Astra
Astra utiliza un constructor de cabeceras con configuraciones diferenciadas para escritorio y dispositivos móviles. Puede mostrar menús desplegables o paneles fuera del lienzo. Un fallo puede estar relacionado con la asignación del menú, el elemento de navegación móvil, los scripts del tema o la configuración guardada por el personalizador.
Blocksy
Blocksy incluye un constructor visual de cabeceras y un área específica para el menú móvil. El botón de apertura, el panel fuera del lienzo y los elementos incorporados a la cabecera móvil deben estar correctamente relacionados.
Kadence
Kadence permite diseñar filas y elementos diferentes para escritorio y móvil. El menú puede estar correctamente creado, pero no incorporado al área móvil o vinculado a un activador adecuado.
GeneratePress
GeneratePress puede utilizar la navegación principal responsive, una navegación móvil independiente o configuraciones complementarias proporcionadas por módulos y bloques. Los conflictos de scripts y CSS también pueden impedir la apertura.
Neve
Neve dispone de un constructor de cabecera adaptable. El menú móvil puede depender de un icono activador y de una barra lateral o área desplegable configurada para dispositivos pequeños.
OceanWP
OceanWP ofrece varios estilos de menú móvil. Un cambio entre estilos, una configuración incompleta o un conflicto con extensiones del tema puede hacer que el botón aparezca sin abrir correctamente la navegación.
Hello Elementor y cabeceras construidas con Elementor
Cuando se utiliza Hello Elementor, la cabecera suele estar construida mediante Elementor Pro o mediante un plugin adicional. En este caso, el comportamiento del menú depende más del widget de navegación y del constructor visual que del tema base.
Temas de bloques
En temas compatibles con la edición completa del sitio, la navegación puede estar integrada en una parte de plantilla. El diagnóstico debe considerar el bloque Navegación, sus opciones responsive, la plantilla activa y los estilos globales.
Otros constructores visuales
El mismo enfoque puede utilizarse en cabeceras creadas con Bricks, Beaver Builder, Divi, Breakdance, Oxygen u otros sistemas. En estos casos hay que identificar qué componente genera el botón, qué script controla la apertura y qué plantilla se aplica en cada página.
Síntomas habituales cuando el menú no se despliega
Antes de modificar 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 no aparece en móvil, el problema suele estar en la configuración de la cabecera, en el punto de ruptura responsive, en la visibilidad del elemento o en una plantilla que elimina la cabecera. También puede deberse a CSS personalizado que oculta el activador.
El botón aparece, pero no hace nada
El botón existe visualmente, pero al pulsarlo no se abre el menú. En este caso, el problema suele estar en JavaScript, en la relación entre el botón y el contenedor, en una capa invisible que captura el clic o en una inicialización incompleta del componente.
El botón cambia, pero el menú no se ve
Si el icono cambia, aria-expanded pasa a true o se añade una clase al documento, el JavaScript probablemente funciona. El problema estará entonces en CSS, en el posicionamiento del panel, en su opacidad, en su visibilidad o en el orden de las capas.
El botón abre un panel vacío
Si el panel se abre pero no aparecen enlaces, puede existir una ubicación de menú sin asignar, un bloque de navegación vacío, una plantilla incorrecta o una configuración del panel móvil que no contiene ningún elemento.
El menú aparece detrás del contenido
En este caso suele existir un problema de z-index, posicionamiento o contexto de apilamiento. El panel se abre, pero queda detrás del slider, de la imagen principal, de una cabecera fija o de otro bloque.
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 de aterrizaje, cabeceras transparentes, constructores visuales, sliders, formularios incrustados y scripts cargados únicamente en esas páginas.
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, editores visuales, plugins de depuración o herramientas de personalización.
El menú funciona en el personalizador, pero no en la web pública
Puede haber cambios sin publicar, caché desactualizada, diferencias entre la vista previa y el sitio público o una optimización aplicada solamente a visitantes.
El menú funciona en un navegador, pero no en otro
La causa puede estar en la caché del navegador, una extensión, una diferencia de compatibilidad, un error JavaScript específico o una versión antigua almacenada por un sistema de caché.
Primeras comprobaciones en WordPress
La revisión debe empezar por la configuración de WordPress y de la cabecera. Si el menú está mal asignado o la cabecera móvil está incompleta, cualquier análisis posterior será más confuso.
Identificar el sistema de navegación utilizado
Antes de buscar opciones, hay que determinar si la web utiliza:
- Menús clásicos gestionados desde Apariencia > Menús.
- Un constructor de cabecera incluido en el tema.
- El editor completo del sitio y el bloque Navegación.
- Una cabecera creada con Elementor, Divi, Bricks u otro constructor.
- Un plugin específico de menús o megamenús.
No todas las instalaciones muestran las mismas pantallas. En un tema de bloques puede no existir la sección clásica Apariencia > Menús.
Revisar ubicaciones de menú
Si la instalación utiliza menús clásicos, accede a Apariencia > Menús > Gestionar ubicaciones. Los nombres varían según el tema, pero pueden aparecer ubicaciones como:
- Menú principal.
- Navegación primaria.
- Menú móvil.
- Menú secundario.
- Menú fuera del lienzo.
- Menú de cabecera.
- Menú de pie de página.
Para una web sencilla, puede utilizarse el mismo menú tanto en escritorio como en móvil. Esto permite descartar rápidamente que el panel móvil esté vacío por falta de asignación.
Revisar que el menú tenga elementos
Entra en el menú asignado y comprueba que contiene enlaces reales, como Inicio, Servicios, Blog y Contacto. Un menú correctamente asignado pero sin elementos generará un panel vacío.
Revisar la cabecera móvil
Abre el personalizador, el constructor de cabeceras o el editor del sitio y cambia a la vista móvil. Comprueba que exista un activador de menú y que la navegación esté incorporada al área que debe abrirse.
Comprobar la visibilidad por dispositivo
Muchos constructores permiten ocultar elementos en escritorio, tableta o móvil. El menú puede estar correctamente creado, pero marcado por error como oculto en teléfonos.
Revisar el punto de ruptura responsive
El punto de ruptura determina cuándo desaparece el menú horizontal y aparece la hamburguesa. Una configuración incoherente puede hacer que el botón aparezca en un ancho en el que el panel todavía no está preparado o que ambos sistemas queden ocultos.
Guardar o publicar los cambios
Cuando se importa una web, se cambia de tema o se migra desde un entorno de pruebas a producción, puede haber estados guardados de forma incompleta. Conviene confirmar las asignaciones y pulsar Guardar cambios, Publicar o Actualizar, según el sistema utilizado.
Diferenciar si el fallo es de configuración, CSS, JavaScript o plantilla
Un diagnóstico profesional consiste en separar capas. No basta con decir que el menú no funciona. Hay que determinar qué parte del sistema está fallando.
Fallo de configuración
El menú no está asignado, el bloque de navegación está vacío, la cabecera móvil no contiene un componente de menú o el activador no está relacionado con el panel correcto.
Fallo de CSS
El menú se abre internamente, pero no se ve. Puede estar oculto por propiedades como:
display: none.visibility: hidden.opacity: 0.- Un
z-indexinsuficiente. - Un desplazamiento que lo coloca fuera de la pantalla.
- Un contenedor superior con
overflow: hidden. - Una transformación CSS que crea un contexto de apilamiento inesperado.
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, fragmentos personalizados, recursos no cargados o falta de inicialización del componente.
Fallo de plantilla
Algunas plantillas eliminan la cabecera normal o utilizan una cabecera distinta. Esto ocurre en páginas de aterrizaje, plantillas canvas, páginas creadas con constructores visuales o diseños importados.
Fallo de superposición
El botón puede existir, pero otro elemento transparente estar situado encima. El usuario cree que pulsa la hamburguesa, aunque el clic realmente llega a un slider, una capa decorativa, un contenedor vacío o una cabecera duplicada.
Fallo de caché u optimización
La configuración puede estar corregida en WordPress, pero el visitante sigue recibiendo una versión antigua del HTML, CSS o JavaScript. También puede haberse generado una combinación de scripts incompatible con la versión actual del tema.
Diagnóstico con DevTools del navegador
Las herramientas de desarrollo del navegador son esenciales, pero deben usarse con orden. Ejecutar comandos sin interpretar su resultado puede generar más confusión que información.
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. La administración de WordPress utiliza scripts y estilos diferentes.
Activar la simulación móvil
Abre DevTools y activa la barra de dispositivos. Selecciona un ancho móvil o reduce manualmente la ventana. Después recarga la página para permitir que todos los componentes responsive se inicialicen en ese ancho.
Probar también en un teléfono real
La simulación del navegador es útil, pero no reproduce exactamente todos los eventos táctiles ni el comportamiento de los navegadores móviles. Cuando sea posible, conviene repetir la prueba en un teléfono real.
Comparar administrador y visitante
Si el fallo se ha observado estando conectado como administrador, conviene empezar en esas condiciones. Después puede repetirse en una ventana privada como visitante. Esta comparación ayuda a detectar recursos o capas que solo aparecen para usuarios autenticados.
Revisar la consola
Abre la pestaña Console, recarga la página y pulsa el botón hamburguesa. Los errores rojos pueden indicar que un script ha interrumpido la ejecución, aunque no todos los avisos están relacionados con el menú.
Hay que fijarse especialmente en errores como:
Uncaught TypeError.Uncaught ReferenceError.Unexpected token.Cannot read properties of null.- Recursos JavaScript que devuelven códigos 404 o 500.
Revisar la pestaña Network
En Network, marca Disable cache, recarga la página y filtra por JS. Comprueba si algún archivo del tema, del constructor de cabecera o de WordPress no se carga correctamente.
También puede filtrarse por términos relacionados con el tema activo, como:
astra.blocksy.kadence.generatepress.neve.oceanwp.elementor.navigation.frontend.
Inspeccionar el botón
Utiliza el selector de elementos de DevTools y pulsa sobre el botón hamburguesa. Comprueba:
- Qué etiqueta HTML utiliza.
- Qué clases CSS tiene.
- Si contiene atributos
aria-controlsoaria-expanded. - Si está realmente por encima de otros elementos.
- Si tiene aplicado
pointer-events: none. - Si existe más de un botón similar en la página.
Comprobaciones JavaScript útiles
Los selectores exactos cambian entre temas. Por eso, antes de ejecutar comandos específicos, conviene inspeccionar el botón y copiar una clase o atributo que realmente exista en el HTML de la página.
Localizar posibles botones de navegación
document.querySelectorAll(
'button[aria-controls], button[aria-expanded], .menu-toggle, .mobile-menu-toggle, .nav-toggle'
)Este comando busca varios patrones habituales. Si devuelve varios elementos, hay que inspeccionarlos para identificar cuál corresponde a la cabecera visible.
Seleccionar un botón concreto
Después de conocer su clase real, puede utilizarse un selector específico:
const botonMenu = document.querySelector('.clase-real-del-boton');
botonMenuSi devuelve un elemento HTML, el botón existe. Si devuelve null, el selector es incorrecto o el componente todavía no se ha generado.
Comprobar aria-expanded
botonMenu?.getAttribute('aria-expanded')Antes de pulsar, lo habitual es que devuelva false. Después de pulsar, muchos sistemas lo cambian a true. No todos los temas utilizan este atributo, pero cuando existe resulta muy útil.
Comprobar aria-controls
botonMenu?.getAttribute('aria-controls')Este atributo puede contener el identificador del panel controlado por el botón. Si devuelve, por ejemplo, mobile-navigation, puede localizarse el contenedor con:
const idPanel = botonMenu?.getAttribute('aria-controls');
const panelMenu = idPanel
? document.getElementById(idPanel)
: null;
panelMenuSi el botón apunta a un identificador que no existe en el documento, la estructura de la cabecera está incompleta o contiene identificadores incoherentes.
Comprobar cambios de clase
Algunos temas no dependen únicamente de aria-expanded. Puede observarse si cambian las clases del botón, del panel o del elemento <body>:
console.log('Botón:', botonMenu?.className);
console.log('Panel:', panelMenu?.className);
console.log('Body:', document.body.className);Ejecuta el comando antes y después de pulsar. Si las clases cambian, el JavaScript está respondiendo y el problema puede ser visual.
Comprobar si existe jQuery
typeof window.jQueryAlgunos temas y plugins todavía dependen de jQuery, mientras que otros utilizan JavaScript nativo. Que jQuery devuelva undefined no es necesariamente un error. Solo resulta relevante si el tema o algún componente concreto lo necesita.
Comprobar si el clic llega al botón
botonMenu?.addEventListener('click', function () {
console.log('El clic ha llegado al botón del menú');
});Después de ejecutar el código, pulsa el botón. Si aparece el mensaje, el clic llega al elemento. Si no aparece, puede existir una capa superpuesta, un botón duplicado o un problema con los eventos.
Identificar el elemento situado bajo el cursor
En una prueba desde escritorio con simulación móvil, puede utilizarse:
document.elementFromPoint(30, 30)Las coordenadas deben adaptarse a la posición del botón. Este comando ayuda a comprobar si otro elemento está situado encima de la hamburguesa.
Evitar selectores escritos incorrectamente
Este comando busca una etiqueta HTML llamada <menu-toggle>:
document.querySelector('menu-toggle')Para buscar una clase CSS debe añadirse un punto:
document.querySelector('.menu-toggle')Para buscar un identificador debe utilizarse una almohadilla:
document.querySelector('#mobile-menu')Comprobaciones CSS y problemas de superposición
Si el botón cambia de estado, pero el menú no aparece, es probable que JavaScript esté funcionando y que el problema sea visual.
Consultar los estilos calculados del panel
panelMenu
? {
display: getComputedStyle(panelMenu).display,
visibility: getComputedStyle(panelMenu).visibility,
opacity: getComputedStyle(panelMenu).opacity,
position: getComputedStyle(panelMenu).position,
zIndex: getComputedStyle(panelMenu).zIndex,
transform: getComputedStyle(panelMenu).transform
}
: 'Panel no localizado';Comprobar las dimensiones del panel
panelMenu?.getBoundingClientRect()Si el ancho o el alto son cero, el menú puede estar abierto internamente pero sin dimensiones visibles. Si las coordenadas están fuera de la ventana, puede existir una transformación o un posicionamiento incorrecto.
Revisar el z-index
Un slider, una imagen principal, una barra fija o un aviso de cookies pueden quedar por encima del panel. No basta con aumentar el z-index sin entender la estructura, porque los contextos de apilamiento dependen también de propiedades como position, transform, opacity y filter.
Revisar overflow
Si un contenedor padre tiene overflow: hidden, puede recortar un menú desplegable o lateral. Hay que recorrer los elementos superiores desde DevTools hasta encontrar cuál limita el panel.
Revisar pointer-events
Si el botón o alguno de sus contenedores tiene pointer-events: none, será visible pero no podrá recibir interacción.
Comprobar capas invisibles
Los constructores visuales pueden generar columnas, separadores o contenedores transparentes que ocupan más espacio del esperado. Una capa invisible situada sobre la cabecera puede bloquear todos los clics sin resultar evidente visualmente.
Comprobaciones con WP-CLI
WP-CLI permite revisar el estado real de temas, plugins y opciones 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.
Identificar el tema activo
sudo -u www-data wp theme list --status=active --path=/var/www/miempresa.comAntes de utilizar comandos específicos de un tema, hay que confirmar cuál está activo y si existe un tema hijo.
Listar todos los temas
sudo -u www-data wp theme list --path=/var/www/miempresa.comEl resultado permite comprobar versiones, actualizaciones disponibles y posibles temas padre asociados a un tema hijo.
Actualizar el tema activo
Después de identificar el slug real del tema, puede actualizarse con:
sudo -u www-data wp theme update slug-del-tema --path=/var/www/miempresa.comPor ejemplo, para Astra:
sudo -u www-data wp theme update astra --path=/var/www/miempresa.comPara Blocksy:
sudo -u www-data wp theme update blocksy --path=/var/www/miempresa.comReinstalar un tema desde el repositorio
sudo -u www-data wp theme install slug-del-tema --force --path=/var/www/miempresa.comEste comando sustituye los archivos del tema por una copia limpia. No borra páginas, entradas ni menús, pero antes de usarlo en producción conviene disponer de una copia de seguridad.
La reinstalación solo resulta apropiada cuando el tema procede del repositorio oficial y su slug se conoce con certeza. Los temas comerciales pueden requerir un archivo ZIP o su propio sistema de actualización.
Listar plugins
sudo -u www-data wp plugin list --path=/var/www/miempresa.comEl listado permite localizar plugins de caché, optimización, snippets, constructores visuales, megamenús o extensiones asociadas al tema.
Desactivar un plugin de forma controlada
sudo -u www-data wp plugin deactivate slug-del-plugin --path=/var/www/miempresa.comEs preferible desactivar un plugin, probar el menú y registrar el resultado antes de continuar con el siguiente.
Activar de nuevo un plugin
sudo -u www-data wp plugin activate slug-del-plugin --path=/var/www/miempresa.comVaciar la caché interna de WordPress
sudo -u www-data wp cache flush --path=/var/www/miempresa.comEste comando no siempre limpia la caché del servidor, de la CDN, del navegador o de plugins especializados, pero resulta útil durante las pruebas.
Comprobar la dirección del sitio
sudo -u www-data wp option get home --path=/var/www/miempresa.com
sudo -u www-data wp option get siteurl --path=/var/www/miempresa.comDespués de una migración, una incoherencia entre estas direcciones puede provocar cargas incorrectas de recursos o referencias al dominio antiguo.
Buscar referencias a un dominio anterior
sudo -u www-data wp search-replace \
'https://sandbox.miempresa.com'
'https://miempresa.com'
--all-tables-with-prefix
--dry-run
--path=/var/www/miempresa.comLa opción --dry-run permite comprobar cuántos cambios se realizarían sin modificar la base de datos.
Plugins, caché y conflictos habituales
Cuando un menú móvil no abre, los plugins más sospechosos suelen ser los que modifican scripts, cabeceras, caché, diseño o interacción.
Plugins de optimización
Los plugins que minifican, combinan, difieren o retrasan JavaScript pueden impedir que el tema o el constructor inicialicen correctamente el menú. Durante el diagnóstico conviene desactivar temporalmente opciones como:
- Combinar archivos JavaScript.
- Diferir JavaScript.
- Retrasar JavaScript hasta la primera interacción.
- Minificar JavaScript.
- Eliminar recursos considerados no utilizados.
- Cargar scripts de forma asíncrona.
- Optimizar o combinar CSS.
Plugins de caché
Una caché antigua puede entregar HTML que corresponde a una configuración y JavaScript que corresponde a otra. Hay que limpiar todas las capas relevantes:
- Caché del plugin.
- Caché de objetos.
- Caché del servidor.
- Caché de la CDN.
- Caché del navegador.
Plugins de snippets
Herramientas como WPCode, Code Snippets o plugins para insertar código en la cabecera y el pie pueden introducir errores JavaScript. Un fragmento mal pegado puede generar mensajes como Unexpected token '<', especialmente cuando se introduce HTML dentro de un bloque JavaScript.
Constructores visuales
Elementor, Divi, Bricks y otros constructores pueden sustituir la cabecera del tema. También pueden cargar una cabecera distinta según la página, el dispositivo, el estado de conexión o determinadas condiciones de visualización.
Plugins de megamenú
Un plugin de megamenú puede reemplazar parcialmente el funcionamiento nativo del tema. Hay que comprobar si el menú móvil está controlado por el tema, por el plugin o por ambos al mismo tiempo.
Plugins de formularios externos
Los formularios incrustados pueden cargar scripts propios. Si el fallo solo aparece en la página de contacto, hay que revisar el código de inserción y los errores generados por el servicio externo.
Plugins de sliders
Un slider puede crear capas superpuestas, capturar gestos táctiles o utilizar un z-index elevado. Si el menú falla únicamente en la portada, conviene comprobar si el slider está situado sobre la cabecera o sobre el panel abierto.
Plugins de consentimiento
Los sistemas de consentimiento pueden bloquear scripts hasta que el usuario acepta determinadas categorías. Los scripts esenciales para la navegación no deberían clasificarse como analíticos, publicitarios o opcionales.
Plugins de seguridad
Algunos plugins de seguridad modifican cabeceras, políticas de contenido o carga de recursos. Una política demasiado restrictiva puede bloquear archivos necesarios para el tema o el constructor.
Constructores de cabecera, menús desplegables y paneles laterales
Los temas modernos suelen separar la configuración de escritorio, tableta y móvil. No basta con crear un menú: también es necesario incorporarlo a la cabecera adecuada y configurar el elemento que lo abre.
No confundir el menú con la cabecera
El menú contiene enlaces y jerarquías. La cabecera decide dónde se muestra, en qué dispositivos, mediante qué botón y con qué comportamiento.
Un menú puede estar correctamente creado y asignado, pero la cabecera móvil puede no contener el componente que debe mostrarlo.
Revisar todas las filas de la cabecera
Algunos temas permiten utilizar filas superiores, principales e inferiores. El activador puede estar en una fila y el panel asociado en otra. También puede existir una cabecera diferente para móvil.
Revisar el panel fuera del lienzo
El panel fuera del lienzo suele contener elementos independientes: navegación, buscador, iconos sociales, botones o texto. Si la hamburguesa abre el panel pero no aparecen enlaces, hay que comprobar que el componente de navegación se haya añadido al interior.
Probar un comportamiento sencillo
Cuando un panel lateral complejo da problemas, puede configurarse temporalmente un menú desplegable simple. Si el desplegable funciona, el problema estará relacionado con el modo fuera del lienzo, la capa superpuesta o su animación.
Revisar cabeceras transparentes o fijas
Las cabeceras transparentes y adhesivas suelen aplicar estilos adicionales. Puede existir una configuración para la cabecera normal y otra para la cabecera fija. Si el fallo aparece después de desplazarse por la página, hay que inspeccionar la versión adhesiva.
Comprobar condiciones de visualización
Los constructores permiten aplicar cabeceras según página, categoría, tipo de contenido, usuario o dispositivo. Una condición mal definida puede cargar dos cabeceras simultáneamente o dejar una página sin la cabecera esperada.
Comprobar cabeceras duplicadas
Si el tema genera una cabecera y el constructor visual genera otra, ambas pueden coexistir. Aunque una esté aparentemente oculta, puede conservar elementos transparentes que bloqueen la interacción.
Menús creados con el editor del sitio y bloques
En los temas de bloques, la navegación puede gestionarse desde Apariencia > Editor. El procedimiento cambia respecto a los menús clásicos, pero las mismas capas siguen estando presentes.
Revisar la parte de plantilla de cabecera
Dentro del editor del sitio, abre la cabecera activa y localiza el bloque Navegación. Comprueba que contenga enlaces y que no haya sido eliminado de la versión móvil.
Revisar la plantilla aplicada
Una página puede utilizar una plantilla diferente con otra cabecera. Si el menú falla solo en determinadas páginas, hay que comprobar qué plantilla está asignada a cada una.
Revisar el modo de superposición
El bloque Navegación puede mostrar un menú superpuesto en pantallas pequeñas. Hay que comprobar su configuración responsive y si el icono de apertura está visible.
Revisar estilos globales y CSS adicional
Los estilos globales pueden afectar al bloque de navegación, a los botones y a las capas superpuestas. Un CSS añadido para la cabecera de escritorio puede ocultar accidentalmente el panel móvil.
Guardar los cambios del editor
El editor del sitio puede requerir guardar varias entidades, como la plantilla, la parte de plantilla y los estilos. Conviene revisar el resumen de cambios antes de salir.
Configuración interna y opciones de base de datos
Parte de la configuración de los temas clásicos se almacena en opciones conocidas como theme mods. El nombre depende del tema activo.
Identificar la plantilla activa
sudo -u www-data wp option get template --path=/var/www/miempresa.com
sudo -u www-data wp option get stylesheet --path=/var/www/miempresa.comtemplate suele identificar el tema padre y stylesheet el tema activo, que puede ser un tema hijo.
Consultar los ajustes del tema
La opción suele seguir el formato:
theme_mods_SLUG_DEL_TEMAPor ejemplo:
sudo -u www-data wp option get theme_mods_astra \
--format=json
--path=/var/www/miempresa.comEn otro tema, el nombre de la opción será diferente. No debe suponerse sin comprobar primero el slug correspondiente.
Interpretar los datos con prudencia
Que una opción tenga pocos datos no significa automáticamente que esté dañada. Algunos temas guardan parte de la configuración en opciones adicionales, tipos de contenido, metadatos o estructuras propias.
No borrar ajustes como primera prueba
Un comando como este puede eliminar gran parte de la configuración visual:
sudo -u www-data wp option delete theme_mods_SLUG_DEL_TEMA \
--path=/var/www/miempresa.comLa eliminación puede afectar a cabecera, pie, colores, tipografías, anchos, widgets, logotipo, blog y ubicaciones de menú. No debe ejecutarse en producción sin copia de seguridad y sin entender exactamente qué se perderá.
Hacer una copia antes de cambios delicados
sudo -u www-data wp db export \
/var/backups/miempresa-antes-menu-movil.sql
--path=/var/www/miempresa.comLa ruta de copia debe existir y ser accesible para el usuario que ejecuta el comando.
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.
Buscar únicamente opciones de Astra
Los nombres utilizados por Astra no son universales. Blocksy, Kadence, GeneratePress, Neve, OceanWP y los constructores visuales utilizan estructuras y selectores diferentes. Primero hay que identificar qué sistema genera realmente la cabecera.
Usar selectores copiados de otro tema
Que un tutorial utilice .menu-toggle no significa que esa clase exista en todas las webs. El selector correcto debe obtenerse inspeccionando el HTML real.
Mirar la pantalla equivocada
Analizar recursos de /wp-admin/themes.php no sirve para saber qué scripts carga la portada pública. El diagnóstico debe realizarse en la URL donde ocurre el fallo.
Asumir que todo error rojo es la causa
Un error de consola puede ser relevante o no. Hay que comprobar cuándo aparece, qué archivo lo genera y si realmente interrumpe el código relacionado con la navegación.
Desactivar todos los plugins a la vez
Desactivar todo puede indicar que existe un conflicto, pero no permite identificar qué componente lo causa. Es mejor trabajar por grupos y registrar cada resultado.
No limpiar todas las cachés
Vaciar únicamente la caché de WordPress puede ser insuficiente cuando existe caché de página, servidor, CDN, navegador u optimización de archivos.
Confundir un fallo de JavaScript con uno de CSS
Si el estado del botón cambia y el panel recibe nuevas clases, seguir buscando exclusivamente errores JavaScript puede hacer perder tiempo. En ese momento deben revisarse visibilidad, dimensiones, posición y capas.
Resetear el tema demasiado pronto
Restablecer o borrar las opciones del tema puede destruir una configuración visual que después habrá que reconstruir. Debe ser una medida final y realizarse primero en un entorno de pruebas.
Probar solo en el personalizador
La vista previa no reproduce siempre la caché, optimización y condiciones de la página pública. El resultado debe verificarse también como visitante.
No documentar los cambios
Si se modifican varias opciones sin registrar qué se ha hecho, resulta difícil saber qué cambio solucionó el problema o cómo volver al estado inicial.
Procedimiento recomendado de resolución
El siguiente orden de trabajo reduce el riesgo y evita realizar cambios destructivos antes de disponer de un diagnóstico.
Fase 1: identificar el síntoma exacto
- Comprobar si aparece el botón hamburguesa.
- Comprobar si el botón recibe el clic.
- Comprobar si cambia el icono o el atributo
aria-expanded. - Comprobar si el panel se genera, aunque no sea visible.
- Comprobar si ocurre en todas las páginas o solo en algunas.
- Comprobar si el fallo afecta a visitantes, usuarios autenticados o únicamente a determinados perfiles de usuario.
- Comparar el resultado como visitante y como administrador.
- Probar en otro navegador y, cuando sea posible, en un móvil real.
Fase 2: identificar quién genera la cabecera
- Confirmar el tema activo.
- Comprobar si existe un tema hijo.
- Determinar si la cabecera procede del tema, del editor del sitio o de un constructor visual.
- Comprobar si hay un plugin de megamenú.
- Comprobar si existen varias cabeceras con condiciones diferentes.
Fase 3: revisar la configuración de WordPress
- Identificar qué sistema de navegación utiliza el sitio (menús clásicos, editor del sitio o constructor visual).
- Identificar todas las ubicaciones de menú disponibles en el tema.
- Comprobar qué menú está asignado a cada ubicación.
- Revisar específicamente el menú principal.
- Revisar el menú secundario, si existe.
- Comprobar la configuración del menú móvil o del menú fuera del lienzo.
- Si existe un menú para usuarios conectados, verificar que tenga un menú asignado y que funcione correctamente.
- Comprobar que todos los menús contienen enlaces válidos.
- Revisar la cabecera en vista móvil.
- Comprobar que el botón hamburguesa está asociado al panel de navegación correcto.
- Verificar la visibilidad de los elementos en escritorio, tableta y móvil.
- Guardar o publicar los cambios antes de continuar con el diagnóstico.
Fase 4: revisar el navegador
- Recargar con la caché desactivada.
- Revisar la consola.
- Revisar archivos JavaScript que no cargan.
- Inspeccionar el botón real.
- Comprobar
aria-expandedyaria-controls. - Comprobar cambios de clases al pulsar.
- Comprobar si una capa bloquea el clic.
Fase 5: diferenciar JavaScript y CSS
- Si no cambia ningún estado, investigar JavaScript e inicialización.
- Si cambia el estado pero no se ve el menú, investigar CSS.
- Revisar
display,visibility,opacityy dimensiones. - Revisar
z-index, contextos de apilamiento yoverflow.
Fase 6: limpiar caché y desactivar optimizaciones
- Limpiar la caché del plugin.
- Limpiar la caché del servidor y de la CDN.
- Desactivar temporalmente combinación, retraso y diferido de JavaScript.
- Probar en una ventana privada.
Fase 7: aislar plugins
- Desactivar primero plugins de optimización y caché.
- Después plugins de snippets.
- Después plugins de megamenú.
- Después constructores o extensiones de cabecera, cuando sea viable.
- Después formularios, sliders y otros componentes cargados en la página afectada.
- Probar después de cada cambio.
Fase 8: revisar el tema
- Actualizar el tema y sus extensiones.
- Reinstalar los archivos del tema si se sospecha que están dañados.
- Revisar modificaciones del tema hijo.
- Probar temporalmente un tema estándar en un sandbox.
- Comprobar si el fallo desaparece con una cabecera mínima.
Fase 9: revisar migraciones y configuración interna
- Confirmar las opciones
homeysiteurl. - Buscar referencias al dominio anterior.
- Comprobar que las ubicaciones de menú se han conservado tras la migración.
- Verificar que cada ubicación (principal, secundaria, móvil, fuera del lienzo, usuarios conectados y pie de página, si existen) sigue teniendo un menú asignado.
- Revisar las opciones internas del tema sin modificarlas ni eliminarlas.
- Comprobar que la cabecera activa sigue siendo la prevista y que no se ha sustituido por otra durante la migración o el cambio de tema.
- Si existe un tema hijo, comprobar que sigue siendo compatible con la versión actual del tema padre.
Fase 10: trabajar en un entorno de pruebas
Si las comprobaciones reversibles no resuelven el problema, lo apropiado es clonar la web a un entorno sandbox. Allí pueden probarse cambios de tema, eliminación de opciones, reconstrucción de cabeceras y desactivaciones más amplias sin afectar a los visitantes.
Buenas prácticas para evitar el problema
Los problemas de navegación móvil suelen aparecer después de importaciones, migraciones, cambios de tema, instalación de plantillas, modificaciones de cabecera o activación de optimizadores.
Trabajar primero en un sandbox
Los cambios de cabecera, tema y estructura visual deberían probarse en un entorno de pruebas. Después se trasladan a producción de forma controlada.
No editar directamente los archivos del tema
Las modificaciones deben realizarse mediante un tema hijo, un plugin específico o mecanismos compatibles con las actualizaciones. Editar directamente el tema complica el mantenimiento y el diagnóstico.
Evitar cabeceras duplicadas
Si se utiliza un constructor visual para crear la cabecera, hay que desactivar o sustituir correctamente la cabecera nativa del tema. Dos cabeceras simultáneas pueden provocar solapamientos e interacciones inesperadas.
Documentar los snippets
Todo fragmento añadido a la cabecera o al pie debe incluir una descripción, una fecha y su finalidad. Un script olvidado puede convertirse meses después en el origen de un error difícil de localizar.
Aplicar optimizaciones de forma gradual
Antes de activar minificación, combinación, diferido o retraso de scripts, hay que comprobar que la navegación, formularios, sliders y otros elementos interactivos funcionan correctamente.
Excluir scripts esenciales cuando sea necesario
Si una opción de retraso de JavaScript rompe el menú, puede ser necesario excluir los archivos del tema, del constructor o de la navegación. La exclusión debe basarse en los archivos realmente utilizados, no en nombres copiados de otra web.
Comprobar la versión móvil después de cada cambio
Una modificación puede no afectar al escritorio y romper únicamente la navegación móvil. Después de actualizar temas, plugins o estilos, conviene probar varios anchos de pantalla.
Mantener copias de seguridad
Antes de actualizar temas, modificar cabeceras o actuar sobre opciones internas, debe existir una copia recuperable de archivos y base de datos.
Actualizar con control
Mantener WordPress, el tema y los plugins actualizados es importante, pero conviene revisar la web después de cada actualización, especialmente la navegación, los formularios y las páginas principales.
Preguntas frecuentes
¿Este procedimiento sirve únicamente para Astra?
No. Se puede aplicar a Astra, Blocksy, Kadence, GeneratePress, Neve, OceanWP, Hello Elementor, temas de bloques y cabeceras creadas con constructores visuales. Los nombres de las opciones y los selectores cambian, pero las capas que deben revisarse son similares.
¿Por qué aparece el botón hamburguesa pero no se abre el menú?
Porque la parte visual responsive puede estar funcionando mientras falla el JavaScript, la configuración móvil, la relación con el panel, el contenedor de navegación o la recepción del clic.
¿Cómo sé si el problema es de JavaScript o de CSS?
Si al pulsar no cambia aria-expanded, no se añaden clases y no cambia ningún estado, probablemente exista un problema de JavaScript o inicialización. Si el estado cambia, pero el panel no se ve, es más probable que el problema sea de CSS, dimensiones, posición o capas.
¿Debo buscar siempre la clase menu-toggle?
No. .menu-toggle es solo una clase habitual. Cada tema o constructor puede utilizar otras clases. Hay que inspeccionar el botón real de la página y utilizar el selector que exista en su HTML.
¿Puede el botón estar funcionando aunque no aparezca el menú?
Sí. El botón puede cambiar atributos y clases correctamente, mientras el panel permanece oculto por display, opacity, visibility, un desplazamiento, un z-index insuficiente o un contenedor con overflow: hidden.
¿El problema suele ser del tema o de un plugin?
Puede proceder de cualquiera de los dos. Si desaparece al desactivar la optimización, la caché, los snippets o un plugin de megamenú, existe un conflicto con un plugin. Si continúa con una instalación mínima, hay que revisar el tema, la cabecera, la plantilla y la configuración interna.
¿Puede un slider impedir que se pulse el menú?
Sí. Un slider puede crear una capa transparente sobre la cabecera, capturar eventos táctiles o utilizar un z-index elevado. Es una posibilidad especialmente relevante cuando el fallo solo aparece en la portada.
¿Puede un plugin de cookies romper la navegación?
Sí, si bloquea por error scripts esenciales del tema o del constructor. La navegación debe considerarse funcionalmente necesaria y no debería depender de que el visitante acepte cookies opcionales.
¿Conviene borrar la opción theme_mods del tema?
No como primera medida. Esa opción puede contener la configuración de la cabecera, el pie, los colores, las tipografías, el logotipo y las ubicaciones de menú. Solo debe eliminarse con copia de seguridad, preferiblemente en un entorno de pruebas y conociendo las consecuencias.
¿Es suficiente reinstalar el tema?
La reinstalación puede corregir archivos dañados, pero no solucionará necesariamente una configuración incoherente, una caché antigua, un conflicto de plugins, un error de CSS o una cabecera creada por un constructor externo.
¿Debo probar como administrador o como visitante?
Conviene probar en ambas situaciones. Si el problema solo aparece como administrador, puede estar relacionado con la barra de administración, el editor visual o recursos cargados para usuarios autenticados. Si solo aparece como visitante, hay que revisar caché, consentimiento y optimización.
¿Por qué funciona en el personalizador, pero no en la web pública?
La vista previa puede utilizar recursos sin optimizar, ignorar ciertas cachés o mostrar cambios todavía no publicados. La página pública puede estar entregando una versión anterior del HTML, CSS o JavaScript.
¿Puede una migración romper el menú móvil?
Sí. Una migración puede dejar ubicaciones de menú sin asignar, referencias al dominio anterior, opciones serializadas incorrectas, cachés antiguas o archivos incompletos. Por eso conviene revisar tanto la configuración como la carga de recursos.
¿Qué significa que aria-expanded no cambie al pulsar?
Cuando el botón utiliza ese atributo, que permanezca en false suele indicar que la lógica de apertura no se está ejecutando. Puede deberse a falta de inicialización, un error JavaScript, un elemento superpuesto o una estructura HTML incoherente.
¿Cuál es la forma más segura de investigar una web en producción?
La opción más segura es hacer una copia, clonar la web en un sandbox y reproducir allí el problema. En producción deberían limitarse las pruebas a acciones reversibles, como inspeccionar el navegador, revisar configuraciones, limpiar caché y desactivar temporalmente componentes no críticos.