Pagination and Canonical Tags: Google’s Current Approach to Multi-Page Series
- Filed November 10, 2026
- Crawling and indexing, guide 12 of 16
Each page in a paginated series should have its own URL and its own self-referencing canonical tag. Pointing page 2, page 3 and every later page to page 1 as the canonical is the configuration Google tells site owners not to use: its pagination guide says “Don’t use the first page of a paginated sequence as the canonical page. Instead, give each page its own canonical URL” (Google’s pagination guide). The reason is simple. Page 3 of a category lists different products from page 1. Telling Google that page 3 is a duplicate of page 1 asks it to ignore the products that only appear on page 3.
What Google says today
Google’s pagination guide (last updated December 10, 2025) sets out the current approach in a few rules:
- Unique URLs. “Give each page a unique URL”, for example
?page=2, and do not use URL fragments (#page=2) for page numbers, because “Google ignores fragment identifiers”. - Sequential links. Include links from each page to the next page using normal
<a href>links, because Google’s guide says it generally crawls the URLs found in thehrefattribute of<a>elements. - Self-referencing canonicals. Each page is its own canonical.
- Optional link back to page 1. Google suggests “linking from all individual pages in a collection back to the first page of the collection”, which “can give Google a hint that the first page of a collection might be a better landing page than other pages”.
- Titles may repeat. Google notes that pages in a paginated sequence “don’t need to follow” the usual advice to give pages distinct titles, and that Google tries to recognize pages in a sequence.
- Filters and sort orders. To avoid indexing variations of the same list (for example
?order=price), block unwanted URLs from indexing withnoindexor discourage crawling of the URL patterns with robots.txt.
The history of rel=next and rel=prev
For years, Google recommended marking paginated series with <link rel="next"> and <link rel="prev"> in the page head. Google’s current guide states: “In the past, Google used” these tags, and “Google no longer uses these tags, although these links may still be used by other search engines”.
Practical consequences:
- Existing
rel="next"andrel="prev"tags do no harm and can stay if another search engine or tool you care about reads them. - They do not substitute for crawlable
<a href>links between pages. A series connected only by<link>tags in the head and by JavaScript buttons gives Google no links to follow. - Advice that relies on these tags to “consolidate” a series is outdated.
Canonical configuration for pages 1, 2 and 3
Assume a category at https://www.example.com/shoes/ with 72 products, 24 per page.
Page 1
<!-- https://www.example.com/shoes/ -->
<link rel="canonical" href="https://www.example.com/shoes/">
<a href="https://www.example.com/shoes/?page=2">Next page</a>
Page 2
<!-- https://www.example.com/shoes/?page=2 -->
<link rel="canonical" href="https://www.example.com/shoes/?page=2">
<a href="https://www.example.com/shoes/">Page 1</a>
<a href="https://www.example.com/shoes/">Previous page</a>
<a href="https://www.example.com/shoes/?page=3">Next page</a>
Page 3
<!-- https://www.example.com/shoes/?page=3 -->
<link rel="canonical" href="https://www.example.com/shoes/?page=3">
<a href="https://www.example.com/shoes/">Page 1</a>
<a href="https://www.example.com/shoes/?page=2">Previous page</a>
Two details matter:
- Page 1 is canonicalized to the clean category URL, not to
?page=1. If the site also generates?page=1, redirect it or canonicalize it to the clean URL so that two URLs do not compete for the first page. - Requests for page numbers beyond the end of the series (
?page=99on a three-page category) should return a 404. Google’s faceted navigation guidance lists nonexistent pagination URLs among the cases where a 404 is appropriate (Google on faceted navigation).
These snippets are illustrative and show only the relevant elements.
Sort and filter variants
Sorting and filtering create URLs that show the same products in a different order or a subset of them. They are a separate problem from pagination and need a separate decision.
| URL type | Example | Recommended handling |
|---|---|---|
| Paginated page | <!–INLINECODE17–> | Indexable, self-canonical, linked sequentially |
| Sort order | <!–INLINECODE18–> | Keep out of the index (<!–INLINECODE19–>), canonicalize to the unsorted page, or discourage crawling (robots.txt) |
| Sorted page 2 | <!–INLINECODE20–> | Same as sort order |
| Filter that defines a useful landing page | <!–INLINECODE21–> | Treat as its own category with its own pagination |
| Filter combinations | <!–INLINECODE22–> | Block crawling when combinations multiply; see Google's faceted navigation guidance |
Do not canonicalize every sort variant of page 3 to page 1. Canonicalize a sorted variant to the unsorted version of the same page if you keep it crawlable, or keep it out of crawling altogether.
“View all” pages
Google’s current pagination guide does not discuss view-all pages; its recommendation is the self-canonical pattern above. A single page listing every item can still be a good experience for small sets, and a site that genuinely wants searchers to land on a fast view-all page can make that page the canonical for the series and accept that the paginated pages will not be indexed separately. For large sets, a slow view-all page is a poor landing page, and paginated self-canonicals remain the safer pattern. Choose one approach and apply it consistently.
Load more and infinite scroll
Google’s guide notes that “load more” and infinite scroll are generally implemented with JavaScript and that Google does not interact with pages to trigger more content. If content beyond the first batch should be indexable, each batch needs a crawlable URL, either through a paginated fallback with <a href> links or by updating the URL with the History API as new content loads, with each URL serving its own content when requested directly.
Checks after a migration or redesign
Pagination breaks quietly during platform changes and other site migrations. After a migration, test:
- Each paginated URL returns 200 and its own content when requested directly.
- Each carries a self-referencing canonical.
- Next and previous links are
<a href>elements in the rendered HTML. - Old pagination URLs (for example
/page/2/changed to?page=2) redirect to their direct equivalents, not to page 1. - Out-of-range page numbers return 404.
- URL Inspection on page 3 shows the user-declared canonical matching Google’s selected canonical.
Worked example: products disappearing from the index
Suppose a plugin on a store set every paginated category page’s canonical to page 1. URL Inspection on products listed only on pages 3 and later no longer shows category pages among their referring pages, and some of those products show “Discovered, currently not indexed” in the Page indexing report.
- Diagnosis: URL Inspection on
/shoes/?page=3shows the user-declared canonical as/shoes/, and Google has selected the same. - Fix: change the canonical on each paginated page to its own URL; confirm
<a href>next links exist; leave product URLs in the XML sitemap. - Verification: after recrawl, check that URL Inspection shows page 3 as its own canonical and that product URLs linked only from deep pages are crawled again.
- Google’s call: recrawling deep pages can take time, and canonical selection is Google’s decision; the declared canonical is a strong signal, not an order.
Summary rules
- Unique URL per page, no fragments.
- Self-referencing canonical on every page.
- Crawlable
<a href>links between pages; optionally link each page back to page 1. - Keep sort and filter variants out of the index or out of crawling.
- Treat
rel="next"andrel="prev"as history for Google, harmless to keep. - Never canonicalize the whole series to page 1 by default.