
Mobile Menu Works on Desktop but Not on Your Phone—How to Find the Failure
A mobile menu can look perfect in a desktop editor and still ignore taps on a real phone. The icon may be visible, yet nothing opens. Or the panel opens behind the page, closes immediately, refuses to scroll, or sends visitors to a parent page instead of revealing its submenu.
This is rarely fixed by making the hamburger icon larger. The reliable approach is to identify which layer fails: responsive visibility, touch input, JavaScript state, stacking order, menu data or cached assets.
First, reproduce the exact failure
Test the published site on at least one real phone before editing anything. A desktop browser narrowed to 390 pixels checks the layout, but it does not fully reproduce touch input, the mobile browser viewport, the address bar, safe-area insets or device-specific caching.
Test while logged out in a private browser tab.
Try both portrait and landscape orientation.
Tap the icon, its surrounding button area and any submenu arrow separately.
Check whether the page scrolls or shifts when the menu should open.
Repeat on Wi-Fi and mobile data if the behaviour is inconsistent.
Record the page URL, device, browser and exact tap sequence.
If the whole site works on Wi-Fi but fails over a carrier connection, use the Wi-Fi versus mobile-data diagnostic before changing the menu itself.
1. Check whether an invisible element is intercepting the tap
The most common cause is an overlapping layer. Cookie banners, announcement bars, chat widgets, transparent sections, sticky headers and page-builder containers can sit above the menu button even when they appear visually empty.
Open the page in mobile device inspection, select the point under the hamburger icon and inspect which element receives the pointer. Then temporarily hide suspicious fixed or absolute-positioned elements. If the menu starts working, fix that component’s dimensions, stacking context or pointer behaviour rather than assigning an extreme z-index to everything.
CSS stacking is local to each stacking context, so a child with a very large z-index can still remain behind an element in a different parent context. MDN’s stacking-context guide explains why simply increasing the number may not work. The pointer-events reference is also useful when a decorative overlay should not receive taps.
A support widget can create the same problem lower on the page. Webcurry’s guide to a mobile chatbot covering checkout buttons shows how to test fixed overlays without removing useful support tools.
2. Confirm that the mobile menu exists at the active breakpoint
Many sites render separate desktop and mobile navigation components. The hamburger may be visible at one width while its associated panel is hidden by a conflicting media query. Inspect the button and menu panel around every breakpoint, not just one phone preset.
Confirm the button controls the intended panel, not an old duplicate with a similar ID.
Check display, visibility, opacity, transform and off-screen positioning before and after tapping.
Look for a gap or overlap between desktop-menu and mobile-menu media queries.
Verify that a page-builder visibility rule has not hidden the panel on phones.
Check tablet widths separately; a failure may start at 768 or 1024 pixels rather than at a specific device.
Do not detect mobile users only by checking for touch support. Laptops can have touchscreens, while browsers differ in the touch APIs they expose. MDN recommends pointer events for hardware-independent mouse, pen and touch input.
3. Inspect the button state before debugging animations
A functional menu button should change state when activated. In the DOM, look for a class such as is-open, an updated aria-expanded value, removal of a hidden attribute, or a matching change on the menu panel.
If no state changes, the click handler did not run or is bound to the wrong element. If the state changes but the panel is invisible, the problem is usually CSS, stacking, clipping or animation. This distinction prevents hours of editing transitions when JavaScript never opened the menu.
Also verify that the trigger is a real button or another correctly implemented interactive control. It should be reachable by keyboard, have an accessible name, expose whether the menu is expanded and retain a logical focus order. W3C guidance requires focus order to preserve the page’s meaning and operation.
4. Look for the first JavaScript error
A menu can fail because an unrelated script throws an error before navigation code initialises. Open the browser console, reload the page and investigate the first new error—not the final warning in a long chain.
Temporarily disable delayed-JavaScript, script-combination and minification features.
Test without marketing pop-ups, consent tools, chat widgets and animation libraries.
Confirm that the menu script is not loaded twice by the theme and a plugin.
Check whether Content Security Policy blocks a required inline or external script.
Verify that the production bundle and source map belong to the current release.
If the site behaves differently across browsers, follow the Chrome-versus-Safari troubleshooting workflow to separate unsupported code from a cache or extension problem.
5. Test touch, click and pointer handling
Desktop navigation often depends on hover, but fingers do not provide a stable hover state. A submenu that appears on mouseover may never become usable on a phone, or the first tap may navigate away before the submenu expands.
Where custom code is involved, prefer the Pointer Events model rather than maintaining separate mouse and touch behaviour without a clear need. Test the control with a finger, keyboard and mouse because responsive width and input type are different concerns.
For parent items with submenus, decide deliberately what the first tap does. Common patterns are a separate expand button beside the parent link, or a top-level button that opens the submenu while a clearly labelled child link leads to the parent destination. Avoid hiding essential navigation behind hover.
6. Check the menu panel for clipping and scroll locks
Sometimes the menu opens, but only a small portion is visible. A parent with overflow hidden, a transformed header, a fixed height or a negative translate can clip the panel. Full-screen menus can also become unusable when the page’s scroll lock is applied to the wrong element.
Inspect the panel’s actual bounding box after opening.
Check overflow on the header and every positioned ancestor.
Test with the browser address bar both expanded and collapsed.
Use modern viewport units carefully and account for device safe areas.
Confirm that the close button remains visible and that long menus can scroll.
After closing, verify that normal page scrolling and focus are restored.
7. Verify the menu data and links
If the panel opens but items are missing or incorrect, the interaction code may be fine. Check whether the site is displaying the right menu assignment, whether pages are published, whether translated or market-specific navigation is selected and whether submenu nesting is correct.
A top-level link can also steal the tap intended to expand its children. Shopify’s current drop-down-menu documentation notes that a mobile parent item that redirects may need its link field set to #, depending on the theme’s navigation behaviour. Test this in a duplicate theme before changing a live store.
Platform-specific checks
Wix
In Wix Editor, inspect the mobile version independently from desktop. Wix’s mobile layout troubleshooting guidance notes that elements can be positioned differently on mobile. Its menu guidance also identifies overlapping elements and frozen headers or footers as reasons a menu may not respond.
Bring the menu to the front only after identifying the overlapping item. Check the Hidden on Mobile panel, header boundaries, frozen-menu setting and whether an anchor used by a menu item is available on mobile. Publish the site and test the live version; editor preview alone is not enough.
WordPress
For block themes, select the Navigation block and review its official mobile overlay and submenu settings. Confirm Overlay visibility is set to Mobile or Always as intended, and choose click rather than hover when that matches the submenu experience.
If the configuration is correct, duplicate the site to staging. Switch temporarily to a default theme, disable optimisation features and isolate plugins. Pay special attention to tools that remove unused CSS or defer scripts, because responsive navigation styles and state classes may appear unused during their build-time scan.
If a recent change caused the failure, use the WordPress update recovery checklist to compare versions and roll back safely rather than editing production blindly.
Shopify
Preview a duplicate theme in Shopify’s mobile theme preview. Then review menu nesting and parent destinations using Shopify’s drop-down menu documentation.
Disable app embeds selectively in the duplicate theme to find overlays or scripts that intercept the menu. Preserve the working live theme until the fix has passed phone, tablet, cart and checkout-entry tests.
8. Clear every relevant cache after the fix
A correct change can appear ineffective if the phone still receives an older HTML document, CSS bundle or JavaScript file. Purge the platform cache, performance-plugin cache and CDN cache as appropriate. Change asset versions when needed, then retest in a fresh private session.
If customers continue seeing the previous design, the old website version and cache diagnostic explains how to identify which cache layer is serving stale assets.
A focused verification checklist
The hamburger button responds on real iOS and Android devices.
The open state is visible through the button and panel attributes or classes.
No transparent overlay intercepts taps.
The panel appears above the page and is not clipped by a parent.
Every item and submenu works without hover.
The menu is usable with keyboard focus and a screen reader.
Long menus scroll, while the page behind them remains controlled.
Closing the panel restores focus and page scrolling.
The fix survives cache purges and a logged-out production test.
Conclusion
A mobile navigation failure is a conversion problem, not a cosmetic detail. Visitors who cannot reach services, product categories or contact pages rarely spend time diagnosing the site for you.
Start with the element receiving the tap, then follow the state change from the button to the panel. That evidence separates overlay, CSS, JavaScript, configuration and caching failures quickly. Fix the failing layer, test the published site on real devices, and keep the desktop menu unchanged unless the evidence shows it shares the same fault.
Frequently asked questions
Why does my mobile menu work in preview but not on my phone?
Preview reproduces width but not every real-device condition. Touch input, mobile browser viewports, cached production assets, overlays and device-specific scripts can differ. Test the published URL on a real phone while logged out.
Why is the hamburger icon visible but not clickable?
An invisible or transparent element is often above it. Inspect which element receives the pointer, then correct the overlay’s size, stacking context or pointer behaviour.
Can a caching plugin break a mobile menu?
Yes. Delayed JavaScript, removed unused CSS, combined files or stale cached bundles can prevent navigation state styles or handlers from loading. Test each optimisation separately on staging.
Should I solve the problem by adding a very high z-index?
Not automatically. Z-index works inside stacking contexts, so a large number may not escape a parent context. Identify the competing layers and fix their structure or stacking relationship.
Why do submenus work with a mouse but not with touch?
The menu may rely on hover or a parent link may navigate before the submenu expands. Use an intentional click or pointer interaction and provide a clear submenu toggle.
How do I test a WordPress mobile menu safely?
Use staging, confirm the Navigation block’s overlay settings, disable optimisation features temporarily, and isolate the theme and plugins. Keep a verified backup before changing production.
How do I troubleshoot a Wix mobile menu?
Inspect the Wix mobile editor, Hidden on Mobile panel, header placement, frozen-menu setting and overlapping elements. Publish and verify the live site on a real phone.
How do I troubleshoot a Shopify mobile menu?
Preview a duplicate theme, verify menu nesting and parent links, then disable app embeds selectively. Do not replace the working live theme until the fix passes mobile tests.
Comments