Pagination and SEO: How to Index Category Pages Correctly

Pagination without proper canonical tags and crawl budget control costs e-commerce stores thousands of duplicate pages and lost organic traffic. This guide covers concrete settings for WordPress, OpenCart and Magento, a comparison of three canonical approaches, and a real case study with 500+ pagination pages.

What is pagination and why it matters for SEO

Pagination is the practice of splitting a large list of content into sequential pages: /category/, /category/page/2/, /category/page/3/, and so on. It appears in e-commerce product catalogues, blogs, tag archives, and site search results.

From an SEO standpoint, pagination is a classic double-edged sword. On one hand, it helps Google crawl and index hundreds of products or articles that would never fit on a single page. On the other, poorly configured pagination generates thousands of duplicate pages, drains crawl budget, and dilutes link equity across an ever-growing number of URLs.

Across the projects we manage with catalogues of 1,000+ SKUs, pagination consistently ranks among the top three causes of organic traffic drops identified during technical audits — alongside canonical issues on product pages and incorrect robots.txt configurations.

Pagination SEO problems: duplicates, crawl budget, link juice

The three main SEO problems caused by pagination are closely interconnected.

Content duplication

When a CMS generates identical or near-identical title and description tags for /category/ and /category/page/2/, Google treats them as duplicates. In WordPress without an SEO plugin, this happens by default — the <title> tag on page 2 of a category is identical to page 1. We have verified this across more than 30 client projects: the problem appears in 8 out of 10 new sites with no prior SEO configuration.

Crawl budget drain

For a large e-commerce store, 500 pagination pages can consume 40–70% of crawl budget. This means Googlebot spends its allotted resources crawling technical pages instead of re-indexing new products or updated prices. Google Search Console → Settings → Crawl Stats makes this pattern clearly visible.

Link juice dilution

When external links point to /category/page/5/ — because someone linked directly to that URL — the link equity gets spread across a technical page rather than consolidating on the main category page. A self-canonical solves this: any link pointing to /page/5/ gets attributed to the self-referencing URL, keeping equity where it belongs.

Three canonical approaches for paginated pages

There are three common approaches — and only one of them aligns with Google's current guidance for 2025–2026.

Approach 1: Canonical to the first page (outdated)

For years, it was common practice to set a canonical from /category/page/2/ to /category/. The logic: concentrate all link weight on the first page. The problem: Google sees that the canonical points elsewhere and may ignore all content on /page/2/. Products that only appear on page 2 or beyond risk never being indexed.

Approach 2: Self-canonical (recommended)

Each paginated page references itself as canonical. /category/page/2/ carries <link rel="canonical" href="https://example.com/category/page/2/">. This signals to Google that each page is an independent document and allows products across all pagination pages to be indexed.

Approach 3: Noindex (not recommended)

Blocking /page/2/ and beyond via meta robots noindex. Short-term logic: removes duplicates from the index. Long-term problem: products on those pages become unreachable for Google, the crawler still visits the pages (wasting budget), and category rankings suffer because Google cannot see the full product range.

For more on how it works and common configuration mistakes, see our article on canonical tags.

Google and pagination after 2019: the rel=prev/next retirement

On 21 March 2019, the Google Search team officially announced that it no longer uses rel=prev and rel=next as signals for recognising paginated series. The SEO community was caught off guard — these tags had been actively recommended for years.

In practice, Google had quietly dropped support for these tags internally as far back as 2011. Bing still officially supports rel=prev/next, so removing the tags is not strictly necessary. But treating them as your primary pagination SEO strategy in 2025–2026 is a mistake.

What Google recommends today

• Self-canonical on each paginated page — the primary recommendation.
• Unique title and meta description for every pagination page. For example: "Nike Trainers — Page 2 of 15 | Store Name".
• Clear previous/next links in HTML, crawlable by Googlebot.
• Do not block paginated pages in robots.txt if they contain unique products.

"We have developed systems that can identify the relationship between paginated pages without special tags. The best thing you can do is ensure that each page has unique content and a correct canonical." — Google Search Central.

Pagination settings in WordPress, OpenCart, Magento

WordPress + Yoast SEO / Rank Math

By default, WordPress adds pagination for categories and archives. Yoast SEO automatically adds self-canonicals to each paginated page — but there is a common pitfall: after plugin activation, the canonical setting for pagination sometimes defaults to "canonical to the first page". Check the following:

1. Yoast SEO → Search Appearance → Taxonomies → Categories → enable "SEO for Archive pages".
2. Check via View Source on /category/page/2/ — the <link rel="canonical"> tag must point to /page/2/ itself, not to /category/.
3. In Rank Math: General Settings → Links → Canonical URL → ensure "Use Pagination Base" is disabled.

OpenCart

OpenCart does not generate canonical tags by default. Without an SEO extension, all category pages with pagination are potential duplicates. Configuration steps:

1. Install an SEO extension (SEO Pack Pro or equivalent), or add canonical tags manually in catalog/view/theme/[theme]/template/product/category.tpl.
2. In the template, verify that the canonical is generated dynamically: for /index.php?route=product/category&path=25&page=2 the canonical should be the SEO URL equivalent of /your-category/?page=2.
3. Enable SEO URLs in Admin → Settings → Store → SEO URL = Yes. This removes raw parameters from URLs and simplifies canonical management.

Magento 2

Magento has built-in canonical settings at Stores → Configuration → Catalog → Catalog → Search Engine Optimization:

1. Use Canonical Link Meta Tag For Categories → set to "Yes".
2. Be aware: by default Magento sets the canonical to /category/ (the first page) for all paginated pages — this is the outdated approach. To change it, you need to customise the module or use an SEO extension.
3. Review filter parameter URLs: Magento generates URLs like /category.html?color=34&size=5 — these must be closed from indexation.

Infinite scroll and SEO: problems and solutions

Infinite scroll looks great for user experience, but it is an SEO trap. When new products load dynamically via JavaScript, Googlebot only sees the first "screen" of items. Everything below that point simply does not exist for the search engine indexer.

We ran into this directly on a client project in the women's clothing category — after launching infinite scroll on the main category page, more than 400 previously indexed product URLs dropped out of the GSC index within 6 weeks. The root cause: Googlebot renders JavaScript, but only up to a point — deep infinite scroll pages are not processed.

Solutions for infinite scroll

• Hybrid approach: infinite scroll + individual URLs for each "batch" (/page/2/, /page/3/). Google officially recommends this. Implemented via the History API (pushState) — the URL updates as the user scrolls.
• "Load more" button instead of automatic loading: more SEO-friendly, since the first page contains a defined set of products and the rest are accessible via paginated URLs.
• Server-side rendering (SSR): for React/Vue storefronts this is a critical requirement. Client-side infinite scroll is invisible to Googlebot in roughly 90% of cases.

Filters and pagination in e-commerce stores

The combination of faceted filtering and pagination is the most dangerous SEO territory in any e-commerce store. Every filter combination generates a unique URL: /category/?color=red&size=XL&page=3. For a store with 50 colours, 10 sizes and 20 pages of pagination, the maths is brutal — up to 10,000 unique URLs for a single category alone.

Strategies for managing filter URLs

• Canonical to clean category: all filtered URLs point their canonical to /category/. Works well when filtered pages have no standalone SEO value.
• Selective noindex for combined filters: single-filter pages (e.g., /category/red/) may have genuine SEO value. Combined filters (two or more parameters) are usually best closed with noindex.
• GSC URL Parameters: in Google Search Console → Legacy Tools → URL Parameters you can tell Google that ?sort= or ?order= parameters don't change page content. However, this tool is being deprecated by Google.
• robots.txt Disallow for parameters: Disallow: /*?*color= blocks the crawler from all URLs containing the color parameter. Use with care — it is easy to accidentally block important pages.

Practical pagination audit checklist

Use this checklist during a technical SEO audit. For large catalogues (500+ URLs) we recommend Screaming Frog or Ahrefs Site Audit.

1. Check canonical on /page/2/: open View Page Source and locate <link rel="canonical">. It must point to /page/2/ itself, not to /category/.
2. Check title/description uniqueness: in Screaming Frog, filter URLs containing /page/ or ?page=. Compare their titles against the first category page — they should be different.
3. Analyse Crawl Stats in GSC: Settings → Crawl Stats → By response code. If /page/ URLs account for more than 30% of all requests, you have a crawl budget problem.
4. Check robots.txt: confirm that no paginated page is blocked if it contains unique products.
5. Check filter parameter URLs: find URLs in GSC or Screaming Frog carrying two or more parameters (?color=&size=) — these should be closed from indexation.
6. Verify next/prev HTML links: every paginated page should have visible "Previous page" / "Next page" links in HTML for both users and the crawler.
7. Check breadcrumbs: they should appear on all paginated pages and correctly represent the hierarchy.
8. Infinite scroll: if used, check in Google Search Console → URL Inspection whether Google actually sees the rendered page with all products.

How to use GSC to analyze the indexing of paginated pages — in our complete Google Search Console guide.

Case study: store with 500+ pagination pages

A client came to us — an electronics e-commerce store with a catalogue of over 6,000 products. The initial audit found:

• 548 pagination pages without canonical tags (duplicating the first category page title)
• 1,200 URLs with combined filter parameters in the Google index
• Crawl Stats: 65% of requests were going to /page/ and ?filter= URLs
• 2,400 products from /page/10/ onwards had zero internal links

What we did in 8 weeks: added self-canonicals to all paginated pages, created unique titles with page numbers, closed combined filter URLs via canonical, and fixed breadcrumbs. Results after 3 months: indexed products increased by 68%, category organic traffic +34%, Crawl Stats — share of /page/ URLs dropped to 18%.

In Practice

The client ran a WordPress recipe blog — 4,200 recipes spread across eleven categories: baking, soups, salads, desserts and seven others. Each category had up to 8 pagination pages. The owner had noticed the problem themselves: overall traffic was growing, but almost entirely to the category index pages rather than to individual recipes.

A Screaming Frog crawl made the cause immediately clear: none of the 70 pagination pages (/recipes/baking/page/2/ through /page/8/) carried a self-canonical. Every one of them pointed its canonical back to /recipes/baking/, the category root.

GSC Crawl Stats confirmed what that meant in practice: 62% of all crawl requests were going to /page/2/–/page/8/ instead of recipe pages. Googlebot was burning its budget on pagination and barely reaching the recipes themselves.

Over 3 weeks we corrected the canonicals via Yoast SEO (disabling "Use Pagination Base"), submitted all 4,200 recipes to the XML sitemap at priority 0.8, and used GSC → URL Inspection to verify rendered HTML on 20 randomly selected deep-page recipes. Eleven weeks later, organic traffic was up 44% and the share of /page/ URLs in Crawl Stats had fallen from 62% to 19%.

On a deep-pagination content blog, self-canonical on every page is not optional — it is the prerequisite for individual posts surviving in the index at all. As long as /page/2/ points its canonical at /page/1/, Google has no reason to look any further.

Frequently asked questions

Should I use noindex on pagination pages?

No. Adding noindex to /page/2/ and beyond removes those pages from the index, but Googlebot will still crawl them, wasting crawl budget. Products and articles on those pages become practically unreachable for Google. The optimal solution is a self-canonical on each paginated page combined with internal links pointing to the indexed category pages.

What happened to rel=prev/next tags after 2019?

In March 2019, Google officially announced it no longer uses rel=prev/next as a pagination signal. Bing and some other search engines may still consider them, so removing the tags is not mandatory, but relying on them as your primary pagination strategy is a mistake.

How do I correctly set up canonical tags for pagination pages?

Each paginated page should have a self-canonical: /category/page/2/ points its canonical to itself. Avoid pointing canonical to the first page — this causes Google to potentially ignore content on /page/2/ and beyond, which means products on those pages may drop out of the index.

Does pagination hurt crawl budget?

Yes, if pagination is not optimised. For a large e-commerce store with 500+ pagination pages, Googlebot can spend 60–70% of its budget on technical pages instead of priority ones. The fix: close filter-parameter URLs from crawling, keep only clean pagination, and monitor via Google Search Console → Crawl Stats.