Pagination SEO: give every page its own URL, and never canonicalize to page one

Pagination SEO comes down to one rule with three consequences: every page in a sequence is its own page. Give it its own address, its own canonical pointing at itself, and a real link from the page before it. The failure that costs the most is the tidy-looking one — pointing page 2, 3 and 4 at page 1 with a canonical, which tells Google those pages do not exist as destinations.

Before you start

This chapter assumes your list is long enough to split. Two neighbouring decisions have their own chapters and are worth having settled first: whether crawling volume is a problem on your site at all, worked through in is crawl budget your problem, and which mechanically generated addresses to close off, in faceted navigation. Filters and pages are cousins — both turn one list into many addresses — and the answers pull in opposite directions. Filters usually deserve fewer addresses. Pages usually deserve to keep theirs.

Why a paginated sequence confuses a crawler

Because pages 2 through 40 look like near-duplicates of each other. Same template, same title, same navigation, and the only thing that differs is the twenty items in the middle. A crawler arriving at page 17 has to decide whether this is a distinct destination or another rendering of the list it already has, and every signal on the page except the items themselves says the second thing.

Google's answer to that ambiguity is stated plainly: URLs in a paginated sequence "are treated as separate pages by Google" (Pagination, incremental page loading, and their impact on Google Search, read 2026-09-08). Separate pages, not variants of one page. Everything below follows from taking that sentence literally.

The historical wrinkle is that the web spent years being told otherwise. The rel="next" and rel="prev" link elements were the recommended way to declare a sequence, and the same documentation now says of them: "Google no longer uses these tags, although these links may still be used by other search engines." They are not harmful. They are also not doing the job people still believe they are doing.

Page 2 is a destination. If your markup says it is a copy of page 1, Google will believe you.

That belief has a cost you can see in Search Console rather than in your rankings, which is why it goes unnoticed for so long. Pages that get canonicalized away stop appearing as indexed pages. Their items stop being reachable through search. The list page itself keeps ranking, so nothing looks broken.

How common is the old markup, really

Rare, on the evidence we have. Reading 27 large homepages on 2026-09-08, exactly one still ships a pagination link element in the head: techcrunch.com sends <link rel="next" href="https://techcrunch.com/page/2/">. No site on that panel sends rel="prev".

Homepages are a weak place to look for pagination, so treat this as a floor rather than a rate — a category listing or a blog archive is where these elements would live, and we did not read those. What the number is good for is calibration. If you are still budgeting engineering time to add rel="next" across a site, you are spending it on markup that the largest publishers on the web have already stopped emitting, for a signal Google says it no longer uses.

Do it: five steps, in this order

The order matters because step 2 is destructive if step 1 has not been checked. Each step has a completion signal you can verify without waiting for Google.

1. Confirm each page has its own address. Load page 2 of a real list and read the address bar. If it is unchanged from page 1, or if the page number lives after a #, stop here — the rest of this chapter cannot help until that is fixed. Google's wording on the second case is absolute: "Don't use URL fragment identifiers (the text after a # in a URL) for page numbers in a collection. Google ignores fragment identifiers." Done when pages 1, 2 and 3 have three different addresses that each load the right items in a fresh browser session.
2. Point each page's canonical at itself. This is the one that gets done backwards. The documented instruction: "Don't use the first page of a paginated sequence as the canonical page. Instead, give each page its own canonical URL." Done when curl on page 2 returns a canonical containing the page 2 address, not the page 1 address.
3. Make the next-page control a real link. A button that calls a script is invisible to a crawler that is not executing scripts. Google's stated behaviour is narrow: it "generally crawls URLs found in the href attribute of <a> elements". Done when the address of page 2 appears in the raw HTML of page 1 inside an anchor's href.
4. Decide what happens to sort and filter variants. The same documentation notes that sites "may support filters or different sort orders for long lists of results", and those produce addresses that return the same items in a different arrangement. Pagination should be kept; re-sorts of the same list usually should not multiply. Done when you can name, for each parameter your list accepts, whether it creates a page worth indexing or a rearrangement of one.
5. Check the deep end of the sequence. Load the last page and one past it. A sequence that answers 200 for page 900 of a 40-page list is manufacturing addresses. Done when a page number beyond the end returns 404 rather than an empty list with a 200.

What to ship: the head block and three checks

The markup for page n of a sequence is short, and most of the work is in what it does not contain. There is no canonical pointing backwards and no declaration of the sequence.

<!-- On https://example.com/blog?page=3 -->
<link rel="canonical" href="https://example.com/blog?page=3">
<title>Blog — page 3</title>

<!-- and in the body, a real link, not a button -->
<a href="/blog?page=4">Next page</a>

The title carries the page number so the sequence does not read as forty identical titles in a report. Google does not require this, and it will rewrite titles when it judges them unhelpful — but a human reading an indexing report needs to tell page 3 from page 30.

# 1. Does page 2 point at itself?
curl -s 'https://example.com/blog?page=2' | grep -i 'rel="canonical"'

# 2. Is the next page reachable without scripts?
curl -s 'https://example.com/blog' | grep -oE 'href="[^"]*page=2[^"]*"'

# 3. Does a page past the end refuse?
curl -sI 'https://example.com/blog?page=9999' | head -1

Three ways pagination SEO goes wrong

Each of these produces a site that looks correct in a browser, which is why they survive review.

1. Every page canonicalized to page 1. The most common one, and it usually arrives as a plugin default or a well-meant fix for a duplicate-content warning. The symptom is items on page 2 and beyond that never appear in search while the list page ranks fine.
2. Infinite scroll with no addresses underneath. The list is complete for a visitor and one page deep for a crawler. Google's guidance here points at the same anchor requirement rather than at a special mechanism, so the fix is to give each batch an address and link to it, keeping the scroll behaviour for people. A sitemap helps the pages be found; it does not substitute for the links.
3. An unbounded sequence. A list that answers 200 for any page number will hand a crawler an endless supply of empty pages. This is the pagination version of the problem the faceted navigation chapter deals with, and the fix is the same shape: refuse the addresses that have nothing behind them.

Where this stops

Google documents the mechanisms and declines to give thresholds, so this chapter does the same. Three things are outside what anyone can tell you from the documentation.

1. How deep a sequence gets crawled. There is no published number, and no way to derive one for your site from outside it. If deep pages matter, the honest answer is to check your own indexing report rather than to trust a rule of thumb.
2. Whether fixing pagination changes rankings. We have not measured it, and on a live site the variable cannot be isolated. What is documented is that pages canonicalized away are removed from consideration. That is a mechanism, not a promise about traffic.
3. What to do with a "view all" page. The current documentation does not address it. Older advice around a single combined page has not been restated, so we are not going to restate it either.

One more boundary worth naming: none of this makes a thin list worth indexing. If pages 4 through 40 hold items nobody searches for, making them crawlable gets them crawled and no further. The canonical decision and the "is this page worth having" decision are separate, and the first is covered in how to use canonical tags.

Frequently asked questions

Should I still use rel="next" and rel="prev"?

Google says it no longer uses them, and other search engines may. They cost nothing and do nothing for Google Search. If they are already in your template, leave them; adding them to a site that lacks them is not work worth scheduling.

Should page 2 canonical to page 1?

No. The documentation says to give each page its own canonical URL and specifically warns against using the first page as the canonical for the sequence. This is the single most common pagination mistake and the most expensive.

Is infinite scroll bad for pagination SEO?

The scrolling is not the problem; the absence of addresses is. Google crawls addresses it finds in anchor elements, so a scroll that loads more items without ever producing a link leaves nothing to follow. Keep the scroll and add the links underneath it.

Do paginated pages need unique titles and descriptions?

Not as a requirement. Google builds titles from several sources and rewrites them when it judges yours unhelpful. The practical reason to number them is human: an indexing report full of forty identical rows cannot be read.

How do I check whether AI crawlers can reach my paginated pages?

Same way as any other page — the reachability question sits one layer below pagination, and if the list page itself is blocked, none of the above matters. The AI crawler access check answers that half.