Pagination

TL;DR — Pagination is splitting a long list — products, blog posts, search results — across numbered pages like page 1, 2, 3. Each page needs its own URL, and you want search engines to be able to crawl all of them so they can find the content linked from the deeper pages. The big mistakes are telling Google those deeper pages don’t matter (by canonicalizing them all to page 1 or noindexing them).

What pagination is

When you have more items than fit on one page — say 500 products in a category, or years of blog posts in an archive — you split them across a series of pages. Page 1 shows the first batch, page 2 the next, and so on. Each page lives at its own address (a URL), usually something like ?page=2 or /page/2/.

That’s pagination. You’ve used it a thousand times without thinking about it.

Why it matters for SEO

The pages themselves almost never rank for anything or get direct traffic. Their real job is to be a path that search engines follow to reach the products or posts listed on them. If a bot can’t get to page 3, it can’t find the things that are only linked from page 3.

So the whole game is simple: let search engines crawl every page in the sequence. Most pagination problems come from accidentally blocking that path.

The three ways to show paginated content

1. Numbered pages (traditional pagination). Page 1, 2, 3, each its own URL. This is the safe, SEO-friendly default.
2. A “Load more” button. One page, and clicking the button loads the next batch. Fine if the button is built on real links — a problem if it’s a JavaScript-only button that bots can’t click.
3. Infinite scroll. Content keeps loading as you scroll. Great for users, but bots don’t scroll, so without real numbered-page links somewhere, the content further down may never get found.

The mistakes to avoid

• Don’t point every page’s canonical tag at page 1. That tells Google pages 2, 3, 4 are just duplicates of page 1 and shouldn’t be indexed — which can hide the content on them.
• Don’t add noindex to page 2 and beyond. It feels tidy, but it can cause Google to eventually stop crawling those pages, and then it loses the path to everything they link to.
• Don’t block pagination in robots.txt or add nofollow to the page links. Both cut off the crawl path.

The one piece of history worth knowing

There used to be a special bit of code — rel="prev" and rel="next" — that told Google how paginated pages connected. Google stopped using it in 2019. Don’t panic and rip it out, though: Bing still uses it and browsers use it to load the next page faster, so it’s worth keeping.

Want the full version — self-canonicals, the crawl-chain problem with noindex, and the strange story of how Google’s deprecation got discovered — switch to the Advanced tab.

TL;DR — Treat every paginated URL as a standalone page: self-referencing canonical, crawlable, indexable, real <a href> links. The classic mistakes — canonicalizing pages 2+ to page 1, noindexing them, nofollowing their links, blocking them in robots.txt — all break the crawl chain to the content those pages link to. Google silently stopped using rel=prev/next before announcing it in March 2019; Bing still uses it, so leave the markup in place. Crawl budget only matters at very large scale, and paginated pages drive almost no direct traffic (one case study: ~0.3% of organic clicks) — their value is as crawl paths.

Each paginated page stands on its own

This is the single mental shift that fixes most pagination problems. After Google dropped rel=prev/next, John Mueller put the new reality plainly: “For the most part, we just index the pages as we find them, so as we’ve recommended for a long time, it’s good to make sure that all pages can stand on their own.”

“Stand on their own” means each page in the sequence is a normal, indexable page with a self-referencing canonical — page 2’s canonical points at page 2, page 3’s at page 3. Google’s own current guidance is explicit: give each page its own canonical URL; do not use the first page as the canonical for the whole set.

One exception to normal best practice: Google says identical <title> tags across a paginated sequence are fine. Pages in a paginated set “don’t need to follow” the usual unique-title recommendation, so you don’t have to contrive “Page 2 of 9” suffixes (though they don’t hurt).

The rel=prev/next story — and why it’s the interesting part

Back in 2011 Google introduced rel="prev" and rel="next" — <link> elements in the <head> that told Google which URLs formed a paginated sequence so it could consolidate signals across them. For most of the 2010s, adding them was standard technical-SEO hygiene.

Then it quietly stopped mattering. The way the SEO world found out is the part most write-ups skip: Gary Illyes discovered, during internal research, that Google had already silently stopped using rel=prev/next — and had not been using it for some time. He escalated it internally, and on March 21, 2019 the @googlewmc account made it public:

“Spring cleaning! As we evaluated our indexing signals, we decided to retire rel=prev/next. Studies show that users love single-page content, aim for that when possible, but multi-part is also fine for Google Search.”

The rationale: Google’s indexing had become good enough at recognizing paginated sequences from headings, titles, and internal linking that the explicit hint was redundant. When I spoke about this at SMX West in early 2020, the thing I kept coming back to was how completely it caught the industry off guard — we’d all been doing work that, it turned out, Google hadn’t been reading for a while.

Should you remove rel=prev/next? No — and this is where a lot of people overcorrect. I covered exactly this in my Ahrefs piece, SEOs Are Breaking Pagination After Google Changed Rel=Prev/Next. Keep it, because:

• Bing still supports and recommends it. Bing’s guidance is unchanged — one rel="next" and/or one rel="prev" per page, in the <head>. Stripping it to “clean up after Google” can only hurt your Bing performance.
• Browsers prefetch with it — they can preload the next page for a faster experience.
• It’s a W3C standard and helps with accessibility.

So: Google ignores it, everyone else still benefits. Leaving it in place is the correct call.

Canonicals: self-reference, not page 1

The old, now-harmful pattern was canonicalizing pages 2, 3, 4… back to page 1. The intent was to “avoid duplicate content,” but the effect is the opposite of what you want: you’re telling Google those deeper pages are duplicates that shouldn’t be indexed, which orphans the content linked only from them and breaks the crawl path through the sequence.

Correct: each page is self-canonical. The one legitimate alternative is a view-all page — a single URL showing the whole set — with the paginated pages canonicalizing to that. Google’s older guidance leaned on view-all heavily; the current guidance softens it to “an option if the page loads fast enough.” For most large catalogs, self-referencing canonicals on each paginated page is the simpler, safer default.

Should you noindex page 2+? Almost never — and here’s the trap

The tidy-looking move is to noindex everything past page 1 so only page 1 shows in search. The problem is what noindex does to crawling over time: Google eventually crawls noindexed pages less, and can effectively stop following the links on them. If page 3 is noindexed and Google stops crawling it, Google loses its path to everything that’s only linked from page 3. That’s the crawl-chain problem, and it’s why noindex on pagination tends to quietly bury content.

Mueller’s heuristic for whether a page can be safely noindexed is a useful gut check: “If someone only saw this page from my site, would that be OK?” For a genuinely thin, valueless page the answer might be yes — but for a paginated listing that’s the only route to dozens of products, the answer is almost always no.

Where noindex is often appropriate: filter and sort variants, which people confuse with pagination. A true paginated sequence (?page=2) should stay indexable. A filtered or sorted variant (/shoes/?color=red&sort=price) is usually a near-duplicate spider-trap candidate that you may legitimately want to noindex or block. Knowing which is which is the whole skill — this overlaps heavily with how you handle faceted navigation, which is its own topic.

The other crawl-path killers

The same “don’t break the path” rule rules out a few more patterns:

• Don’t nofollow pagination links. Each paginated page is part of your internal link graph; nofollowing the nav links blocks PageRank flow and crawl signal to the deeper pages.
• Don’t block pagination in robots.txt. That stops Google reaching the pages at all — and therefore everything linked from them.
• Use real <a href> links for pagination controls. Google crawls URLs found in href attributes; a JavaScript-only “Load more” button that fires an onclick without a real link is invisible to Googlebot. Google is explicit that its crawlers “don’t ‘click’ buttons and generally don’t trigger JavaScript functions that require user actions.”

Infinite scroll and “Load more” — make them crawlable

Infinite scroll is fine for users and hostile to crawlers unless you give bots a fallback. The fix is a paginated, crawlable counterpart: real ?page=n URLs with <a href> links (often surfaced in a footer or a <noscript> fallback) that expose the same content the scroll loads dynamically. Same advice for “Load more” — the button can drive the UX, but there should be a real anchor-link path to every page of results behind it. For very large catalogs, lean on XML sitemaps (or a Merchant Center feed) to supplement discovery, since you can’t count on link discovery alone reaching everything.

Structured data on paginated content

There’s no special schema type for “a paginated series.” Mark up what’s actually on each page: Product markup belongs on individual product pages (not the pagination container), and Article markup on each page of a multi-part article series. Don’t try to express the prev/next relationship through structured data — that’s not what it’s for.

Crawl budget and the reality check

Pagination creates a lot of URLs, which is why it gets blamed for crawl-budget problems. The honest answer: for most sites it doesn’t matter. Crawl budget is a real constraint only at large scale — think 1M+ pages, or very large rapidly changing catalogs. Google has, in Mueller’s framing, “a lot of experience dealing with pagination” and learns your URL patterns over time, so it generally handles paginated sequences well without special configuration.

And worth keeping in perspective: paginated pages drive almost no direct organic traffic. One well-known case study found pagination URLs accounted for only ~0.3% of total organic clicks, with no negative SEO impact from having lots of them indexed. That reinforces the framing throughout this page — paginated pages earn their keep as crawl paths to the content they expose, not as ranking pages in their own right. So the practical advice I keep giving: don’t over-engineer it. Make the pages crawlable and self-canonical, then leave them alone and let Google figure it out.

One honest caveat: getting the technical setup right — crawlable links, self-canonicals, no accidental noindex — only keeps the door open. It doesn’t guarantee Google crawls, indexes, or ranks any given paginated page, and it doesn’t guarantee traffic or an AI citation either. What it removes is the architectural reasons content on deeper pages gets missed in the first place.

This topic sits alongside the rest of the website structure cluster — internal linking, faceted navigation, URL structure, and breadcrumbs all shape the same crawl-path question from different angles.

AI summary

A condensed take on the Advanced version:

• Pagination splits large content sets (category pages, archives, search results, article series) across sequentially numbered URLs. Each page’s SEO value is as a crawl path to the content it links to — not as a ranking page.
• Each paginated page should stand on its own: indexable, crawlable, with a self-referencing canonical. Google: give each page its own canonical URL — don’t canonicalize pages 2+ to page 1.
• rel=prev/next: Google silently stopped using it before announcing the retirement on March 21, 2019 (Gary Illyes found it internally). Bing still uses it, browsers prefetch with it, it’s a W3C standard — so don’t remove it.
• Don’t noindex page 2+ in normal cases: noindexed pages get crawled less and Google can stop following their links, breaking the crawl chain to content linked only from those pages. Mueller’s test: “If someone only saw this page… would that be OK?”
• Filter/sort variants ≠ pagination. True ?page=n stays indexable; filtered (?color=red&sort=price) variants are often legitimately noindexed/blocked.
• Also avoid: nofollowing pagination links, blocking them in robots.txt, and JavaScript-only “Load more” buttons. Use real <a href> links; give infinite scroll a crawlable paginated fallback.
• Structured data: mark up what’s on each page (Product, Article); no schema type expresses a paginated series.
• Crawl budget matters only at large scale (~1M+ pages). Paginated pages drive ~0.3% of organic clicks in one case study. Don’t over-engineer it.
• No guarantees: correct setup removes the architectural reasons deeper pages get missed — it doesn’t guarantee crawling, indexing, rankings, traffic, or AI citations.

Official documentation

Primary-source guidance from the search engines.

Google

• Pagination best practices for Google — current canonical guidance: give each page its own canonical URL, the three UX patterns (pagination, load more, infinite scroll), and crawlable-link requirements.
• Pagination with rel=“next” and rel=“prev” (2011) — the original (now-deprecated) guidance, kept for historical context.
• Video about pagination with rel=“next” and rel=“prev” (2012) — the 2012 follow-up.
• Consolidate duplicate URLs — canonicalization methods (the adjacent topic that pagination handling depends on).

Bing / Microsoft

• Implementing markup for paginated and sequenced content — Bing’s still-current rel=prev/next guidance: one rel="next"/rel="prev" per page, in the <head>, pairable with canonical.
• Bing Webmaster Guidelines.

Quotes from the source

On-the-record statements from Google. Each link is a deep link that jumps to the quoted passage on the source page.

Google — the rel=prev/next retirement (March 21, 2019)

• “Spring cleaning! As we evaluated our indexing signals, we decided to retire rel=prev/next. Studies show that users love single-page content, aim for that when possible, but multi-part is also fine for Google Search.” — @googlewmc, March 21, 2019. See the tweet
• “Google no longer uses these tags, although these links may still be used by other search engines.” — Google Search Central, pagination docs. Jump to quote

Google — give each page its own canonical

• “Give each page its own canonical URL” — and don’t use the first page as the canonical for all paginated pages. Jump to quote
• On crawling JavaScript pagination: Google’s crawlers “don’t ‘click’ buttons and generally don’t trigger JavaScript functions that require user actions to update the current page contents.” Jump to quote

John Mueller, Google — pages must stand on their own

• “For the most part, we just index the pages as we find them, so as we’ve recommended for a long time, it’s good to make sure that all pages can stand on their own.” Coverage
• On the heuristic for noindexing a paginated page: “If someone only saw this page from my site, would that be OK?” If yes, you can noindex it — but that’s a high bar for most paginated content. Coverage

Pagination SEO checklist

A pass to confirm search engines can crawl your paginated sequences and the content behind them:

• Each paginated page has its own unique URL (e.g. ?page=2) — no fragment identifiers (#) marking page numbers (Google ignores fragments).
• Each page carries a self-referencing canonical — not a canonical pointing back to page 1 (unless you’re deliberately using a view-all page).
• Pages 2+ are indexable (no blanket noindex).
• Pagination controls are real <a href> links, not JavaScript-only buttons.
• Pagination links are not nofollowed.
• Pagination URLs are not blocked in robots.txt.
• rel="prev" / rel="next" left in place (for Bing, browser prefetch, accessibility) — even though Google ignores them.
• Infinite scroll / “Load more” has a crawlable paginated fallback with real anchor links.
• XML sitemaps supplement discovery for large catalogs (especially JS-rendered listings).
• Filter/sort variants (e.g. ?color=red&sort=price) handled separately from true pagination — noindex/block these if they add no unique value.
• Structured data marks up what’s on each page (Product, Article), not the pagination container.

The mental models

1. Paginated pages are crawl paths, not destinations. Their job is to expose the products/posts linked from them so bots (and PageRank) can reach those. Once you internalize that, almost every rule follows: don’t do anything that breaks the path. One case study clocked pagination at ~0.3% of organic clicks — they don’t rank, they route.

2. “Can this page stand on its own?” Mueller’s reframing after the rel=prev/next retirement. Treat each paginated URL as a normal, self-canonical, indexable page rather than a dependent fragment of a set.

3. The four crawl-chain breakers. Keep these straight and most pagination mistakes disappear:

• Canonicalizing pages 2+ → page 1 (says “duplicate, don’t index”)
• noindex on pages 2+ (gets crawled less → links stop being followed)
• nofollow on pagination links (blocks PageRank + crawl signal)
• robots.txt disallow (blocks access entirely)

4. “Google uses it” ≠ “it’s still useful.” rel=prev/next is the canonical example: Google dropped it, but Bing uses it, browsers prefetch with it, and it’s valid HTML. Decide what to keep on all consumers, not just Google.

5. Pagination vs. faceted variants. A true sequence (?page=2) stays indexable. Filter/sort variants (?color=red&sort=price) are usually near-duplicate clutter you can noindex or block. Same-looking URLs, opposite handling — classify before you configure.

How should a long listing expose more items?

Pagination mistakes that cut the crawl path

Canonicalizing every page to page one

Page two and later contain different items, so page one is not their equivalent. Let component pages self-canonicalize; use redirects or canonical consolidation only when URLs are genuinely duplicates.

Adding noindex to page two and beyond

The directive removes those URLs from the index and can weaken the path to items linked only from deeper pages. Keep the sequence crawlable and improve the listing instead of hiding its continuation.

Building infinite scroll without persistent URLs

A scroll event or button is not a crawl path. Pair the experience with unique, loadable page URLs and real anchors so every item remains reachable without user interaction.

Common pagination failures

Products on later pages are not discovered

Symptom: Items visible after clicking or scrolling never appear in a crawl. Likely cause: The next batch loads only through JavaScript and has no anchor URL. Fix: Expose persistent paginated URLs, link them with normal anchors, and verify a crawl beginning at page one reaches the item URLs.

Google selects page one as canonical for the whole series

Symptom: URL Inspection reports page one as Google’s canonical for deeper pages. Likely cause: All pages declare page one as canonical or render nearly identical content. Fix: Use self-canonicals, distinct item sets, stable titles where useful, and consistent internal links to each component page.

Crawlers loop through endless page numbers

Symptom: A crawl discovers empty or repeated URLs far beyond the last real page. Likely cause: The next link is generated without checking whether another batch exists. Fix: Stop emitting the next anchor on the final page and return a proper not-found response for impossible page numbers.

Pagination signal reference

Test yourself: Pagination

Five quick questions on handling pagination for SEO. Pick an answer for each, then check.

Resources worth your time

My pagination writing

• SEOs Are Breaking Pagination After Google Changed Rel=Prev/Next: Here’s How to Get It Right — my primary piece on this topic: why to keep the markup, and the four mistakes that break pagination.
• Canonical Tags: A Simple Guide for Beginners — the canonical mechanics that pagination handling depends on.
• The Beginner’s Guide to Technical SEO — where pagination sits in the bigger crawl/index picture.

My speaking

• Video: Patrick Stox on pagination, technical SEO & community (Search Engine Land, SMX West 2020) — my take on how Google’s quiet rel=prev/next deprecation caught the industry off guard, and why SEOs over-engineer pagination.

From around the industry

• Pagination best practices for Google (Google Search Central) — the current official guidance.
• Implementing markup for paginated and sequenced content (Bing Webmaster Blog) — Bing’s still-current rel=prev/next requirements.
• Gary Illyes — The Googler Who Discovered rel=prev/next No Longer Supported (Search Engine Roundtable) — the story of how the deprecation surfaced.
• Google’s Advice On Pagination & Page Series Post rel=next and rel=prev (Search Engine Roundtable) — Mueller’s “stand on their own” guidance.
• What happens when 67% of a site’s indexed URLs are pagination? (GSQI / Glenn Gabe) — the case study where pagination drove only ~0.3% of organic clicks with no negative impact.
• Explaining the ‘rel=prev/next’ saga of 2019 (Embryo) — a clear walkthrough of the deprecation and its aftermath.

Pagination

Pagination splits a large set of content — product listings, blog archives, search results — across multiple sequentially numbered URLs. For SEO, each paginated page should be crawlable, indexable, and self-canonical; Google no longer uses rel=prev/next, but Bing still does.

Related: Canonical Tag, Crawl Budget

Pagination

Pagination is the practice of dividing a large set of content across multiple sequentially numbered pages, each accessible via its own unique URL (commonly ?page=2, /page/2/, and so on). You see it on ecommerce category pages, blog archives, search results, forum threads, and multi-part article series.

From an SEO perspective, paginated pages exist mainly as crawl paths to the content they link to. Each page in a sequence should be individually crawlable and indexable so search engines can discover everything on the deeper pages. The common mistakes all break that crawl path: canonicalizing every page back to page 1, adding noindex to pages 2+, nofollowing the pagination links, or blocking the pattern in robots.txt.

The headline nuance: Google stopped using rel="prev" / rel="next" in 2019 — it had silently dropped the signal before announcing it — and now treats each paginated URL as a standalone page. Bing still supports rel=prev/next, browsers use it for prefetching, and it’s valid HTML, so you leave the markup in place rather than removing it. Each paginated page should be self-canonical (point to itself), not canonicalized to page 1.

Related: Canonical Tag, Crawl Budget

Changelog