Pagination and SEO: How to Handle Paginated URLs Without Wasting Crawl Budget

A paginated set is one list of items split across a sequence of URLs: 300 blog posts served as pages 1 through 30, a docs index broken into sections, a changelog that shows twenty releases and then offers a "next" link. This guide is for anyone running a blog archive, documentation site, changelog or directory listing that paginates and wants to know what to actually do with those URLs. The correct handling depends on the page type, and the fix most teams reach for first, pointing every component page back to page 1 with a canonical tag, is the one that causes the damage. Almost all published advice on this assumes an ecommerce category page, which is why it fits so badly on the sites most software companies run.

The short version

• Canonicalizing page 2 to page 1 is the most common pagination mistake, and it quietly removes the deeper items from Google's index. Self-canonicalize instead.
• rel="next" and rel="prev" stopped being indexing signals years ago. That does not mean delete them, and it does not mean Google is lost without them.
• Paginated pages are not duplicate content. They are distinct pages holding distinct items, and treating them as duplicates is what breaks things.
• Infinite scroll is a rendering problem, not a pagination problem. If there is no crawlable URL for the second batch, the second batch does not exist.
• The right answer differs by page type. A documentation site and a blog archive should not be handled the same way.

What is pagination in SEO?

Pagination is splitting one large set of items across a sequence of URLs so each page loads a manageable slice. The whole sequence is the paginated set. Each URL inside it is a component page. Page 1 is usually the archive's root URL, and every page after it carries a marker in the URL, either a query parameter like ?page=2 or a path segment like /page/2/.

Either pattern works. What matters is that the pattern is consistent, that every state of the list has exactly one URL, and that the URL is stable: loading ?page=4 tomorrow should return the same slice it returned today, give or take new items at the top.

Google's guidance asks for the same thing, and it is worth knowing where that guidance lives. The official page on pagination and incremental page loading sits under the ecommerce section of Search Central. The advice in it is sound and applies generally, but the examples are product listings, which is part of why the wider web has written about pagination as though every paginated set were a shop.

Is pagination bad for SEO?

No. Badly handled pagination is bad for SEO; pagination itself is how large sets are supposed to work. Nobody should serve 300 posts in one document, and Google has never asked anyone to.

What "badly handled" means in practice comes down to three costs:

• Crawl waste: Googlebot spends requests walking page 41, 42 and 43 of an archive instead of fetching the pages that earn revenue. On a small site this is harmless. On a large one it is the difference between a new page being found in a day and being found in a month.
• Thinned internal links: every item sitting on a deep component page is many clicks from the homepage, and clicks from the root are a rough proxy for how much internal authority a URL receives. A post on page 30 has almost none.
• Component pages treated as duplicates: pages 2 through 30 look alike structurally, so teams assume Google sees duplicate content and "fix" it. The fix is what removes the items.

Each of those has a specific remedy, and none of the remedies is abandoning pagination. If you want the broader context for where this sits, our technical SEO guide covers the crawl and index pipeline these decisions plug into.

Should paginated pages canonicalize to page 1?

No. Each component page should carry a self-referencing canonical that points at its own URL, page parameter included. Google's documentation is direct about this: do not use the first page of a sequence as the canonical for the rest, and give each page its own canonical URL.

The mechanism is worth understanding, because knowing why it fails is what stops the mistake coming back after the next template change. A canonical tag is a declaration that two URLs are the same page. Google's guidance on consolidating duplicate URLs describes it as a strong signal for choosing one preferred URL and folding the signals from the duplicates into it. So when page 4 declares page 1 as its canonical, Google is being told that page 4 is a copy of page 1 and its own content is not worth holding separately.

Except page 4 is not a copy. It holds twenty items that appear nowhere else in the set. If those items have no other inbound path, and on a chronological archive they usually do not, the crawl path to them disappears along with the page.

What I've seen in practice is that this is the single most common pagination error on B2B sites, and it is almost always well intentioned. Someone reads that duplicate content is a problem, notices that pages 2 and up look similar, and reaches for the tool built for duplicates. The similarity is structural, not substantive, and the canonical tag cannot tell the difference.

The correct implementation is one line, and it goes on every component page:

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

Not this:

<!-- Wrong: strands every item that only appears on page 4 -->
<link rel="canonical" href="https://example.com/blog">

One caveat on templates: the canonical must reflect the URL that was actually requested, so it has to be generated per request rather than hardcoded into the archive layout. A hardcoded canonical is how this bug gets reintroduced. Our guide to how canonical tags work covers the rest of the rules, including the ordering and filtering cases that sit next to this one.

When this does not apply: if your sort and filter variants genuinely return the same items in a different order, those variants should canonicalize to the unfiltered URL. That is a real duplicate. Pagination is not.

Does Google still support rel="next" and rel="prev"?

Not as an indexing signal. Google's current pagination documentation states the position plainly: Google no longer uses these tags, though other search engines may still read them.

Three things follow from that, and most write-ups get at least one of them wrong.

• Do not remove existing markup: rel="next" and rel="prev" are still valid HTML link relations. Browsers, feed readers and other crawlers consume them. Ripping them out of a working template is unpaid work with a nonzero chance of breaking something.
• Do not add them expecting a ranking effect: if they are not there, adding them will not change how Google handles your set. Spend the effort on the canonical and the links instead.
• Never treat them as the only signal: they were never a substitute for crawlable <a href> links between pages, and they certainly are not now. Google's own advice is to link from each page to the next with a real anchor tag.

The practical replacement for the markup is nothing at all. Google discovers the sequence by following the links, which is what it was mostly doing anyway.

How should each page type be handled?

This is where generic advice stops being useful. A blog archive, a docs index, a changelog and an integrations directory have different growth patterns, different item value and different failure modes, so they need different decisions. During our technical audits, the page type that turns out to have had no decision made about it at all is almost always the changelog, because it grows by accretion and nobody revisits the template that generates it.

Start with the signals. Read the row for whatever you are actually running.

Page type	Canonical target	Index directive for page 2+	In the XML sitemap?
Blog or resource archive	Self-referencing, including the page parameter	Leave it indexable. No directive needed	No. List the individual posts instead
Documentation or API reference	Self-referencing, but most docs sites should not paginate at all	Indexable if you must paginate	No. List every documentation page individually
Changelog or release notes	Self-referencing	Indexable on recent pages. noindex, follow is defensible deep in the archive where entries are one line long	No, unless individual releases have their own URLs. Then list those
Directory, integration or template listing	Self-referencing on the paginated URLs. Filter and sort variants canonicalize to the unfiltered equivalent	Indexable on the pagination. noindex on sort-order combinations that return the same items reshuffled	No for paginated URLs. Yes for each listing detail page
Ecommerce category	Self-referencing	Leave it indexable	No. List category page 1 and the product URLs

Then the part nobody publishes: how each type should be linked, and what actually goes wrong with it.

Page type	Internal-linking treatment	The failure mode this type hits
Blog or resource archive	Numbered links to adjacent pages plus first and last. Give older posts a second path in through tag and category hubs	Cross-canonical to page 1, which strands older posts that have no other inbound path
Documentation or API reference	A persistent navigation tree that links every page from every page, not a next and previous chain	Pagination used where a navigation tree belongs, leaving reference pages many clicks from the root and rarely recrawled
Changelog or release notes	Link by year or version range as well as next and previous, so page 40 is two clicks away rather than forty	An unbounded sequence that grows every release with no shortcut into the middle, so Googlebot walks it linearly forever
Directory, integration or template listing	Link listings from curated category hubs, not only from the paginated sequence	Pagination multiplied by facets, turning a ten-page listing into thousands of crawlable URL combinations
Ecommerce category	Products need a path in that does not depend on their position in the sequence	The same facet explosion, plus paginated URLs competing with the category page for the same query

The last two rows share a root cause, and it is the one worth planning for before you build. When pagination sits on top of filters, the URL count is multiplicative rather than additive, which is a URL architecture question rather than a pagination question. That is the same problem set our programmatic SEO work deals with when a template can generate more URLs than a site can support.

The one row people argue about: noindex on deep pages. It is a real option and not a default. Applying it to a blog archive is usually wrong, because the archive pages are a discovery path and you have just told Google to stop treating them as one worth returning to. Applying it to page 60 of a changelog where each entry is a version number and a bullet is reasonable. Always pair it with follow, never with a robots.txt block, because a blocked page cannot be crawled and therefore its noindex is never read.

Should paginated URLs go in the XML sitemap?

No, in almost every case. A sitemap's job is to declare the canonical, indexable URLs you want Google to consider on their own merits. Pagination's job is different: it provides a crawl path to items that live deeper in a set. Those are separate mechanisms, and using the sitemap to do pagination's work suggests the links are not doing theirs.

List the destination URLs instead. For a blog archive that means the post URLs, for a directory it means each listing page, for docs it means every documentation page. If a component page is genuinely a landing page in its own right, page 1 of a well-optimized category for instance, include that one and leave the rest out.

The exception is diagnostic rather than strategic. If deep items are not being discovered at all and you need to know whether the cause is crawl depth or something else, temporarily listing the component pages will tell you. Take them out once you have the answer. Our guide to what belongs in an XML sitemap covers the composition rules in full.

What is the difference between pagination, infinite scroll, and load more?

The difference that matters to a crawler is whether each batch of items has its own URL. Everything else is interface design.

Pattern	How the next batch loads	What a crawler can reach
Numbered pagination	A full navigation to a new URL	Every batch, by following the links
Load more button	JavaScript appends items to the current page	Only batch one, unless each batch also has a real URL behind a real link
Infinite scroll	JavaScript appends items as the user scrolls	Only batch one. Google does not scroll

That last cell is the whole story. Googlebot renders JavaScript, but it does not scroll a page or click a button to see what happens, so content that only appears in response to those actions is content it never sees. Google's documentation on lazy-loading and infinite scroll asks for each chunk to have its own persistent, unique URL, for those URLs to be linked sequentially so they can be discovered, and for the displayed URL to be updated with the History API as the user scrolls into a new chunk.

So infinite scroll can work. It just has to be built as pagination with a scroll-driven interface on top, rather than as a replacement for pagination.

The test, and it takes a minute: disable JavaScript in your browser and load page 1 of the set. If you can reach batch two by clicking a link, the routing is crawler-visible. If the page is a shell or the button does nothing, it is not. Server-rendering the first batch and progressively enhancing from there is the pattern that satisfies both the crawler and the user. Our guide to JavaScript rendering and SEO covers how Google processes these pages in more detail.

When is a view-all page the right answer?

When the full set is small enough to serve in one document without hurting the page, and users genuinely prefer it that way. A 40-item resource library, a pricing comparison, a short glossary: these are better as one page, and consolidating them concentrates the internal links and the ranking signals that pagination would otherwise scatter.

The conditions are specific:

• Page weight stays reasonable: the document, its images and its scripts still load quickly on a mid-range phone. Once Largest Contentful Paint starts climbing, the view-all page is costing more than it returns.
• The set has a ceiling: a view-all page for something that grows every week is a slow-motion performance problem. Archives and changelogs fail this test by definition.
• Users actually want the whole list: scanning or comparing favors one page. Browsing chronologically does not.

When not to: if you keep both a paginated set and a view-all page, only one of them should be the canonical destination, and you will be maintaining two templates that show the same items. For most archives that maintenance cost is not worth paying, and a good filter beats both.

How do you tell whether pagination is wasting crawl budget?

Look at what Googlebot actually requested, not at what you think it should be requesting. Two sources answer this, and they answer it at different resolutions.

The Crawl Stats report in Search Console: open the report and look at crawl requests broken down by response and by file type, then at the sample URLs. The signature of pagination waste is high-numbered component pages appearing repeatedly in the samples, particularly when your recently published pages are not.

Server logs: higher resolution, and the only place you can see the full picture. You are looking for three specific patterns:

• Requests to component pages beyond roughly page 10 of any set, at any meaningful frequency.
• Deep component pages being fetched more often than the pages that make money.
• Repeated crawls of filter or sort combinations layered on top of pagination, which is the facet explosion showing up in the access log.

Our guide to what server logs reveal about Googlebot covers the parsing and the verification step, because you have to confirm the requests are really from Google before drawing any conclusion from them.

The honest caveat: below roughly 10,000 URLs, crawl budget is rarely the binding constraint, and pagination is unlikely to be your problem. If the site is that size and deep items are not indexed, the cause is almost always the canonical tag or the absence of internal links, not the crawl rate. Diagnose in that order.

What should you check on a paginated set?

Signals: Every component page carries a self-referencing canonical including the page parameter. The canonical is generated per request, not hardcoded. No component page is blocked in robots.txt. Any noindex is paired with follow and applied deliberately, not by default.

Crawl path: Real <a href> links connect the pages. The set has a bounded depth, or shortcuts by year, category or version. The deepest page is reachable in a small number of clicks from the homepage.

Rendering: With JavaScript disabled, batch two is reachable. Each batch has a persistent URL. The displayed URL updates via the History API if the interface scrolls.

Composition: Component pages are absent from the XML sitemap. The destination items are present in it. Filter and sort variants are handled separately from pagination and do not multiply against it.

Everything on that list is checkable in an afternoon, and most of it in a browser.

The habit worth building is smaller than any of this: whenever you ship or inherit a paginated template, check the canonical on page 2 before you check anything else. It takes two minutes, it is wrong on a surprising number of sites, and it is the one error on this page that silently costs indexed pages rather than just crawl efficiency.

This week, open page 2 of your own blog archive, view source, and read the <link rel="canonical"> tag. If it points at page 1, you have found the highest-value fix on your site that can be shipped in a single commit. If you would rather have someone work through the full set of crawl and index decisions with you, that is the kind of thing our organic growth work starts with.