The most common canonical mistake on paginated pages isn't missing a canonical tag — it's adding the wrong one. Someone reads that canonicals prevent duplicate content, notices that page 2 and page 3 of a product listing "feel" like duplicates of page 1, and points every paginated URL's canonical at page 1. Rankings for the deeper pages then quietly drop, because the search engine takes the tag at its word: it consolidates signals onto page 1 and treats the rest as non-canonical, which makes them far less likely to get indexed independently.
Why Paginated Pages Aren't True Duplicates
A canonical tag is a "these are duplicates, prefer this one" signal, not a "these are related" signal. Page 1 and page 2 of a paginated category listing show different items. That's not duplicate content by any reasonable definition — it's the same template rendering different data, which is true of nearly every page on a dynamic site. The pattern that actually is a duplicate is a tracking parameter or session ID appended to an otherwise identical page (?page=2&sessionid=abc123 vs ?page=2), and that's what canonical tags on pagination are for: collapsing parameter noise on a given page, not collapsing the sequence into one URL.
The self-referencing default
For nearly all paginated sequences, each page should canonicalize to itself:
<!-- On /products?page=2 -->
<link rel="canonical" href="https://example.com/products?page=2" />
<!-- On /products?page=3 -->
<link rel="canonical" href="https://example.com/products?page=3" />
This tells search engines page 2 and page 3 are legitimate, independently indexable pages — because they are. It's the same principle behind self-referencing canonicals on any page: the tag mainly exists to specify the preferred URL when parameters, trailing slashes, or protocol/host variants could otherwise produce multiple valid URLs for the same content.
Handling Parameters on Paginated URLs
Real pagination URLs often carry more than a page number — sort order, filters, session tracking, referral codes. The canonical decision depends on whether the parameter changes the result set:
| Parameter changes results? | Example | Canonical strategy |
| --- | --- | --- |
| Yes — different items shown | ?page=2 | Self-reference (include the parameter) |
| Yes — different items shown | ?category=shoes&page=1 | Self-reference (include relevant parameters) |
| No — same items, different order | ?page=2&sort=price_asc | Canonicalize to the version without the sort param, unless sort variants are meant to be independently indexed |
| No — tracking/session only | ?page=2&utm_source=newsletter | Canonical to ?page=2 without the tracking parameter |
The general rule: if stripping the parameter would change which items the user sees, keep it in the canonical. If it only changes presentation or is pure tracking noise, strip it.
rel=next / rel=prev: Not Dead, Just Not Load-Bearing With Google
For years, rel="next" and rel="prev" link elements were the recommended way to hint pagination relationships to Google. Google confirmed it stopped using these signals in 2019 — its systems determine pagination structure without them now. They're harmless to leave in for other crawlers or tooling that still respects them, but don't rely on them to fix an indexing problem; the canonical tag and your internal linking structure do the actual work with Google today.
Handling the "View All" Page
If you offer a single page that lists everything (a "view all" or infinite-scroll fallback), that page is a legitimate candidate for consolidation if you want search engines to prefer indexing the combined view over the paginated sequence. In that case, and only that case, it's reasonable to canonicalize each paginated page to the "view all" page — because the paginated pages genuinely are a subset of that page's content, unlike the page-1-only mistake above. Weigh this against page weight and load time: a "view all" canonical target needs to actually be fast and complete, not a thin fallback.
Infinite Scroll and JavaScript-Rendered Pagination
Infinite scroll and "load more" patterns complicate canonicalization because there's often no discrete, crawlable URL per page of results — content loads into the same document as the user scrolls or clicks. If search engines can't reach a stable URL for page 2's content, they can't index it as a separate result, and self-referencing canonicals become moot because there's nothing distinct to self-reference.
The practical fix is to pair infinite scroll with real paginated URLs underneath it, so the experience is progressive enhancement rather than the only path to the content:
- Each "page" the infinite scroll loads should correspond to a real, linkable URL (
?page=2) that also works if requested directly, without JavaScript, and returns that page's items server-rendered or reliably hydrated. - Update the browser URL (via the History API) as the user scrolls past each page boundary, so the address bar reflects a real, shareable, self-canonicalizing URL rather than staying pinned to page 1 indefinitely.
- Verify the crawlable version independently of the JS-driven UX — request
?page=2directly, with JavaScript disabled if you can test that way, and confirm it returns that page's actual items with its own self-referencing canonical, not a redirect back to page 1 or a client-side-only render that leaves the initial HTML empty.
Sites that skip the underlying paginated URLs entirely tend to end up with only page 1 indexed, because nothing else was ever independently reachable regardless of how the canonical tags were configured.
Canonical Tags vs. Pagination and hreflang
If your paginated content also exists in multiple languages or regions, canonical and hreflang serve different, non-overlapping purposes and shouldn't be conflated. Canonical tags point to the preferred version of this page's content (collapsing near-duplicates within one locale, including pagination parameter variants); hreflang tells search engines which locale-specific version to show which users, and each of those locale versions gets indexed independently rather than consolidated. A paginated page's canonical should point to a same-locale URL, never to the equivalent page in a different language — cross-locale canonicals of that kind typically get ignored by search engines and can produce inconsistent indexing across your locales.
Common Failure Modes
- Canonicalizing every page to page 1 — the mistake described above; it suppresses indexing of everything past the first page.
- Canonical pointing to a URL that itself 404s or redirects — always verify the canonical target resolves with a 200 status; a canonical to a dead URL is worse than no canonical.
- Canonical and pagination disagreeing with the sitemap — if page 2 is self-canonicalized but excluded from your sitemap, you're sending mixed signals about whether you want it indexed. Keep the Sitemap Generator output and your canonical strategy consistent — paginated pages you want indexed should appear in both.
- Relative canonical URLs — always use absolute URLs in the
<link rel="canonical">tag; relative paths are technically allowed by the W3C link relations spec but invite host/protocol resolution bugs across CDNs and staging environments.
Decision Point
Default to self-referencing canonicals on every paginated page. Only deviate when you have a genuine duplicate — the same result set reachable through a different URL, like a tracking parameter or a redundant sort that doesn't change output — or when you're deliberately consolidating onto a "view all" page you've decided should be the sole indexed version. When in doubt, generate and verify your tags with the Meta Tags Generator rather than hand-writing canonical URLs across a template, and spot-check the rendered HTML on a few paginated pages in production, not just the template source.