Pagination and SEO

Pagination creates multiple URLs from a single body of content: a blog archive split across 20 pages, a product category divided into pages of 24 items each, or a comment thread spread across 10 pages. Each paginated URL is technically distinct, and Google must decide what to do with them. The decisions you make about pagination structure affect crawl efficiency, indexation, and where ranking signals consolidate.

The end of rel=prev/next

Many technical SEO guides still recommend rel=prev and rel=next link attributes to signal paginated sequences to search engines. Google announced in March 2019 that it had never used these attributes for indexation and had dropped support for them entirely. They have no effect on how Google handles paginated content.

The announcement surprised many SEOs because Google had previously implied these attributes were useful. The clarification confirmed what Google actually does: it analyses paginated content individually, makes independent indexation decisions for each URL, and does not use prev/next relationships to consolidate signals. Implementing rel=prev/next does no harm, but it also does no good.

How Google handles paginated URLs

Google’s approach to paginated content is largely pragmatic:

• It crawls paginated URLs if they are linked to (typically through “next page” links)
• It makes independent indexation decisions for each URL
• It rarely indexes deep paginated pages (beyond page 3 or 4) unless those pages have strong internal or external links pointing to them
• It does not automatically consolidate signals from paginated URLs to the first page

The practical result is that page 1 of a category typically ranks; pages 2 and beyond rarely do. Users searching for a product category will see the first page in results. They will not search for “page 14 of your shoes category.”

URL structure for paginated content

Paginated URLs can use path-based or parameter-based formats:

Path-based: /blog/page/2/, /category/shoes/2/ Parameter-based: /blog/?page=2, /category/shoes/?paged=2

Path-based URLs are preferable. They are more readable, less likely to be excluded by parameter-handling rules, and less likely to be treated as crawl noise. Parameter-based pagination URLs are more likely to be confused with other parameter types (tracking parameters, filter parameters) and harder to manage consistently.

Strategies for paginated content

Allow independent indexation — do nothing beyond a clean URL structure. Each paginated URL can be crawled and indexed. This is appropriate when each page contains substantial unique content that users might reasonably land on from search: a long-running blog where older posts have no other access path, or a product catalogue where category pages 2+ contain entirely different products.

Canonical to page 1 — add <link rel="canonical" href="/category/shoes/"> to pages 2, 3, 4 and so on, pointing to the first page. This tells Google that you consider page 1 the representative URL for the sequence. Link equity from any external links pointing to deeper pages consolidates to page 1. This is appropriate when deep pages have thin or overlapping content and the primary intent is to rank page 1.

noindex on deep pages — prevents later pages from being indexed while still allowing Googlebot to crawl them (and follow links to individual product or post pages). Use when you are certain that users will never land on page 5 of a category from search, but you still want Googlebot to discover the content on those pages. The page must be crawlable for noindex to work; do not also block it in robots.txt.

Infinite scroll — presents an SEO challenge because paginated content only loads as users scroll. If implemented purely in JavaScript with no server-side HTML, Googlebot will only see the initial page load content. The correct implementation uses the History API to update the URL as users scroll (/category/shoes/, then /category/shoes/2/ as page 2 loads), and ensures each URL is accessible as a standalone page with its own server-rendered HTML.

Crawl waste from deep pagination

Deep pagination is one of the most common sources of crawl budget waste. A large e-commerce site with 500 category pages, each paginated to 50+ pages, can generate tens of thousands of paginated URLs. Most contain thin content and have no realistic search demand. Googlebot crawling them consumes budget that could be spent on product pages with actual ranking potential.

The fix is either to noindex deep paginated URLs, reduce the number of items shown per page (fewer pages total), or block deep pagination from crawling in robots.txt if the content on those pages is accessible through other means (individual product pages, sitemap links, internal category links).

Parameter-based pagination and Search Console

If your site uses parameter-based pagination (e.g. ?page=2), Search Console’s URL Parameters tool (under Legacy Tools and Reports) allows you to configure how Google handles specific parameters. Setting the page parameter to “Doesn’t change, duplicate, or near-duplicate content” can reduce crawl of deep paginated parameter URLs. However, this tool is being deprecated and the more reliable fix is to implement canonical tags or switch to path-based pagination.

Frequently asked questions

Does Google index paginated pages? Sometimes, but rarely beyond the first few pages. The first page almost always has the strongest signals and is the version that ranks.

Should I noindex all pages after page 1? Not necessarily. If deeper pages contain content users might search for directly, allow indexation. If they are thin or near-duplicate, noindex or canonical to page 1.

Will rel=canonical to page 1 lose me traffic from deep pages? If deep pages are not indexed, they cannot lose traffic. Most sites see no measurable traffic from paginated pages beyond page 1 or 2.