Pagination & Canonical Tags: The Correct Approach Since rel=prev/next Was Retired

A paginated series (page 1, page 2, page 3 of a category, a blog archive, or search results within a site) creates a set of distinct-but-related URLs, each showing a different slice of the same underlying content. This post covers what to actually do about that today. It’s distinct from parameter-based duplication generally (covered elsewhere on this site), even though paginated URLs are often parameter-based (?page=2) themselves; the thing that makes pagination its own case is the sequential-series relationship between the pages, not the parameter mechanic.

Why Canonicalizing Every Page to Page 1 Is Wrong

A pattern that shows up often enough to name directly: setting the canonical tag on every page of a paginated series to point at page 1. It looks like a tidy way to consolidate the series into one URL, but it does real damage. Pages 2, 3, and onward each contain content that page 1 doesn’t have. Canonicalizing them all to page 1 tells Google those pages aren’t worth indexing independently, and Google can act on that by effectively dropping pages 2+ out of the index entirely, taking whatever unique content and products or articles they contain out of search visibility with them. This was never a compliant fallback, and it remains a real mistake regardless of what else changes about pagination guidance.

Self-Referencing Canonical: The Current Standard

The current, correct approach is simpler: each page in a paginated series gets its own self-referencing canonical, pointing at itself, not at page 1 and not at any other page in the series. Page 2 canonicals to page 2’s own URL, page 3 to page 3’s own URL, and so on. This preserves each page’s ability to be crawled and indexed independently, which matters directly for e-commerce category pages and content archives where products or articles beyond page 1 still need to surface in search.

Google’s own guidance treats series discovery as a crawling problem to be solved with ordinary, visible HTML links, not a canonicalization problem. Each paginated page should link to the next and previous pages in the series using standard <a href> tags a crawler can follow the same way it follows any other link on the page. That combination, a unique self-referencing canonical plus normal crawlable links between pages, is the entire current model. There’s no separate signal, tag, or attribute needed beyond those two pieces.

rel=”prev”/rel=”next”: Historical Context, Not Current Practice

This is the correction this post exists to make. A lot of pagination content still in circulation describes rel=”prev” and rel=”next” link tags as current best practice, something to implement alongside canonical tags on every paginated page for “maximum clarity.” That guidance is stale, and telling readers in 2026 to build a pagination implementation around it is actively wrong, not just outdated.

What rel=prev/next was: an HTML tag pair, introduced around 2011, meant to tell Google explicitly which paginated page came before and after the current one, so Google could understand a sequence and potentially treat it as a single logical unit for indexing purposes.

What happened to it: Google officially announced its retirement from the Google Webmasters Twitter account on March 21, 2019, stating plainly, “As we evaluated our indexing signals, we decided to retire rel=prev/next.” The announcement itself came as something of a surprise disclosure rather than a forward-looking policy change: Search Engine Journal’s coverage and Search Engine Land’s reporting at the time both note that John Mueller confirmed Google had actually stopped using rel=prev/next in indexing “for a number of years” before the announcement, and a Google spokesperson acknowledged the delayed disclosure as an oversight, saying it was “something that we should have communicated proactively before taking down the documentation.”

What this means practically: rel=prev/next is not doing anything for Google’s indexing or ranking systems, and has not been for years. It may still be technically harmless to leave in a site’s markup for other consumers of the tag (Bing, for instance, has said it still uses rel=prev/next as a hint for page discovery, though not for grouping or ranking pages), but it should not be presented to readers as a ranking or indexing lever, a “HIGH priority” implementation, or something combined with canonical tags for added SEO benefit. It isn’t doing SEO work. Building or maintaining an implementation around it in 2026 is effort spent on a signal Google stopped reading years before it even announced the fact.

This also resolves a common source of confusion left over from the rel=prev/next era: without that tag pair, some site owners assumed Google would have no way to understand a paginated series at all, and reached for canonical-to-page-1 as a substitute way of signaling “these pages belong together.” That instinct gets the mechanism backwards. Canonical tags were never the tool for expressing series membership; ordinary crawlable links were always doing that job, both before and after rel=prev/next existed. Removing rel=prev/next didn’t remove Google’s ability to follow a “next page” link the way it follows every other link on the internet.

Path-Based vs. Parameter-Based Pagination

Two common URL patterns for pagination:

• Path-based: /category/page/2/
• Parameter-based: /category/?page=2

Both are fine choices, and Google’s guidance doesn’t prefer one over the other structurally. The canonical approach is identical either way: self-reference each page to its own URL, whichever pattern that site uses.

View-All Pages: Optional, Complementary

Offering a single “view all” page that displays the entire paginated series as one long page is a legitimate complementary option, not a mandatory one. Where a view-all page exists, it should carry its own self-referencing canonical, same as any other indexable page; it should not be treated as the canonical target for the individual paginated pages. Whether a view-all page makes sense at all depends on practical factors like total item count and page load performance; a category with a handful of paginated pages might reasonably offer one, while a category running into dozens of pages may make a single view-all page impractically heavy to load.

Pagination Plus Faceted Navigation: The Hard Case

The genuinely difficult scenario is page 2 (or later) of a filtered view, for instance, the second page of results after a shopper has applied a size and color filter to a category. The practical recommendation follows the same logic used for filter and facet handling generally: if the filtered, paginated combination represents content with real independent value and search demand, self-reference its canonical like any other paginated page; if it’s a narrow, low-value slice of an already-filtered view, it’s a stronger candidate for canonicalizing back to the base filtered view’s own first page, not back to the unfiltered category’s page 1. This is a judgment call made on the same basis as filter and facet decisions generally, applied at the intersection with pagination specifically.

A Worked Example

Consider a blog archive with 120 posts split across 12 pages at 10 posts each, reachable at /blog/, /blog/page/2/, /blog/page/3/, and so on. Under the pattern this post is arguing against, every one of those 12 pages would carry a canonical tag pointing at /blog/, on the theory that /blog/ is the “main” archive page. In practice, that tells Google the 110 posts that only appear on pages 2 through 12 aren’t worth indexing as part of a paginated series in their own right, since their listing pages have all been signaled away in favor of page 1. Under the current model, /blog/page/7/ canonicals to /blog/page/7/ itself, links forward to /blog/page/8/ and back to /blog/page/6/ through normal <a href> tags, and Google discovers and indexes the full series the same way it discovers any other set of interlinked pages on the site, no special pagination markup required.

Infinite Scroll

Infinite-scroll interfaces, where new content loads automatically as a visitor scrolls rather than through a distinct “next page” click, still need real, crawlable paginated fallback URLs underneath the scripted experience. Google’s crawling infrastructure does not scroll a page the way a human visitor does, so if the only way to reach content past the first batch is through a scroll-triggered JavaScript load with no corresponding URL, that content risks not being discovered or indexed at all. The practical fix is to pair infinite scroll with the same underlying paginated URL structure described above (path-based or parameter-based), so the visual experience and the crawlable structure exist side by side rather than the JavaScript UX replacing the URL structure entirely.

Platform Notes

WordPress and Shopify both handle basic pagination URL generation automatically (WordPress through its standard archive pagination, Shopify through its collection pagination), and the platform-specific setup, plugin behavior, and configuration details for each are covered in full in the platform-specific canonical setup post in this cluster rather than repeated here.

Testing and Validation

• View-source on a sample of paginated pages to confirm each carries its own self-referencing canonical, not a canonical pointing back to page 1.
• Google Search Console URL Inspection to confirm Google’s selected canonical for a paginated page matches the page’s own URL, not a collapsed page-1 version.

One thing intentionally left off this list: testing rel=prev/next tag validity. That was a standard item on pagination QA checklists through the 2010s, but testing whether a signal is correctly implemented only matters if Google is still reading that signal, and it hasn’t been for years. Keeping that test step on a 2026 checklist tests nothing useful.

Checklist

• Self-reference canonical on every page in the series, including page 1
• Never canonical pages 2+ back to page 1
• Don’t implement rel=prev/next as an active ranking or indexing measure; treat it as legacy markup at most, not a checklist item
• Path-based or parameter-based pagination URLs are both acceptable; be consistent
• View-all pages, where offered, get their own self-referencing canonical and remain optional
• Filtered-and-paginated combinations get evaluated for independent search value on a case-by-case basis
• Infinite-scroll interfaces still need real, crawlable paginated URLs underneath the scroll behavior

Conclusion

The correct approach to paginated series today is simpler than a lot of still-circulating pagination content implies: unique, self-referencing canonical on every page, discovery handled through Google’s normal crawling of the visible next/prev links in the page itself, and an optional view-all page as a complementary rather than mandatory addition. rel=prev/next belongs in this story as historical context, retired by Google in March 2019 after years of already going unused in indexing, not as a best practice to implement in 2026.