If your WordPress mobile menu is not working, first check whether its links are missing or the button cannot reveal them. Missing links point you towards menu selection and the header template. Links already present in the page point you towards the toggle, scripts, CSS or an element covering the button. Record the symptom before changing settings.
If visitors cannot reach your enquiry, booking or product pages, request a diagnosis of the broken menu with the affected URL, device and last change. That gives the repair assessment a concrete starting point.
Start with the symptom you can reproduce
- The links are missing everywhere: inspect the selected menu and the header used on that page.
- The desktop menu works but the mobile button does nothing: check the first browser error and whether the navigation script loaded.
- The button changes state but the links stay hidden: inspect the container it controls and the CSS at that screen width.
- The menu opens and immediately closes: trace the existing events before adding another handler.
- It fails in one language or only for logged-out visitors: compare the header, menu selection and cached response for those exact conditions.
Define the failure
Record page, viewport/device, logged-in state, language and whether the menu is absent, wrong, visually hidden or does not open.
Compare desktop and mobile markup. Test keyboard activation as well as touch/click.
Capture:
menu location/name
toggle element/ARIA state
first Console error
loaded theme navigation script
overlay/stacking context
cache status
Avoid screenshots containing private menu items.
Check WordPress menu assignment
In Appearance > Menus or Site Editor, confirm the intended menu/navigation block is assigned to the theme location for each language.
A theme update can rename locations; switching themes can leave the old assignment orphaned. Do not delete the menu merely because its location is unassigned.
Export/screenshot structure before changing complex menus.
Inspect rendered markup
View source/Elements. If links are absent, investigate WordPress location/template/block data. If present, inspect CSS and JavaScript.
Check duplicate IDs, missing button target and whether the toggle controls the correct menu container:
<button type="button" aria-controls="site-navigation" aria-expanded="false">Menu</button>
<nav id="site-navigation">...</nav>
Labels and focus behaviour must remain accessible.
Read the first JavaScript error
Open Console, reload and activate once. An earlier error from optimisation, consent, slider or theme code can stop menu initialisation.
Verify the navigation script returns 200 and correct content type. A cached old script may expect markup from the previous theme version.
Do not add a second click handler until the original event path is understood; double handlers can immediately open and close the menu.
Check overlays and CSS
Cookie banners, chat widgets, sticky headers and transparent elements can intercept taps. Use the element picker and computed z-index, pointer-events, overflow and positioning.
Test with keyboard focus. Avoid arbitrary maximum z-index values or disabling pointer events on consent controls.
Check media-query breakpoints and browser zoom; a menu can be hidden at intermediate widths.
Review block-theme navigation
Navigation blocks store menu/entity data differently from classic menus. Confirm the header template part contains the intended navigation and that changes were saved/published.
Compare customised database template with the updated theme file. Export before resetting.
Reusable patterns/synced blocks may update several pages; test scope before editing.
Check multilingual menu relationships
English, Spanish and Catalan pages may use separate menu entities or translated navigation blocks. Confirm each language header/template resolves the intended menu and every translated link targets a published page.
Do not duplicate the base menu without reviewing language switchers, custom links and hierarchy. Test fallback behaviour when a translation is absent and avoid sending visitors silently to an unrelated language/homepage.
Provide a usable no-script baseline
Critical navigation should remain understandable if JavaScript fails. Links can be visible by default and enhanced into a collapsible menu, with CSS/HTML that does not permanently hide them before initialisation.
If design requires a script-only drawer, provide an accessible fallback link/sitemap and monitor initialisation. Do not solve a broken toggle by exposing two overlapping menus to screen readers.
Check cache and generated assets
Purge only relevant page/asset caches and use versioned CSS/JS. Test after CDN/page cache is warm.
HTML and script from different releases cause intermittent behaviour. Ensure deployment changes both atomically.
Do not publicly cache role-specific/private menu output.
Verify navigation completely
Test nested items, current-page state, Escape/outside click, focus return, scroll lock, orientation and representative browsers. Follow every critical link/language.
Monitor front-end JavaScript errors after release. Recurring care should include an automated mobile-menu interaction test; a visible hamburger icon is not proof navigation is usable.
What to send for a menu repair assessment
Send one affected URL, the device or screen width, the language and whether the failure occurs while logged out. Describe the actual action: for example, “the button opens the drawer, but the product links cannot be tapped”. Add when it started, the last theme or optimisation change and a cropped screenshot or browser error with private information removed.
That evidence helps define which part needs investigation and how the repaired journey will be accepted. The website repair process explains how assessment, scope and approval are handled. Ask for an assessment when the failure blocks a business-critical route or you cannot isolate it.
Documentation for the relevant navigation type
For the editing interface, consult WordPress classic menus or the Navigation block documentation, according to your theme. Controls can differ by version. For a custom collapsible navigation, review the W3C disclosure navigation example and test the actual implementation.