# Pagination SEO: Handling Paginated and Infinite-Scroll Content

**Author:** John Morabito (Founder, /winston)
**Published:** September 18, 2026
**Reading time:** 9 minutes
**Canonical:** https://www.winstondigitalmarketing.com/playbooks/pagination-seo-best-practices/

Pagination is where the deep content of a site quietly goes to disappear. Blog archives, category listings, product grids, anything with a page two, three, and beyond, all depend on the crawler being able to walk the series and reach the items further in. When that path breaks, the items on page five simply stop being found, even though they are live and fine. Infinite scroll and load-more buttons make this worse, because they feel smooth to a person and are often a dead end to a crawler. The good news is that pagination SEO is not complicated once you understand what Google actually does with it now, which is different from the advice most people remember. This is how to handle paginated and infinite-scroll content so nothing gets stranded.

## What pagination is for now

The single most important update is that Google retired rel=next and rel=prev as an indexing signal years ago. It no longer stitches a paginated series into one logical unit; it treats each page as its own standalone page. That changes the entire purpose of pagination. It is no longer a way to tell the engine these pages belong together. It is purely a discovery and crawl-path mechanism: the trail of links that lets a crawler get from page one to page two to the items deep in the series.

So stop thinking of pagination as a consolidation problem and start thinking of it as a reachability problem. The question is not how do I signal that these pages are related, it is can a crawler actually walk the whole series and find the item on page seven. Every decision below follows from that reframing.

## Self-canonical, not canonical-to-page-one

Because each page is its own page, each paginated page should carry a self-referencing canonical. Page two canonicals to page two, page three to page three. They are genuinely different pages showing different items, and they should say so.

The damaging mistake, and a very common one, is canonicalizing every paginated page back to page one. That tells the engine pages two and beyond are duplicates that should not be indexed, and the consequence is that the items appearing only on those deeper pages lose their crawl path and can fall out of the index. A product on page five, canonicalized away, becomes much harder to find and rank. So unless you offer a genuine view-all page, never point the series at page one. Let each page be self-canonical, indexable, and honestly labeled as the page it is. This is the same canonical discipline that matters across a large catalog, and getting it wrong here is a close cousin of the duplicate-signal problems in [faceted navigation SEO](https://www.winstondigitalmarketing.com/playbooks/faceted-navigation-seo/).

## Keep every page crawlable with real links

Pagination only does its job if the links between pages are real, crawlable links. A standard anchor tag with a real URL for page two, page three, and so on is what lets a crawler follow the series. The failure mode is pagination that only works through JavaScript: a load-more button that fetches items and never changes the URL, or numbered controls that are click handlers rather than links. A crawler that cannot follow a real link to the next page sees only the first page and treats everything beyond it as if it does not exist.

So make sure the pagination is built on genuine links to genuine URLs, not scripted navigation. This is a specific case of the broader rule that content and links must exist in the HTML a crawler receives, which is the whole subject of [JavaScript SEO and making dynamic sites crawlable](https://www.winstondigitalmarketing.com/playbooks/javascript-seo-making-dynamic-sites-crawlable/). If your paginated links only appear after a script runs, or only fire on a click, the deep pages are effectively invisible.

## Infinite scroll needs pagination underneath it

Infinite scroll is not inherently bad, but a crawler does not scroll, so if scrolling is the only way to load more items, everything past the first load is invisible to search. The fix is to back the infinite scroll with real, crawlable pagination underneath: each batch of items is also reachable at a normal paginated URL with a standard link. The result is infinite scroll for humans and ordinary paginated pages for crawlers, and both get what they need. The same goes for a load-more button; it is fine as an enhancement as long as a real paginated URL structure exists behind it.

Treat infinite scroll as a presentation layer on top of a crawlable structure, never as a replacement for one. When it replaces the structure, you get a beautiful listing that a search engine can only see the top of.

## When a view-all page is the cleaner answer

Sometimes the simplest fix is a view-all page: a single URL that lists every item in the set. It removes the discovery problem entirely, because everything sits on one crawlable, indexable page, and in that case the paginated versions can canonical to the view-all rather than standing alone. It is a genuinely clean solution when the full list is small enough to load quickly and stay usable.

The limit is performance. If the set is thousands of items, a view-all page becomes slow and unwieldy, and a slow page is its own ranking and experience problem. So the rule of thumb is simple: use a view-all page for modest sets where it loads fast, and use proper self-canonical pagination with crawlable links for large sets where a single page would be too heavy. Both are valid; the goal in either case is that every item is reachable through a real URL.

## Putting it together

Pagination SEO comes down to reachability now that the old series-consolidation signals are gone. Treat each paginated page as its own indexable page with a self-referencing canonical, and stop canonicalizing the series back to page one. Build the pagination on real, crawlable links rather than JavaScript-only controls. Put crawlable pagination underneath any infinite scroll or load-more experience so deep items stay findable. And reach for a view-all page when the set is small enough to load fast. Do that and the items deep in your archives and catalogs keep getting found, instead of quietly dropping off. This kind of technical and crawl-architecture work is core to what we do in our [SEO service](https://www.winstondigitalmarketing.com/services/seo/), and it pairs with the internal-linking work in [recovering lost organic traffic by re-linking orphaned pages](https://www.winstondigitalmarketing.com/playbooks/recover-lost-organic-traffic-internal-relinking/), since a stranded paginated item is really just another page that lost its path in. The free AI visibility check on our [contact page](https://www.winstondigitalmarketing.com/contact/) is a quick way to see how your site is being crawled today.

## Frequently asked questions

### How does Google handle pagination now that rel=next/prev is gone?

Google retired rel=next and rel=prev as an indexing signal years ago, and it now treats each page in a paginated series as its own standalone page rather than stitching the series together into one. That changes what pagination is for. It is no longer a way to tell the engine these pages are one logical unit; it is purely a discovery and crawl-path mechanism, the trail of links that lets a crawler reach page two, then three, and eventually the items deep in the series. So the modern job of pagination is not signaling relationships, it is making sure every item on every page stays reachable. Each paginated page can be indexed on its own, which is fine, and it should describe itself honestly, page two of a category is page two, with its own self-referencing canonical. The practical takeaway is to stop thinking about pagination as a consolidation problem and start thinking about it as a reachability problem: can a crawler actually walk the whole series and find the items on page seven.

### Should paginated pages canonical to page 1?

No, and this is one of the most common and damaging pagination mistakes. Each paginated page should have a self-referencing canonical, page two canonicals to page two, page three to page three, because they are genuinely different pages showing different items. When you canonicalize every paginated page back to page one, you are telling the engine that pages two and beyond are duplicates of page one that should not be indexed, and the effect is that the items that only appear on those deeper pages lose their crawl path and can drop out of the index entirely. A product on page five of a category, canonicalized away, becomes much harder for the engine to find and rank. So treat each page as the distinct page it is: self-canonical, indexable, and honestly labeled. The only time canonicalization across the series is right is when you also offer a single view-all page that genuinely contains everything, in which case the paginated pages can canonical to that view-all, not to page one.

### Is infinite scroll bad for SEO?

Infinite scroll is not inherently bad, but it is a problem when it is the only way to reach deeper content, because a crawler does not scroll. If your listing loads more items only as a user scrolls, and there are no real paginated URLs behind that behavior, then everything past the first load is effectively invisible to search engines, which see the initial page and nothing more. The fix is to back the infinite scroll with real, crawlable pagination: each batch of items should also be reachable at a normal paginated URL with a standard link, so the experience is infinite scroll for humans and ordinary paginated pages for crawlers. The same applies to load-more buttons that fetch content with JavaScript and never change the URL; if a crawler cannot follow a real link to the next set, it cannot see those items. So infinite scroll is fine as an enhancement on top of a crawlable paginated structure, and a trap when it replaces one. This is closely tied to whether your content is in the HTML at all, which is the broader JavaScript rendering question.

### When should you use a view-all page?

A view-all page, one URL that lists every item in the set, makes sense when the full list is small enough to load quickly and be usable, and it can be a clean solution because it puts everything on a single crawlable, indexable page with no discovery problem at all. When you offer one, the paginated versions can canonical to the view-all, which consolidates the set sensibly. The limit is performance and usability: if the full set is thousands of items, a view-all page becomes slow to load and unwieldy for users, and a slow page is its own SEO and experience problem, so paginated pages with crawlable links are the better choice at that scale. So the rule of thumb is a view-all page for modest sets where it loads fast, and proper self-canonical pagination for large sets where a single page would be too heavy. Either way the goal is the same: every item is reachable by a crawler through a real URL, whether that is one big page or a well-linked series.

### How is pagination different from faceted navigation?

They are related but they are different problems. Pagination is about sequence and discovery: one set of items split across numbered pages, where the risk is that deeper items become unreachable, so the job is to keep the whole series crawlable and let each page be indexed on its own. Faceted navigation is about combinatorial explosion: filters and sorts that multiply a single category into thousands of near-duplicate URLs, where the risk is wasted crawl budget and index bloat, so the job is to decide which filtered views deserve to be indexed and suppress the rest. In short, pagination usually needs you to preserve crawl paths, while faceted navigation usually needs you to restrict them. They often appear together on the same large ecommerce category, filters creating the URL explosion and pagination splitting the results within each view, and you handle each with its own approach. Confusing the two, for example applying faceted-style suppression to legitimate pagination, is how deep items accidentally get cut off from the index.