Do AI Answers Skip Content Inside Tabs and Accordions?

Do AI answers skip content hidden inside tabs and accordions?

They can, depending on how the content gets onto the page. Text that sits in the HTML but is visually collapsed is usually readable by crawlers. Text that only loads after a click or a script runs is at real risk. Google says it won't load content that requires user interaction, and not every bot runs JavaScript.

Tabs and accordions are everywhere on B2B websites. FAQ sections, pricing details, feature breakdowns, and integration lists often sit behind a click to keep pages tidy. That design choice is fine for people. The question is whether search engines and AI systems can read what is inside.

I get asked this often by teams who notice that AI answers about their product miss details that are clearly on the site. This article explains how I check whether hidden content is visible to crawlers, and how I decide what belongs behind a click and what does not.

What is the difference between hidden content and unloaded content?

Hidden content is already in the page's HTML and simply styled so it is collapsed until someone clicks. Unloaded content is not in the page at all until a click or script fetches it. Crawlers can read the first kind from the HTML. The second kind depends on whether the crawler triggers the action, and many will not.

This distinction matters more than the visual design. Two accordions can look identical to a visitor while behaving completely differently for a crawler. One ships all its answers in the HTML. The other fetches each answer only when opened.

So the question is never "do I use tabs?" It is "where does the text live when the page first loads?" Once you answer that, most of the risk becomes clear.

What does Google say about content that needs a click?

Google's mobile-first indexing guidance says Google won't load content that requires user interactions, such as swiping, clicking, or typing, to load. It also advises against lazy-loading primary content on user interaction. If your key text only appears after a click triggers a load, Google may never see it.

Google also explains that it processes JavaScript pages in three phases: crawling, rendering, and indexing, with a headless Chromium rendering the page when resources allow. Rendering helps with content that scripts add on page load. It does not mean Google clicks every tab to reveal what a click would fetch.

In the same documentation, Google notes that server-side or pre-rendering is still a great idea because not all bots can run JavaScript. That line matters for AI search, which I cover next.

Why is this a bigger risk for AI answers?

Because AI search relies on many different crawlers, and they do not all behave like Google. As Google itself notes, not all bots can run JavaScript. If an AI system's crawler reads only the raw HTML, any text that scripts add later, or that loads on click, may be invisible to it.

Most AI companies do not publish full details about how their crawlers render pages. I do not try to guess their internals. Instead, I make sure the important text is present in the initial HTML, which is the one thing every crawler can read.

There is a second, quieter issue. AI systems quote passages, not whole pages. If your clearest answers sit inside collapsed panels with vague labels, the passage that gets retrieved may lack context. I explain how passage selection works in why AI search quotes one paragraph of your page.

How do you check whether your tab content is in the HTML?

View the page source, not the rendered page, and search for a sentence that appears inside a tab or accordion. If the sentence is in the source, crawlers that read HTML can see it. If it is missing, the content is added later by scripts or loaded on demand, and you should treat it as at risk.

The browser's "view source" option shows the HTML the server sent. The developer tools inspector shows the page after scripts have run, which can be misleading for this check. Use view source.

Check a few tabs on each important page, especially FAQ sections, pricing details, and feature lists. On Webflow sites built with native elements, content is often in the HTML, but custom code, third-party widgets, and embedded apps can behave differently. Do not assume. Test the actual pages.

If you want a wider look at whether pages are being crawled and indexed at all, I covered the difference in crawling versus indexing for Webflow and AI search.

Which content should never sit behind a click?

Keep your primary answer to the page's main question out of tabs and accordions. That includes what the product does, who it is for, core pricing information, and the key facts buyers compare. Put that text in plain view near the top. Use collapsible elements for supporting detail, not for the answer itself.

A simple test helps. If a buyer, or an AI assistant, could read only the visible text on first load, would they understand the main point of the page? If not, something important is hidden.

FAQ sections are a common exception that works well, as long as the answers are in the HTML. Questions as visible labels with answers collapsed is a fine pattern. Answers fetched from somewhere else on click is not.

Should you remove tabs and accordions entirely?

No. Tabs and accordions are good design tools for long pages, and they help visitors scan. The goal is not to remove them but to use them for the right content and build them so the text ships in the HTML. Good structure for people and readability for crawlers can coexist.

I make the design decision separately from the crawler decision. First, does this content belong in a tab for the visitor's sake? Then, is the implementation crawler-friendly? Most design choices pass both tests with small changes.

If you are deciding between the two patterns for usability reasons, I compared them in Webflow tabs versus accordions. That piece covers the visitor side, and this one covers the crawler side.

How do you fix content that loads only on click?

Change the implementation so the text is in the initial HTML. Replace widgets that fetch content on demand with native elements, render the content server-side, or move the critical text out of the interactive component. Then recheck view source to confirm the sentence appears. Small implementation changes usually fix this without changing the design.

Third-party FAQ widgets and review carousels are frequent culprits. They often load content from an external service after the page loads. If that content matters for search or AI answers, consider moving it into your own CMS and rendering it as part of the page.

After the fix, give it time. Crawlers need to revisit the page before any change shows up in search results or AI answers.

What should you do next?

Pick your five most important pages and use view source to check that every sentence inside tabs and accordions is in the HTML. Move the primary answer for each page into plain view. Replace any content that loads only on click with native, server-rendered elements. Then recheck after crawlers revisit.

This is one of the quickest technical wins for AI visibility, because it removes a hidden barrier without changing what visitors see.

If you want help auditing how your Webflow pages present content to crawlers and AI systems, reach out. I am happy to check a few key pages with you and tell you honestly what I would change. Let's chat.