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 #15 in Website Structure#222 in Technical SEO#301 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 menuA mega menu is a large, categorized navigation panel — usually opened by hover or click on a top-level nav item — that surfaces many links at once, grouped into columns instead of the single list a standard dropdown shows. is internal linksAn internal link is a hyperlink from one page on a website to another page on the same website. Internal links help search engines discover your pages and pass ranking signals (PageRank and anchor-text context) between them. wearing a bigger UI, so every rule from the internal linksAn internal link is a hyperlink from one page on a website to another page on the same website. Internal links help search engines discover your pages and pass ranking signals (PageRank and anchor-text context) between them. 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 textAnchor text is the visible, clickable text of a hyperlink. It tells readers what they'll find on the other end and gives search engines context about the linked page. so you don’t pancake your topical structure. Mobile hamburger/accordion needs the same crawlable links, not a trimmed version. Structured dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding. 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 textAnchor text is the visible, clickable text of a hyperlink. It tells readers what they'll find on the other end and gives search engines context about the linked page., 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 architectureSite architecture is how a website's pages are organized, categorized, and interlinked. It controls how crawlers discover pages, how link equity flows, and how clearly search engines understand each page's topical context. Silo structure, hub and spoke, and topic clusters are the three common models. and website structureWebsite structure (site architecture) is a site's visible hierarchy, navigation, breadcrumbs, and URL organization — how pages relate and how people and search engines move between them. Internal linking is the primary signal Google reads to understand that structure, not URL folders. 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 pagesAn orphan page is a page on your site that no other page links to internally. Because crawlers discover pages by following links, an orphan page is effectively invisible to search engines unless it's in an XML sitemap or linked from an external site. (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 toolA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version. (GSCA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results.). Run the page through Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance.’s URL Inspection and look at the rendered HTML / crawled page. This tells you what GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. actually ended up with.
TIP Turn the mega-menu link set into a review queue

This checks the links the analyzer can observe; it does not prove that interaction-only links exist in the initial HTML. Keep View Source and URL Inspection as the crawlability checks.

Review observed menu destinations and anchor patterns with my free Link Analyzer Free

  1. Analyze a representative desktop page and the equivalent mobile route.
  2. Review non-navigational links, repeated generic anchors, redirected targets, and internal nofollow findings.
  3. Fix the menu component, then verify real anchor elements in source and rerun the sample.

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 indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed.: “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 crawlabilityCrawlability is how well search engine crawlers can discover, access, and fetch a site's pages. A crawlability issue is any technical condition — blocked access, broken links, server failures, or bloated URL inventory — that stops pages from reaching the index. problem. The links don’t exist until a user does something, so a crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. 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 indexingGoogle's practice of using the mobile version of a page's content — crawled by Googlebot smartphone — for indexing and ranking. It is not a separate index and not a ranking boost. guidance is explicit that mobile content — navigation included — should be equivalent to desktop. If your mobile nav is where indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. 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.

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 markupSchema markup is code that uses the schema.org vocabulary to label what your content means so search engines can understand it and show rich results. It's most often written in JSON-LD, and it's not a direct ranking factor. 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 crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor., 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 structureWebsite structure (site architecture) is a site's visible hierarchy, navigation, breadcrumbs, and URL organization — how pages relate and how people and search engines move between them. Internal linking is the primary signal Google reads to understand that structure, not URL folders. 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 a quote first.