Pagination or Infinite Scroll on Collection Pages? Pick by Task

For most storefront collection pages, numbered pagination, or a load more button paired with visible counts, beats pure infinite scroll. Shoppers on collections are often hunting and comparing, not grazing, and infinite scroll breaks position memory, the back button, and access to footer links like shipping and returns.

A shopper found a jacket she liked on what she thinks was page three, clicked a product, changed her mind, and hit back. Infinite scroll returned her to the top and started the feed over. She left. That small story is the whole argument in miniature, and it plays out on collection pages every day.

Neither pattern is wrong in the abstract. Social feeds scroll forever because grazing is the activity. A collection page is a working surface: filter, sort, compare, duck into a product, come back, resume. The pattern has to respect the task.

What infinite scroll quietly breaks

Position is memory. Pagination gives shoppers a coordinate system: it was near the bottom of page two. Infinite scroll replaces coordinates with a single long present, and browser back behavior on long feeds is unreliable enough that many shoppers will not risk opening a product at all.

The footer disappears too. Shipping, returns, and contact links live down there, and on a feed that loads faster than a person can scroll past it, those links are effectively deleted during the exact session when a shopper wants the returns policy. Support desks hear about this. Designers rarely do.

The case for load more, with conditions

A load more button is the honest compromise when it behaves. It keeps the decision to continue with the shopper, it can state the count, showing 48 of 213, and it preserves a reachable footer once loading stops. What it must not do is reset on back navigation or hide the total.

Whichever pattern you run, keep product URLs stable and give each paginated view its own crawlable URL. Search engines handle sequenced pagination with ordinary links; a feed that only exists as JavaScript state is hard to index and harder to share. A link a shopper cannot paste to a friend is a product that cannot be recommended.

Pick by the dominant task, then test the edge cases

Small curated collections under about 48 products can show everything and skip the debate. Large catalogs with comparison shopping need pagination. Lookbook style browsing can scroll, provided product pages open without destroying place, which usually means testing the back button on real devices, not in a design review.

Test the keyboard path and the screen reader path too. An endless feed that keeps appending content can strand assistive technology users in a list with no end and no footer. If your pattern has no bottom, say where the exits are and make sure they work.

Frequently asked questions

Is infinite scroll bad for SEO on collection pages?

It can be, when products are only reachable through scroll triggered loading with no crawlable paginated URLs behind it. Provide ordinary links to paginated views so search engines and shoppers can reach every product directly.

How many products per page works best?

There is no universal number, but ranges around 24 to 48 balance load speed against paging effort for most catalogs. State the total count clearly so shoppers can judge the size of the task.

Does a load more button solve the footer problem?

Mostly, yes, because loading stops when the shopper stops asking, so the footer becomes reachable. It still needs to preserve loaded products and scroll position when the shopper returns from a product page.

Should I offer a view all option?

On moderate collections it is a kind escape hatch for comparison shoppers. On very large catalogs it becomes a performance problem, so cap it or skip it where page weight would punish the people it is meant to help.