State of Pagination in eCommerce: Case Study & Analysis of the Top 150 UK Fashion Retailers
- October 2, 2020
- Website Architecture
AI Summary
Pagination decides whether search engines can reach the products that sit past page one of a category, and this DeepCrawl case study surveyed how the top 150 UK fashion retailers actually handle it. The practitioner takeaway is simple: keep paginated links crawlable with real anchor tags, give each paginated page a self referencing canonical, and never canonicalize page two onward back to page one.
- Numbered pagination built from real anchor tags with href attributes stays crawlable and is the safest default.
- Load more and infinite scroll are fine only when paginated URLs exist behind them for crawlers to follow.
- Canonicalizing every paginated page to page one is a common mistake that hides deep products from indexing.
- Google stopped using rel=next and rel=prev for indexing in 2019, so do not rely on them.
Ecommerce catalogs almost always outgrow a single page, so category listings get split across page one, page two, and often dozens more. The DeepCrawl case study behind this page looked at how the top 150 UK fashion retailers handle that split, and the range of approaches it found is a useful mirror for any store. This page keeps the source and adds practitioner guidance on which pagination patterns keep deep products discoverable and which quietly bury them.
Why pagination is an SEO problem, not just a UX one
A category page is a hub. It links out to individual product pages, and for many stores those internal links are the main way search engines discover products at all. When pagination breaks that link path, the products on page five stop receiving internal links a crawler can follow, so they get crawled less, indexed less, and rank worse. Pagination is therefore a crawl path question first and a user experience question second. The case study framing, a survey of real retailers, is valuable precisely because it shows how often stores get this crawl path wrong.
The four pagination patterns and how they crawl
Most stores use one of four patterns. The difference that matters is whether a crawler can reach page two and beyond by following a normal link.
| Pattern | How it works | Common mistake | Fix |
|---|---|---|---|
| Numbered links | Page numbers rendered as anchor tags | Links built as buttons with no href | Use real anchors with a crawlable href |
| Load more | A button fetches more products via script | No underlying paginated URLs exist | Back it with real page URLs a crawler can reach |
| Infinite scroll | More products load as the user scrolls | Content only exists after scroll events | Pair it with paginated URLs updated in history |
| View all | One page lists every product | The page is too heavy to load quickly | Use only when the full list stays fast |
The canonical mistake that hides half your catalog
The single most damaging pagination error is canonicalizing every paginated page back to page one. The logic seems tidy: page one is the real category, so point page two, page three, and the rest at it. The result is that Google treats pages two onward as duplicates of page one and drops them from indexing, and with them go the internal links to every product that only appears deeper in the list. On /dresses?page=2 the canonical should point at itself, as in the first line below. The second line is the mistake that hides every product past page one:
<link rel="canonical" href="https://example.com/dresses?page=2" />
<link rel="canonical" href="https://example.com/dresses" />The one exception is when you also publish a view all page that is fast enough to serve. In that case Google has historically been happy for paginated pages to canonicalize to the view all URL, because the view all page contains every product link.
Keep the links crawlable
Whatever pattern you pick, the deciding factor is a crawlable link. A page control coded as a button that only fires a JavaScript click is invisible to a crawler. A page control coded as an anchor with a real destination is not. The crawlable pattern to aim for is plain:
<a href="/dresses?page=2">2</a>
<a href="/dresses?page=3">3</a>
<a href="/dresses?page=2" rel="next">Next</a>Infinite scroll and load more can coexist with this. Progressive enhancement is the standard approach: render real paginated anchor links in the HTML, then layer the scroll or button behavior on top with script so users get the smooth experience while crawlers still follow the links. For stores that lean heavily on client side rendering, confirm the links exist in the served HTML, a point covered in our JavaScript SEO case studies.
What has changed since this case study
The biggest change is that Google confirmed in 2019 that it had not been using the rel=next and rel=prev markup for indexing for some time. Many older pagination guides still tell you to add those tags as the primary fix, and that advice is now outdated for Google, although Bing still recognizes them. The modern guidance is to treat each paginated page as a normal, indexable page, keep the links between pages crawlable, and make sure products are also reachable through your XML sitemaps and category structure so discovery does not depend on pagination alone. For more structural patterns see our website architecture case studies and the wider case study library.
Frequently asked questions
What is the best pagination method for SEO?
Numbered pagination built from real anchor tags with href attributes is the safest default because crawlers can follow it to every page. Load more and infinite scroll can work too, but only when they are backed by real paginated URLs. The deciding factor is always whether a crawler can reach page two and beyond by following a link.
Should paginated pages canonical to page one?
No. Canonicalizing page two onward back to page one tells Google those pages are duplicates and drops them from indexing, which hides every product that only appears deeper in the list. Each paginated page should have a self referencing canonical. The only exception is canonicalizing to a fast view all page that contains all products.
Does Google still use rel=next and rel=prev?
No. Google confirmed in 2019 that it had not used rel=next and rel=prev for indexing for some time. Bing still recognizes them, so they do no harm, but they should not be your primary strategy. Focus on crawlable links and self referencing canonicals instead.
Is infinite scroll bad for SEO?
Not inherently. Infinite scroll is a problem only when the additional products exist solely after scroll events with no crawlable URLs behind them. If you pair infinite scroll with real paginated URLs and update the browser history as the user scrolls, crawlers can still reach the deeper products.
How do search engines find products past page one?
Mainly through the internal links on paginated category pages, which is why crawlable pagination matters. If pagination breaks, deep products lose the internal links that help them get discovered and indexed. Supporting the catalog with XML sitemaps and a clear category structure gives discovery a second path.
Should I use a view all page?
A view all page can be a clean solution because it lists every product on one crawlable page, and paginated pages can canonicalize to it. The catch is performance: a view all page must still load quickly, so it works best for medium sized categories. For very large catalogs, crawlable numbered pagination usually scales better.
Source: https://www.deepcrawl.com/blog/best-practice/state-of-pagination-in-ecommerce/
Claude Vincent is a technical SEO consultant focused on crawlability, rendering, and AI-search visibility. He writes the field guides and case studies at SEO ProCheck, with a bias toward the durable, unglamorous work that decides whether search engines and AI answer engines can actually read and cite a site.
About SEO ProCheck
Technical SEO consulting and GEO strategy with 20 years of enterprise experience. Case studies, resources, and tools for search and AI visibility.
Work With Me
Technical SEO audits, GEO strategy, site migrations, and international SEO. Hourly consulting for teams who need hands-on support, not just reports.
Subscribe to our newsletter!
