Pagination, Canonical Tags, and rel=prev/next: What Changed and What Still Matters

Google deprecated rel=prev/next for pagination in 2019 — but the underlying canonicalization problem paginated content creates didn't go away, it just lost its dedicated solution

For years, paginated content (article series split across multiple pages, product category listings with page 1, page 2, page 3, etc.) had a purpose-built solution: rel="next" and rel="prev" link tags, which told search engines "these pages form a sequence; treat them as a connected unit." In 2019, Google announced it had stopped using these signals. This left many sites with pagination markup that no longer does anything — and raised the question of what, if anything, should replace it.

What rel=prev/next was supposed to do

The mechanism, as originally specified:

<!-- On page 2 of a paginated series -->
<link rel="prev" href="https://example.com/category/widgets?page=1">
<link rel="next" href="https://example.com/category/widgets?page=3">

The intended effect: search engines would understand that pages 1, 2, 3, etc. of a series were part of a single logical sequence — potentially consolidating ranking signals across the series, and potentially showing the first page of a series in search results even if a later page might otherwise rank for a query (on the theory that users would prefer to land on page 1 of a series and navigate from there).

Why Google stopped using it: Google's stated reasoning (in their 2019 announcement) was that their systems had become capable of understanding paginated series and grouping related content without relying on explicit rel=prev/next markup — the signal had become redundant with what their algorithms could infer directly from page structure, internal linking, and content similarity.

What this means in practice: pagination markup is now (mostly) inert

Including rel=prev/next markup today doesn't cause any problems — Google has stated they simply ignore it, not that it's harmful. But it also doesn't provide the benefit it once did — sites that previously implemented it specifically for SEO purposes aren't gaining anything from continuing to maintain it, for Google specifically.

Other search engines: Google's deprecation announcement was specific to Google — other search engines' handling of rel=prev/next isn't necessarily identical, though Google's market share means most SEO discussion of pagination is centered on Google's current behavior.

The actual canonicalization question for paginated pages

Separate from rel=prev/next, a related and still relevant question: should each page in a paginated series have a canonical tag pointing to itself, or should all pages canonicalize to page 1?

Self-referencing canonicals (each page canonicalizes to itself) — generally the current recommended approach: page 2 of a category listing has a canonical tag pointing to page 2's own URL (not page 1). This reflects that page 2 contains genuinely different content (different products/items) than page 1 — it's not a duplicate of page 1, so canonicalizing it to page 1 would be telling search engines "this content doesn't really exist independently, treat page 1 as the canonical version" — which could result in page 2's content not being independently indexed/considered for ranking, even though it contains unique items not present on page 1.

Canonicalizing all pages to page 1 — generally NOT recommended for genuinely paginated content with unique items per page: this was sometimes done historically (partly as a misunderstanding of how canonical tags should interact with pagination, and partly because some interpretations of "consolidate signals to page 1" suggested this) — but for a paginated product listing where pages 2, 3, 4, etc. contain genuinely different products than page 1, telling search engines "these are all the same as page 1" via canonical tags can result in those products on later pages not being discoverable via search at all (since search engines are being told the "canonical" version is page 1, which doesn't contain those products).

The distinction that matters: is the paginated content genuinely different per page (different products, different articles) — in which case self-referencing canonicals are appropriate — or is the pagination splitting up what's conceptually the same content (e.g., a single article artificially split across multiple page-views, primarily for ad-impression reasons, where each "page" doesn't have independent value as a search result) — in which case different handling (potentially a "view all" page that is the canonical target, with paginated views canonicalizing to it) might be more appropriate.

"View All" pages and canonical targets

For content that's primarily the same regardless of pagination (e.g., a long article split into 5 pages purely for ad-revenue/pageview reasons, where a "view all on one page" option also exists):

<!-- On paginated page 2 of 5 -->
<link rel="canonical" href="https://example.com/article/view-all">

<!-- On the "view all" page itself -->
<link rel="canonical" href="https://example.com/article/view-all">

This pattern says: "the individual paginated pages are essentially views of the same underlying content; the 'view all' page is the canonical representation" — appropriate when the paginated pages genuinely don't have independent value as distinct search results (a user searching for content from "page 3 of 5" of an article would generally be just as well served by the "view all" page, which contains that same content plus the rest of the article).

This is different from category/product pagination (page 2 of a product listing) — where each page does have independent value (different products), and a hypothetical "view all 500 products on one page" might not even be a good user experience (extremely long page) even if it existed — self-referencing canonicals remain appropriate for this case, as discussed above.

Infinite scroll: a related pattern with its own considerations

Infinite scroll (content loading progressively as the user scrolls, without traditional "page 2/3/4" URLs) presents related but distinct considerations:

If infinite-scroll content has no corresponding paginated URLs at all — only the initial content (what's visible without scrolling/before JavaScript-loaded content appears) may be straightforwardly crawlable — content that only loads via scroll-triggered JavaScript requests might not be discovered/indexed by crawlers in the same way as content present in initial HTML or reachable via traditional paginated URLs, depending on how the infinite scroll is implemented and how search engine crawlers handle the relevant JavaScript execution.

A common pattern for SEO-conscious infinite scroll: implementing infinite scroll for the user experience, while also maintaining traditional paginated URLs (page 2, page 3, etc., each independently accessible and crawlable) that correspond to the "chunks" of content the infinite scroll loads — using the History API to update the URL as the user scrolls (so that if a user is on "conceptually page 3" via scrolling, the URL reflects this and could be directly linked/bookmarked) — providing both a smooth scroll experience and crawlable, linkable URLs for each content chunk.

How to use the Canonical Tag Generator on sadiqbd.com

1. For paginated category/listing pages: generate self-referencing canonical tags for each page — each page's canonical points to itself
2. For content with a "view all" alternative: generate canonical tags pointing the paginated views to the view-all URL, and a self-referencing canonical on the view-all page itself
3. Verify consistency: ensure canonical tags across a paginated series don't inadvertently create conflicting signals (e.g., page 2 canonicalizing to page 1, while page 3 canonicalizes to itself — an inconsistent pattern across the series)

Frequently Asked Questions

Should I remove rel=prev/next markup from my pages now that Google doesn't use it? There's generally no urgency to remove it — Google has indicated it's simply ignored, not harmful — but there's also no benefit to adding it to new pages/templates if you don't already have it, since it doesn't provide the effect it once did (for Google). If maintaining it requires ongoing development effort for templates that don't otherwise need it, that effort could be redirected elsewhere; if it's already part of an existing template and removing it would itself require effort, leaving it in place is unlikely to cause issues.

Does pagination affect crawl budget — is having many paginated pages "wasteful"? For very large sites with extensive pagination (e-commerce sites with categories containing thousands of products across hundreds of paginated pages), crawl budget considerations can become relevant — though this is more a concern for very large sites where crawl budget is a genuine constraint, rather than a general concern for typical sites. For sites where crawl budget isn't a limiting factor (most small-to-medium sites), the canonicalization considerations discussed above (ensuring paginated content is appropriately discoverable) are generally more relevant than crawl-budget optimization specifically.

Is the Canonical Tag Generator free? Yes — completely free, no sign-up required.

Try the Canonical Tag Generator free at sadiqbd.com — generate correct canonical tags for paginated content, view-all pages, and any duplicate content scenario.