AI Summary
Infinite scroll is search friendly only when each batch of content is also reachable at a real paginated URL that a crawler can request directly. If items appear only when a user scrolls and JavaScript fetches them, a crawler and most AI systems see just the first screen and miss everything below it. The fix is to pair the scroll experience with paginated component pages and real links.
- Back every scroll batch with a unique paginated URL, for example /page/2 and /page/3.
- Join the batches with real anchor tags and update the address bar with the History API.
- Make sure each item is reachable without running JavaScript, then test with scripts disabled.
- This 2014 guidance still holds, and it matters more now because most AI crawlers do not run JavaScript.
The source is a Google Search Central recommendation from 2014 on making infinite scroll search friendly. The advice has aged well, and this page brings it up to date: the core pattern is the same, but the stakes are higher now that AI answer engines crawl the web without executing scripts. Below is how the pattern works, how to build it, and how to check that a crawler can actually reach your content.
Why plain infinite scroll loses content
With a pure infinite scroll list, the server sends the first batch of items, and each further batch is fetched by JavaScript as the user scrolls. A crawler does not scroll. It requests a URL, reads what comes back, and follows links. If items four and beyond exist only after a scroll event, and there is no separate address that returns them, the crawler has no way to reach them. The content is real to a human but invisible to search and to the assistants that summarize the web. The same problem hits deep pagination hidden behind a load more button with no underlying URL.
The search friendly pattern: paginated component pages
The durable fix, then and now, is to build the list as a series of paginated component pages and layer the scroll experience on top:
- Give every batch a URL. The items shown after one scroll should also live at a requestable address such as
/products?page=2or/products/page/3, each returning that slice of items in HTML. - Link the batches with real anchors. Include genuine
<a href>links between the component pages so a crawler can walk the whole series, even if users never see the links. - Sync the address with the History API. As the user scrolls into a new batch, use
history.replaceStateto update the URL to the matching paginated address, so sharing or reloading lands on the right slice. - Keep items reachable without JavaScript. The component page URLs should return their items in the server response, not build them client side, so the content does not depend on rendering.
Infinite scroll compared with the alternatives
| Pattern | Crawlable by default? | What makes it safe |
|---|---|---|
| Infinite scroll, scroll only | No | Add paginated URLs and real links behind it |
| Load more button | Only if wired to URLs | Point the button at a real paginated URL |
| Numbered pagination | Yes | Plain anchor links to each page |
| Scroll plus component pages | Yes | Best of both, smooth for users and reachable for bots |
How to test that a crawler can reach every item
- Disable JavaScript in your browser and load the list. If you cannot reach page two by clicking a link, neither can a crawler.
- Request a deep paginated URL directly, for example with
curl -sL https://example.com/products?page=5, and confirm its items are in the returned HTML. - Use the URL Inspection tool in Search Console on a component page URL and check the rendered HTML and screenshot.
- Confirm the paginated URLs are internally linked and, where appropriate, listed in your sitemap so they are discovered.
What has changed since 2014
Two updates matter. First, Google stopped using rel="next" and rel="prev" as an indexing signal, so do not rely on those tags to hold a paginated series together; use real anchor links and self referential canonicals on each page instead. Second, the rise of AI crawlers raises the cost of getting this wrong. The systems behind AI Overviews and assistants such as ChatGPT, Perplexity, and Claude generally do not run JavaScript, so a list that depends on scroll and client rendering is invisible to them even when Googlebot manages to render it. Serving real paginated HTML is now the safe baseline for both search and AI visibility. For related reading, see our guides to crawl budget, faceted navigation, and the discovered, currently not indexed status that deep, weakly linked pages often fall into.
Frequently asked questions
Not by itself, but plain infinite scroll hides content from crawlers because they do not scroll. It becomes safe when each batch is also reachable at a real paginated URL with genuine anchor links, so a crawler can request every slice of the list.
Build the list as paginated component pages where each batch has its own URL such as /page/2, link the pages with real anchor tags, update the address with the History API as the user scrolls, and make sure each item is returned in HTML without needing JavaScript.
No. Google stopped using rel next and rel prev as an indexing signal, so do not depend on them to hold a paginated series together. Use real internal links between pages and a self referential canonical on each paginated URL.
Usually not if the content only loads on scroll through JavaScript. Most AI crawlers do not run scripts, so they see only the first batch. Serving the items at real paginated URLs in HTML is what makes them visible to AI systems.
Disable JavaScript and try to navigate the list, request a deep paginated URL directly with a tool like curl to confirm its items are in the HTML, and use the URL Inspection tool on a component page. If any of these fail, the content is not reachable.
Only if the button is wired to real paginated URLs. A load more button that fetches items with JavaScript and has no underlying address has the same crawlability problem as scroll only infinite scroll.
Case study summary and source
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.
Source: https://developers.google.com/search/blog/2014/02/infinite-scroll-search-friendly
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!
