WordPress mobile menu not working: trace the tap

On a phone, a header menu is usually a small icon that only a script can open. Some themes size that icon in a way that looks right in a wide browser window, but leaves its tappable area smaller than the three lines the visitor sees. A sticky promotion bar, a cookie notice or a chat launcher can sit over the top of the header and take the tap before the icon does. Nothing reports an error in that case. The owner tests on a laptop, where the desktop navigation is always drawn, and never sees the phone path.

• Open the page at phone width and tap the menu icon. Note whether anything opens, even for a moment.
• Look at what sits over the icon. A cookie bar or sticky header on top means the tap never reaches it.
• Open the browser console and tap again. A script error at the tap means the menu handler did not load.
• Turn off caching and script optimization for one test. If the menu opens, the plugin is the cause.
• Tap a link inside the open panel. A panel that opens but cannot be tapped is a layering fault.

A phone menu is usually a small icon that a script opens. The theme draws that icon for small screens, and some themes size it so it looks fine in a wide browser window but leaves a tappable area smaller than the lines a visitor sees. Anything placed over the top of the header can take the tap first. A sticky promotion bar, a cookie banner, a chat launcher, or a desktop menu hidden with the wrong rule can all sit in that spot. The tap lands on that element, not on the icon, and the page shows no error.

A visitor cannot see this. They press the icon, see no change, press again, and then either scroll past the header or leave. The owner sees a working menu on a laptop, where the desktop navigation is always drawn and no banner sits in front of the header. The fastest check is to open the page at phone width and ask the browser which element sits at the icon's position. If that element is not the icon, you have a layering fault, and changing the script will not fix it.

When the tap does reach the icon, a theme script has to change the menu's state. That script can fail in ways that only show on phones. A caching or optimization plugin may combine the theme's scripts into one file, delay them until after the first paint, or drop a file it wrongly thinks is unused. The menu is then left with an icon and no handler. The browser console shows a script error at the moment of the tap, or shows nothing because the handler was never attached. Watching the console while you tap is the only way to see this from outside the site.

A simulated visitor opens the page in a real browser at phone width, taps the icon the way a stranger would, and records each step. When the menu does not open, the report gives you the step, a screenshot of the header at that moment, and any script error recorded at the tap. The run does not read your theme files or your caching settings, so it cannot name the plugin. It shows that the fault is at the tap, which tells you where to look first. Run the same visitors again after a change to see whether the tap now opens the panel.

Menus break again after updates, because a new version of the theme or a caching plugin can rewrite how the header loads. A fix that worked on the last release can fail after the next one. After each update, run the same phone visitors from the homepage to the contact page and confirm the menu opens before you publish. Keep the screenshots, so you can see what the header looked like when it last worked.