Mobile Navigation and Hamburger Menus: SEO Best Practices

Here is a belief I hear from many business owners: “Our desktop menu has all the links, so Google sees our full site structure. The mobile menu is just a smaller version for phones.” For years that was close enough to true. Today it is the wrong way round.

Google now crawls and indexes most sites as a smartphone. That means your mobile menu is the one that tells Google how your pages connect. If your hamburger menu shows only six links while your desktop mega menu shows sixty, Google may be seeing a much thinner site than you think. And if the mobile menu only loads its links when someone taps the icon, Google may not see those links at all.

Let me explain how mobile-first indexing affects menus, how to check link parity between desktop and mobile, the pros and cons of hamburger menus, tab bars and bottom navigation, how to build menu markup Google can crawl, tap-target sizes, and how to test exactly what Googlebot sees.

Why your mobile menu is now the menu Google reads

Mobile-first indexing simply means Google mainly uses the mobile version of a page to index and rank it. In October 2023, Google’s Search Central blog announced that mobile-first indexing has landed, marking the end of a switch that began years earlier. If you want the backstory, our article on the mobile-first indexing rollout covers it, and our beginner lesson on mobile-first indexing explains the basics.

Google’s Googlebot documentation puts the crawling side plainly: for most sites Google Search primarily indexes the mobile version of the content, and the majority of Googlebot crawl requests are made with the mobile crawler.

For navigation, this has three practical effects:

• Links that exist only on desktop may count for less, or not at all. If a category is linked only from the desktop mega menu, the mobile crawler may find it only through other routes, such as the sitemap or internal links in content.
• Menu links that need a tap to load may be invisible. Googlebot doesn’t tap hamburger icons.
• Your mobile menu shapes internal linking. Which pages appear in it, and how deep, affects how Google understands which pages are most important.

If you want the full picture of navigation beyond mobile, our guide to website navigation for SEO covers menus, footers and hierarchy in general.

Desktop and mobile link parity: what has to match

Google’s mobile-first indexing best practices say your mobile site should contain the same content as your desktop site, use the same clear headings, and carry the same structured data. The page does not single out menu links, but the logic carries over directly: if a link is part of how users and crawlers reach a page on desktop, it should exist on mobile too.

Parity doesn’t mean the menus must look the same. It means the links must be present in the mobile HTML. A hamburger menu that holds all 60 links in collapsed lists is fine. A mobile menu that drops 54 of them is not.

Navigation element	Parity needed?	Acceptable mobile version
Main category links	Yes	Inside the hamburger, in collapsible groups
Subcategory links in a mega menu	Yes, for those you want indexed and ranked	Nested accordions inside the menu, links present in HTML
Breadcrumbs	Yes	Shortened or scrollable breadcrumbs, still real links
Footer links	Mostly	Collapsible footer sections
Promotional banners in the menu	No	Can be dropped
Sidebar “popular posts”	Helpful but optional	Moved below content

Breadcrumbs deserve a special mention. On mobile they are often hidden to save space, yet they are one of the cleanest ways to show hierarchy. Our guide to breadcrumb navigation shows how to keep them compact on small screens.

How to measure link parity in practice

1. Pick five key templates: home page, a category, a product or service page, a blog post and a location page.
2. Crawl each with a desktop user agent and with a smartphone user agent. Most desktop crawlers let you switch the user agent and render JavaScript.
3. Export the internal links found on each page in both modes.
4. Compare the lists. Note every link that exists on desktop but not on mobile.
5. For each missing link, decide: add it to the mobile menu, add it elsewhere on the mobile page, or accept that it doesn’t need to be in navigation.

If your site serves the same HTML to every device and only changes the layout with CSS (called responsive design), the lists will usually match. Differences tend to appear on sites with separate mobile templates, dynamic serving or JavaScript-built menus.

Hamburger, tab bar or bottom navigation: which pattern fits

There is no single right mobile menu. Each pattern trades visibility for space.

Pattern	Strength	Weakness	Good fit
Hamburger menu (icon that opens a drawer)	Holds a lot of links; tidy	Hidden by default, so less discoverable	Large stores and content sites with deep structure
Visible top links or scrollable tab bar	Main sections always visible	Room for only 3–6 items	Sites with a few key sections
Bottom navigation bar	Easy thumb reach; always visible	Very limited space; can feel app-like	Web apps, marketplaces, account areas
Combo: visible top links plus hamburger	Best of both	Needs careful design to avoid clutter	Most business sites

The usability research leans toward showing your most important links. In a 2016 Nielsen Norman Group study with 179 participants across six sites, hiding global navigation hurt the experience on both desktop and mobile, although the effect was smaller on mobile and varied by site. On mobile, navigation use ranged from 89% on one site to 44% on another where the menu icon was low-contrast and tucked beside the logo. The study is from 2016, so I treat the exact numbers as dated, but the direction still holds: a hamburger icon that people can’t spot is a menu people don’t use.

Ahrefs’ guide to website navigation (February 2023) makes the same point in one line:

“Hidden navigation is less discoverable, so make it visible by default if it’s important.”

— Ahrefs, Website Navigation Best Practices for SEO

From an SEO point of view, the pattern matters less than the markup. A hamburger menu with all links in the HTML is perfectly crawlable. A beautiful bottom bar with five links and no route to your subcategories leaves Google relying on other paths. My usual suggestion: show 3–5 of your most important sections visibly, and keep the full structure in a hamburger menu whose links are present in the page code.

Menu markup Google can actually crawl

This is where most mobile menu SEO problems really live. Google’s guide to making links crawlable says Google can generally only crawl links that are <a> elements with an href attribute, and that it can’t reliably extract URLs from <a> elements without one.

Compare these menu items:

<!-- Crawlable -->
<a href="https://example.com/mens-boots/">Men's boots</a>

<!-- Not reliably crawlable -->
<span onclick="openPage('mens-boots')">Men's boots</span>
<a onclick="goto('/mens-boots/')">Men's boots</a>
<a href="javascript:goTo('mens-boots')">Men's boots</a>

Then there is the bigger risk: menus that don’t exist until someone taps. Google’s mobile-first guidance is direct about this:

“Google won’t load content that requires user interactions (for example, swiping, clicking, or typing) to load.”

— Google Search Central, Mobile site and mobile-first indexing best practices

That sentence is about content in general, but it applies to menus. There are two very different ways to build a hamburger menu:

• Hidden but present: all menu links are in the HTML when the page loads, and CSS hides the drawer until the icon is tapped. Google can see the links.
• Loaded on tap: the drawer is empty until a tap triggers JavaScript to fetch and insert the links. Google likely never sees them.

The first is safe. The second is a common reason why sites with “perfect” menus still have orphaned categories in Google’s eyes.

A clean pattern for an accessible hamburger menu

<button aria-expanded="false" aria-controls="site-menu">Menu</button>
<nav id="site-menu" aria-label="Main">
  <ul>
    <li><a href="https://example.com/boots/">Boots</a>
      <ul>
        <li><a href="https://example.com/boots/hiking/">Hiking boots</a></li>
        <li><a href="https://example.com/boots/work/">Work boots</a></li>
      </ul>
    </li>
  </ul>
</nav>

A real <button> toggles the menu, the button tells screen readers whether the menu is open, and every destination is a normal link. JavaScript only switches visibility. This also helps keyboard and screen reader users, which overlaps nicely with SEO; our guide on accessibility and SEO covers more of that overlap.

Also check that your page has a correct viewport tag, because without it your “mobile” menu may not render as intended on phones at all. Our guide to the viewport meta tag explains it.

Tap targets and thumb-friendly menu design

A mobile menu that Google can crawl but people can’t use still loses you sales. Tap targets are the buttons and links people press with a finger. Too small or too close together, and people tap the wrong thing.

The Web Content Accessibility Guidelines 2.2 set a minimum at Level AA. According to the W3C’s explanation of Success Criterion 2.5.8:

“The size of the target for pointer inputs is at least 24 by 24 CSS pixels, except when:”

— W3C, Understanding SC 2.5.8: Target Size (Minimum)

The exceptions include enough spacing around smaller targets. The stricter Level AAA criterion, 2.5.5 Target Size (Enhanced), asks for more, and is worth aiming for on main menu items.

Practical menu guidelines I suggest:

• Make each main menu row tall enough to tap comfortably, well above the 24-pixel minimum.
• Make the whole row tappable, not only the text.
• Separate “open submenu” arrows from the link itself, and make both large enough. A tiny arrow beside a link is a classic mis-tap.
• Label the menu icon. A visible word “Menu” next to the icon helps people who don’t recognize the symbol.
• Keep the menu button where thumbs can reach it, and make it high contrast.
• Avoid menus that cover the whole screen with no obvious close button.

If you want to go further into how navigation affects conversions, our conversion rate optimization team tests these patterns on real traffic.

Testing what Googlebot sees in your mobile menu

Don’t guess. Here is a straightforward testing routine that needs only free tools:

1. Search Console URL Inspection. Inspect a key page, run a live test and open the tested page’s HTML. Search it for a few menu links, such as a deep subcategory URL. If they’re there, Google can see them.
2. View source versus rendered HTML. In Chrome, “View page source” shows the HTML before JavaScript. DevTools’ Elements panel shows it after. If menu links exist only in the second, your menu depends on JavaScript rendering, which Google can usually handle, but only if no tap is needed.
3. Device emulation with the menu closed. In Chrome DevTools, switch to a phone viewport, reload, and without touching the menu, run document.querySelectorAll('nav a[href]').length in the Console. Compare that number with desktop.
4. A smartphone-user-agent crawl. Crawl the site with a smartphone user agent and JavaScript rendering on, then look for pages with very few internal links pointing to them. Those may be pages only your desktop menu reached.
5. Check click depth. If a category is three clicks from the home page on desktop but six on mobile, it gets less internal link support. Our guide to click depth and SEO explains why that matters.

A worked example: the missing subcategories

Example (hypothetical): An outdoor-gear store has 12 main categories and 140 subcategories. The desktop mega menu links to all 152. The mobile menu was rebuilt as an app-style drawer that shows the 12 main categories and loads subcategories through an API call when a shopper taps a category.

A smartphone crawl finds 12 menu links per page instead of 152. Of the 140 subcategories, 38 are linked from nowhere else except the desktop menu and the XML sitemap. In Search Console, several of those 38 show “Discovered – currently not indexed.”

The fix is to render all 152 links in the initial HTML, inside collapsed accordions, so the drawer only toggles visibility. The design stays the same for shoppers. After the change, a new smartphone crawl finds the full set of menu links, and the team monitors indexing for the 38 subcategories over the following weeks.

I can’t promise what would happen to rankings in a case like this, because many factors play in. But the crawl gap is real and measurable, and closing it removes one obvious obstacle.

Mobile menu errors that quietly cost you traffic

These are the problems I would check first on any mobile navigation:

Error	Why it hurts	Fix
Menu links loaded only on tap	Google doesn’t tap, so it may never see them	Put links in the HTML; toggle visibility with CSS
Mobile menu much smaller than desktop menu	Weaker internal links to dropped pages	Restore key links in collapsible groups
Menu items built with span or div click handlers	Not reliably crawlable	Use <a href>
Hidden breadcrumbs on mobile	Loses hierarchy signals and a navigation aid	Show compact breadcrumbs
Tiny or cramped tap targets	Mis-taps and frustrated users	Follow WCAG 2.5.8 at minimum
Unlabeled, low-contrast menu icon	Users don’t find the menu	Add a label and contrast
Menu overlay shifts layout on load	Hurts Cumulative Layout Shift	Reserve space or render without shifting
Duplicate mobile and desktop headers in HTML	Repeated links and sometimes duplicate H1s	One responsive header

That last row is a sneaky one. Some themes output two full headers, one for desktop and one for mobile, and hide one with CSS. It doesn’t usually break anything, but it doubles your navigation links and can create duplicate headings. Our guide to multiple H1 tags explains when that matters.

Also be careful with the number of links. A full mega menu in a hamburger can add hundreds of links to every page. That’s not automatically a problem, but it dilutes the signal of which pages matter most. Our guide on how many internal links per page is too many covers that balance, and our faceted navigation guide handles filter links in menus.

Questions owners ask about mobile menus and SEO

Are hamburger menus bad for SEO?

No. A hamburger menu is fine for SEO if its links are real <a href> links present in the HTML when the page loads. The bigger concern is usability, because hidden menus are less discoverable.

Does Google see links inside a collapsed mobile menu?

Yes, if they are in the page’s HTML and only hidden with CSS. If the links are fetched by JavaScript after a tap, Google likely won’t see them.

Do my mobile and desktop menus need to be identical?

They don’t need to look the same, but important links should exist in both. Google mainly indexes the mobile version, so links missing on mobile may not support the pages they point to.

How big should tap targets be in a mobile menu?

WCAG 2.2 Level AA sets a minimum of 24 by 24 CSS pixels, with spacing exceptions. For main menu items, aim larger so they are comfortable to tap.

Is a bottom navigation bar better than a hamburger menu?

It depends on your site. A bottom bar keeps a few key sections visible and easy to reach, but it can’t hold your full structure. Many sites pair a few visible links with a hamburger for the rest.

Checking your own mobile menu this week

In brief: your mobile menu is now the version Google relies on, so treat it as your main navigation, not a cut-down copy. Keep important links in the HTML, use real links, show your top sections visibly, make tap targets comfortable, and test with a smartphone crawl rather than trusting what you see on desktop.

Start with one template, your main category or service page, and run the five-step test above. If you find a gap, fixing it is usually a template change, not a redesign. For a full review of mobile usability and technical issues, see our mobile SEO guide, or ask our SEO team to look at it with you. Get in touch for a quote.

Further reading on mobile navigation SEO

• Image Sitemaps: Do You Need One?
• SVG, Icons and Background Images: What Google Can Index
• Related Posts Modules: Internal Links That Actually Help

Sources for this mobile navigation SEO guide

1. Google Search Central: Mobile site and mobile-first indexing best practices
2. Google Search Central Blog: Mobile-first indexing has landed
3. Google Search Central: Googlebot
4. Google Search Central: Link best practices for Google
5. Ahrefs: Website Navigation Best Practices for SEO
6. Nielsen Norman Group: How to Make Navigation (Even a Hamburger) Discoverable on Mobile
7. W3C: Understanding SC 2.5.8 Target Size (Minimum)