The short answer
Setting up pagination comes down to four things: every list page has its own address, the links to those addresses are plain <a href> elements, each page's canonical points at itself, and the page number is not hidden behind a hash. The rel="next" and rel="prev" tags are not needed: Google's ecommerce pagination guide states that Google no longer uses them (developers.google.com, verified 28.09.2026).
Everything else usually discussed around pagination is secondary. Unique text on pages 2, 3 and 4, noindex on the whole list, a canonical pointing to page one: that is either wasted work or active damage.
What Google asks of pagination today
Google's position reads better as a list of technical requirements than as SEO advice. Below is what its ecommerce guide states, verified 28.09.2026.
| Google's requirement | What it means in markup | Typical violation |
|---|---|---|
| A unique URL per list page | ?page=2 or /page/2/ in the address | Every page served from one address via AJAX |
| The page number is not a fragment | Google ignores everything after # | Addresses like /sofas#page=2 |
| Self-referencing canonical | <link rel="canonical" href="…?page=2"> | Every page canonicalised to the first |
| Links reachable without user action | Page numbers as <a href> in the HTML | A «load more» button on a click handler |
| rel next/prev is not used | The tags can be left out | Configuring them instead of the links |
On buttons Google leaves no room for interpretation: its crawlers don't click buttons and generally don't trigger JavaScript functions that require a user action to update page contents. That gives you a one-minute test: if the products on page two appear only after a click, as far as Google is concerned they are not on your site.
Three ways to show a long list
The choice between them is usually framed as a usability question. In practice it decides how many product pages reach the index: in a 200-item category the crawler gets either all 200 or the 20 on page one.
| Pattern | What a person sees | What a crawler sees | When I use it |
|---|---|---|---|
| Numbered pages | A «1 2 3 … 10» block | Every list page, if they are <a href> links | The default for a catalogue of any size |
| «Load more» | A button under the list | Only the first batch, unless parallel links exist | Catalogues under 100 items where mobile UX matters |
| Infinite scroll | Content loading on scroll | Only the first batch, unless separate URLs exist | A content feed, not a product catalogue |
The second and third patterns do work, but only with ordinary pagination underneath: each batch needs its own address, and the HTML needs links to those addresses. Google adds in the same guide that sitemaps and a Merchant Center feed help with incrementally loaded content. That is a way to let the crawler find products, not a replacement for navigation: a sitemap passes no link equity.
Four mistakes I see most often in catalogues
The order here is by frequency, not by severity.
- Every page canonicalised to the first. The most common and the most expensive: the platform puts the category's canonical on pages 2 and up, Google is told those pages do not exist, and products reachable only from page 7 lose their crawl path. Google asks you not to do this in plain words.
- Script-driven pagination with no addresses. Common on custom-built catalogues and on storefronts that moved to an SPA. One minute to check: open page two, see whether the address changed, then request that address in a separate tab.
- The same SEO text on every page. One identical paragraph across ten list pages plus identical titles produces exactly the pattern I break down in the article on duplicate content. Fixed by removing the text from page two onward and adding the number to the title.
- Pagination stacked on filters. Every filter combination with its own set of pages produces thousands of addresses. Here pagination cannot be fixed on its own, only together with indexing rules for filters, otherwise you carefully configure canonicals on URLs that should never be crawled. How that waste eats the crawl, I covered in the piece on crawl budget.
The order of work
Six steps I go through in a catalogue before handing anything to development. The first 3 need no developer only if pagination is already built on links.
- Open page two of any large category and check the address: it must change and open directly, without JavaScript.
- Look at that page's canonical. Pointing to the first page means a template fix; pointing at itself means you move on.
- Check the title: on page two it must differ from page one at least by the number.
- Crawl the category and see how many product pages were discovered by following links only, with no sitemap in the start list.
- Compare that count against the real number of products from the platform's export. The gap is the size of the problem.
- Recalculate how many list pages the current items-per-page setting produces and estimate the click depth of the last product. How to count it, I go through in the article on click depth from the homepage.
Step 4 without step 5 is useless: a crawler always finds something, and the report looks fine until you compare it with the product export.
When pagination is not worth your time
A category of 60 products showing 20 at a time produces three list pages. At that size the difference between correct and broken pagination is close to zero: Googlebot will walk three pages either way. Here I raise items per page to 60 and close the question.
It starts to matter on catalogues of several thousand URLs, where crawling stops being complete. There pagination decides which share of your products reaches the index, and there it starts overlapping with keyword cannibalisation: list pages with identical headings compete with each other and with the category.
Pagination does not lift rankings. It decides how many of your 200 or 20,000 products exist for the search engine, and its role ends there.
On the limits of my own evidence I will be straight. I have no isolated measurements of the «we fixed the pagination canonical and traffic grew N percent» kind, and I have not seen a clean experiment on it either: pagination is almost never fixed separately from the category template. The effect I can confirm is more modest: after pagination moves to proper addresses, the crawler starts finding products that were absent from the crawl report entirely. Where those products then rank depends on the product page, not on pagination, and that is separate SEO work.
