Is it true that hidden content in tabs and accordions is actually considered by Google?

What exactly does “loaded but hidden content” mean?

Google refers here to content present in the DOM (Document Object Model) at the initial page load but visually hidden through CSS or JavaScript. Typically: tabs, accordions, dropdown menus, or sections revealed upon clicking.

The crucial nuance: the content must be in the default HTML, not loaded via lazy-loading after user interaction. If your accordion requires an Ajax call to retrieve the text on click, Google will not see it during the initial crawl.

Why is this statement important for mobile-first indexing?

With the shift to mobile-first indexing, Google uses the mobile version of your page as the reference for ranking. On mobile, hiding content behind tabs is a common UX practice to avoid endless pages.

This official confirmation alleviates a widespread concern: no, visually hiding content to enhance the mobile experience does not dilute its SEO value. The bot crawls the source HTML, not the visual display.

How does this differ from cloaking or banned techniques?

Cloaking involves serving different content based on the user-agent (Googlebot vs. user). Here, we are talking about identical content for everyone, just displayed differently via CSS.

Google clearly distinguishes these two practices. Hiding content using display:none or visibility:hidden for legitimate UX reasons has never been considered spam—provided the content is relevant and accessible to the user when needed.

• Hidden content must be present in the initial HTML—not loaded later after interaction.
• CSS/JS hiding techniques (tabs, accordions) are normally treated by Google.
• Mobile-first indexing uses the mobile version as a reference, even if content is visually hidden.
• Key difference from cloaking: same HTML for everyone, only the visual presentation changes.
• The display context (active tab vs. inactive) does not affect the SEO value of the content present in the DOM.

Is this statement consistent with field observations?

Yes, but with persistent gray areas. Field tests show that content in inactive tabs or closed accordions is indeed indexed—as long as it’s in the source HTML. Featured snippets are regularly extracted from visually hidden content.

However, [To be verified]: several studies suggest that visible content at load time may carry slightly more weight in the algorithm. Google has never officially confirmed or denied this nuance. Field caution recommends prioritizing critical information for visible display.

What are the practical limits of this rule?

First trap: content loaded via lazy-loading after interaction (Ajax request triggered on click) will not be crawled during Googlebot's initial pass. If your accordion makes a fetch() call on click to retrieve the text, Google may never see it.

Second nuance: Mueller specifies “as long as it is already in the default HTML.” Some JavaScript frameworks (React, Vue) render content client-side after initial load. If the content does not appear in the raw source HTML (View Page Source), even if it displays correctly in the browser, indexing remains uncertain.

In what cases does this rule not apply?

It does not apply to content generated dynamically after user interaction (API calls, infinite scroll without pre-rendering). It also does not apply to pop-ups or modals triggered by complex JavaScript events—Google can see them, but their treatment remains unpredictable.

Another borderline case: content hidden for misleading reasons (invisible keyword stuffing for the user but present for bots) remains sanctionable. The red line: intent. If hidden content serves the user experience, it’s okay. If it only serves SEO, sanction is likely.

What should you do concretely on your current pages?

Audit your tabs, accordions, and dropdown menus: is the content present in the source HTML (right-click > View Page Source)? If yes, you are compliant. If no, prefer an implementation that injects content into the DOM at load time, hidden via CSS.

For heavy JavaScript sites (React, Vue, Angular), implement Server-Side Rendering (SSR) or static generation (SSG) to ensure critical content is in the initial HTML. Next.js, Nuxt, or solutions like Prerender.io can solve this issue.

What mistakes should you absolutely avoid?

Never load SEO-critical content only via Ajax after user click. Google can theoretically execute JavaScript and trigger events, but it’s slow, costly on crawl budget, and unreliable. The content must be there from the first HTML render.

Avoid also hiding large content without user logic. If you hide 5000 words behind a “Technical Specifications” tab that no one ever clicks, Google might see it as an attempt to manipulate. UX/SEO consistency remains the rule.

How can you check that your implementation is correct?

Use the URL Inspection tool from Google Search Console: enter the URL, click “Test Live URL,” then “View Crawled Page.” Check in the HTML tab if the content from your tabs/accordions is present. If not, your implementation is faulty.

Also compare the raw HTML rendering (View Source) with the JavaScript rendering (Inspect Element). If the content only appears in the latter, Googlebot may not see it reliably, despite its JavaScript execution capabilities.

• Ensure that the hidden content is present in the raw source HTML (not just in the DOM after JS).
• Test with the URL Inspection tool from Search Console to see what Google actually crawls.
• Prefer tabs/accordions in pure CSS or lightweight JS with pre-loaded content in the DOM.
• Avoid lazy-loading Ajax for SEO-critical content—reserve this technique for images or secondary content.
• Implement SSR/SSG for SPAs to ensure a complete initial HTML.
• Maintain UX/SEO consistency: hidden content should serve a legitimate user function, not just SEO.