El menú móvil de la web WordPress del evento no abre: diagnostica la ruta publicada

1. Registra el fallo y conserva un acceso directo

Descargar hoja de síntomas y publicación del menú móvil (Markdown, en inglés)

Abre la URL pública exacta en un teléfono real, sin iniciar sesión. Desde una carga nueva, anota si falta el icono, falla el primer toque, el panel queda detrás del contenido o no se puede abrir un submenú. Registra dispositivo, navegador, página, ancho, hora y si el problema aparece al desplazar. Repite en otra página con la misma cabecera. La vista del editor y la de escritorio no demuestran el resultado público.

Mantén nombre, fecha, recinto y acceso a entradas mediante un enlace de texto directo en la página afectada o una ruta alternativa aprobada. Comprueba que lleva al evento actual y no a una edición anterior. Conserva una captura y la última hora conocida de funcionamiento; no publiques cambios de navegación sin revisión para salvar un solo enlace.

2. Identifica quién controla la cabecera

Averigua si la cabecera usa el bloque Navegación de WordPress, una ubicación de menú del tema clásico, un widget Elementor o un complemento propio. Los controles son diferentes. En un tema de bloques revisa el bloque, el menú elegido y la superposición. En uno clásico revisa el menú asignado a la ubicación del tema. En Elementor identifica la cabecera publicada y el widget exacto antes de usar sus controles.[1][2][3]

Anota tema, constructor, versiones, plantilla, asignación y último cambio. Si falla solo una página, compara plantillas y condiciones de visualización antes de editar el menú global. Puede existir una estructura correcta con una cabecera equivocada en una página. Guarda configuración actual y vía de recuperación; no modifiques varios sistemas a la vez.[1][2][3]

3. Si falta el botón, revisa visibilidad y asignación

Si no hay icono, compara teléfono vertical, tableta y un ancho algo mayor. Puede ocultarlo un punto de ruptura, una regla adaptable o una cabecera distinta. El bloque Navegación tiene un ajuste de superposición, con opciones propias «Móvil» y «Siempre». Elementor ofrece visibilidad adaptable y puntos de ruptura en sus elementos y widgets. Revisa el componente realmente utilizado.[1][4]

Si la ausencia es intencional, asegura otra ruta visible a las secciones del evento. Si debería aparecer, prueba en un entorno de pruebas una corrección concreta de visibilidad o asignación. Evita CSS global que muestre todo lo oculto: puede duplicar cabeceras y esconder el verdadero error. Repite en horizontal y con zoom.[1][4]

4. Si el botón no responde, examina la primera interacción

Si el icono se ve pero el primer toque falla, compara primer y segundo toque y prueba tras desplazar. Examina la página pública sin sesión; un banner o elemento transparente puede tapar el botón. Anota el gesto exacto y, si no contiene datos de asistentes, una grabación breve.

Pide al responsable que revise consola y solicitudes de scripts fallidas en la misma página. Una dependencia ausente o un error anterior puede impedir el menú. No deduzcas la causa de una sola alerta, añadas otro script ni actualices complementos a ciegas. Si solo cambió un ajuste de rendimiento, aísla la hipótesis en pruebas, sin desactivar pagos, formularios ni seguridad en vivo.

5. Si el panel abre mal, revisa recorte y submenús

Si el panel queda detrás o recortado, inspecciona el contenedor de cabecera, el desbordamiento y el orden de capas. Aumentar la capa del panel no resuelve un padre que recorta. Compara antes y después de desplazar; una cabecera fija puede alterar el contenedor. Corrige el control responsable en pruebas y verifica que la información esencial sigue accesible.[6]

Prueba enlace principal y submenú por separado. Algunas interfaces usan la etiqueta como enlace y una flecha para expandir; otras usan la etiqueta como control. Pasar el cursor en escritorio no demuestra el toque móvil. Programa, recinto y entradas deben alcanzarse con tacto y teclado, con foco visible y cierre posible.[6]

6. Compara la página publicada y las cachés

El editor conectado, la vista previa y el móvil público pueden recibir archivos distintos. Compara la URL exacta sin sesión y desde otra red. WP Rocket documenta que Delay JavaScript Execution retrasa scripts en páginas guardadas u optimizadas hasta una interacción. Es una pista condicional, no prueba de que ese complemento cause el fallo.[5]

En una copia protegida, guarda la configuración y cambia una opción relevante. Si el menú revive, identifica el script necesario y usa la exclusión más pequeña admitida; restaura optimizaciones ajenas. No dejes exclusiones generales ni consideres una purga total como reparación. Si la cabecera pública es antigua, compara versión y capa de caché antes de refrescarla.[5]

7. Haz una corrección controlada en pruebas

Escribe síntoma, componente, evidencia, cambio propuesto y vuelta atrás en la hoja. Obtén aprobación del responsable. Reproduce el fallo en pruebas, cambia una sola cosa y repite allí. Si requiere actualizar tema, constructor o complemento, confirma compatibilidad y recuperación antes. Evita ensayos en producción si la cabecera se comparte con compra, registro o soporte.

Compara la página que funciona con la que fallaba. La corrección debe conservar estructura y destinos, no solo hacer visible el icono. Comprueba que las entradas no dirigen a una campaña antigua. Si falla el cambio, recupera el estado de pruebas y entrega las pruebas al responsable; no acumules CSS y scripts.

8. Comprueba la ruta completa tras publicar

Tras publicar, repite la prueba original en teléfono real, carga nueva y sin sesión. El primer toque debe abrir; cerrar y reabrir deben funcionar y devolver el desplazamiento. Sigue un enlace principal, abre submenú y visita entradas, programa, recinto y ayuda actuales. Repite en otra página, tras desplazar, en ancho estrecho, horizontal y con zoom.[6]

Con teclado, alcanza el control, abre, sigue un enlace y cierra sin perder el foco visible ni quedar atrapado. Comprueba la versión pública en caché, no solo el editor. Registra URL, dispositivo, navegador, hora, cambio, responsable y resultado. Si persiste el fallo, conserva el enlace directo y reabre la incidencia con evidencia precisa.[6]