Infinite scroll and SEO: give every batch of items its own URL, then test what a crawler sees

Infinite scroll is fine for SEO when every batch of content that loads on scroll also has its own address that works without scrolling. Googlebot does not scroll or click like a visitor, so items that appear only after a scroll event can stay invisible to it. The fix is a paginated set of component pages, such as /products?page=2, that a crawler can request directly, plus links that lead to them. The scroll experience sits on top of that structure.

Why infinite scroll hides content

A crawler fetches a URL, renders the page, and reads what is there. It does not hold a session open and keep pulling the page down. If your list loads the next twenty items only when the browser reports a scroll position, the crawler may see the first twenty and stop. Everything after that depends on whether another route to those items exists.

The cost is not abstract. Products, articles or listings that never get crawled cannot rank, and pages that are reachable only through the scrolling list are also weakly linked inside your site. Both problems come from the same cause, so one fix covers both.

What Google recommends

Google's Search Central blog has a post titled Infinite scroll search friendly recommendations, and its pagination and incremental page loading documentation covers the same ground. The advice reduces to four points.

• Break the content into component pages. Each one has a unique URL and holds a fixed set of items.
• Make each component page loadable on its own, without JavaScript events or a prior scroll.
• Link the component pages together with ordinary anchor links, so a crawler can walk from page one to the last.
• Keep the visitor's URL in step with the content. As the visitor scrolls into a new batch, the address bar updates through the History API to the component URL, so a shared link lands on the right batch.

Read both Google pages before you build: the infinite scroll recommendations post and the pagination and incremental page loading guide. Both returned a live page on 12 October 2026.

Three ways to build it

Pattern	What visitors get	What crawlers get	Fits
Infinite scroll on top of paginated URLs	Continuous scroll	Normal numbered pages with links	Product lists, blogs, directories
Load more button over paginated URLs	A button that appends the next batch	The same numbered pages	Lists where the footer must stay reachable
Plain pagination	Numbered pages	Numbered pages	Large catalogues where position in the list matters

The first two give visitors the smooth behaviour and give crawlers the structure. A load more button also keeps your footer reachable, which an endless feed buries.

Implementation rules that keep it clean

One address per batch

Give page two a plain URL. A query string parameter such as ?page=2 or a path such as /page/2/ both work. Pick one and keep it.

Self canonical on each component page

Each component page names itself as its canonical. Pointing every page's canonical at page one tells Google to ignore the items on pages two onward. Our guide to canonical tags and duplicate content explains the choice.

Real anchor links to the next page

Include an anchor with an href to the next component page in the HTML. A button wired only to a click handler gives the crawler nothing to follow. If the scroll script is the only thing that triggers the next load, add a visible next link as the fallback.

Server rendered first batch

The first batch of items should be in the HTML the server returns. If a script has to run before any item appears, the crawl depends on rendering. Our JavaScript SEO guide shows how to check that.

Stable ordering

If the list reshuffles on every load, item 21 on a crawl may be item 15 for the next visitor. Sort by a fixed field such as date or ID so each component page holds the same items from one visit to the next.

The test that proves it works

1. Open the component URL, for example page 3, in a fresh private window with no scrolling. The items for that batch should appear.
2. View the page source, not the inspected DOM, and find the product or article titles. If they are present in source, the content is delivered to crawlers directly.
3. Use the URL Inspection tool in Google Search Console on page 3 and read the rendered HTML. The items should be there.
4. Search Google for a distinctive phrase from an item that appears only on page 3, with the site: operator. If it is indexed, the route works.
5. Check the sitemap. Item pages, not only list pages, should be in it, so discovery does not depend on the list at all.

Run the same checks after any theme or framework change, because a redesign is when component URLs quietly disappear.

Item pages carry the ranking

Even a perfect paginated list is a route to your content, not the content. Each product or article should have its own page that earns its own ranking, linked from the list, from related items, and from the sitemap. Treat the list as navigation. Treat the item page as the asset.

What an assistant says about a list you built for scrolling

Infinite scroll decisions get made for the visitor's thumb and tested against a crawler, and a third reader now reads the same pages: an AI assistant that answers questions about what you sell or publish. Ask ChatGPT or Perplexity for the pieces on a topic you cover and the answer may name three items from your first screen and none from the batches behind the scroll, because only the first batch was ever readable. If you run a large list, ask the assistants for items you know sit deep in it and note which ones come back. AI Knows Us can run that kind of question across five assistants and show which of your pages each one cites, which turns the crawl test above into a check on whether the deep items are known at all.

Questions about infinite scroll and SEO

Does Google crawl infinite scroll pages?

Google crawls the URLs it can fetch and render. Content that loads only after a scroll event is at risk, so give each batch its own linked URL.

Is infinite scroll bad for SEO?

The pattern is fine when it is built on paginated URLs. It causes trouble when it is the only route to the content.

Should I use rel next and prev?

Google has said it does not use those link elements as an indexing signal. Plain anchor links between component pages do the work.

Load more button or true infinite scroll?

Both work on the same paginated base. A load more button keeps the footer within reach and gives you a clear click to measure.

Which URL should the sitemap list?

List the item pages. Include the component pages too if the items on them are your main content.