Test Hidden Content

Element Code: HT-031

Nearly every audit I run has at least one page where half the copy lives inside an accordion, a tab set, or a read-more toggle. Designers love these patterns, and honestly, so do users on mobile. The problem is that nobody ever tests the hidden state. The page gets QA'd with everything collapsed, it looks fine, it ships, and six months later someone asks why the FAQ answers never rank. This check exists because hidden content has to be tested twice: once as delivered, once as revealed.

What this check covers

Hidden content is anything present on the page but not visible on initial load: tabbed product specs, FAQ accordions, read-more expansions, off-canvas navigation, modal content, and slides beyond the first in a carousel. Testing it means answering two separate questions for every hidden element:

• Indexability: is the content in the HTML or rendered DOM that Googlebot receives, or does it only come into existence after a user interaction?
• Function: when the panel opens, does it actually work? Do images load, do links resolve, does the layout hold?

How Google treats hidden content, and where people go wrong

The folklore here is a decade out of date, so let's reset it. In the desktop-first era, Google did devalue content hidden behind tabs and accordions. Since mobile-first indexing, that is no longer the case: Google's John Mueller has said repeatedly that content in expandable sections gets full weight, because hiding secondary content behind toggles is normal, user-friendly design on a phone.

So the CSS is not the problem. The real trap is one level deeper: content that is not in the DOM at all until someone clicks. Googlebot renders pages with a headless Chromium, but it does not click your tabs, expand your accordions, or trigger your read-more buttons. If opening a panel fires a network request that fetches the text from an API, that text does not exist in anything Google renders. It is not devalued. It is simply not there.

There is a third scenario worth naming: text hidden with intent to manipulate, like white-on-white keyword lists or paragraphs shoved off-screen purely for engines. That is plain old hidden text under Google's spam policies, and it can get a site into real trouble. The line is intent: hiding content for users to reveal is fine, hiding content from users is not.

The decision that actually matters

Technique by technique

How to detect problems

1. The exact-phrase test. Copy a distinctive sentence from inside a hidden panel and search site:yourdomain.com "that sentence". If a long-indexed page returns nothing, the content probably is not in the index.
2. URL Inspection in Search Console. Inspect the page, open View crawled page, and search the rendered HTML for the hidden text. This is the closest thing to Google's own eyes you have. If the string is there, you are fine on indexability.
3. Screaming Frog with JavaScript rendering. Set rendering to JavaScript, add the hidden strings as Custom Search filters, and crawl. This scales the check across every template instead of one URL at a time.
4. DevTools Network check. Open the Network tab, clear it, click each tab or accordion. Any request that fires to bring the content in is a red flag: that payload does not exist for a crawler that never clicks.
5. Manual reveal pass. Open every panel on your key templates. Look for images that never load, dead anchor links, overflowing layouts, and panels that trap focus or fail to open on mobile at all.

How to fix it

If the content is in the DOM and merely hidden by CSS, you have no indexing problem. Leave the UI pattern alone and just fix whatever the reveal-state QA turned up.

If the content arrives only on interaction, get it into the initial payload: server-render it, or ship it in the DOM hidden by CSS and let the click merely toggle visibility. Same UX, completely different crawlability. If the hidden payload is genuinely heavy, a full spec sheet, hundreds of reviews, ask whether it deserves its own URL instead of a panel; a dedicated page can rank on its own, a lazy-loaded panel cannot.

For images inside panels, prefer native loading="lazy" on real img tags with src set, rather than custom JS that swaps a placeholder only when the panel opens. Native lazy loading keeps the image discoverable in the markup; click-triggered swapping does not.

And if you find text that exists only to be hidden from users, keyword blocks, invisible paragraphs, delete it. Whatever it is doing for you, it is not worth what it costs when it gets flagged.

What good looks like

Every hidden panel's text appears in the rendered HTML that URL Inspection shows. Exact-phrase site searches return the pages that carry the content. No network requests fire when panels open, or if they do, the content they fetch is supplementary rather than substantive. And a human clicking through every tab and accordion finds working images, valid links, and intact layout. Hidden-by-design, present-in-DOM, tested-when-revealed: that is the whole standard.

FAQ