A reader wrote to me during acceptance testing for his company's new website, with two worries I have been hearing for ten years. On the product pages, the introductory text is folded behind a "Read more" button: is that content really read by Google? And the product listing uses infinite loading, a decision taken before he joined: are the products that only appear as you scroll ever indexed? His closing question summed it all up: "is our pagination SEO friendly?"
For years I answered that kind of question with caution: when in doubt, fold nothing. That answer is no longer right, and I would rather say so plainly than leave old advice lying around. Google's position on hidden content changed with mobile-first indexing. A different constraint has taken its place, more serious and far less negotiable: accessibility. Here is where the rules actually stand, on the search side and on the regulatory side.
Collapsed content: what Google says today
The document that settles the matter is not a social media post or a conference talk. It is the page setting out the Google Search spam policies. Its section on hidden text and links draws an explicit line: concealment designed to manipulate rankings is still a violation, ordinary interface components are not. Named in that second group are accordion or tabbed content that alternates between showing and hiding, slideshows, tooltips and text meant only for screen readers. That page was updated on 28 August 2026 — this is current doctrine, not an old position half remembered.
The documentation on mobile-first indexing, updated on 10 December 2025, points the same way. It allows a different mobile layout, "for example by moving content into accordions or tabs", on one condition: the content must remain equivalent to the desktop version. Folding is not hiding. The fold is a layout decision, not an indexing decision.
The logic is simple. Under mobile-first indexing the mobile version is the reference, and on a phone almost all secondary content is folded away. Penalising the fold would mean penalising most of the mobile web.
The real dividing line: in the HTML, or loaded on click
The criterion is not visual, it is technical. Is the content in the served HTML, or in the rendered HTML after JavaScript has run? Or does it only arrive once a visitor acts?
Google is unambiguous here: do not lazy-load primary content on interaction, because the crawler does not load anything that requires a swipe, a click or a keystroke. The page on lazy loading, also updated on 10 December 2025, puts it another way: the recommended methods, including the IntersectionObserver API, depend on no user action, which matters because Google Search does not interact with the page.
Two accordions that look identical on screen can therefore have opposite fates:
- the panel is in the HTML and simply hidden with CSS, or closed inside a
<details>element: the text is indexable like the rest of the page; - the panel is empty on load and its content is fetched over AJAX at the moment of the click: the text does not exist for a crawler, which does not click.
The difference shows in the source: the first pattern below ships the text, the second an empty shell.
<!-- Indexable: the text is in the served HTML -->
<details>
<summary>Delivery and returns</summary>
<p>Orders are prepared within two working days.</p>
</details>
<!-- Not indexable: the panel is filled only after a click -->
<div class="accordion" data-endpoint="/api/panel/delivery">
<button type="button">Delivery and returns</button>
<div class="panel"></div>
</div>Checking which one you have takes two minutes and no paid tool. Open URL inspection in Search Console, run the live test, then search the rendered HTML for a sentence from the folded panel. If it is there, the matter is closed. That is the check I asked my reader to run before committing to any fix: the text was in his source, and the "Read more" button was causing no problem at all.
Infinite loading: the problem is not the scroll, it is the URL
For product listings the reasoning is different. Google describes the three families of solutions on its page about pagination and incremental page loading, updated on 10 December 2025, and repeats the decisive point: its crawlers do not click buttons and generally do not trigger JavaScript functions that require a user action.
| Solution | What the visitor experiences | What the crawler sees |
|---|---|---|
| Classic pagination | Numbered pages, a known position in the list | One URL and a set of links per page: direct crawling |
| "Load more" button | A single page that grows on demand | Nothing beyond the first batch, unless the button is backed by a link |
| Infinite loading | Continuous scrolling, no interruption | Nothing beyond the first batch, unless pagination runs in parallel |
Infinite loading can therefore coexist with good search visibility, provided you lay real pagination underneath the interface. The rules come down to four points, all from the documentation above:
- every batch of results has its own URL, with a parameter such as
?page=2and absolute numbers, never relative ones: a URL like?date=yesterdayshould be avoided; - those URLs are connected by genuine
<a href>links, even when the visible interface only shows a button; - the displayed URL is updated through the History API as the visitor scrolls, never with a fragment after a
#, which Google ignores for pagination; - page 1 is not the canonical URL of the following pages: each page canonicalises to itself. As for
rel="next"andrel="prev", Google no longer uses them.
One consequence is often forgotten: infinite loading produces heavy pages that get heavier with every scroll. If your catalogue stacks hundreds of items into one document, the indexing gain is paid for in load time and responsiveness. Settle that trade-off early, with the same seriousness you would give to website speed work.
Accessibility: the constraint that replaced the SEO risk
The real danger with these components no longer comes from search engines. A sloppy accordion — a bare <div> with a click listener bolted on — cannot be reached with a keyboard and says nothing to a screen reader. The disclosure pattern in the W3C ARIA Authoring Practices Guide sets the minimum: the element that opens and closes the panel takes the button role, responds to Enter and Space, and exposes aria-expanded="true" when the panel is visible and false when it is hidden.
The simplest route is usually <details> and <summary>, which give you keyboard navigation and the open state natively: that is the mark-up used by the FAQ below. Tabs follow a different pattern — arrow key navigation, role="tablist" — and take more code. If the team cannot do it properly, plain headings and paragraphs do the same job with none of the risk.
Where the obligation now bites
This is no longer only a good practice. Directive (EU) 2019/882, the European Accessibility Act, has applied since 28 June 2025 to a range of services supplied to consumers, e-commerce among them. It exempts microenterprise service providers, defined as employing fewer than ten people and with an annual turnover or balance sheet total not exceeding 2 million euros. Above those thresholds an online shop is in scope, and an accordion that cannot be operated with a keyboard stops being a finishing detail.
Territory matters more than head office: a UK business selling to consumers in the EU or the EEA faces the same requirements as one established there. In the UK, public sector bodies have had their own accessibility regulations since 2018. The usual technical reference under both regimes is the W3C's Web Content Accessibility Guidelines, and the practical demand is the one the ARIA pattern describes: components that work without a mouse and announce their state.
What I recommend in practice
Fold what deserves to be folded, not what carries your positioning. A clean accordion over technical specifications, frequently asked questions or delivery terms is neutral for search and comfortable for the reader. I still advise against folding the content that justifies the page: the main product description, the central argument of a service page. Not because Google devalues it, but because text nobody unfolds rarely ends up well written or up to date.
On the build side, three habits are enough. Serve the content in the HTML rather than on click. Back every "Load more" button with pagination that uses real URLs. Test with a keyboard before release: if you cannot reach and open every panel with Tab and Enter, the implementation needs rework, however good the animation looks. These checks sit inside a UX audit, or alongside a technical SEO audit when you want the crawl side covered too. They are cheaper to apply while the templates for a new business website are still open to change.
Common questions
Does Google penalise text hidden inside an accordion?
No, provided the hiding serves the user experience rather than ranking manipulation. The Google Search spam policies name accordions and tabs explicitly as acceptable uses of hidden content. The penalty targets text concealed to mislead the engine: white text on a white background, or a font size of zero.
How can I check that my accordion content is indexed?
Use URL inspection in Search Console, run a live test, and search the rendered HTML for a sentence from the folded panel. If it appears, Google sees the content. You can also disable JavaScript in your browser: what remains on screen is broadly what the engine receives before rendering.
Does infinite loading stop my products being indexed?
It does as soon as the later batches are reachable only through a visitor action, because Google's crawlers neither click nor scroll. The remedy is real pagination underneath: one clean URL per batch, and genuine links between those URLs. Continuous scrolling then stays a comfort layer for the visitor.
Should I still use rel="next" and rel="prev"?
Google no longer relies on them to understand a paginated sequence; it works from links and URLs. They do no harm, but they are no substitute for explicit links between pages.
What mark-up should I choose for an accessible accordion?
The native details and summary elements give you keyboard navigation and an announced open state with no extra code. In a custom component, the trigger needs the button role, must respond to Enter and Space, and must carry an aria-expanded attribute toggling between true and false.
Is my online shop covered by accessibility obligations?
Directive (EU) 2019/882 has applied since 28 June 2025 to services sold to consumers, including e-commerce, and it reaches businesses selling into the EU or the EEA wherever they are established. Microenterprise service providers are exempt: fewer than ten staff, and an annual turnover or balance sheet total no higher than 2 million euros. Above those thresholds an online shop is in scope, and national rules may apply on top.