What does Google say about SEO? /
Quick SEO Quiz

Test your SEO knowledge in 5 questions

Less than a minute. Find out how much you really know about Google search.

🕒 ~1 min 🎯 5 questions

Official statement

Hamburger menus that conceal links until clicked are perfectly acceptable as long as the links are not dynamically loaded after the click but are available upon page loading.
27:25
🎥 Source video

Extracted from a Google Search Central video

⏱ 59:22 💬 EN 📅 09/02/2017 ✂ 13 statements
Watch on YouTube (27:25) →
Other statements from this video 12
  1. 12:12 Les backlinks pointant vers une page AMP bénéficient-ils vraiment à la version HTML canonique ?
  2. 17:46 Les textes en pied de page nuisent-ils vraiment au référencement de votre site ?
  3. 18:30 Combien de temps faut-il vraiment pour qu'un changement de métadonnées impacte vos positions ?
  4. 21:11 Googlebot indexe-t-il vraiment les images en lazy loading ?
  5. 25:45 Les pop-ups intrusifs détruisent-ils vraiment votre SEO ?
  6. 29:20 Le Data Highlighter vaut-il encore le coup face au JSON-LD ?
  7. 42:00 Pourquoi Google réécrit-il vos balises title et meta description sans vous demander votre avis ?
  8. 46:00 Le masquage de contenu en mobile est-il vraiment sans risque pour le SEO ?
  9. 53:02 Le code 503 est-il vraiment l'ami du SEO en cas de surcharge serveur ?
  10. 54:20 Les erreurs 410 nuisent-elles vraiment au référencement de votre site ?
  11. 55:44 Hreflang et sous-domaines multilingues : contenu dupliqué ou non ?
  12. 57:30 Pourquoi diviser ou fusionner des domaines ralentit-il votre visibilité SEO ?
📅
Official statement from (9 years ago)
TL;DR

Google confirms that hamburger menus pose no crawling or indexing issues, provided that the links are present in the DOM at initial load, not loaded via AJAX or JavaScript after interaction. This technical distinction is crucial for mobile-first architecture. Specifically, a CSS-hidden menu is fine, while a dynamically generated menu after a click hinders crawling.

What you need to understand

Why this distinction between CSS hiding and dynamic loading?

Googlebot analyzes the Document Object Model (DOM) as it exists after the initial rendering of the page. If your navigation links are already in the HTML code but simply hidden via display:none or a CSS class, the crawler can see and follow them without difficulty.

The problem arises when the hamburger menu triggers an asynchronous call (fetch, XMLHttpRequest) that retrieves the links from the server only after user interaction. In this scenario, Googlebot loads the page, sees no links in the initial DOM, and moves on. Your orphan pages will receive neither PageRank nor crawl authority.

How does this differ from past recommendations on hidden content?

For years, Google has stated that hiding content could be viewed as cloaking or manipulation. This warning mainly concerned editorial content: hiding entire paragraphs of text to mislead the algorithm.

Navigation menus operate under a different logic. They enhance mobile user experience, not keyword density manipulation. Mueller explicitly approves this common UX practice, provided the complete DOM rule is respected from the start.

Does Googlebot really simulate a click on the hamburger menu?

No. Googlebot does not simulate complex user interactions like clicks, hovers, or infinite scrolls without explicit signals. It executes the initial JavaScript, waits for rendering, and then analyzes the resulting DOM.

If your menu requires user action to exist in the code, it will never exist for the bot. This is why modern frameworks (React, Vue, Angular) must render critical links server-side (SSR) or include them in the initial bundle, not in a lazy-loaded chunk post-interaction.

  • Links hidden with pure CSS (visibility:hidden, display:none, position:absolute out of viewport) are crawlable without restriction
  • Menus that inject links via JavaScript after a user event block crawling of those URLs
  • SSR (Server-Side Rendering) or static generation ensure that the complete DOM is available from the first load
  • Google does not penalize hiding for mobile UX reasons, unlike hiding editorial content for manipulative purposes
  • This rule equally applies in mobile-first indexing: the mobile DOM must contain all essential links, even if hidden

SEO Expert opinion

Is this statement consistent with real-world observations?

Absolutely. It has been observed for years that e-commerce sites built with React or Vue that lazy-load their navigation after interaction see their category pages poorly crawled. Discovery rates of pages decline, the crawl budget concentrates on URLs already known via the sitemap, and internal linking loses all effectiveness.

In contrast, sites that adopt Next.js with SSR or Nuxt in universal mode maintain a smooth crawl, even with complex hamburger menus. The initial DOM contains the links, the bot sees them, end of story. No magic, just accessible HTML from the first render.

What gray areas remain despite this clarification?

Mueller does not clarify the relative weight of hidden versus visible links. We know that Google can weight a link in the main content differently than a link in the footer. Does a link in a CSS-hidden hamburger menu transfer as much PageRank as a link visible in traditional navigation? [To be verified] with rigorous A/B tests.

Another unclear point: progressive menus that load sub-levels of navigation on hover or click. If level 1 is in the DOM but levels 2-3 load via AJAX, does Google crawl these deep levels? Probably not, which poses a problem for sites with complex hierarchies. [To be verified] through rendering tests with the URL inspection tool in Search Console.

In what cases does this rule not suffice for optimal crawling?

Having links in the initial DOM is necessary but not sufficient. If your hamburger menu contains 200 links to low-relevance pages, you dilute PageRank and send mixed signals about the site's hierarchy. Google will crawl these links, but that doesn't mean it will value them.

Another pitfall: sites that apply nofollow to all their links out of fear of PageRank sculpting often end up with hamburger menus that are completely barren for crawling. If the goal is to retain juice on important pages, it is better not to include secondary links in the main menu, even if hidden. The presence in the DOM is not an obligation for blind linking.

Warning: Some CSS frameworks like Tailwind generate classes like "hidden" that use display:none, thus crawlable. However, other component libraries (Material-UI, Ant Design) may lazy-load content via JavaScript. Always check the final DOM in the Mobile-Friendly Test or via a curl of the page, not just in DevTools after manual interaction.

Practical impact and recommendations

What should you check immediately on your site?

Load your homepage in private browsing mode, open DevTools, go to the Elements tab, and search for your navigation links in the HTML code. If they are there, even with a CSS class hiding them, you are good. If they only appear after a click or event, you have a crawling issue.

Also, use the URL inspection tool in Search Console: request a live test, wait for rendering, and then check the rendered HTML code. Compare it with what you see in your browser after interaction. If the bot does not see the same links, your menu loads content asynchronously, and Google does not crawl it.

How to fix a hamburger menu that loads links via JavaScript?

If you are using a modern framework, enable Server-Side Rendering (SSR) or static generation (SSG). Next.js, Nuxt, SvelteKit: all offer modes that render complete HTML server-side before sending it to the client. Your links will exist in the initial DOM, even if the menu remains interactive.

For sites using jQuery or vanilla JavaScript, the simplest solution is to code the links directly in the HTML, then hide them with CSS. Replace your script that fetches /api/menu with <a href> tags present from the start, wrapped in a div with display:none by default. The JavaScript only needs to toggle the class, not create the content.

What mistakes to avoid when redesigning a mobile menu?

Do not test Googlebot rendering. Many developers validate UX in Chrome, see that the menu opens correctly on click, and consider the job done. Then three months later, the organic traffic of category pages plummets because Google no longer crawls them. Always use the Mobile-Friendly Test and URL inspection.

Another common mistake: adding nofollow directives to the hamburger menu links out of fear of diluting PageRank. If these links point to important pages (product categories, SEO landing pages), you undermine your own internal linking. Nofollow has its place on utility links (terms of service, legal notices), not on strategic navigation.

  • Inspect the initial DOM with DevTools and check for the presence of <a href> tags before any user interaction
  • Test rendering using the URL inspection tool in Search Console and compare with the source HTML
  • Enable SSR or SSG if the site uses React, Vue, or Angular to ensure a complete DOM from the first load
  • Replace AJAX navigation calls with CSS-hidden HTML links if the framework allows it
  • Audit nofollow attributes on menu links: remove those blocking crawling of strategic pages
  • Monitor the rate of discovered pages in Search Console after modifying the menu to validate the impact
Hamburger menus are not a problem for SEO as long as the links exist in the code from the page load. The real risk comes from JavaScript architectures that load navigation asynchronously after user interaction. Correcting this type of configuration often requires a technical overhaul of server-side rendering, expertise in crawl budget, and rigorous validation through Google tools. If these optimizations seem complex to implement alone or if you lack the technical resources to audit your site's architecture, working with a specialized SEO agency can save you months and avoid costly organic traffic mistakes. Personalized support allows prioritizing projects based on real impact and validating each change before deployment in production.

❓ Frequently Asked Questions

Est-ce que cacher des liens avec visibility:hidden pose un problème pour le crawl ?
Non, tant que les liens sont présents dans le DOM dès le chargement initial. visibility:hidden, display:none, opacity:0 ou position:absolute hors viewport sont tous crawlables par Googlebot.
Un menu burger chargé via un fetch() après clic empêche-t-il vraiment l'indexation des pages liées ?
Oui. Si les balises <a> n'existent pas dans le DOM avant interaction utilisateur, Googlebot ne les voit jamais. Ces pages peuvent quand même être indexées via sitemap ou backlinks externes, mais elles perdent tout le bénéfice du maillage interne.
Le poids SEO d'un lien dans un menu burger masqué est-il identique à celui d'un lien visible ?
Google n'a jamais confirmé de pondération différente. Empiriquement, un lien masqué en CSS semble transmettre du PageRank normalement, mais certains tests suggèrent qu'un lien visible dans le contenu principal peut avoir un poids relatif légèrement supérieur.
Comment vérifier si mon menu burger est crawlable sans DevTools ?
Utilise l'outil d'inspection d'URL dans la Search Console, demande un test en direct, puis consulte le code HTML rendu. Compare-le avec un curl de la page en ligne de commande : si les liens sont absents dans les deux, c'est qu'ils se chargent en JavaScript après interaction.
Est-ce que cette règle s'applique aussi aux mega-menus avec plusieurs niveaux de navigation ?
Oui, mais attention : si les sous-niveaux se chargent dynamiquement au survol ou au clic, ils ne seront pas crawlés. Tous les niveaux de profondeur pertinents pour le SEO doivent être présents dans le DOM initial, même masqués.
🏷 Related Topics
Domain Age & History AI & SEO Links & Backlinks Pagination & Structure

🎥 From the same video 12

Other SEO insights extracted from this same Google Search Central video · duration 59 min · published on 09/02/2017

🎥 Watch the full video on YouTube →

Related statements

💬 Comments (0)

Be the first to comment.

2000 characters remaining
🔔

Get real-time analysis of the latest Google SEO declarations

Be the first to know every time a new official Google statement drops — with full expert analysis.

No spam. Unsubscribe in one click.