Elementor mobile menu not working on phones

Elementor headers are built for a desktop row of links, and on a phone the row has to become something else. The site's responsive settings decide the width where that happens and which widgets stay visible. If the menu toggle is hidden on mobile while the links are hidden too, the visitor has nothing to tap. If the toggle is visible, a full-height panel opens, and the browser's address bar and bottom toolbar change the height the panel is built on. The last links can then sit under the toolbar, where a visitor scrolls the page beneath them instead.

• Breakpoint: the width where the header switches to its phone version, checked at phone width.
• Hide-on-device settings on the header, the menu or the toggle, which can remove the only way in.
• A panel height tied to the screen, so the last links fall under the browser toolbar.
• Scrolling behind an open panel, which moves the links away from the visitor's thumb.
• A close control that stays visible when the panel is scrolled to its bottom.

Begin in the header's settings, not the menu's. Each widget can be shown or hidden per device, and the site-wide breakpoints decide when the layout becomes the phone version. A header can be correct on a laptop and still lose its icon on a phone because a different breakpoint applies, or because one widget was hidden on mobile months ago and nobody remembered. Look at the header at phone width in the editor, then load the live page on a phone, since the two can disagree when a cache or a theme loads the header differently.

Then check what sits above the icon. Phone headers often carry a sticky bar, a chat launcher or a notice in the same top corner, and a layer above the header can receive the tap before the icon does. Tap the icon in a phone browser and watch whether anything opens. If the tap seems to land on another element, the fix is a layering change in that element. If the tap is clean and nothing opens, look at the toggle itself.

A menu that opens is not yet a menu a visitor can use. A full-height panel is usually sized to the screen, and on a phone that height changes as the address bar collapses and the toolbar appears. The last links can land under the toolbar. The visitor scrolls, the page underneath moves instead of the panel, and the close control drifts out of view. From the owner's side it looks like a working menu, because the links exist in the page. From the visitor's side, the last few are out of reach.

Test it by opening the panel, scrolling to the bottom link, and tapping it. A link that navigates means the menu is usable on that device. A page that scrolls behind the open panel means the panel does not hold the scroll, and a visitor can lose their place when they close it. Repeat the check in a phone browser and in an in-app browser opened from a social app, since those toolbars behave differently and a link can be reachable in one and not the other.

A simulated visitor on a phone looks for the navigation, taps the icon, reads what opened, and tries to reach the pricing or contact link. The run records a screenshot at each step and whether the pricing link was reached. A failure reads as a specific step, such as the toggle not opening or the last link out of reach, so the next fix can target that step and nothing else.

Rerun the same visitors after you change a breakpoint or a header widget, because one header serves every page that shares it. A fix on the home page can leave the article template with the old breakpoint. Include a laptop visitor too, so the desktop menu is checked against the same change. The run does not open an installed app, so a menu inside a native app is outside what a run covers.

The menu is rarely broken by the menu alone. A chat launcher added for a campaign, a promo bar pinned to the top, or a header template edited for one landing page can cover the icon without touching it. Rerun the same phone visitors after any change to the header or the top of the page, and before a campaign sends people to the site.