Initial assessment without passwords Quote before intervention One accountable specialist from start to finish

Errors & Diagnosis

WordPress Mobile Menu Not Working

WordPress mobile menu not working? Identify missing links, a broken toggle, CSS overlays or script errors, then prepare a focused repair assessment.

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.

BEFORE YOU SEND THE REQUEST

Frequently asked questions.

Do you ask for passwords in the form?+

No. The public form never requests access. Secure credentials are requested only after the scope and quote are approved.

Who reviews the incident?+

The request goes to Jordi Ensenyat, founder of Code Barcelona and a WordPress specialist with more than 15 years of experience.

Is anything changed before the quote?+

No. Visible symptoms and scope are reviewed first. Intervention begins after approval and with a rollback path prepared.

Do you work internationally?+

Yes. WP Repair handles WordPress and WooCommerce incidents in English and Spanish through a remote service.

Assess my incident↗