Pagination SEO: What Google Crawls and What Breaks

Pagination is the part of technical SEO where the advice aged badly and nobody announced it. A lot of what is still repeated in audits, including audits I have been handed by previous agencies, describes a system Google retired. This piece works from the current documentation and then does the arithmetic that most pagination sections skip.

What Google’s documentation says now

Google’s ecommerce guidance on pagination and incremental page loading is short and unusually direct. Four statements in it do most of the work:

On URLs: “Give each page a unique URL. For example, include a ?page=n query parameter.”
On rel next and prev: “In the past, Google used <link rel="next" href="..."> and <link rel="prev" href="..."> to identify next page and previous page relationships. Google no longer uses these tags.”
On canonicals: “Don’t use the first page of a paginated sequence as the canonical page. Instead, give each page its own canonical URL.”
On fragments: “Don’t use URL fragment identifiers (the text after a # in a URL) for page numbers in a collection.”

Read the third one twice, because it is the single most common pagination error I find on live sites, and it is almost always implemented on purpose by someone trying to solve a duplicate content worry that does not exist.

The arithmetic: a 4,000 product category

Take an ordinary category listing. 4,000 products, 24 per page. That is 167 pages, because 4,000 divided by 24 is 166.7 and you round up. Now run three scenarios on it.

Setup	Products reachable by an internal link	Worst-case clicks from page 1	What Google sees
Every page has its own URL and its own canonical	4,000	Depends on the link widget, typically 3 to 5 with first/last and number links	167 indexable listing pages, each linking to 24 products
Every page canonicalised to page 1	24	Not reachable at all through pagination	One listing page. Pages 2 to 167 are consolidation candidates, and the 3,976 products only on those pages lose their listing path entirely
Next and previous links only, no numbers	4,000	166	A 166-hop chain. Everything past the first few pages sits at a crawl depth that in practice does not get crawled often

Worked example. Product count and page size are illustrative; the arithmetic is the point.

The middle row is the one that hurts. 4,000 minus the 24 products on page one leaves 3,976 products whose only internal link came from a page you just told Google not to index as itself. If those products have no other internal path, and on most ecommerce builds they do not, you have manufactured orphan pages while believing you were tidying up duplicates. The products may still be in the sitemap, but a sitemap is a discovery aid, not an internal link.

The four patterns, ranked by what Google can crawl

Pattern	Unique URL per page	Crawlable without running JavaScript	Google’s position	Use it when
Numbered links with `?page=n` or `/page/n/`	Yes	Yes	The documented recommendation	Always, unless you have a specific reason not to
Load more button	Only if the button also updates the URL and a real link exists	No	Permitted, with JavaScript SEO best practices, and Google suggests a sitemap or Merchant Center feed to help find products	You want the UX and you are willing to ship real paginated URLs behind it
Infinite scroll	Usually not	No	Same as load more, with the same caveats	Rarely. Pair it with paginated URLs or accept the discovery cost
Fragment based paging, `#page=3`	No, fragments are not separate URLs	No	Explicitly advised against	Never for pagination

The rel next and prev question, settled

Google no longer uses those tags. That is stated plainly in the documentation quoted above. Two practical consequences follow, and they point in opposite directions from what people expect:

Removing them will not help you. They are ignored, not penalised. If your CMS emits them, leaving them in costs nothing and other search engines may still read them.
Adding them will not fix anything either. If a paginated set is not being crawled, the cause is link depth, canonical misconfiguration, JavaScript-only navigation, or a robots rule. It was never the missing tag. I have watched a team spend a sprint adding rel next and prev to a listing that was blocked in robots.txt the whole time.

A seven-point pagination audit

Open page 2 of your largest category in a browser with JavaScript disabled. If the products vanish, that is your finding.
Check the canonical on page 2. It should point at page 2. If it points at page 1, stop and count how many items live only on later pages.
Check for a noindex on paginated pages. It is a common inherited setting and it has the same orphaning effect as the canonical error.
Count the maximum click depth to the last page. If the only route is next and next and next, the tail of your catalogue is functionally invisible.
Confirm each paginated URL returns 200 and is not disallowed in robots.txt.
Check whether sorting and filtering create separate paginated sequences. If they do, you have a faceted navigation problem sitting on top of a pagination problem, and the faceted one is bigger.
Verify products on deep pages have at least one other internal link, from a related-products module, a hub page, or breadcrumbs, so their discovery does not depend on pagination alone.

Where this sits in a recovery

Pagination rarely causes a ranking collapse on its own. What it does is set a ceiling: a catalogue that cannot be crawled cannot be ranked, and no amount of content work on individual product pages fixes a listing structure that hides them. On recovery projects it belongs in the same early pass as crawl paths and canonical logic, before anyone writes a word.

Pagination SEO: What Google Actually Crawls, and the 167-Page Example That Breaks Most Category Pages