Pagination

How to handle pagination for SEO — self-canonicals, why noindex breaks the crawl chain, the rel=prev/next story (Google dropped it, Bing kept it), and infinite scroll.

First published: Jun 26, 2026 · Last updated: Jul 18, 2026 · Advanced
demand #2 in Website Structure#12 in Technical SEO#18 on the site
AIAuthored byAI v2

Pagination splits big content sets — category pages, blog archives, search results — across numbered URLs. Treat each paginated page as a standalone, self-canonical, crawlable page: don't canonicalize them all to page 1, don't noindex page 2+, don't nofollow their links, don't block them in robots.txt. Google quietly stopped using rel=prev/next before announcing it in 2019; Bing still uses it, so leave the markup in place. Paginated pages drive almost no direct traffic — their value is as crawl paths to the content they link to.

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.txtA plain-text file at the root of a host that tells crawlers which URLs they may and may not request. It controls crawling, not indexing — a blocked URL can still be indexed if it's linked from elsewhere. — 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 budgetThe number of URLs an engine will crawl in a timeframe. 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.

Evidence for this claim Google treats paginated component pages as individual URLs and recommends crawlable links between them. Scope: Current official or standards documentation. Confidence: high · Verified: Google: Pagination Evidence for this claim Paginated pages should generally use their own canonical URLs rather than canonicalizing every page to page one. Scope: Current official or standards documentation. Confidence: high · Verified: Google: Pagination canonicalization

Each paginated page stands on its own

Pagination is a crawl path: every page needs its own URL, self-canonical, and a real link onward. Source: Google Search Central

Page one, page two, and page three each have a unique URL and self-referencing canonical. Real anchor links connect one page to the next, and deeper pages expose unique product links. Canonicalizing deeper pages to page one, adding noindex, blocking them in robots.txt, or relying on JavaScript-only controls breaks or weakens that crawl path.

© Patrick Stox LLC · CC BY 4.0 ·

This is the single mental shift that fixes most paginationPagination 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. problems. After Google dropped rel=prev/next, John Mueller put the new reality plainly: “For the most part, we just indexStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. 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 URLHow search engines pick one canonical URL among duplicates and consolidate signals onto it.; 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 foundA 302 (\"Found\") is a temporary redirect: it forwards users to a new URL while telling search engines the original URL should stay in the index. It's a weak canonicalization signal, not the zero-equity dead end of SEO folklore. 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 indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. 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 linkingAn internal link is a hyperlink from one page on a website to another page on the same website. Internal links help search engines discover your pages and pass ranking signals (PageRank and anchor-text context) between them. 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 preloadResource hints are <link> elements (or equivalent HTTP Link headers) that tell the browser to do network work — DNS lookups, connection setup, or fetching a resource — earlier than it would discover the need on its own. The main ones are dns-prefetch, preconnect, preload, modulepreload, and prefetch. the next page for a faster experience.
  • It’s a W3C standard and helps with accessibilityWeb accessibility means designing sites so people with disabilities can use them, per the W3C's WCAG guidelines. It overlaps with SEO in specific, checkable ways — alt text, heading structure, descriptive link text, captions, and page speed all serve both audiences — but Google has said accessibility itself is not a ranking factor, and most WCAG success criteria (keyboard focus order, ARIA live regions, form labels) have no SEO effect at all..

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 contentThe same or very similar primary content reachable at more than one URL. There's no general duplicate content penalty — the real costs are possible signal dilution, the wrong URL getting chosen, and less-efficient crawling.,” 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 crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. 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 noindexNoindex is a directive that tells search engines to keep a page out of their index, so it won't appear in search results. It works only on pages a crawler can actually fetch — a page blocked in robots.txt can never be noindexed. 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 navigationFaceted navigation (faceted search, product filtering) lets visitors refine a list of products or content by attribute — price, color, size, brand, rating. The SEO problem: each filter combination can spawn a distinct crawlable URL, turning a small catalog into millions of near-duplicate pages that waste crawl budget and dilute ranking signals., 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 linkAn internal link is a hyperlink from one page on a website to another page on the same website. Internal links help search engines discover your pages and pass ranking signals (PageRank and anchor-text context) between them. graph; nofollowing the nav links blocks PageRankPageRank is Google's original recursive link-graph algorithm: a page's score depends on the scores of the pages linking to it, and in the published model each page's score is split across its outbound links (the simplified version: links are weighted votes). Google says it's evolved since launch but still part of its core ranking systems. 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 GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer.. Google is explicit that its crawlersA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. “don’t ‘click’ buttons and generally don’t trigger JavaScript functions that require user actions.”

Infinite scroll and “Load more” — make them crawlable

Infinite scrollInfinite scroll is a loading pattern where content appears automatically as a user scrolls, instead of via numbered pages. Because Googlebot doesn't scroll or click, indexable infinite scroll needs real per-chunk URLs (paginated loading) that update via the History API — otherwise deep content may never be crawled, or worse, get merged into the wrong page. 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 sitemapsAn XML sitemap is a UTF-8 file listing the canonical URLs on your site (with optional lastmod) so search engines can discover and prioritize them. It's a discovery and diagnostic aid, not a guarantee of indexing — and Google ignores its priority and changefreq tags. (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 dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding. — 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 budgetThe number of URLs an engine will crawl in a timeframe. 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 structureWebsite structure (site architecture) is a site's visible hierarchy, navigation, breadcrumbs, and URL organization — how pages relate and how people and search engines move between them. Internal linking is the primary signal Google reads to understand that structure, not URL folders. cluster — internal linking, faceted navigation, URL structureURL structure is how the parts of a web address — scheme, domain, path, query string, and fragment — are organized and formatted. It mostly affects crawling, usability, and how engines understand a page, not rankings directly., and breadcrumbsBreadcrumbs are a secondary navigation trail (Home > Category > Page) that shows where a page sits in a site's hierarchy. They create internal links that pass PageRank, and when marked up with BreadcrumbList structured data they can drive the path Google shows in desktop search results. all shape the same crawl-path question from different angles.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.