Pagination is how you split a long list, such as a blog archive or a product category, across multiple numbered pages. For SEO, the goal is straightforward: make sure crawlers can reach every page in the series and discover the items sitting on the deeper pages, while keeping each paginated page distinct in the index. Done badly, pagination buries content on page five that search engines never crawl, and you end up with a catalog whose tail is effectively invisible.

The canonical question

The most common mistake I see is canonicalizing every paginated page back to page one. That tells search engines pages two and beyond do not exist as far as indexing is concerned, and the links on those pages lose their value. Each paginated page should canonical to itself.

  • Page two canonicals to page two, not back to the root listing.
  • Do not noindex deeper pages if they are the only path crawlers have to certain items.
  • Avoid a separate view-all page unless it loads fast enough to be a genuine alternative rather than a liability.

The reason this mistake is so common is that it looks safe. Canonicalizing to page one seems like it should consolidate authority and clean up potential duplicate content. In reality it tells Googlebot that pages two through twenty are duplicates of page one and can be ignored, which means every item listed only on those pages is effectively orphaned from a crawl perspective. If those items have their own URLs and internal links from other places on the site they may still get crawled, but the category pages stop helping them.

What replaced rel next and prev

Google stopped using rel='next' and rel='prev' as indexing signals years ago. They do no harm if you keep them, but do not rely on them to carry the load, because they no longer do.

  • Make sure every paginated page is reachable by a plain crawlable a href link, not a button that only works once a user clicks it.
  • Keep the page-number links in the HTML so crawlers can follow the sequence without executing any scripts.
  • Give each page a distinct title, or at least include the page number, so the set is not flagged as duplicate content. Related: hreflang tags.

How to structure paginated URLs cleanly

URL structure for paginated content is one of those things that seems simple until you audit a large site and find five different patterns in production. The cleanest approach is a consistent parameter or path convention applied everywhere.

A path-based approach keeps URLs readable and avoids the parameter handling complexity in Google Search Console:

/blog/page/2/
/blog/page/3/
/products/running-shoes/page/2/

A parameter-based approach works equally well from a crawl standpoint as long as the parameters are not listed in robots.txt and not blocked in Search Console’s URL Parameters tool:

/blog/?page=2
/products/running-shoes/?page=2

What I see go wrong most often is a mix of both patterns on the same site, usually the result of different CMS plugins handling different sections. Screaming Frog will surface both in a crawl, and fixing the inconsistency is usually a quick template edit rather than a large project.

Infinite scroll and load-more

Infinite scroll looks clean but is a frequent SEO trap, because the deeper content only appears when a user physically scrolls, and it often never renders for a crawler at all. The same applies to a load-more button that fetches results through script. If you use either pattern, pair it with real, crawlable paginated URLs underneath, so every batch of content still has a fetchable address a crawler can request directly.

The implementation that works is to keep numbered paginated URLs as the crawlable layer and use the infinite scroll or load-more purely as a progressive enhancement for users who prefer it. The paginated URLs remain in the sitemap. Crawlers follow them in sequence. Users with JavaScript get the smoother experience on top. This is not a complex architecture, but it requires the frontend and the SEO considerations to be in the same conversation at build time, which often they are not.

Crawl budget and pagination on large sites

On sites with tens of thousands of paginated pages, crawl budget becomes a real constraint. Googlebot has a finite number of requests it will make to your site in a given period, determined partly by your server’s capacity to respond quickly and partly by how much authority Google assigns to the domain. If crawlers are spending that budget on page 400 of a category archive that has not changed in months, they are not spending it on pages that actually need to be discovered or refreshed.

I check this by pulling Googlebot visits from server log files and looking at the distribution across paginated URLs. If a substantial fraction of crawl activity is going to deep pagination rather than to content pages, the structural fix is usually one of two things: better internal linking to surface important items without requiring crawlers to traverse dozens of paginated screens, or tighter category architecture that keeps lists short enough that crawlers reach the end on every visit.

How deep should pagination go

There is a practical limit to how far crawlers will follow a paginated series, and the deeper an item sits, the less often it gets crawled and the weaker its internal signals become. I treat pagination depth as a structural problem to design around, not something to ignore.

  • Keep important items within the first few pages by improving sorting, filtering, or default ordering.
  • Link to key category and subcategory landing pages directly rather than relying on someone clicking through ten paginated screens.
  • If a list runs to dozens of pages, that is usually a sign the category needs to be broken into tighter subcategories that each have their own shorter series. Related: content audit.
  • Make sure the items themselves are linked from somewhere more permanent than a single deep paginated page.

One check I run on every audit is looking at which paginated pages Googlebot actually visited in the log files versus which ones are in the sitemap. If the sitemap lists pages one through thirty but the logs show Googlebot only ever visiting pages one through eight, that tells you exactly where the crawl is stopping. The fix is almost always faster server response times, fewer wasted crawl requests on blocked paths, or reducing the total number of paginated URLs so the series is short enough to be fully crawled on every visit.

That depth issue sits right at the edge of how crawlers handle client-side rendering, which is a substantial topic in its own right. I go into it in JavaScript SEO. If your archives or category pages run deep and you suspect content is not being crawled, I can trace exactly where the crawl stops in a website audit.