Is hidden content in tabs truly indexed in mobile-first?

Why does Google make a distinction between initial and dynamic loading?

The answer lies in how Googlebot crawls mobile pages. When indexing a URL in mobile-first, it simulates a smartphone and loads the page just once. It then analyzes the DOM as it appears after the initial JavaScript rendering, without simulating clicks, scrolls, or interactions.

If your content requires a user action (clicking a tab, a "See more" button, hover) to trigger an AJAX call or delayed loading, Googlebot will never see it. The bot isn't tasked with testing all possible interactions on every crawled page. It only takes the first state of the DOM once JavaScript has executed.

This limitation has major implications for SPA (Single Page Application) architectures and rich JavaScript interfaces. Many modern frameworks (React, Vue, Angular) load conditional content that only appears after interaction. If this content is not present in the initial client-side rendered DOM, it is invisible to the index.

What does "loaded on page load" really mean?

The term refers to any content present in the DOM once the initial JavaScript rendering is complete. In other words: Googlebot loads the URL, executes the JS, waits a few seconds (usually a maximum of 5 seconds), then freezes the state of the DOM and indexes what it sees at that precise moment.

If your tabs are coded with HTML that is already present but hidden via CSS (display:none, visibility:hidden, aria-hidden), the content is indeed indexable. However, if your tabs only load HTML on click (via fetch() or XMLHttpRequest), that content does not exist at the time Googlebot analyzes the page. Therefore, it will not be indexed.

How can you check what Googlebot actually sees?

Use the mobile-friendly test tool in Search Console (formerly Mobile-Friendly Test). This tool simulates the behavior of Googlebot on mobile and shows you the rendered HTML after JavaScript execution. Compare this rendering with what you see in your browser's inspector after clicking on each tab.

Another option: request the HTML rendering via the URL Inspection Tool in Search Console. The "More info" tab > "View tested page" > "HTML" shows you exactly what Google has indexed. If your tab content does not appear here, it is not indexed.

• Indexable content: HTML present in the initial DOM, even hidden by CSS
• Non-indexable content: HTML loaded after a click, hover, or user interaction
• Technical solution: load all tabs at initial rendering and hide them with CSS or aria-hidden
• Verification tool: Search Console > URL Inspection > Rendered HTML
• SEO impact: content invisible to Googlebot contributes neither to ranking nor keyword indexing

Does this statement align with real-world observations?

Yes, but with important nuances. I've observed cases where content loaded very quickly after the initial rendering (within the first 2-3 seconds) was sometimes indexed, likely because Googlebot waits a certain period before freezing the DOM. However, relying on this is risky: wait times vary depending on server load, JS complexity, and the crawl budget allocated.

In practice, I've seen sites lose key positions after migrating to a dynamic tab architecture without pre-loading. The content literally disappeared from the index. Google does not crawl the same URL twice to test different interface states. If your content isn't there on the first pass, it's over.

What are the gray areas of this rule?

Mueller does not specify what happens to content loaded via Intersection Observer (lazy loading on scroll). If a tab becomes visible through automatic scroll or progressive enhancement, is it indexed? [To be verified] Official documentation remains vague on this point. My tests suggest that content visible in the initial viewport is indexed, but not content located further down even though it is technically "loaded" in the DOM.

Another edge case: nested accordions. If content is hidden in a tab that itself is within another tab, does Google index it if the HTML is present? Yes, but with lesser weight than content that is directly visible. Google understands the visual hierarchy and adjusts the weight of signals accordingly. Content hidden in three levels of tabs will have less impact than content displayed by default.

When does this rule not apply?

On desktop, historically, Googlebot was more lenient. Before the switch to mobile-first, the desktop bot sometimes executed basic interactions (expanding accordions, loading basic lazy load). But since mobile-first indexing has become the norm for most sites, this exception has disappeared. Do not rely on the desktop bot to salvage poorly architected content.

Notable exception: sites explicitly excluded from mobile-first (very rare now, mainly legacy non-responsive sites). For them, the old desktop logic still applies, but this situation is temporary. Google is gradually migrating all sites, and no new site escapes mobile-first from its initial indexing.

How can I audit the tab architecture on my site?

Start by identifying all pages using tab interfaces, accordions, or hidden content. List the affected templates: product sheets, service pages, FAQs, landing pages. For each template, inspect the source code and verify whether the HTML for all tabs is present from the initial loading or is loaded dynamically.

Use Search Console to compare the raw HTML (Ctrl+U in the browser) with the rendered HTML (URL Inspection > View tested page). If you notice significant discrepancies, particularly content that appears in the browser but not in the Google rendering, you have an indexing issue. Prioritize strategic pages: those that generate organic traffic or target priority keywords.

What technical solution should I adopt to ensure indexing?

The most reliable method: pre-load all tabs in the DOM and hide them using CSS (display:none or visibility:hidden). The content is technically present in the source code, making it indexable, but invisible until the user clicks on the relevant tab. This approach works with all modern frameworks.

If your tabs contain a lot of content (which could slow down initial loading), opt for server-side rendering (SSR) or static site generation (SSG). Next.js, Nuxt.js, and Gatsby allow you to generate the complete HTML server-side, sent directly to the bot without depending on client-side JavaScript. Another option: progressive lazy loading using Intersection Observer, but be cautious of the gray areas mentioned earlier.

What mistakes should I absolutely avoid?

Classic mistake: implementing tabs using React or Vue in pure SPA mode without SSR, where each tab corresponds to an empty default state component. Content loads on click via a useState() or a conditional v-if. For the user, it’s smooth. For Googlebot, it’s a black hole.

Another trap: using hash fragments (#tab1, #tab2) to control tab display without pre-loading content. Google ignores hash fragments and does not crawl URL variants with different anchors. If your content only exists when the URL contains #tab2, it will never be indexed. Prefer query parameters (?tab=2) or, better yet, pre-loaded content.

• Ensure all tabs are present in the initial DOM (no conditional AJAX loading)
• Test each affected template via the URL Inspection in Search Console
• Compare the raw HTML (Ctrl+U) with the HTML rendered by Google
• Migrate to SSR or SSG if the current architecture relies on conditional loading
• Avoid hash fragments to manage tab display
• Favor display:none or visibility:hidden rather than delayed loading