Pagination Canonical: The Correct Strategy for Paginated Pages
Pagination is one of the few SEO topics where a single wrong choice silently destroys indexing for hundreds of pages. The wrong choice is canonicalizing every paginated page back to page 1. It looks tidy. It feels like consolidation. It is wrong, and it has been wrong since Google deprecated rel=next/prev in 2019. This guide covers the correct strategy — self-referencing canonicals on every paginated page — and explains exactly why the alternatives fail. If your category, blog, or listing pages run to multiple pages, the rules below decide whether everything past page 1 lives or dies in Google's index.
The Correct Strategy: Self-Referencing Canonicals on Every Page
Each paginated page should declare itself as its own canonical. Page 2 canonicals to page 2. Page 3 canonicals to page 3. Page 47 canonicals to page 47. There is no consolidation, no parent, no shortcut. Each URL is a distinct page with distinct content (different products, different articles), and Google needs to see that distinction to index the items on each page.
Here is what correct canonical output looks like across a paginated category:
<!-- /category/shoes/ --> <link rel="canonical" href="https://example.com/category/shoes/" /> <!-- /category/shoes/page/2/ --> <link rel="canonical" href="https://example.com/category/shoes/page/2/" /> <!-- /category/shoes/page/3/ --> <link rel="canonical" href="https://example.com/category/shoes/page/3/" /> <!-- /category/shoes/page/4/ --> <link rel="canonical" href="https://example.com/category/shoes/page/4/" />
Each page asserts its own URL. Each page is independently crawlable and indexable. The products that appear only on page 4 still receive crawl signals and still flow internal link equity to their product detail pages. Google will naturally choose page 1 to rank for the broad category query ("running shoes") because page 1 has the most internal links pointing at it — that consolidation happens at the ranking layer, not the canonical layer.
The Wrong Pattern: Canonicaling Pages 2+ to Page 1
The most common pagination mistake is to canonicalize every paginated page back to page 1. Some SEO plugins still ship with this as a configurable option. Some old style guides still recommend it. It is consistently wrong:
<!-- WRONG: every page points at page 1 --> <!-- /category/shoes/page/2/ --> <link rel="canonical" href="https://example.com/category/shoes/" /> <!-- /category/shoes/page/3/ --> <link rel="canonical" href="https://example.com/category/shoes/" /> <!-- /category/shoes/page/4/ --> <link rel="canonical" href="https://example.com/category/shoes/" />
What this tells Google: pages 2, 3, and 4 are duplicates of page 1. Their unique content (the products and articles that appear only on those pages) is irrelevant. Index page 1, ignore the rest.
What Google actually does: in most cases, Google ignores the false canonical (because the content is plainly different) and reports "Duplicate, Google chose different canonical than user" in Search Console. In some cases — especially for thin paginated pages with little unique content above the listing — Google accepts the canonical and drops pages 2+ from its index entirely. Either outcome is bad. The first creates GSC noise that masks real canonical errors. The second hides real content from search.
The downstream effect on ecommerce sites is severe. If you have 600 products in a category split across 12 paginated pages, and you canonical pages 2–12 to page 1, you have just told Google that 550 of those 600 products are duplicates of the first 50. Internal links from those pages to product detail pages still flow some signal, but the listing context — "this product is in the running shoes category" — is lost.
Google's 2019 Deprecation of rel=next/prev
In March 2019, Google announced that it had stopped using rel=next and rel=prev markup as an indexing signal "a few years ago." The announcement was clarification, not a behavior change — Google had not been treating those tags as a hint for paginated content for years before the public confirmation.
This created a brief panic in the SEO community over what was supposed to replace it. The honest answer: nothing. There is no Google directive that tells the crawler "these URLs form a paginated series." What replaced it functionally is a combination of two things you should already be doing:
Good internal linking. Every paginated page should link to the adjacent pages (Previous, Next) and ideally to the full numeric range (1, 2, 3, ... last). This gives Googlebot a clear crawl path through the pagination. The links should be standard <a href> elements rendered server-side, not JavaScript-only buttons.
Self-referencing canonicals. Each paginated page declares itself as its own canonical, as described above. Together, internal links plus self-canonicals tell Google: "these are distinct, related pages — crawl them all, index them all, and rank them based on their own content and signals."
You can leave existing rel=next/prev markup in place if you have it. Google ignores it, but Bing still uses it as a signal, and there is no penalty for keeping it. Do not invest engineering time adding it to new templates — it is purely a Bing-only signal in 2026.
The View All Alternative
If you do want to consolidate ranking signals across a paginated series — say, an article split across 5 pages where you genuinely want one URL ranking for the topic — Google's recommended approach is the "View All" pattern. You publish a single URL that contains the entire content of all paginated pages, and you canonicalize the paginated pages to the View All page.
<!-- /article/long-guide/view-all --> <!-- This page contains ALL content from pages 1-5 combined --> <link rel="canonical" href="https://example.com/article/long-guide/view-all" /> <!-- /article/long-guide/ (page 1 of paginated version) --> <link rel="canonical" href="https://example.com/article/long-guide/view-all" /> <!-- /article/long-guide/page/2/ --> <link rel="canonical" href="https://example.com/article/long-guide/view-all" /> <!-- /article/long-guide/page/3/ --> <link rel="canonical" href="https://example.com/article/long-guide/view-all" />
This is legitimate because the View All page genuinely contains all the content of the paginated versions — they really are duplicates of the View All. Two important constraints:
The View All must actually contain everything. If your "View All" only shows the first 100 of 600 products and lazy-loads the rest via JavaScript that Googlebot doesn't execute, the canonical claim is false. Make the full content available in the server-rendered HTML.
The View All must load reasonably fast. Google will deprecate the View All canonical if the page is too slow or too heavy. For a long-form article split across pages, this works well. For a category page with 5,000 products across 100 pages, View All is impractical and you should stay with the self-canonical pattern.
Parameter-Based vs Path-Based Pagination
Pagination URL structure varies by platform. The two dominant patterns:
Path-based: /category/shoes/page/2/, /category/shoes/page/3/. Common in WordPress, Shopify, and most modern frameworks. Treats each paginated page as a fully distinct URL path. Easier to reason about, easier to audit in crawlers.
Parameter-based: /category/shoes?page=2, /category/shoes?page=3. Common in older PHP frameworks, custom-built sites, and some search result pages. Each variant is a query-parameter URL on the same path.
The canonical strategy is identical in both cases — each variant self-references its own canonical, including the parameter. This is the critical detail with parameter-based pagination: the canonical must include the page parameter exactly as it appears in the URL.
<!-- Parameter-based pagination: each variant self-canonicals --> <!-- /category/shoes --> <link rel="canonical" href="https://example.com/category/shoes" /> <!-- /category/shoes?page=2 --> <link rel="canonical" href="https://example.com/category/shoes?page=2" /> <!-- /category/shoes?page=3 --> <link rel="canonical" href="https://example.com/category/shoes?page=3" /> <!-- WRONG (common mistake on parameter-based sites): --> <!-- /category/shoes?page=2 outputs canonical without the param --> <link rel="canonical" href="https://example.com/category/shoes" /> <!-- BAD -->
The wrong pattern at the bottom is what most CMS platforms produce out of the box because they strip query parameters from canonicals as a default behavior — sensible for tracking parameters like ?utm_source, catastrophic for pagination parameters. If you are on a parameter-based system, audit the canonicals on page 2+ specifically and confirm the page parameter is preserved.
Distinguish pagination parameters from sort and filter parameters. ?page=2 changes which results appear (different products) and deserves a self-canonical. ?sort=price_asc shows the same products in a different order and should canonical to the unsorted base URL. The distinction is whether the URL produces different content or merely a different view of the same content.
Implementing Pagination Canonicals in Next.js
Next.js App Router with dynamic route segments is the standard pattern for server-rendered pagination. Use the generateMetadata function to compute the canonical URL from the route params:
// app/category/[slug]/page/[page]/page.tsx
import type { Metadata } from 'next';
type Props = {
params: Promise<{ slug: string; page: string }>;
};
export async function generateMetadata(
{ params }: Props
): Promise<Metadata> {
const { slug, page } = await params;
const pageNum = parseInt(page, 10);
const canonicalPath =
pageNum === 1
? `/category/${slug}`
: `/category/${slug}/page/${pageNum}`;
return {
title: `${slug} - Page ${pageNum}`,
alternates: {
canonical: `https://example.com${canonicalPath}`,
},
};
}
export default async function CategoryPage({ params }: Props) {
const { slug, page } = await params;
// fetch products for this page, render listing
return <div>{/* ... */}</div>;
}Three things this pattern does correctly. First, the canonical is computed server-side and emitted in the initial HTML response — no client-side hydration delay. Second, page 1 canonicals to the bare category URL (without /page/1/) to avoid creating a duplicate of the root category page. Third, every other page self-references its own URL.
For parameter-based pagination in Next.js (using searchParams), the same idea applies — read the page parameter, include it in the canonical when greater than 1, omit it for page 1. The unique constraint is that searchParams is dynamic by default, so the page renders on demand rather than being statically generated. For high-traffic ecommerce sites, prefer the path-based [page] route segment so Next.js can statically generate the most-visited paginated pages at build time.
Common Pagination Mistakes to Avoid
Beyond the canonical-to-page-1 mistake, there are three other patterns that recur on real audits:
Noindex on pages 2+. The reasoning sounds plausible: "Pages 2+ have lower SEO value, so let's noindex them." The problem is that Google eventually treats long-term noindex URLs as noindex,nofollow — it stops crawling the links on those pages. Every product or article that appears only on page 2+ loses its internal link signal. The correct approach is to keep paginated pages indexable (with self-canonicals) and let the natural ranking signals decide which page surfaces for which query.
Blocking pagination in robots.txt. A handful of sites still try to "clean up" pagination by adding Disallow: /page/ rules to robots.txt. This blocks crawl, blocks indexing of any items only reachable through paginated pages, and breaks internal link equity flow. Never block paginated URLs in robots.txt.
Including paginated URLs in the sitemap when they are canonicalized elsewhere. If you do follow the View All pattern and canonical pages 2–N to the View All URL, do not include those paginated URLs in the XML sitemap. Sitemap entries should only ever be self-canonical URLs. Mixing them creates "Duplicate, submitted URL not selected as canonical" warnings in Search Console.
For deeper audit patterns across canonical and sitemap interactions, see the canonical issues fix guide.
Pagination vs Faceted Navigation
Pagination and faceted navigation often coexist on ecommerce category pages, and they get conflated in canonical strategy discussions. They are different problems with different solutions.
Pagination splits a single result set across multiple URLs because there are too many items to fit on one page. Page 2 contains different items than page 1. Each paginated URL has unique content. Strategy: self-referencing canonical on each page.
Faceted navigation filters or refines a result set based on user-selected attributes (color, size, brand, price range). ?color=red&size=large shows a subset of the same items. Most facet combinations have no independent search demand and would create thin, near-duplicate index entries if left indexable. Strategy: canonical filtered URLs to the unfiltered category page, except for high-demand combinations (e.g., "Nike running shoes") which deserve their own indexable canonical.
Where they intersect: /category/shoes?color=red&page=2. The correct canonical here is /category/shoes (the unfiltered category) because the filter is the dominant signal — the user has narrowed to red shoes, and we are showing page 2 of that filtered set, but search intent for "red shoes page 2" is essentially zero. Filter-then-paginate URLs canonical to the unfiltered base, not to the filtered page 1.
Monitoring Pagination in Search Console
After implementing the correct pagination canonicals, monitor Search Console's Pages report (Indexing → Pages) for these signals:
Indexed paginated URLs. Use the "Indexed" filter and search for your pagination URL pattern (e.g., /page/). You should see paginated pages indexed alongside their parent category. If only page 1 is indexed and pages 2+ are missing, your canonicals are still pointing back to page 1 somewhere — re-audit the rendered HTML.
"Duplicate, Google chose different canonical than user." If pagination URLs appear here after your fix, Google is overriding your canonical because of conflicting signals — usually internal links or sitemap entries pointing somewhere different from the canonical tag. Check that your pagination links in the page footer or pagination component point to the same URL form as the canonical (trailing slash matching, parameter encoding, etc.).
"Crawled — currently not indexed" for paginated URLs. This is normal for very deep pages (page 30+) on low-authority categories — Google has crawled them but not assigned index resources. It becomes a problem only if it affects pages 2–5 of important categories. The fix in that case is improving internal linking depth: pagination components should expose more page numbers in the link list so deep pages are not 5+ clicks from the homepage.
URL Inspection on representative pages. Pick page 2 of three different important categories and run URL Inspection. Confirm: indexable status is "URL is on Google," the user-declared canonical matches the Google-selected canonical, and the canonical points to the same URL as the inspected URL (self-reference). If any of those three are off, the canonical strategy has a leak.
Quick Reference: Pagination Canonical Decisions
Distilled from the sections above, here is the decision table for any pagination scenario:
Standard category or blog pagination → self-referencing canonical on each page. Page 1 canonicals to the bare category URL, pages 2+ canonical to themselves with the page identifier preserved.
Long-form article split across pages, you publish a View All version → all paginated pages canonical to the View All URL. View All canonicals to itself. Include only the View All in the sitemap.
Filtered + paginated URL → canonical to the unfiltered base category, unless the filter combination has independent search demand (large retailers only).
Infinite scroll or load-more with single URL → only one canonical question, the single URL self-canonicals. Ensure server-rendered content includes everything Googlebot needs.
Parameter-based pagination → preserve the page parameter in the canonical for pages 2+. Strip pagination from canonicals only when the platform also serves the same items at the bare URL (rare; verify before assuming).
For broader internal linking strategy that complements pagination canonicals, see the internal linking guide. For canonicals on product variant pages and tag archives that share some of the same patterns, see canonical product tags.