In short
Show as many products as the page can load quickly on a phone, which for most stores lands between 24 and 48, and paginate the rest with real URLs. The number itself is not a ranking factor. What matters for search is that every product is reachable through crawlable links within a few clicks, and what matters for shoppers is that the first screen loads fast and the filters do the narrowing. Platform limits apply too: Shopify's Liquid pagination caps a page at 50 items.
The count is a speed and crawl-depth decision, not a ranking rule
Google does not reward a particular number of products per page. The number matters through two side effects. The first is page weight: every product tile adds an image and markup, and on a mobile connection a page of 96 tiles can push Largest Contentful Paint past the threshold and make scrolling sluggish. The second is depth: a collection of 600 products at 12 per page is 50 pages deep, and a product on page 40 gets a weak internal link and an infrequent crawl.
More products per page makes the collection shallower and each product easier to reach. Fewer products per page makes the first load lighter. Lazy-loading the images below the fold softens the trade-off, because the HTML can list 48 products while the browser only fetches the first dozen images, and the crawler still sees all 48 links.
So the honest answer is a range. Pick the largest count that keeps the collection's field Core Web Vitals in the good band on mobile, then reduce depth further with subcollections rather than with larger pages.
What each platform allows and where the setting lives
On Shopify the products-per-page value is a theme setting on the collection template, and the Liquid paginate tag that powers it accepts a maximum of 50 items per page. Paginated URLs use the page parameter and carry a self-referencing canonical. Shopify does not add rel next and prev tags, which is fine because Google stopped using them in 2019.
On WooCommerce with a classic theme the grid is set in the Customizer under WooCommerce and Product Catalog as products per row and rows per page, and a developer can override it with the loop_shop_per_page filter. Block themes set it on the Product Collection block. Paginated archives live at /page/2/ and are rendered server-side. On BigCommerce the count is a theme editor setting for category pages, with the exact label depending on the theme.
Headless storefronts set whatever they like, and that freedom is where the most mistakes happen: the count is often chosen for design and pagination is left to client-side state with no URLs at all.
Pagination needs real URLs, whether or not you add a load-more button
Every page beyond the first must exist as a URL that returns a full HTML response with the product links in it, is linked from the previous page with an ordinary anchor, keeps its own canonical rather than pointing at page one, and is not noindexed. A load-more button is fine as long as the button is also a link to the next page URL and the fetched content is what that URL serves.
Do not block the page parameter in robots.txt, and do not canonicalize deeper pages to the first page. Both hide the products those pages link to, which is the opposite of what pagination is for. Filtered and sorted URLs are a separate concern and are the ones to canonicalize or block.
Infinite scroll without underlying page URLs is the pattern that breaks collections for search, because Googlebot neither scrolls nor clicks. If your theme uses it, confirm that page two exists and is linked in the initial HTML before worrying about the count per page.
How to choose the number for your catalogue
Start from depth. Find the collection with the most products and divide by candidate page sizes to see how many clicks separate the home page from the last product. Aim to keep every product within three or four clicks, and if a single collection cannot achieve that at 48 per page, it is a signal that the collection needs subcollections, not a bigger page.
Then test speed. Run the collection through PageSpeed Insights at 24 and at 48 products and compare the mobile results, paying attention to the field data if the page has enough traffic to have any. If both pass, use the larger. If only the smaller passes, fix image sizing and lazy-loading before settling for the smaller number, because the same weight problem is hurting every collection.
Finally, treat page one as the page that matters commercially. It gets nearly all the clicks, so the sort order decides which products are seen. Best sellers or highest-margin products first, with new arrivals and clearance handled by their own collections, is a better use of that space than alphabetical order.
Depth arithmetic for a 600-product collection
- 12 per page
- 50 pages; the last product is 50 clicks from page one
- 24 per page
- 25 pages
- 48 per page
- 13 pages
- Six subcollections of about 100 at 48 per page
- 3 pages each, and every product within four clicks of the home page
Illustrative figures. Subcollections reduce depth far more than page size does, and they also give each group of products its own page to rank.
Related questions
Is a view-all page with every product good for SEO?
Only for a small catalogue where the page stays light. For a collection of hundreds of products a view-all page is slow on mobile and offers nothing the paginated series and the sitemap do not already provide. Subcollections do the job better because they add pages that can rank.
Are paginated collection pages duplicate content?
No. Page two lists different products from page one, so they are distinct pages that happen to share a heading and an introduction. Give each its own self-referencing canonical and let Google index the ones it finds useful. They rarely rank on their own, and that is expected.
Should page two onward be noindexed to keep the index clean?
No. Google has said that pages left under noindex for a long time are eventually treated as if their links carried nofollow, which would cut the products on those pages off from internal link value. Keep paginated pages indexable and let Google decide what to show.