Infinite scroll loads more products as the visitor scrolls rather than requiring them to click through pages. It generally improves the browsing experience and frequently breaks discovery, because content that only appears in response to scrolling may never be seen by a crawler.
The problem is not infinite scroll itself. It is implementing it without a crawlable equivalent underneath.
Why it breaks crawling
- A crawler does not scroll. It requests a URL and reads what comes back.
- Products loaded by a scroll event may not exist in that response at all.
- Where there is no distinct URL for subsequent batches, there is nothing to crawl.
- Products past the first batch can end up reachable only through internal search, which is effectively orphaned. See ecommerce internal linking.
On a large catalogue this can leave the majority of products undiscoverable, while the category page itself looks perfectly healthy.
The implementation that works
Keep real paginated URLs underneath the scroll behaviour. The visitor experiences continuous loading; the crawler sees a conventional sequence of pages.
- Each batch corresponds to a real URL such as
?page=2that returns those products server-side. - Those URLs are linked with genuine anchor tags, not triggered only by JavaScript events.
- Each paginated URL is self-canonical rather than canonicalising to page one.
- The scroll behaviour updates the URL as the visitor progresses, so a position can be shared and returned to.
- Requesting page three directly returns page three, without requiring any scrolling.
The test is simple: disable JavaScript and load the category. If you can still reach every product by following links, the implementation is sound.
Common mistakes
- Load-more buttons bound only to JavaScript, with no underlying URL. Same problem, different interface.
- Canonicalising every paginated URL to page one, which tells search engines the deeper pages are duplicates and removes them.
- Blocking paginated URLs in robots.txt to save crawl budget, which orphans everything beyond the first batch.
- Noindexing paginated pages, which has a similar effect over time as they get crawled less.
- Relying on the sitemap to expose products. Sitemaps aid discovery but do not substitute for internal links.
Pagination is not the enemy
Teams frequently try to eliminate paginated URLs because they look untidy in a crawl. They are not a problem. They are how deep products stay reachable, and removing them causes far more harm than the tidiness is worth. Treat page one as the ranking target and let the rest exist to be crawled.
Frequently asked questions
Is infinite scroll bad for SEO?
Not inherently. Implemented over real paginated URLs it is fine. Implemented as a pure JavaScript behaviour with no crawlable equivalent, it can hide most of your catalogue.
How do I know if mine is broken?
Disable JavaScript and load a category page. If you cannot reach products beyond the first batch by following links, crawlers generally cannot either.
Should paginated pages be indexed?
They should be crawlable and self-canonical. Whether they get indexed matters less than whether they can be crawled, since their main job is exposing the products they link to.
What about a load-more button?
Same requirement. If the button is the only route to further products and it exists only in JavaScript, the products are not discoverable. Give it an underlying URL and a real link.
Consulting CTA
If products beyond your first page are not being indexed, book an SEO consultation for a crawl and discoverability review of your category templates.