If your WordPress mobile menu is not working, start with what the visitor can actually do. Is the menu icon missing, does tapping it do nothing, or does the panel open while its links stay out of reach? These failures need different fixes.
A working desktop header does not prove that phone visitors can reach your services, products or contact page. However, a broken menu does not automatically mean WordPress needs reinstalling or your theme needs replacing. First identify the component that owns the menu and reproduce the failure outside the editor.
This guide covers WordPress block navigation, theme menus and Elementor headers. It is a diagnostic guide, not a notice of a new WordPress or Elementor incident.
Match the mobile menu symptom before changing anything
Open the public page in a private browser window on a phone. Start from a fresh load, before scrolling or tapping elsewhere. Try the menu once, wait briefly, then try it again. Record the difference rather than treating several taps as a successful test.
| What the visitor sees | First area to inspect | Useful comparison |
|---|---|---|
| No menu icon on a small screen | Mobile visibility, menu assignment and responsive breakpoint | Does the icon appear on another page using the same header? |
| Icon is visible but the first tap does nothing | Menu script loading, an error, or another element covering the button | Does it work after scrolling, a second tap or signing in? |
| Menu opens behind the page or gets cut off | Header container overflow and stacking order | Does the problem start only after the header becomes sticky? |
| Top-level items work but submenus do not | Submenu trigger and the distinction between a link and an expand button | Test the item label and its arrow separately |
| Only some pages have a broken menu | Header display conditions, page templates and page-specific assets | Compare one working URL with one failing URL |
This table narrows the investigation; it does not prove a cause. Save the affected URL, device, browser, time and recent change. A short screen recording of the first failed tap is often more useful than a screenshot of an already-open menu.
Find out which component owns your menu
Do not change three menu systems at once. The right control depends on how the header was built:
- Block theme: inspect the header’s Navigation block in the Site Editor.
- Classic theme: inspect the assigned WordPress menu and the theme’s header or mobile-navigation controls.
- Elementor: inspect the published header template and the actual menu widget it contains. Different widgets expose different controls.
- Menu add-on or custom header: use that component’s documentation and support path.
The official Navigation block documentation describes an overlay menu that can appear on mobile, always or not at all. That setting is different from whether a navigation item opens a submenu. A missing icon may therefore be a configuration issue rather than a failed script.
For Elementor’s Menu widget, check the selected layout, breakpoint and dropdown interaction. Do not copy a setting intended for this widget into an unrelated legacy menu or third-party add-on. Confirm the owning widget before following a tutorial.
Separate a hidden menu from a menu that cannot open
If the icon is missing, inspect the header and its parent containers for mobile visibility rules. Check the actual breakpoint, not just the editor’s phone icon. A tablet in landscape may use a different layout from a phone in portrait.
Next, compare the public header with the editor preview. Elementor’s mobile layout guidance covers responsive visibility and spacing. Use the native controls for the responsible element. Avoid adding a global CSS rule that forces every hidden menu to display.
If the icon is present but nothing opens, changing its colour or size will not fix missing behaviour. Likewise, increasing a stacking value cannot repair a script that never ran. Move to the first-tap and overlay checks instead.
Menu works after scrolling or only when logged in?
This comparison is particularly useful on sites with script optimization. Logged-in administrators and ordinary visitors can receive different cached or optimized output. Editor previews also load assets that the public page may load differently.
WP Rocket’s Delay JavaScript Execution documentation explains that scripts can wait for user interaction and that the feature applies to cached or optimized pages. It also describes targeted exclusions for compatibility problems. That is a reason to investigate timing, not proof that WP Rocket caused your menu failure.
On a protected staging copy, preserve the current optimization settings and test one relevant change. If the menu works without that optimization, identify its required script and dependencies before selecting the smallest supported exclusion. Re-enable unrelated optimizations and test again. Do not leave every script excluded as the final fix.
A developer should also check failed asset requests and the first relevant browser error. The menu may never initialize because an earlier dependency failed. Pasting another menu script into the page can produce duplicate handlers without resolving that failure.
If the public page keeps showing an older header, use our guide to WordPress changes not showing to identify which cache layer serves it. Purging a cache refreshes output; it does not correct the underlying menu configuration.
Check overlays, sticky headers and submenu taps
A transparent banner or container can cover the menu button even when the icon is visible. Try the header before and after scrolling, and compare the page with any dismissible banner closed. Keep the same device and URL during this comparison.
When the panel opens but disappears behind content, inspect the owning header’s stacking context and parent overflow. A large stacking value on the panel alone may not escape a parent that clips its children. Correct the responsible container’s native layout control where available instead of applying a sitewide override.
Submenus need a separate test. Some designs use the parent label as a destination and a nearby arrow as the expand control. Others use the label to toggle children. Choose the intended behaviour, retain access to meaningful parent pages and verify it with touch and keyboard. Do not rely on desktop hover to prove a phone submenu works.
If closing the menu leaves the page unable to scroll, the fix is still incomplete. Check close, reopen and navigation as one sequence. Do not accept a solution that reveals links but traps the visitor on the page.
Test a repair against a clear acceptance table
Use a working page and the originally failing page. Check small phone widths as well as the real device that showed the problem. Browser emulation helps find layout faults, but it does not replace an actual Safari or Android browser check.
| Test | Pass condition |
|---|---|
| Fresh logged-out load | The first intentional tap opens the menu without a preliminary scroll |
| Open, close and reopen | Controls keep working and normal page scrolling returns after closing |
| Submenu and destination | Children expand reliably and the chosen link reaches the correct page |
| Small widths and zoom | Labels wrap without covering controls; links stay reachable without page-wide horizontal scrolling |
| Keyboard | Focus is visible, the toggle works and navigation does not trap focus |
| Sticky header and other pages | The repair works before and after scrolling across the affected templates |
| Final cached page | The public optimized version passes the same checks after cache refresh |
Keep the test record specific: which page, browser, width and interaction passed, plus anything not tested. A green speed score or a screenshot of the desktop header is not mobile-menu verification.
When to stop testing and get help
Stop live experimentation if the header is shared across the site, the failure started after several updates, or a proposed fix requires disabling business-critical plugins. Preserve a backup of the exact template and settings before any repair. Test plugin conflicts on staging rather than switching off checkout, forms or security features for visitors.
For an urgent navigation failure, provide Webless with the public URL, the failing step, the owning theme or builder, and the last known working time. Keep passwords, customer details and private logs out of public screenshots and general enquiry text.
Our WordPress development services are a relevant next step when the repair involves custom headers, conflicting scripts or a menu behaviour change. The useful scope is to identify the responsible component, make a controlled correction and verify the visitor journey. It is not automatically a full redesign.