Pagination and SEO: How to Handle Paginated Content Correctly

Pagination splits a long list of content — products in a category, posts in an archive, comments on a thread — across multiple URLs like /category/shoes, /category/shoes?page=2, /category/shoes?page=3. Each page typically shows different items, which makes pagination a genuinely different problem from the duplicate-content cases covered by canonical tags: page 2 isn't a duplicate of page 1, it's a continuation of it, and search engines need a way to understand that relationship.

Google deprecated rel="next"/rel="prev" — now what?

For years, the standard advice was to add <link rel="next"> and <link rel="prev"> tags pointing to the adjacent pages in a series. Google officially stopped using these signals in 2019. They're not harmful to leave in place if your CMS already generates them, but they no longer influence how paginated series are crawled or indexed — treat them as inert metadata, not a fix.

What actually matters now

• Self-referencing canonical tags on every page in the series — page 2 canonicalizes to itself, not to page 1. Canonicalizing every paginated page back to page 1 is a common mistake that tells Google the content on pages 2 onward doesn't need to exist independently, which can get those pages dropped from the index even though they contain unique items.
• Crawlable links between pages — actual <a href> links to "next," "previous," and ideally numbered pages, not JavaScript-only pagination controls that require a click event to load the next page's URL. If a crawler can't find a real link to page 2, it may never discover it regardless of how the sitemap is structured.
• Unique, descriptive titles and meta descriptions per page — appending "Page 2," "Page 3," etc. to an otherwise identical title is enough differentiation; the goal is just avoiding exact duplicate <title> tags across the series.
• Sitemap inclusion for the whole series if pages 2+ contain content worth ranking on their own — see our XML sitemap guide for what else to include alongside paginated URLs.

"View all" and infinite scroll alternatives

If a category has a manageable number of items, a single "view all" page can outperform a 5-page-deep paginated series — it consolidates all the links and engagement onto one URL instead of splitting them across five, and gives users (and crawlers) the full picture in one fetch. The tradeoff is page weight: a "view all" page with thousands of items can hurt load performance enough to offset the SEO gain, so this works best for categories in the dozens-to-low-hundreds of items range, not catalogs with tens of thousands of SKUs.

Infinite scroll is the trickiest pattern to get right. If new items load via JavaScript as the user scrolls with no corresponding URL change, crawlers typically only see the first batch — everything loaded by scrolling is invisible to search engines unless the implementation also updates the URL (via the History API) as the user scrolls and serves an equivalent server-rendered version at each of those URLs directly. Infinite scroll without that URL-syncing layer is, from a crawler's perspective, identical to having no pagination at all past the first screen.

A simple decision rule

If each paginated page contains genuinely different, individually valuable items (products, distinct articles), keep it paginated with self-referencing canonicals and real crawlable links. If pagination exists purely because of an arbitrary items-per-page limit and the full list would be a reasonable page weight as one URL, consolidate to a single "view all" page instead and skip the pagination problem entirely.