Languages

Mega Menu SEO

How to build a mega menu that stays crawlable and doesn't dilute your topical structure — the real-href requirement, the JS-flyout failure mode, hidden-until-hover content, link-budget guidance, mobile parity, and a good-vs-bad markup example.

First published: Jul 3, 2026 · Last updated: Jul 18, 2026 · Advanced
demand #16 in Website Structure#257 in Technical SEO#357 on the site
AIAuthored byAI v2

A mega menu is just internal links wearing a bigger UI, so it lives or dies by the same rules: every link must be a real <a href>. The single most common failure is a JS click/hover flyout that never renders real anchors — it looks linked to a user but silently orphans the pages. Content hidden until hover isn't automatically discounted for being hidden, as long as it's in the initial HTML and not fetched only on interaction — Google says it's taken into account, though identical ranking weight to always-visible content isn't documented. There's no hard link-count ceiling; the real lever is organization — group by category with descriptive anchor text. And your mobile hamburger/accordion needs the same crawlable links (and its own keyboard-tested disclosure), not a trimmed-down version.

TL;DR — A mega menu is internal links wearing a bigger UI, so every rule from the internal links write-up applies unchanged — starting with the <a href> requirement. The #1 real-world failure is a JS click/hover flyout whose links aren’t real anchors: it looks linked to a user but Google can’t crawl it, silently orphaning pages if the menu was their only internal link. Verify with View Source, not Inspect. Content hidden until hover isn’t automatically discounted for being hidden as long as it’s in the initial HTML and not fetched only on interaction — CSS-hidden is fine; AJAX-on-hover is the risk. Google says it takes that content into account, though it hasn’t documented identical ranking weight to always-visible content. No hard link-count ceiling exists (the 100-link rule is a myth), but organization is the real lever: group by category with scannable columns and descriptive anchor text so you don’t pancake your topical structure. Mobile hamburger/accordion needs the same crawlable links, not a trimmed version. Structured data is not a substitute for real links.

Evidence for this claim Google reliably crawls standard anchor elements with resolvable href URLs; script-only navigation may not be parsed as links. Scope: Current Google crawlable-link requirements. Confidence: high · Verified: Google Search Central: Make links crawlable Evidence for this claim Under mobile-first indexing, Google recommends equivalent primary content and links on mobile and desktop versions. Scope: Current mobile-first indexing parity guidance. Confidence: high · Verified: Google Search Central: Mobile-first indexing best practices

I want to set expectations before getting into the specifics. There is nothing magical or separate about “mega menu SEO.” A mega menu is a navigation component built entirely from internal links, and every rule that governs internal links generally — the crawlable-link requirement, descriptive anchor text, the fact that there’s no magic link-count limit — applies here with zero modification. I’m not going to re-derive those; the internal links article in this cluster covers them, and this page cross-references it repeatedly.

What makes mega menus worth their own page is that they do one thing normal navigation doesn’t: they cram an unusually large number of links into a single, repeated, sitewide UI element. That concentration is what raises two distinct risks — an implementation risk (JavaScript flyouts that never render real links) and a structural risk (over-flattening your site so Google loses the grouping signal). The structural side — the flat-vs-deep, pyramid-vs-pancake argument — is already covered in the site architecture and website structure articles in this cluster, including Mueller’s line that over-flattening a site with a mega menu can make it so “Google can’t recognize which parts of the site belong together.” I’m not going to re-litigate that here. This page is about the practical build.

Here’s the one I see break in the wild more than any other. A team builds a mega menu — often with an older jQuery plugin, or a hand-rolled React/Vue component — and the flyout’s “links” are actually click handlers, a router attribute with no href, or content that only gets injected into the DOM after a hover or click event fires. Google’s own list of link formats it can’t reliably crawl maps directly onto exactly these patterns:

<a routerLink="products/category">Shoes</a>          <!-- no href -->
<span href="https://example.com">Shoes</span>        <!-- not an anchor -->
<a onclick="goto('https://example.com')">Shoes</a>   <!-- onclick, no href -->

The reason this one is so dangerous is that the failure is silent. The pages look linked — a human hovers, sees the flyout, clicks, and lands on the category page. Nothing appears broken. But those destination pages get zero crawl and zero link-equity credit from the mega menu, and if the mega menu was their only internal link, they become orphan pages (see the internal links article on why orphans are a discovery dead end). You can have an entire category tree that’s invisible to Google while looking perfectly navigable to every human who tests it. That’s why it survives QA: humans don’t experience the bug.

How to verify a mega menu is actually crawlable

Don’t trust the rendered page — check the source.

  • View Page Source, not Inspect Element. Right-click → View Page Source shows the raw HTML the server sent. Inspect Element shows the live DOM after JavaScript has run, which hides exactly the problem you’re hunting. If your flyout links appear as <a href="..."> in View Source, they’re server-rendered and safe. If they only show up in the Inspect view, that’s your red flag.
  • URL Inspection tool (GSC). Run the page through Search Console’s URL Inspection and look at the rendered HTML / crawled page. This tells you what Googlebot actually ended up with.

The nuance worth stating plainly: yes, Google renders JavaScript now, so a JS-built menu might get crawled. But “might” is the operative word. The verifiable, safe pattern is server-rendered <a href> links, progressively enhanced with JavaScript for the hover animation and interactivity — not links that depend on JS to exist at all. Use JS to make the menu behave, not to make the links exist.

Is hidden-until-hover content discounted?

This is the question everyone eventually asks about mega menus, and it’s the one place where old SEO folklore is genuinely outdated. A mega-menu flyout is hidden until you hover it — does Google discount all those links because they’re not visible on load?

Not automatically — but be precise about what that means, because this is where people overclaim. Current Google guidance and John Mueller’s own statement say content present in the HTML but visually hidden — inside a hover flyout, a closed accordion, an inactive tab — is taken into account, not excluded outright. Mueller, asked directly whether hidden tab/accordion content is devalued under mobile-first indexing: “No. Specifically when it comes to content on mobile pages we do take into account anything that’s in the HTML. So if there’s something there that might be visible to users at some point we will include that… so that’s completely normal” (reported by Roger Montti in Search Engine Journal’s write-up of the myth). Google’s mobile-first indexing docs back this operationally, telling you it’s fine to move content “into accordions or tabs” for mobile UX as long as it stays equivalent to desktop.

What that quote actually establishes is availability — the content gets crawled, rendered, and considered, rather than thrown out. It doesn’t establish that hover-hidden content carries identical ranking weight to always-visible content; Google hasn’t published anything on that specific question either way, so treat it as undocumented rather than assuming equivalence. Keep the two questions separate: is it excluded outright (no — settled) versus does it rank exactly like visible content (not documented).

This supersedes the older (roughly 2015–2016-era) line that content behind tabs and click-to-expand boxes carried less ranking weight — that specific claim is dead. What the record actually supports is narrower: hidden-in-HTML content isn’t discounted out of hand, but no one has documented that its weighting is identical to visible content. If you’ve heard the old “discounted” version, this is what changed — don’t swap it for an equally unsupported “definitely equal” version.

But there’s a nuance that trips people up, and it’s the whole game: “hidden via CSS” and “fetched only on interaction” are two completely different things.

  • A flyout that’s display:none until hover, with the links already sitting in the DOM, is fine — indexed normally.
  • A flyout whose HTML is fetched via an API call triggered by the hover event may never be crawled at all.

That’s not a “hidden content is discounted” problem — it’s a crawlability problem. The links don’t exist until a user does something, so a crawler never sees them. Conflating those two failure modes is exactly how the myth survives. Keep them separate: CSS-hidden links = fine; AJAX-on-interaction links = broken.

There is no documented hard limit on how many links a mega menu can have. The old “100 links per page” rule is a flat myth — the internal links article debunks it in full, so I won’t re-argue it here. Google’s line is that there’s no magical ideal number.

But “no limit” doesn’t mean “dump everything in.” The real lever isn’t raw count — it’s organization. This is where Mueller’s actual mega-menu answer is useful. In a 2021 Search Central hangout (reported by Barry Schwartz), someone described a mega menu with over 1,000 links and a traffic drop after moving those links from hover-loaded to static HTML. Mueller’s practical concern wasn’t the number — it was whether a huge, undifferentiated set of same-level links flattens the topical grouping. As he put it, going too flat means “we think, oh, all of these are equally important, and we don’t really know which of these are connected to each other,” whereas “a pyramid structure helps us a lot more to understand the context of individual pages.” Notably, he also treated reverting some of those 1,000 links to hover-loading — while keeping a crawl path to them via other, more relevant pages — as a legitimate structural fix, not something inherently bad.

The practical takeaway: a well-organized 150-link mega menu with clear column headers (Men’s / Women’s / Kids’, then subcategories under each) preserves the hierarchy signal. An unorganized wall of 150 links with no grouping doesn’t — even at the identical count. So:

  • Group by real category boundaries. Columns and headings that mirror your actual site hierarchy.
  • Keep columns scannable. A handful of items per group, not an alphabetical soup of everything.
  • Keep anchor text descriptive and specific. Link text that describes the destination — not “Shop now” repeated thirty times.
  • Don’t make it exhaustive. A mega menu is for high-level discovery paths. Your true priority pages should also earn contextual, in-content links, not rely solely on the global menu (which repeats identically on every page and spreads the same “importance” signal everywhere).

On mobile your mega menu becomes a hamburger or accordion. The trap is teams trimming the mobile menu for UX cleanliness and, in doing so, dropping destinations that existed only on the desktop mega menu. Google’s mobile-first indexing guidance is explicit that mobile content — navigation included — should be equivalent to desktop. If your mobile nav is where indexing happens (and under mobile-first indexing, it is), links you dropped there can be treated as less important, or — if the mega menu was their only internal link — go undiscovered entirely.

Evidence for this claim Under mobile-first indexing, Google recommends equivalent primary content and links on mobile and desktop versions. Scope: Current mobile-first indexing parity guidance. Confidence: high · Verified: Google Search Central: Mobile-first indexing best practices

So run the same audit on mobile that you run on desktop: pull up the mobile nav’s rendered HTML, confirm the same destinations are present, and confirm each is a real <a href>. Same crawlability test, same parity test — just on the smaller UI.

That covers destinations. It doesn’t cover interaction — a separate check, and one teams skip. Mobile-first indexing requires the important destination set to be present, not an identical interaction layout, so a hamburger/accordion is fine as a pattern. But whatever disclosure pattern you use needs its own keyboard and focus test: can a keyboard-only user reach the trigger, open it, and tab through the destinations, with an accurate aria-expanded state? The WAI-ARIA disclosure navigation pattern is a worked example of that behavior — treat it as one conforming implementation, not the only one. Test destination parity and disclosure/keyboard behavior as two separate pass/fail checks, since a menu can pass one and fail the other.

One more myth: structured data isn’t a crawlability fix

Some mega-menu guides present SiteNavigationElement schema markup as if it makes a menu crawlable. It doesn’t. Structured data can describe your navigation semantically, but it is not a substitute for real crawlable links — the same principle the internal links article covers, where Mueller notes that even when you provide URLs in structured data, “we don’t use those URLs in the same way as we would use normal internal links on a page.” Schema is a layer you add on top of already-crawlable <a href> links, never instead of them.

What these checks do — and don’t — guarantee

Real anchors, source-visible links, grouped structure, mobile parity, and keyboard-operable disclosure remove the specific failure modes covered above: undiscovered pages, flattened topical structure, broken parity, and inaccessible navigation. None of it guarantees crawling, indexing, higher rankings, more traffic, or an AI citation — those depend on far more than navigation markup. Treat source/rendered anchors, crawler extraction, desktop/mobile destination parity, and keyboard/focus behavior as separate pass/fail tests, not one bundled fix; a mega menu can pass some of these and fail others.

Should your site even have a mega menu?

Briefly, because the full flat-vs-deep argument lives in the site architecture and website structure articles: a mega menu earns its place when your site is large enough that cross-category discovery is a genuine user journey and surfacing deep category pages from everywhere meaningfully cuts click depth (it’s one of the best tools for keeping important pages within a few clicks of the homepage — and for hitting Bing’s roughly three-clicks-from-home target). If your catalog is small, or the long tail of menu items barely gets clicked, a mega menu is overhead you don’t need. Decide whether to have one before you obsess over how to build it — the decision tree lens walks through it.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin an expert quote first.