Pagination vs Load More on Product Listings
Pagination vs load more vs infinite scroll for ecommerce SEO: why crawlable paginated URLs beat JS-only listings.
Standard sequential pagination beats “load more” and infinite scroll for SEO on most ecommerce product listings, because it gives every page of results a real, crawlable URL that Googlebot can reach without clicking a button or scrolling. Load more and infinite scroll load new products via JavaScript in response to a user action a crawler can’t perform, which means anything beyond the initial batch of products is invisible to Google unless the site separately exposes those same products through paginated URLs behind the scenes. If you want the UX benefits of load more, you can still have them — but only if a parallel, fully crawlable paginated structure exists underneath it.
Key takeaway
- Pure infinite scroll and load-more buttons are invisible to Googlebot unless a crawlable, paginated URL structure exists in parallel — the crawler can’t scroll or click.
- Google deprecated rel=”next”/rel=”prev” as a pagination signal back in 2019; modern pagination relies on self-referencing canonicals and standard crawlable links instead.
- Never noindex paginated pages 2, 3, 4 and beyond — doing so eventually causes Google to stop following the links on them, orphaning the products that only appear on those deeper pages.
- A hybrid approach — visual load-more UX backed by real paginated URLs and updated browser history — gets you both good UX and full crawlability.
Why load more and infinite scroll cause indexing gaps
Googlebot doesn’t click buttons and it doesn’t scroll the way a human visitor does. When a category page uses “load more” or infinite scroll to fetch additional products via JavaScript after the initial page load, Google’s crawler sees only whatever was present in the first batch — everything a real visitor would see after clicking “load more” three or four times simply doesn’t exist from the crawler’s point of view unless the site is built to expose it another way. On a large catalogue, this means products sitting on page three, four or five of a category effectively become unreachable through normal crawling, which is a direct loss of indexing and ranking opportunity for exactly the products often positioned deeper because they’re lower-priority or newer arrivals that haven’t built up sales rank yet.
This connects directly to category page SEO more broadly — a category page is only as complete, from Google’s perspective, as what it can actually crawl. A beautifully optimised category page that hides 80% of its products behind a JavaScript load-more interaction is only getting credit for the 20% Google can see.
What happened to rel=”next” and rel=”prev”
For years, the standard advice was to mark up paginated series with rel=”next” and rel=”prev” link tags so Google could understand the sequence. Google confirmed in 2019 that it had stopped using these tags as a ranking or indexing signal, explaining that its systems had become capable of inferring paginated relationships directly from URL patterns, internal linking structure and page content without needing an explicit hint. Any technical SEO guide still recommending rel=”next”/”prev” as a required implementation is working from outdated information — it doesn’t hurt to leave the tags in place if they’re already there, but building new pagination around them today is solving a problem Google no longer needs help with.
| Pattern | Crawlability | Best use case |
|---|---|---|
| Standard sequential pagination (page=2, page=3…) | Fully crawlable by default | Default choice for most ecommerce category and search listings |
| “Load more” button, JS-only | Invisible to Googlebot without a parallel paginated structure | UX enhancement layered on top of real pagination, not a replacement for it |
| Pure infinite scroll | Invisible to Googlebot; also weak for Core Web Vitals | Rarely recommended for SEO-relevant listing pages |
| Hybrid: load more that updates the URL and browser history | Crawlable if implemented with real, indexable per-page URLs | Best of both — smooth UX for users, discrete URLs for crawlers |
| “View all” single-page listing | Fully crawlable but can hurt page speed at scale | Works for small-to-medium categories only, not thousand-product catalogues |
How to implement pagination correctly in 2026
Current best practice centres on self-referencing canonical tags rather than rel=next/prev: each paginated page should canonicalise to itself, not back to page one, since each page shows genuinely different products and deserves its own indexing consideration. Every paginated page also needs standard, crawlable HTML anchor links to adjacent pages — not just a JavaScript-only page-number control — and it helps to expose links to the first page, the last page, and a handful of intermediate page numbers so Googlebot can jump deep into a long series in a few hops rather than needing to crawl every single page sequentially to reach page 40.
- Use self-referencing canonical tags on every paginated URL — page 2 canonicalises to page 2, not to page 1.
- Ensure pagination controls render as real, crawlable HTML links (standard
<a href>tags), even if JavaScript also powers a smoother visual interaction on top. - Never apply noindex to paginated pages beyond page 1 — it stops Google from crawling the links on those pages, which can orphan deeper products entirely.
- Give each paginated page a unique or dynamically varied title tag where practical, so pages aren’t fighting each other as exact duplicates in the index.
- If you want a load-more UX, implement it so it updates the URL and browser history to a real paginated URL as the user loads more — this is the hybrid approach that satisfies both users and crawlers.
- Test with a crawler tool (Screaming Frog or similar) with JavaScript rendering disabled to confirm what a basic crawl actually sees, since that approximates what a chunk of Googlebot’s crawling looks like even though Google can render JavaScript in a second pass.
2019
The year Google confirmed it had stopped using rel=”next”/rel=”prev” pagination markup as a ranking signal, explaining its algorithms had become capable of understanding paginated series directly from URL structure and internal linking without an explicit tag. Pagination advice built around these tags predates that change.
Source — Google Search Central pagination guidance update, 2019
Pagination, page speed, and Core Web Vitals
Pagination choice also affects Core Web Vitals directly, particularly Cumulative Layout Shift. Infinite scroll implementations are notorious for CLS problems, since new products loading in below the fold can shift ad units, footers, or “back to top” elements that were previously positioned based on a shorter page. Standard pagination avoids this because each page loads a fixed, predictable set of products with a known layout. If your store also uses faceted navigation alongside pagination, keep the two systems consistent — a filtered, paginated URL should still follow the same self-referencing canonical logic, and testing filter-plus-page combinations specifically is worth doing since that’s where pagination bugs most often hide.
Sort order and pagination interacting badly
One implementation detail that trips up otherwise well-built pagination systems: sort order parameters combined with page numbers. If a category can be sorted by price, popularity or newest-first, and each sort option generates its own paginated sequence, you can end up with the same underlying products appearing across dozens of URL combinations — page 2 sorted by price and page 2 sorted by popularity may show substantially different products, or substantially the same ones depending on catalogue size, and Google has to work out which combinations are worth treating as distinct. The safest default is to canonicalise non-default sort orders back to the default-sorted equivalent page unless a specific sort order has independent search demand worth targeting on its own — which is rare for something like “price: low to high” but occasionally real for something like “newest arrivals” if that phrase shows up in your keyword research.
It’s worth testing this specifically rather than assuming your platform handles it correctly out of the box, since default sort-and-paginate behaviour varies significantly between platforms and themes, and a misconfigured combination is one of the more common sources of unexpected duplicate content flags in Search Console for stores that otherwise have clean pagination.
Frequently asked questions
Is infinite scroll bad for SEO?
Pure infinite scroll is generally bad for SEO because Googlebot can’t scroll to trigger additional content loading, meaning products beyond the first batch go uncrawled unless a parallel paginated URL structure exists. It can also hurt Core Web Vitals, particularly layout stability, if new content loading shifts other page elements.
Should I still use rel=”next” and rel=”prev” tags?
No, they’re not necessary. Google confirmed in 2019 it no longer uses these tags as a signal, relying instead on URL patterns and internal linking to understand pagination. Leaving existing tags in place won’t hurt, but don’t build new pagination systems around them.
Should paginated pages be noindexed to avoid duplicate content?
No. Noindexing paginated pages beyond page one is a common mistake — it stops Google from following the product links on those pages over time, which can effectively remove deeper products from the index entirely. Use self-referencing canonicals instead of noindex.
Is “view all” better than pagination for SEO?
It depends on catalogue size. A single “view all” page is fully crawlable and can work well for small-to-medium categories, but loading hundreds or thousands of products on one page usually hurts page speed and Core Web Vitals badly enough to outweigh the crawlability benefit on large catalogues.
Can I use load-more buttons if I still want good SEO?
Yes, with the right implementation. Build load-more so it updates the URL and browser history to a real, crawlable paginated URL as products load, rather than relying purely on JavaScript state that leaves no trace a crawler can follow. This hybrid approach preserves the UX while staying fully crawlable.
The bottom line
Pick pagination patterns based on what Googlebot can actually crawl, not just what looks smoothest to a human visitor. Standard sequential pagination with self-referencing canonicals remains the safest default for ecommerce listings, and any load-more or infinite scroll UX needs a crawlable paginated structure running underneath it to avoid orphaning products. This sits alongside the other technical fundamentals in our ecommerce SEO guide.
Wondering whether your category pages are hiding products from Google behind a load-more button? We can check — see our ecommerce SEO plans.
