# Pagination SEO: How Google Handles Pagination and Infinite Scroll

**Author:** John Morabito (Founder, /winston)
**Published:** September 18, 2026
**Updated:** October 5, 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.

## Pagination on large ecommerce catalogs

Pagination solves three problems in a site's architecture. It keeps any single listing page light enough to load fast. It gives every item in a large set a short, stable path of links from the category, so a crawler can reach it. And it spreads internal links across the set instead of piling them all onto page one. On a ten-page blog archive that is a minor detail. On a catalog with tens of thousands of products, it decides which products Google ever sees.

Large catalogs fail in predictable ways. This is the checklist we run on an ecommerce site before touching anything else:

- **Find the deepest page a crawler actually reaches.** Crawl one large category the way Googlebot would, following only real links, and note the last page number reached. Compare it with the page count your platform reports. A gap means items are stranded.
- **Check canonicals on page two and beyond.** Platform defaults and SEO plugins still canonical the whole series to page one. Spot-check a handful of categories and fix it at the template level, not page by page.
- **Look for products that only live deep in the series.** If an item is reachable only from page 40 of a category, add a second path in: a subcategory, a related-products block, or a curated collection page.
- **Keep pagination and filters on separate rules.** Filtered and sorted URLs usually need to be restricted. Plain paginated URLs need to stay open. One noindex rule applied to both is how whole sections drop out.
- **Watch Search Console for the symptom.** Product URLs sitting in Discovered or Crawled, currently not indexed while their category pages are fine is often a pagination or crawl-path problem, not a content problem.

If your team runs a large catalog and suspects deep products are not getting crawled, we will run that check on one of your biggest categories and walk you through what we find on a 20-minute call. Your team keeps the fixes; we just show you where the crawl path breaks.

[Book a 20-minute call](https://www.winstondigitalmarketing.com/contact/)

## 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.

### What problems does pagination solve in website architecture?

Pagination solves three architecture problems. It keeps each listing page small enough to load quickly, it gives every item in a large set a short and stable chain of links from its category so crawlers can reach it, and it distributes internal links across the set rather than concentrating them on page one. The trade-off is that every extra page is another step between the category and the deepest items, so on very large sets you also want a second path in, such as subcategories or related-product links, so nothing depends on a crawler walking to page 40.

### How do I check whether Google is reaching products deep in my paginated categories?

Crawl a large category following only real links, the way Googlebot does, and record the deepest page number reached. Compare that with the number of pages your platform says exist. Then spot-check the canonical tag on pages two and beyond, since many platforms still point the whole series at page one. Finally, look in Search Console for product URLs stuck in Discovered or Crawled, currently not indexed while the category pages themselves are indexed. That pattern usually points to a crawl-path problem in pagination rather than a problem with the product pages.