The content was hidden to the user behind accordion dropdowns
- March 3, 2022
- Crawling and Indexing
AI Summary
Yes, content tucked inside accordions, tabs, and read more dropdowns is indexed and counted at full weight, provided it exists in the rendered HTML rather than being fetched only after a user click. Since mobile first indexing became the default, the old idea that hidden by default text is discounted no longer holds.
- Hidden by CSS is fine: if the text is in the DOM, Google can index it.
- The real risk is content that loads by a network request triggered on click.
- Confirm with the URL Inspection tool and the rendered HTML, not the raw source alone.
- Mobile first indexing removed the historical penalty on collapsed content.
The question behind this case is one every technical practitioner eventually hits: if a block of copy sits inside a collapsed accordion or a tabbed panel, does Google actually read and rank it? The short answer today is yes, but the reason matters more than the answer, because the same interface pattern can either be perfectly safe or quietly invisible depending on how it is built.
The distinction that decides everything is where the text lives. When an accordion hides its panel with a CSS rule such as display:none or a height clamp, the words are still present in the HTML that the browser and Googlebot receive. The crawler parses the full Document Object Model, sees the copy, and indexes it. Hiding something visually is not the same as withholding it from the machine. This is why a page can rank for a phrase that a human never sees until they click to expand a section.
Why the fear existed in the first place
For years the community repeated that hidden text carried reduced weight. That belief had a real basis before mobile first indexing. Google historically evaluated the desktop experience, where expandable sections were often used to push secondary content out of view, so it made sense to discount copy that was hidden on load. Once mobile became the primary crawl, accordions and tabs stopped being a workaround and became the expected mobile pattern, so treating them as second class no longer fit how the web is built. Google representatives have said repeatedly that content in tabs and expandable regions is weighted normally under mobile first indexing.
The failure mode that still bites
The trap is not CSS hiding. The trap is deferred loading. Some accordions do not contain their text at all on the first response. Instead the click handler fires a request to an API endpoint, receives a payload, and injects the result into the DOM. Googlebot does render JavaScript, but it does not click. If the copy only materializes after a user interaction that triggers a fetch, the crawler may never obtain it, and the section is effectively unindexed. The same is true for content that waits on an intersection observer or a scroll event that the headless renderer does not reproduce.
How to verify what is really indexable
Do not trust the raw view source, because it shows the pre render HTML. Use the URL Inspection tool in Search Console, run a live test, and read the rendered HTML tab. If your accordion copy appears there, you are safe. You can also open the page, disable JavaScript, and check whether the text still exists in the markup, which quickly separates CSS hidden content from click fetched content. A site search for a distinctive sentence from inside the panel is a fast production check once the page has been crawled.
What has changed since
Mobile first indexing is now the default for essentially the entire web, which retires the old weighting concern for good. The live area of risk has shifted to JavaScript delivery. As more design systems lazy load panel content for performance, the gap between what renders for a user and what renders for a crawler widens. The practical guidance in 2026 is simple: keep primary content in the server rendered HTML, reserve on click fetching for genuinely secondary material, and treat any revenue relevant copy inside an accordion as something to confirm in the rendered DOM rather than assume.
If canonical selection or crawl efficiency is also on your list, the neighboring studies on how Google chooses a canonical and quality indexation on large sites pair well with this one, and the full crawling and indexing case study library collects the related patterns.
Accordion patterns and indexing outcome
| Build pattern | Text in initial DOM? | Indexed? | Notes |
|---|---|---|---|
| CSS collapsed panel | Yes | Yes | Full weight under mobile first |
| Tabs with all panels in markup | Yes | Yes | Same as visible content |
| Click triggers API fetch | No | Often no | Crawler does not click or fetch |
| Content on scroll or observer | Usually no | Risky | Headless render may not trigger it |
| Server rendered, JS enhances | Yes | Yes | Safest option for key copy |
Frequently asked questions
Does Google index text hidden in an accordion?
Yes. If the text is present in the rendered HTML and only hidden with CSS, Google indexes it and, under mobile first indexing, weighs it the same as visible content.
Is hidden content penalized?
No. There is no penalty for using accordions or tabs. The historical weighting concern applied before mobile first indexing and no longer holds for standard collapsed content.
When does accordion content fail to index?
When the copy is not in the initial response and only loads after a click that fires a network request. Googlebot renders JavaScript but does not interact, so fetch on click content can be missed.
How do I check if my hidden content is indexed?
Use the URL Inspection tool, run a live test, and read the rendered HTML. You can also disable JavaScript and confirm the text still exists in the markup, then run a site search for a unique sentence.
Should I put important content in an accordion?
You can, as long as it renders into the DOM on load. Keep primary, revenue relevant copy in the server rendered HTML and reserve deferred loading for secondary material.
This SEO case study documents a successful optimization initiative, providing actionable insights for practitioners. The documented approach demonstrates how strategic SEO implementation drives measurable results.
Initial Situation
Understanding the starting point is essential context for evaluating any case study. This documentation covers the initial challenges, competitive position, and business objectives that shaped the SEO strategy.
Strategy and Approach
The strategic approach combined multiple SEO disciplines to address identified opportunities. Key decisions around prioritization and resource allocation provide a template for similar initiatives.
Implementation
Moving from strategy to execution required specific technical implementations, content development, and process changes. This case study documents the practical steps that translated strategy into action.
Results and Learnings
The outcomes demonstrate effectiveness through measurable improvements in rankings, traffic, and business metrics. Analysis of successes and challenges provides learning value for practitioners.
Case studies like this contribute to the SEO knowledge base, helping practitioners learn from documented real-world experiences.
Claude Vincent is a technical SEO consultant focused on crawlability, rendering, and AI-search visibility. He writes the field guides and case studies at SEO ProCheck, with a bias toward the durable, unglamorous work that decides whether search engines and AI answer engines can actually read and cite a site.
About SEO ProCheck
Technical SEO consulting and GEO strategy with 20 years of enterprise experience. Case studies, resources, and tools for search and AI visibility.
Work With Me
Technical SEO audits, GEO strategy, site migrations, and international SEO. Hourly consulting for teams who need hands-on support, not just reports.
Subscribe to our newsletter!
