Does Content Hidden in Tabs and Accordions Still Rank?

Does content hidden in tabs and accordions still rank?

Yes, if the text is already in the HTML and only the styling hides it. No, if a click is what fetches it. That single distinction settles almost every argument we have on this topic, and it has nothing to do with whether the section looks open or closed to a visitor.

The confusion is old. For years, SEO advice said hidden content was discounted, and designers heard that as "never use accordions". Meanwhile product teams kept using them, because a spec table with forty rows genuinely does not belong open by default.

Google's current documentation is clearer than the folklore. It is worth reading what it actually says before redesigning a page around a rule that no longer exists.

What does Google actually say about accordions?

It says they are fine. Google's mobile-first indexing guidance states that "you can have a different design on mobile to maximize user experience (for example, moving content into accordions or tabs); just make sure that the content is equivalent to the desktop site".

That is an explicit permission, naming accordions and tabs directly. The condition attached is about parity, not visibility. The mobile version has to carry the same content as the desktop version, because mobile-first indexing means the mobile version is the one Google uses.

So the design pattern itself is not the problem. As of September 2026, we cannot find any Google documentation that says collapsed text is weighted less. What the documentation does warn about is something else.

Where is the real line, then?

The line is whether the content exists before anyone clicks. Google's guidance on lazy loading is blunt: "Don't lazy-load primary content upon user interaction. Google won't load content that requires user interactions (for example, swiping, clicking, or typing) to load."

Read that next to the accordion permission and the picture is complete. An accordion whose panels are in the HTML and hidden with CSS is indexable. An accordion whose panels are fetched by JavaScript when the header is clicked is invisible to Google.

Both look identical to a visitor. They are opposite situations for a crawler. This is why the rule of thumb about accordions has stayed confusing for so long: the pattern is neutral and the implementation decides the outcome.

Why does "Google Search does not interact with your page" matter so much?

Because it removes any hope that the crawler will find content behind a gesture. Google states it directly in its lazy-loading guidance: "The methods mentioned don't rely on user actions, such as scrolling or clicking, to load content, which is important as Google Search does not interact with your page."

No clicking. No scrolling. No typing. Whatever the page renders on its own is the entire page as far as Search is concerned. Google's recommended techniques reflect that: native browser lazy loading for images and iframes, the IntersectionObserver API with a polyfill, or a library that loads data when it enters the viewport.

Notice the shape of all three. They react to the viewport, not to a person. A pattern that waits for a human is a pattern that waits forever when the visitor is a crawler.

How do you tell the two cases apart on your own site?

Read the rendered HTML. Google's own instruction for lazy-loaded content applies here too: "check the rendered HTML to make sure your content is in the rendered HTML by looking for it in URL Inspection Tool".

Open URL Inspection in Search Console, request the live URL, and look at the rendered HTML for a sentence that only appears inside a collapsed panel. If the sentence is there, you are fine. If it is not, the panel is fetching on click and the content is not in the index.

A faster local check works too. Disable JavaScript in your browser and load the page. Collapsed sections built with CSS will still have their text present in the source. Sections built to fetch on click will be empty. That check takes fifteen seconds and settles the question.

Do tabs and accordions hurt AI answer visibility?

The same rule carries over, for the same reason. Google says a page must be "indexed and eligible to be shown in Google Search with a snippet" to appear as a supporting link in AI Overviews or AI Mode. Content that never reached the index cannot be quoted by a feature that draws on the index.

What Google also says is that no extra work is required beyond that: "You don't need to create new machine readable files, AI text files, or markup to appear in these features. There's also no special schema.org structured data that you need to add." The requirements are the ordinary ones.

Our own view is that collapsed content is more of a risk for AI answers than for classic rankings, because an answer engine is looking for a self-contained passage it can lift. A paragraph buried in the fourth tab is technically indexed and practically easy to miss. We wrote about that retrieval behaviour in how page chunking affects AI retrieval.

When is an accordion the right design choice?

When the content is reference material that most readers do not need. Full technical specifications, legal terms, a long compatibility matrix, historical changelog entries, or the twelfth question in a support section. Collapsing those respects the reader who wants the other ninety percent of the page.

Tabs earn their place when the content is genuinely parallel and mutually exclusive. Pricing by plan. Setup instructions by operating system. Case studies by industry. A visitor picks one path and the others would only be noise.

We treat both as tools for managing attention, not for hiding weak content. The design reasoning behind that sits in our piece on progressive disclosure in web design.

When should the content just be on the page?

When it is the reason the page exists. If a searcher arrives asking what your product does, the answer should not be behind a tab labelled "Details". The same goes for pricing, for the problem you solve, and for whatever makes the page different from three competitors.

We also open content by default when it is short. An accordion holding two sentences is pure friction. The visitor pays a click to reveal less text than the header they clicked.

The debate we keep having with teams is about long FAQ sections. Our position is that the first three questions should be open and the rest collapsed, because the open ones do the persuading and the collapsed ones do the reassuring. We set that out in more detail in designing a FAQ section.

What about structured data inside collapsed sections?

Be careful here, because this is where a real policy applies. Google's structured data guidance says "don't add structured data about information that is not visible to the user, even if the information is accurate".

A collapsed panel is still visible content: the visitor can open it without leaving the page. Markup describing text that a visitor can reveal is a different thing from markup describing text that does not appear anywhere. The second is the problem.

Where we do get cautious is markup for content that was cut from the page but left in the JSON. That happens more often than people expect when a page is edited and the structured data is maintained separately. Keep them in sync, or generate the markup from the same content the page renders.

How should teams decide in 2026?

Stop asking whether hidden content ranks and start asking whether the content is in the HTML. That is the only version of the question with a clean answer. Design the page for the reader, then verify the implementation with URL Inspection.

The second question we ask is whether a collapsed section is protecting the reader or protecting the page. Reference detail behind a click is good design. A thin value proposition behind a click is a content problem wearing an interface.

If you have a page where the accordions might be eating your most important content, we are happy to check it. Send the URL through phoenix.studio and we will tell you what Google can see.