Pagination is one of the few technical SEO topics where the mainstream advice actively changed and a lot of sites never updated. Google retired support for rel="next" and rel="prev" in 2019 — and mentioned it had already stopped using them years before the announcement. Plenty of sites still ship those tags, still canonicalise every page to page one, and still cannot work out why their deeper product listings never get indexed. Here is what actually works now.
What Changed
For years the recommended approach was to mark paginated sequences with rel="next" and rel="prev" link elements, telling Google the pages formed a series.
Google no longer uses them. It treats each paginated page as a standalone page, discovering content through the ordinary links between them.
You can leave the tags in place — Bing still uses them, and they do no harm — but do not expect Google to act on them. The important consequence is that pages two, three and beyond are now evaluated on their own merits, and your job is making sure Google can reach and understand them.
The Mistake That Hides Your Content
The most damaging pattern, and it is everywhere: canonicalising every paginated page to page one.
<!-- On /products?page=4 — wrong -->
<link rel="canonical" href="https://example.com/products" />
The reasoning sounds sensible — pages two onward look like duplicates of page one, so consolidate them. It is wrong because paginated pages are not duplicates. Page four contains entirely different products or articles than page one.
By canonicalising to page one, you tell Google that page four should not be indexed and that its content belongs to page one. Google then largely stops crawling it, and everything only reachable from page four becomes hard to discover. On a large catalogue this can bury the majority of your inventory.
Each paginated page should have a self-referencing canonical:
<!-- On /products?page=4 — correct -->
<link rel="canonical" href="https://example.com/products?page=4" />
If you are unsure whether your canonicals are configured this way, our guide to “alternate page with proper canonical tag” covers how to check and how the failure shows up in Search Console.
Should Paginated Pages Be Indexed?
Generally, let them be indexed. They are legitimate pages containing real, distinct content.
Should they rank? Usually not — page one is what you want ranking for the category term. But indexing and ranking are different, and blocking indexation to prevent ranking is heavy-handed. Google is perfectly capable of preferring page one on its own.
Where noindex on deeper pages is defensible:
- Very deep pagination — page 40 of 60 — where the pages have negligible standalone value
- Filtered sequences that combine pagination with parameters, multiplying URLs enormously
Even then, be careful: noindex eventually causes Google to reduce crawling of those URLs, and anything only linked from them becomes harder to find. If you noindex deep pages, make sure your products are reachable another way — through a sitemap, a well-structured category tree, or internal linking.
The safer default for most sites is: index them, do not try to rank them, and make sure page one is the strongest page in the set.
What to Actually Do
1. Self-referencing canonicals on every page. The single most important item.
2. Use crawlable links between pages. Real <a href> elements with URLs Google can follow. Buttons wired to JavaScript that never produce a URL are invisible to crawlers. This is worth testing rather than assuming.
3. Give each page a distinct title. “Running Shoes — Page 4” rather than “Running Shoes” on all sixty pages. Identical titles across a sequence look like duplication and make Search Console reports unreadable.
4. Keep pagination shallow. Sixty pages of twenty products is worse than twenty pages of sixty. Deeper pages get crawled less, so reducing depth directly improves how much of your catalogue Google sees. Better category structure and filtering reduce depth more effectively than raising items-per-page indefinitely.
5. Do not put paginated URLs in your XML sitemap. Sitemaps should list canonical destination pages — the products and articles themselves, not the listing pages that link to them.
6. Link deep pages from somewhere. If page 40 is only reachable by clicking “next” thirty-nine times, it will barely be crawled. Numbered pagination showing first, last, and nearby pages helps considerably over next/previous alone.
7. Put unique content only on page one. Category descriptions and intro copy belong on page one. Repeating them across every page in the sequence creates genuine duplication.
Infinite Scroll and “Load More”
Both are common and both are invisible to crawlers by default. If new content appears only after a scroll or click event, and no URL changes, Google sees only the initial batch.
The fix is the same for both: back the interface with real, crawlable paginated URLs.
- Each batch corresponds to a URL like
?page=2that returns that content on its own when requested directly - The History API updates the URL as the user scrolls, so the state is shareable
- Standard paginated links exist in the markup as a fallback, even if visually hidden from users who have JavaScript
This is sometimes described as progressive enhancement, and it means both users and crawlers get a working experience. Without it, everything past the first batch is effectively unreachable, however good it is.
Test by disabling JavaScript and loading the page, or by using URL Inspection’s rendered HTML view. If only the first batch is present, crawlers see only the first batch.
The View-All Option
If your listings are small enough to show everything on one page without a performance penalty, a view-all page is often the strongest option — all content on one URL, all signals consolidated.
The constraint is page speed. A view-all page with four hundred products and their images will be slow, and that cost usually outweighs the consolidation benefit. Our guide to Core Web Vitals covers what that trade-off looks like in practice.
The practical rule: view-all works below roughly a hundred items, assuming images are lazy-loaded. Above that, paginate.
Pagination Plus Filters
Where this gets genuinely difficult is faceted navigation. Every filter combination multiplied by every page number produces an enormous URL space — ?colour=blue&size=10&sort=price&page=7 and thousands of variants.
Left unmanaged, this consumes crawl budget that should be going to product pages, and it is a common reason real content ends up “crawled – currently not indexed”.
Approaches that work:
- Allow crawling of filters with genuine search demand — “blue running shoes” is a real query worth a landing page — and block the rest
- Block sort orders entirely. Nobody searches for “products sorted by price descending.”
- Use
robots.txtto block parameter combinations past a reasonable depth. See our robots.txt guide. - Avoid canonicalising filtered pages to the unfiltered category unless the filtered content really is equivalent, which it usually is not.
For ecommerce specifically, this is often the highest-value technical work available — more so than anything on the individual product pages.
Get the Canonical Right First
If you take one thing from this: check whether your paginated pages canonicalise to page one, and stop if they do. That single misconfiguration hides more content from Google than every other pagination mistake combined, and fixing it is usually a one-line change in a template.
After that, the priorities are crawlable links between pages, distinct titles, and shallower sequences. None of it is complicated, but it compounds — on a large catalogue, the difference between good and bad pagination handling is the difference between most of your inventory being indexed and most of it being invisible.
If you run a large catalogue and suspect Google is only seeing part of it, our SEO services include crawl and indexation analysis that identifies exactly how much is being reached. Get in touch with the team at blogthememachine.com, and subscribe to our newsletter below for more technical SEO guides. For the wider technical picture, start with technical SEO basics.