Can Googlebot really crawl hidden links in a hamburger menu?

What does "absent from the DOM" really mean for a navigation link?

The DOM (Document Object Model) represents the HTML structure as it exists in memory after the initial page load. When Martin Splitt refers to "links absent from the DOM", he is specifically targeting navigation elements generated dynamically by JavaScript following a user interaction.

Take a classic hamburger menu: if the initial HTML code only contains an <button> icon and the JavaScript injects <a href> tags only on click, these links do not exist for Googlebot. The crawler does not execute onClick, onHover, or onScroll events — it loads the page, waits for the JS to execute automatically, and then scans the resulting DOM.

What is the difference between "visually hidden" and "absent from the DOM"?

This is where many developers go wrong. An element can be invisible on the screen while still being perfectly accessible to Googlebot. CSS techniques like display:none, visibility:hidden, opacity:0, or transform:translateX(-100%) visually hide a link without removing it from the source code.

If your mobile menu exists in the initial HTML with all its <a> tags, but it is simply positioned off-screen using left:-9999px or hidden by opacity:0 before the user clicks, Googlebot will crawl these links without issue. The interaction simply serves to reveal what was already there — and that’s exactly what Google recommends.

Why does this distinction have such an impact on mobile-first crawling?

Since the shift to mobile-first indexing, Google prioritizes crawling and indexing the mobile version of your pages. If your desktop navigation displays all links in a standard dropdown menu (present in the DOM), but your mobile version generates them on click via React or Vue, you're creating a critical crawl asymmetry.

The Google smartphone bot will see only a fraction of your link architecture, which fragments your internal linking and dilutes the distributed PageRank. Entire sections of your site can become orphaned from Google's perspective, even if they are perfectly accessible to a human visitor on mobile.

• Incomplete crawl: deep pages linked only from the interactive mobile menu will never be discovered
• PageRank dilution: link juice does not flow to hidden sections, weakening their ranking potential
• Partial indexing: Google cannot assess the complete structure of your site if half the links are invisible
• Loss of semantic context: absence of links to certain categories prevents Google from understanding the thematic hierarchy
• Risk of orphan pages: uncrawled pages can drop out of the index if no other link paths reach them

Is this rule consistent with what we observe in the field?

Absolutely, and it’s even one of the most empirically verifiable statements from Google. When auditing hundreds of mobile-first sites, we consistently find that pages linked exclusively through conditional JavaScript menus show a reduced crawl rate in Search Console. Server logs confirm: Googlebot smartphone does not trigger any requests to these URLs.

The confusion often arises from a misunderstanding of how Google handles JavaScript rendering. Yes, Googlebot executes the JS — but only the code that runs automatically on load, not that which requires a scroll, a click, or a touch event. Martin Splitt has been clear on this point in several talks: user interaction remains an insurmountable barrier for the crawler.

What nuances should be added to this statement?

First point: the concept of "link absent from the DOM" only applies to elements generated after interaction. If your JavaScript framework (Next.js, Nuxt, Gatsby) does server-side rendering (SSR) or static site generation (SSG), the links are indeed present in the initial HTML sent by the server — even if the interactive behavior is handled by client-side JS.

Second nuance: Google can discover some URLs through other pathways — XML sitemaps, external backlinks, crawl history. But this is no reason to neglect internal linking. A page discovered only via a sitemap receives far less PageRank than a page linked from the main navigation present on every template. [To verify]: Google has never published quantitative data on the difference in treatment between a URL discovered via sitemap vs. internal link, but field observations show a significant gap.

In what cases does this rule present a real strategic problem?

Let’s be honest: if your mobile menu is hiding only links to "Contact" or "Legal Notices", the SEO impact is negligible. The problem becomes critical when you hide product categories, SEO landing pages, or content hubs that should receive distributed PageRank from every page on the site.

Typical case: an e-commerce site that displays 8 main categories on desktop, but only 3 shortcuts + a "See All" button on mobile (which expands the rest on click). The result: 5 categories become partially orphaned for Google, their crawl slows down, and they lose organic visibility. And this is where it really struggles for high-volume sites.

How can I check if my site is affected by this issue?

Start with a simple test: display the raw HTML source code of your mobile page (right-click > "View Page Source" or use curl in the command line). Manually search for the <a href> tags of your main navigation. If they are all present with their complete href attributes, you're good — regardless of whether they are hidden by CSS.

Second check: use Google’s Mobile-Friendly Test tool or URL inspection in Search Console. Click on "View crawled page" then "More info > HTML Code". Compare this rendered DOM with your initial source code. If links appear only after you click on the hamburger in your browser but are missing from the DOM rendered by Google, you have an issue.

What technical solution should I adopt to remain crawlable?

The cleanest method: include all links in the initial HTML and visually hide them via CSS. Your mobile menu can remain completely invisible (max-height:0; overflow:hidden; or transform:translateY(-100%)) until the user clicks the hamburger icon — at which point you add a CSS class that animates the appearance.

Avoid frameworks that generate navigation via ReactDOM.render() or Vue.createApp().mount() only after an onClick event. Prefer conditional rendering on the server side or a JavaScript hydration of already present HTML. Next.js and Nuxt in SSR/SSG mode handle this natively — but always check the final result.

What should I do if my current frontend architecture is incompatible?

If a complete overhaul isn’t feasible in the short term, several workarounds exist. You can duplicate critical links elsewhere in the DOM — for example, in a desktop footer hidden on mobile, or via a secondary navigation component with display:none but present in the source code. Not elegant, but functional.

Another option: compensate with a strengthened internal linking in editorial content. If your product categories aren’t crawled via the mobile menu, make sure they are linked from "Popular Products" blocks, breadcrumbs, or contextual recommendations present on each page — and of course, all in the initial DOM.

• Inspect the raw HTML source code (not the developer DOM) to verify the physical presence of <a> tags
• Test the URL with Google's "URL Inspection" tool and compare the rendered DOM to the initial source code
• Prefer SSR/SSG frameworks (Next.js, Nuxt, Gatsby) that include the links from the server-side HTML
• Use only CSS to hide/show mobile navigation, never generate JS conditionally post-click
• Audit server logs to detect under-crawled pages despite their presence in the sitemap
• Compensate for the weaknesses of the mobile menu with enhanced editorial internal linking on key pages