rel=next/prev and Canonical Tags: The Modern Pagination Setup
The combination of rel="next", rel="prev", and rel="canonical" on paginated archives — category pages, blog indexes, search results, forum threads — is one of the most-changed and most-confused topics in technical SEO. The advice that was correct in 2014 is wrong now. The advice that was correct in 2019 is partly wrong now. This guide covers what the tags do, what each search engine does with them in 2026, and how to combine them correctly on the paginated pages of a real production site.
What rel=next and rel=prev Were Originally For
Google introduced support for rel="next" and rel="prev" in September 2011. The intent was to give site owners a way to indicate that a series of URLs — typically ?page=1, ?page=2, ?page=3 of a category listing — represented a logical sequence rather than independent pages. Google said it would consolidate indexing properties for the series and typically show the first page in search results.
Implementation was straightforward. Each page in the series declared its sibling relationships in the <head>:
<!-- On https://example.com/category?page=2 --> <link rel="prev" href="https://example.com/category?page=1"> <link rel="next" href="https://example.com/category?page=3"> <link rel="canonical" href="https://example.com/category?page=2"> <!-- On the first page (no rel=prev) --> <link rel="next" href="https://example.com/category?page=2"> <link rel="canonical" href="https://example.com/category"> <!-- On the last page (no rel=next) --> <link rel="prev" href="https://example.com/category?page=4"> <link rel="canonical" href="https://example.com/category?page=5">
For seven years this was the recommended pattern. SEO plugins (Yoast, All in One SEO, Rank Math) all output it by default. CMS templates baked it into archive layouts.
The 2019 Announcement: Google Stopped Using rel=next/prev
On 21 March 2019, Google's John Mueller posted on Twitter that Google had stopped using rel=next/rel=prev as an indexing signal "years ago" — meaning the markup had been silently ignored long before the public announcement. The reasoning given was that users typically land on individual pages of a series via search, so Google had moved to evaluating each paginated page on its own merits rather than treating the series as a single logical entity.
The announcement caused two waves of confusion. The first was site owners removing all pagination markup, assuming if Google ignored it, it was useless. The second was site owners assuming the deprecation meant pagination needed special canonical handling — and incorrectly canonicalizing all paginated pages back to page 1.
Both reactions were wrong. The correct interpretation is narrower: Google treats each paginated URL as an independent page now. That means each one needs to be a fully indexable page with a self-referencing canonical, and each one should link clearly to its siblings via in-body navigation links. The rel=next/rel=prev tags themselves are still valid HTML and still useful for other consumers — they just no longer help with Google.
What to Do Now: Self-Referencing Canonical on Each Page
The single most important rule for paginated archives in 2026: every paginated page declares a canonical that points to itself, not to page 1. This is the opposite of what many older SEO guides still recommend.
The reason is simple. Canonical tells Google "this URL is the preferred version of a page with this content." If /category?page=2 canonicalizes to /category, you are claiming page 2 is a duplicate of page 1. It isn't — it has different products, different articles, different content. Google will obey the canonical and drop page 2 from its index, which means none of the items unique to page 2 onwards will be indexed via the category path. They will only be indexed if Googlebot finds them via some other route, and even then they accumulate fewer ranking signals because the category-level link path is broken.
The correct configuration:
<!-- /category (page 1) --> <link rel="canonical" href="https://example.com/category"> <!-- /category?page=2 --> <link rel="canonical" href="https://example.com/category?page=2"> <!-- /category?page=3 --> <link rel="canonical" href="https://example.com/category?page=3"> <!-- /category?page=N --> <link rel="canonical" href="https://example.com/category?page=N">
If your URL pattern uses /category/page/2/ instead of query parameters, the same rule applies — the canonical on /category/page/2/ points to /category/page/2/, not to /category/. Whatever URL form your CMS uses for pagination, that exact URL is the canonical for that page.
Bing and Other Engines Still Use rel=next/prev
The 2019 deprecation was a Google-only change. Bing has publicly confirmed (most recently via Fabrice Canel and Frédéric Dubut on multiple occasions) that it continues to use rel=next/rel=prev as a hint for understanding pagination relationships. Yandex has historically supported the markup as well. Several smaller engines and crawlers — including some assistive technology and feed readers — also rely on it.
The practical consequence: keep emitting rel=next and rel=prev. Removing them only harms you on engines that still use them, while gaining nothing on Google (which already ignores them). The cost of keeping them is a few hundred bytes per page; the upside is hint-level signals to non-Google traffic sources, which on some sites can be 10–25% of organic traffic.
Combine the two: emit self-referencing canonicals, AND emit rel=next/rel=prev. Both at once, no conflict.
The Correct Combined Markup
Here is the modern, complete pagination markup for a five-page archive at /blog:
<!-- Page 1: /blog --> <link rel="canonical" href="https://example.com/blog"> <link rel="next" href="https://example.com/blog/page/2/"> <!-- Page 2: /blog/page/2/ --> <link rel="canonical" href="https://example.com/blog/page/2/"> <link rel="prev" href="https://example.com/blog"> <link rel="next" href="https://example.com/blog/page/3/"> <!-- Page 3: /blog/page/3/ --> <link rel="canonical" href="https://example.com/blog/page/3/"> <link rel="prev" href="https://example.com/blog/page/2/"> <link rel="next" href="https://example.com/blog/page/4/"> <!-- Page 4: /blog/page/4/ --> <link rel="canonical" href="https://example.com/blog/page/4/"> <link rel="prev" href="https://example.com/blog/page/3/"> <link rel="next" href="https://example.com/blog/page/5/"> <!-- Page 5 (last): /blog/page/5/ --> <link rel="canonical" href="https://example.com/blog/page/5/"> <link rel="prev" href="https://example.com/blog/page/4/">
Notes on this template:
The first page omits rel=prev (no previous page exists). The last page omits rel=next (no next page exists). The first page's canonical points to the bare category URL /blog — not /blog/page/1/ — because most CMS routing serves the same content for both, and the bare URL is the canonical form. If your CMS serves /blog/page/1/ as a separate URL, 301-redirect it to /blog and never expose /page/1/ in pagination links.
The View-All Page Pattern
An alternative pattern Google still officially supports is offering a single "view-all" page that contains all items at once, then canonicalizing each paginated page to the view-all URL. This consolidates ranking signals but has practical drawbacks — view-all pages are slow when item counts are high, and they can hurt Core Web Vitals.
<!-- View-all page: /category/all --> <link rel="canonical" href="https://example.com/category/all"> <!-- Paginated views all canonical to view-all --> <!-- /category --> <link rel="canonical" href="https://example.com/category/all"> <!-- /category?page=2 --> <link rel="canonical" href="https://example.com/category/all"> <!-- /category?page=3 --> <link rel="canonical" href="https://example.com/category/all">
This pattern only makes sense if (a) your view-all URL exists, returns 200, and contains every item, (b) it loads fast enough not to harm performance, and (c) total item count is bounded — usually under a few hundred. For a category with 50 products, view-all is reasonable. For one with 50,000 products, do not use this pattern. Use self-referencing canonicals on each paginated page instead.
Also: do not combine the view-all pattern with self-referencing canonicals. Pick one strategy per archive. Mixing them creates contradictory signals.
Infinite Scroll and "Load More" Patterns
Infinite scroll changes the question entirely. If your archive loads additional items via JavaScript without changing the URL, there is only one URL — and the question of pagination canonicals does not arise. The single URL gets a single self-referencing canonical, and you make sure Googlebot can see all the items.
The two ways to make infinite scroll content crawlable:
<!-- Pattern 1: Infinite scroll URL is the only canonical -->
<!-- /category -->
<link rel="canonical" href="https://example.com/category">
<!-- Items beyond the initial render are loaded via JS as user scrolls.
For Googlebot to discover them, either:
A) Server-side render the full list on first paint, or
B) Provide a fallback paginated route that crawlers can follow: -->
<noscript>
<a href="/category?page=2">Load more</a>
</noscript>
<!-- Pattern 2: Hybrid — infinite scroll for users, paginated URLs underneath -->
<!-- The URL updates to /category?page=2 as user scrolls (history.pushState).
Each canonical URL has its own page with self-referencing canonical: -->
<!-- /category?page=2 -->
<link rel="canonical" href="https://example.com/category?page=2">
<link rel="prev" href="https://example.com/category">
<link rel="next" href="https://example.com/category?page=3">Pattern 2 — sometimes called "progressive pagination" — is the safer default for SEO-critical archives. Users see a smooth infinite-scroll experience, but each scroll-loaded segment has a real URL Googlebot can crawl independently.
When to noindex Paginated Pages (Almost Never)
A common older recommendation was to noindex paginated pages 2 through N to "avoid duplicate content." This advice was wrong when it was given and is still wrong. noindex on paginated pages tells Google to drop them from the index entirely. Combined with Google's long-running treatment of noindex,follow as eventually equivalent to noindex,nofollow, this means the products and articles linked from those pages stop receiving any link signal from the category path.
The correct default: paginated pages stay indexable. Every product link, every article link in your category structure should be reachable from indexable pages.
The narrow exceptions where noindex on paginated pages can be appropriate:
Search results pages. Internal site search result pages (/search?q=widget&page=3) are explicitly mentioned by Google's guidelines as low-value for the index. noindex on these is fine and often beneficial.
Tag-archive thin pages. If a tag archive has only one or two posts and is essentially duplicative of the post URLs themselves, noindexing makes sense.
Noisy faceted combinations. Combinations of three or more filters with low search demand (?color=red&size=xl&brand=nike&page=4) — but these usually need broader treatment than just noindex; see the faceted navigation guide.
Faceted/Filtered URLs That Look Like Pagination but Aren't
One of the most common canonical mistakes is treating filtered URLs as if they were pagination. They aren't — and the canonical strategy for them is different.
Pagination URLs (?page=2) are slices of the same fundamental list. Filter URLs (?color=blue, ?sort=price) are different lists derived from filters or sorts on that base list. The two get different treatment:
# Pagination — self-referencing canonical: /category?page=2 → canonical /category?page=2 ✓ # Sort filter — canonical to base (sorts are reorderings, not new content): /category?sort=price_asc → canonical /category ✓ # Single attribute filter with high search demand — self-referencing: /category?color=red → canonical /category?color=red ✓ # (only if "red [category]" has independent search demand) # Combined filter + pagination: /category?color=red&page=2 → canonical /category?color=red&page=2 ✓ # (preserves the filter + page in canonical) # Low-value combined filters: /category?color=red&size=xl&brand=nike → canonical /category ✓ # (or noindex; do not let combinatorial explosion get indexed)
The decision rule: a filtered URL deserves its own self-canonical if and only if its content has independent search demand worth ranking for. Otherwise canonical it to the base.
JS-Rendered Pagination
If your pagination is rendered by client-side JavaScript — React Router, Vue Router, Next.js client navigation — then the canonical, rel=next, and rel=prev tags must be present in the server-rendered HTML, not just injected on the client. Googlebot's first-wave crawl reads raw HTML. If the canonical is missing on first wave, the page enters a slower "discovered, not indexed" pipeline.
In Next.js App Router, use generateMetadata on the dynamic pagination route:
// app/category/[category]/page/[page]/page.tsx
import type { Metadata } from 'next';
export async function generateMetadata({
params,
}: {
params: { category: string; page: string };
}): Promise<Metadata> {
const { category, page } = params;
const pageNum = parseInt(page, 10);
const baseUrl = `https://example.com/category/${category}`;
const selfUrl = pageNum === 1 ? baseUrl : `${baseUrl}/page/${pageNum}`;
const totalPages = await getTotalPages(category);
const prevUrl = pageNum > 1
? (pageNum === 2 ? baseUrl : `${baseUrl}/page/${pageNum - 1}`)
: null;
const nextUrl = pageNum < totalPages
? `${baseUrl}/page/${pageNum + 1}`
: null;
return {
alternates: {
canonical: selfUrl,
...(prevUrl || nextUrl ? {
types: {
...(prevUrl ? { 'prev': prevUrl } : {}),
...(nextUrl ? { 'next': nextUrl } : {}),
},
} : {}),
},
};
}For Pages Router, output the same tags inside next/head within getStaticProps/getServerSideProps. The key requirement is that view-source: on the page shows the canonical and pagination links — not just the rendered DOM in DevTools.
Schema.org Pagination Properties
Schema.org provides CollectionPage with a hasPart property and the standalone properties nextItem, previousItem, and position. These are not consumed by Google for pagination understanding either, but they do provide structured-data-aware crawlers (some research and AI crawlers) with explicit relationships:
{
"@context": "https://schema.org",
"@type": "CollectionPage",
"@id": "https://example.com/blog/page/2/",
"url": "https://example.com/blog/page/2/",
"name": "Blog — Page 2",
"isPartOf": {
"@type": "Blog",
"@id": "https://example.com/blog"
},
"mainEntity": {
"@type": "ItemList",
"itemListOrder": "https://schema.org/ItemListOrderDescending",
"numberOfItems": 10,
"itemListElement": [
{ "@type": "ListItem", "position": 11, "url": "https://example.com/post-11" },
{ "@type": "ListItem", "position": 12, "url": "https://example.com/post-12" }
]
}
}Optional but cheap. Adds explicit machine-readable pagination context for any consumer that parses JSON-LD.
Common Pagination Canonical Mistakes
Canonicalizing all pagination to page 1. The biggest single mistake. Drops pages 2+ from the index. If you have this pattern in your CMS today, fix it before doing anything else.
Missing self-canonicals on paginated pages. If pages 2+ have no canonical at all, Google may pick a different canonical itself — often choosing page 1 — and you end up with the same outcome as the previous mistake. Always emit an explicit self-referencing canonical.
Including pagination parameters in the URL conflicting with canonical. If /category?page=2&ref=newsletter&utm_source=email outputs a canonical of /category?page=2&ref=newsletter&utm_source=email, you have just created an indexable URL for every tracking-parameter combination. Strip tracking parameters from the canonical: emit /category?page=2 as the canonical regardless of what tracking params are appended in the visited URL.
Including /page/1/ in pagination links. If your "previous" link from page 2 points to /category/page/1/ instead of /category/, you have created two URLs for the same page-1 content. Always link to the bare category URL for page 1.
Mismatching canonical and rel=prev/rel=next URL forms. If your canonical uses trailing slashes (/page/2/) but your rel=prev doesn't (/page/1), you create signal contradiction. Pick one URL form for the entire site and apply it consistently across canonicals, pagination links, and internal links.
Putting paginated URLs in the sitemap when they're canonicalized away. If you canonical pages 2+ to a view-all page or to page 1, do not also include those paginated URLs in your sitemap. That triggers the GSC "Duplicate, submitted URL not selected as canonical" warning. Either keep self-canonicals and submit all paginated URLs, or use view-all and submit only the view-all URL.
Using rel=next/prev as canonical replacement. Some site owners, after the 2019 deprecation, removed canonical entirely from paginated pages assuming rel=next/prev was the canonical mechanism. It is not, and never was. Canonical and pagination links describe different things and both should be present.
Auditing Your Current Pagination Setup
The fastest way to check whether your paginated pages have the right canonicals:
# Check canonical on a paginated URL — should return the URL itself
curl -s https://example.com/blog/page/2/ \
| grep -oE 'rel="canonical"[^>]*href="[^"]+"'
# Expected output:
# rel="canonical" href="https://example.com/blog/page/2/"
# WRONG — this is the broken pattern:
# rel="canonical" href="https://example.com/blog"
# Verify rel=prev/rel=next are present:
curl -s https://example.com/blog/page/2/ \
| grep -E 'rel="(prev|next)"'
# Bulk-check all paginated URLs in your sitemap:
curl -s https://example.com/sitemap.xml \
| grep -oE '<loc>[^<]*page[^<]*</loc>' \
| sed -E 's|</?loc>||g' \
| while read URL; do
CANONICAL=$(curl -s "$URL" | grep -oE 'rel="canonical"[^>]*href="[^"]+"' | grep -oE 'https?://[^"]+')
if [ "$CANONICAL" != "$URL" ]; then
echo "MISMATCH: $URL → canonical $CANONICAL"
fi
doneAny output from the bulk script indicates a paginated URL whose canonical doesn't match itself — almost always the "canonical to page 1" mistake. Fix at the CMS or template level, not URL-by-URL.