You have /blog/, /blog/page/2/, /blog/page/3/. Search Console flags page 2+ with “Duplicate, Google chose different canonical.” Old SEO posts told you to canonical every paginated page to /blog/, or to add rel="prev" / rel="next". Newer posts say the opposite. Both are partly stale.
Fastest fix: make each paginated page self-canonical (/blog/page/2/ points its canonical at /blog/page/2/, not at /blog/), keep the pagination links as real <a href> anchors, and only noindex, follow the genuinely low-value variants (search results, faceted filter combinations). This is exactly what Google’s own docs say today — “Don’t use the first page of a paginated sequence as the canonical page. Instead, give each page its own canonical URL” (Pagination best practices, Google Search Central).
Google stopped using rel=next/prev in 2019 and the guidance has not changed since. The rest of this guide is the diagnosis and the per-step implementation.
Which bucket are you in?
Before changing anything, look at the actual canonical your paginated page emits and decide what kind of page it is.
| What you observe | Diagnosis | Fix |
|---|---|---|
page/2/ canonical points to /blog/ | Old “canonical to page 1” advice (most common) | Make it self-canonical (Step 2) |
page/2/ has noindex AND is in sitemap | Mixed signals; Google distrusts both | Pick one: index + self-canonical, or noindex + drop from sitemap (Step 4) |
URL is ?page=2&sort=date&filter=ai | Parameter permutations look like duplicates | Self-canonical the real list; noindex filter/sort variants (Step 4) |
URL only exists from a filter combo (?tag=ai&page=2) | Faceted filter view, not real pagination | noindex, follow (Step 4) |
| Scrolling loads items but URL never changes | Infinite scroll with no crawlable state | Add real paginated URLs + sitemap (Steps 5-6) |
| Self-canonical already, still flagged | Often a reporting lag, not a true error | Verify in URL Inspection (see “How to confirm”) |
To read the canonical directly:
curl -s https://yoursite.com/blog/page/2/ | grep -i 'rel="canonical"'Common causes
Ordered by hit rate, highest first.
1. Old tutorials say page/2 → page/1 canonical
Pre-2019 advice was to canonical every paginated page to page 1. Modern Google reads that as you declaring “these aren’t real pages — show page 1 instead,” so page 2-N content effectively drops out of the index. Google’s current docs are explicit that this is wrong: each page gets its own canonical.
How to spot it: inspect /blog/page/2/’s <link rel="canonical">. If it points to /blog/, you followed the old advice.
2. Still emitting rel=next/prev (usually harmless)
Google ignores rel=next/prev as of 2019, so they do nothing for Google ranking. They are not harmful, and Bing plus some other engines still read them — Yoast deliberately keeps emitting them for that reason. Remove them only if you want cleaner markup; do not treat their presence as the bug.
How to spot it: curl -s https://yoursite.com/blog/page/2/ | grep -E 'rel="next"|rel="prev"'. Present is fine; it is not the cause of your duplicate flag.
3. Paginated pages have a noindex + sitemap conflict
Some templates noindex pagination and leave it in sitemap.xml, creating the contradiction described in Robots meta vs sitemap conflict. Google sees one signal saying “don’t index” and another saying “here’s an important URL.”
How to spot it: view source of the paginated page. If it has noindex AND the same URL appears in sitemap.xml, resolve the conflict.
4. Pagination uses URL parameters Google can’t tell apart
/blog?page=2&sort=date&filter=ai — Google’s heuristics may treat permutations as duplicates without canonical guidance, and crawlers can burn budget on every low-value combination.
How to spot it: pagination relies on query-string parameters (especially several at once) instead of clean path segments like /page/2/.
5. Paginated content actually IS a duplicate (filter views)
/blog/?tag=ai, /blog/?tag=ai&page=2, etc. Each combination is a unique URL, but the page only filters an existing list. These should be noindex, follow.
How to spot it: the paginated URL exists only because of a filter combination, not because your library is genuinely deep enough to page through.
6. Infinite scroll with no crawlable URL state
Infinite-scroll listings load more items via JavaScript but never change the URL, so Google cannot reach the deeper items. (Related, slightly different problem.)
How to spot it: scrolling adds items but the URL stays /blog/. Google indexes only the first batch it sees in the initial HTML.
Shortest path to fix
Step 1: Decide per pagination type
| Pagination type | Treatment |
|---|---|
Main blog index pagination (/blog/page/2/) | Each page self-canonical, indexable |
| Category / tag pagination | Self-canonical, indexable |
| Search results | noindex, follow |
| Faceted filter combinations | noindex, follow, or block the pattern in robots.txt |
| Infinite scroll | Add real paginated URLs in parallel + list them in the sitemap |
Step 2: Make blog / category pagination self-canonical
Each paginated URL should point its canonical at itself.
Astro:
---
const url = new URL(Astro.url.pathname, Astro.site).toString();
---
<link rel="canonical" href={url} />/blog/page/2/ canonical → /blog/page/2/. Done.
WordPress / Yoast already does this — paginated archives self-reference by default, so you usually only need to confirm a plugin or theme has not overridden the canonical back to page 1.
Step 3: Leave (or remove) rel=next/prev — your choice
Google does not use them either way. Keep them if you care about Bing; remove them if you want cleaner markup. They are not the cause of the duplicate flag, so do not spend time here unless you are tidying templates.
- <link rel="next" href={`/blog/page/${currentPage + 1}/`} />
- <link rel="prev" href={`/blog/page/${currentPage - 1}/`} />Step 4: Noindex only the genuinely low-value variants
For search results, sort orders, or filter combinations, use the robots meta tag — this is Google’s own recommendation for “variations of the same list of results”:
<meta name="robots" content="noindex, follow">follow matters — Google still crawls the internal links to discover indexable content. If a URL is noindex, also remove it from sitemap.xml so you do not send the mixed signal in cause 3.
Step 5: Make sure pagination is crawlable
Pagination links must be real <a href> anchors, not JavaScript-only buttons. Google’s render budget may not execute JS pagination, so deeper pages can go undiscovered.
<a href="/blog/page/2/">Next</a>Google also suggests linking each page back to the first page so the start of the collection is reinforced.
Step 6: Submit a sitemap with the paginated URLs
List /blog/, /blog/page/2/, /blog/page/3/ … as individual entries so Google can discover deep pagination. For infinite scroll specifically, this sitemap (or a product feed) is the primary discovery path Google recommends.
For very deep pagination (more than ~30 pages), also build browseable category/tag listings so deep articles have a shorter click path from the homepage.
Step 7: Audit Search Console after the fix
Search Console → Pages → check the status of paginated URLs. They should move from “Duplicate, Google chose different canonical” to “Indexed” over roughly 2-4 weeks once Google recrawls.
How to confirm it’s fixed
- Live URL Inspection: in Search Console, run URL Inspection on
/blog/page/2/, click “Test Live URL,” and check that “User-declared canonical” and “Google-selected canonical” now both read/blog/page/2/. - Recheck the raw tag:
curl -s https://yoursite.com/blog/page/2/ | grep -i 'rel="canonical"'should return the page’s own URL. - Watch the report shift: the “Duplicate, Google chose different canonical” count should fall on the Pages report over the next few crawl cycles.
One caveat worth knowing as of June 2026: Google’s Martin Splitt noted in 2025 that a URL flagged this way can still be part of Google’s index as a near-duplicate cluster member even while the GSC report shows it as not indexed. So if the page is self-canonical, returns 200, and is internally linked, it is likely fine — the label can lag reality. Do not start canonicalizing back to page 1 to “fix” the label.
FAQ
Should each paginated page have a self-referencing canonical, or canonical to page 1? Self-referencing. Google’s current docs state plainly: don’t use page 1 as the canonical for the series; give each page its own canonical URL.
Will removing rel=next/prev fix my duplicate-canonical flag?
No. Google has ignored those tags since 2019, so they are neither the cause nor the fix. The flag comes from your canonical (or noindex/sitemap) signals, not from rel=next/prev.
Is “Duplicate, Google chose different canonical” actually hurting me? Not necessarily. It means Google picked a different canonical than the one you declared. If your paginated pages are self-canonical, return 200, and are internally linked, the status is often a reporting artifact and the pages can still sit in the index. Fix it only if real listing pages are being collapsed into page 1.
Should I noindex all my paginated pages to avoid duplicate-content penalties?
No — there is no duplicate-content penalty for legitimate pagination, and noindex on real list pages hides the articles they link to. Only noindex, follow low-value variants: search results, sort orders, and faceted filter combinations.
My pagination uses ?page=2 query parameters. Do I have to switch to /page/2/ paths?
Not strictly, but clean path segments are easier for Google to treat as distinct pages. If you stay on parameters, make each one self-canonical and noindex the filter/sort permutations so crawlers do not waste budget on duplicates.
How long until Search Console shows the pages as Indexed? Usually 2-4 weeks after Google recrawls. You can request indexing via URL Inspection for the most important paginated pages to speed up the first recrawl.
Prevention
- Treat each paginated page as an independent listing — self-canonical, indexable.
- Don’t rely on
rel=next/prevas a fix; Google ignores them (keep them only for Bing). - For filter/search-result variants, use
noindex, follow— never fully block, or Google can’t discover the content behind them. - Use real
<a>links for pagination, not JS-only buttons. - Keep
noindexURLs out of the sitemap so you never send mixed signals. - Re-audit pagination behavior any time you add a new listing type to the site.
Related
- Canonical misconfigured
- Canonical mismatch bilingual
- Robots meta vs sitemap conflict
- Last-Modified header missing
- Duplicate without user-selected canonical
Tags: #SEO #Troubleshooting