If your converted site's hamburger menu does nothing when tapped, you've hit one of the more structurally confusing Framer export problems — and the fix isn't obvious from the DOM alone.
The core issue: the "open" state doesn't exist yet
Framer's mobile nav is typically a component with responsive breakpoint variants (desktop/tablet/phone) and interaction-driven state variants (closed/opened). The static, server-rendered HTML only ever contains the closed state. The full-screen open panel — the one with your actual nav links laid out large — is built by Framer's client runtime the moment you click the trigger. Before that click, it genuinely does not exist anywhere in the page source. We confirmed this directly: querying a freshly-loaded page's DOM for the open-state panel by name returns nothing at all, before any interaction.
That means no amount of clever static HTML parsing will ever recover it — there's nothing to parse.
A second, sneakier problem: finding the trigger
Even once you accept you'll need to build the open panel yourself, you still need to correctly detect what to click. A lot of Framer sites don't name their hamburger icon container anything obviously related to "menu" — it's just as likely to be named after a visual state ("Dark closed", "Light opened") as anything semantic. Matching on the word "menu" alone misses a meaningful share of real sites.
A far more reliable signal: Framer's hamburger icon is almost always two or three small stacked "Line" elements (the bars), inside a small, currently-visible container near the top of the page. That structural fingerprint holds up across naming conventions that "look for the word menu" doesn't.
What actually works
Since the real open-panel markup can't be recovered, the practical fix is to build an equivalent panel from data that does exist statically: the real navigation links, which are present in the page (just hidden behind a CSS breakpoint at narrow widths). Concretely:
- Find the trigger via the Line-bar-count fingerprint above, not just name matching.
- Collect every real
<a href>inside the site's nav, deduped by URL (watch out — Framer often renders a "Main" and "Hover" text copy of the same link inside one<a>, which will double up your label text if you naively grab.textContent). - Build a simple full-screen overlay with those links and wire it to the trigger.
It won't be a pixel-identical animation of Framer's own transition, but it's a genuinely working menu with your real links — which beats a hamburger icon that silently does nothing.
If you're keeping Framer's runtime instead
None of this applies if your export keeps Framer's actual JS running rather than reproducing behavior. In that case the real menu works exactly as authored, because it's the same code — this whole problem only exists for exports that strip the runtime.
Related conversion check
FNJ's exports — the Framer to Next.js export, the Framer to HTML export and the Astro export — all retain Framer's runtime, so the real menu works as authored in each; if it does nothing, check that requests to Framer's servers aren't being blocked. Test the actual menu on a phone-sized preview before launch.
Starting a new site instead? FNJ's AI website builder designs one from a description and a site you like, then gives you the code to host anywhere.
