Ecommerce pagination seo is the area where outdated advice survives longest. Google confirmed years ago that it no longer uses rel=”next” and rel=”prev” as indexing signals — it had quietly stopped supporting them well before the announcement — and yet checklists, plugin defaults, and agency audits still recommend them as if nothing changed.
They do no harm. They also do nothing. Meanwhile the things that genuinely determine whether page 7 of your category gets crawled are getting ignored, and the products sitting on page 7 quietly fall out of the index.
What Google actually does with paginated series
Google treats each paginated URL as its own page. Not as a fragment of a series, not as a duplicate of page one — as an individual document that it will crawl, evaluate, and index or not on its own merits.
That reframing changes every decision downstream. Page 4 needs to be reachable, needs to be crawlable, and needs to be canonically distinct. It does not need to rank; almost nobody wants to land on page 4 of a listing. Its job is to be a crawl path to the 48 products it contains. If it fails at that job, those products lose their most direct route into the index.
It also means the old debates are settled by default. You do not need to consolidate the series into a single canonical entity, you do not need a special markup pattern, and you do not need to hide pages 2 onward from Google to protect page one. Treat each URL as what it is: a page containing 48 products that need a route into the index.
You can also stop worrying about paginated pages “competing” with page one. They rarely do, because page one has the descriptive copy, the internal links, and the external links. Deep pages are plumbing, and plumbing is fine.
The setup that works
Four rules cover almost every store:
- Self-canonicalize each page. Page 3 canonicals to page 3. Not to page one, not to a view-all URL you don’t maintain.
- Keep pagination links as real anchor tags with real href values. A JavaScript-only “load more” button with no underlying URL is invisible as a crawl path.
- Let paginated pages be crawlable. Do not block
?page=in robots.txt. This is a common overcorrection from faceted navigation cleanup that severs your product discovery. - noindex is optional and usually unnecessary. Applying noindex, follow to pages 2+ is defensible if index bloat is a genuine problem, but Google generally handles deep pages sensibly on its own. If you do it, make sure “follow” is present so links still pass.
Two things to actively avoid. Never canonicalize page 5 to page 1 — it’s the most common pagination mistake and it orphans everything past page one. And never let the paginated URL for page 1 exist as a separate URL from the clean category path; /shoes/ and /shoes/?page=1 should not both resolve independently. Redirect or canonicalize one to the other.
Content duplication across paginated pages
If your category template prints the same 400-word buying guide on every page of the series, you’ve generated forty near-identical documents. That’s self-inflicted duplication that looks exactly like the manufacturer-description problem on product pages.
Keep descriptive copy on page one only. Same for the FAQ block and any structured content. Pages 2 onward should carry the product grid, the pagination links, breadcrumbs, and nothing else that repeats.
Title tags and meta descriptions are worth differentiating too, though lightly. Appending “— Page 3” is enough to avoid duplicate-title flags in your crawl reports without turning it into a project. Most crawl tools will list identical paginated titles as duplicates, and the noise makes it harder to spot the duplicate titles that actually matter.
View-all pages: when they help and when they don’t
A view-all page consolidates the entire listing into one URL, which is genuinely useful when the full set is modest. Google has historically preferred serving view-all when users prefer it, and it removes the pagination question entirely.
The trade-off is page weight. A view-all page with 800 products and 800 images is unusable on mobile and will wreck your Core Web Vitals. Judge by the number, not the principle: under roughly 100 products, a view-all is often the cleaner answer. Above 200, it isn’t.
If you do offer both, canonicalize the paginated pages to the view-all page — that’s the one scenario where cross-page canonicalization is correct, because the view-all genuinely contains everything the paginated pages contain. Do not do this if the view-all lazy-loads its products, since then it doesn’t actually contain them at crawl time.
Infinite scroll without losing the crawl path
Infinite scroll is a UX pattern, not an indexing strategy. Implemented naively, it means there is exactly one URL for the whole listing and everything below the first batch exists only after user interaction — which Googlebot does not perform.
The workable version pairs infinite scroll with real paginated URLs underneath. As the user scrolls, the History API updates the address bar to /shoes/?page=2, and those URLs load a full paginated view when requested directly. You get the smooth experience and a crawlable series. Test it by disabling JavaScript and navigating: if you can still reach every product through links, crawlers can too.
Deep pagination is usually a taxonomy problem
Here’s the uncomfortable part. If a category runs to 40 pages, no amount of correct markup will get products on page 35 crawled with any frequency. Pages that deep receive little internal link equity and get visited rarely, regardless of your canonical setup.
The real fix is structural. Break the category into subcategories driven by actual search demand, so no listing exceeds a handful of pages. Attribute-based subcategories — “waterproof hiking boots,” “office chairs for tall people” — do double duty: they shorten pagination and they capture search volume that the parent category never could.
Sort order compounds the depth problem quietly. If your default sort is “newest first,” the set of products on page 3 changes every time you add inventory, so Google is repeatedly crawling a page whose contents keep shifting. A stable default sort — bestselling, or a fixed relevance order — gives paginated URLs consistent content and makes them far more useful as crawl paths.
Increasing products per page helps at the margins. Going from 24 to 48 per page halves your page depth at the cost of some load time, and on a listing of lightweight product cards that’s usually a good trade. Going to 200 per page is not.
Auditing pagination across a real catalog
You cannot check this by hand. The signals worth pulling are the ratio of indexed to submitted URLs in Search Console, the distribution of Googlebot hits across page depth in server logs, and a full crawl showing which paginated pages are reachable and what canonicals they declare.
SEO Rocket’s technical audits cover the crawl side of this — an instant quick scan of about 25 pages, and deep full-site crawls verified at 900+ pages that return concrete evidence per issue: the actual URLs, the actual duplicate titles, the actual H1 text, rather than a count you then have to go hunting for. Combined with keyword research to decide which subcategories are worth building, that’s most of the diagnosis. It does not manage product feeds, Merchant Center, or inventory — those live in your ecommerce platform.
Expect recrawling to take four to twelve weeks before index counts settle after a pagination change, and treat two or three positions of daily movement as normal noise rather than a signal. The metric that moves first is crawl distribution: more Googlebot requests reaching real product URLs, fewer spent on dead ends. That shows up in logs long before it shows up in rankings, and it’s the honest early indicator that the fix worked.
