Pagination SEO: How to Handle Paginated Series Correctly

Google dropped support for rel="next" and rel="prev" on 21 March 2019 and confirmed it had not used them for indexing for years before that. The correct pattern for a paginated series in 2026 is unglamorous: give every page a unique, crawlable URL, put a self-referencing canonical on each page — page 2 canonicalizes to page 2, never to page 1 — link the pages with real <a href> anchors, and keep titles consistent. Most pagination problems trace back to one of those four rules being broken.

rel=next/prev is dead — stop maintaining it

For years the received wisdom was to declare rel="next" and rel="prev" link relations so Google would treat a series as a group. Google announced on 21 March 2019 that it no longer uses these signals, and revealed it had actually stopped years earlier without announcing it. Keeping the markup does no harm, but it does nothing for Google either, and maintaining it is wasted effort. Other search engines and some tools may still read it, so removing it is optional — but it should never be the load-bearing part of your pagination strategy. Google now understands paginated series from the page structure and links themselves.

Self-referencing canonicals, not canonical-to-page-1

The most common and most damaging pagination mistake is canonicalizing every paginated page back to page 1. The reasoning sounds plausible — "these are all part of one series, so page 1 is the canonical" — but it is wrong, because the pages are not duplicates. Page 2 of a product listing shows different products than page 1. Telling Google they are the same page means the items that appear only on page 2 and beyond may never be discovered or indexed, because Google is being told to consolidate them onto a page that does not contain them.

The correct pattern: each paginated page carries a self-referencing canonical to its own URL. Page 2's canonical points to page 2. This states plainly that each page is its own indexable entity. Pointing the canonical at page 1 is the error; pointing it at a URL that redirects or that carries noindex compounds it — Crawlinx flags those targets as canonical.to_redirect and canonical.to_noindex. The general rules for a valid canonical target are in our canonical tags guide.

Give each page a unique URL — ?page=2, /page/2/ — never a fragment like #page=2, which Google does not treat as a distinct URL. Keep titles and on-page structure consistent across the series so Google recognizes them as related.

Crawlable links, not JavaScript buttons

Pagination only works if Google can follow it, and Google follows links, not clicks. In Google's own words, its crawlers do not click buttons. If your "next page" control is a <button> with a JavaScript click handler, or a link with no real href, the deeper pages may be undiscoverable — the crawler has no URL to fetch. Every pagination control must be a genuine <a href="..."> anchor pointing at the real page URL.

This is also where pagination meets crawl depth. Deep paginated series bury content many clicks from the homepage. Pages that sit far down the pagination chain are crawled less often and can be treated as low priority. Crawlinx flags pages with no crawlable outbound links as links.no_outlinks and pages buried deep in the click hierarchy as links.click_depth. If a paginated page is set to noindex but is still the only path to its linked items, you strand those items — Crawlinx surfaces the pattern of noindex pages being linked as a crawl-demand issue in budget.noindex_linked.

The "View All" alternative

For a series short enough to load quickly, a single "View All" page is a legitimate and often preferable option. Google has historically favored serving users a fast view-all page where one is available. If you offer both a paginated series and a view-all page of the same content, canonicalize the paginated pages to the view-all page — this is the one case where paginated pages legitimately canonicalize elsewhere, because the view-all page genuinely contains all their content.

The constraint is performance. A view-all page that loads slowly or is enormous is worse than pagination, and for large catalogs it is impractical. Use it when the full set is small enough to remain fast; otherwise keep paginated pages self-canonical.

Infinite scroll and load-more

Infinite scroll and "load more" buttons are user-experience patterns that are hostile to crawlers by default, because the additional content appears only in response to user interaction the crawler will not perform. The content beyond the first viewport-load can be invisible to Google.

The fix is to back each chunk of content with a persistent, unique URL that the crawler can reach directly, and to update the address bar with the History API pushState as the user scrolls, so the paginated URLs are real, shareable, and crawlable. In practice this means building infinite scroll on top of a working paginated URL structure — the scroll is a progressive enhancement over ?page=n URLs that exist and return content on their own. A view-all page is again an acceptable alternative where the set is small.

Pagination versus faceted navigation

Pagination and faceted navigation are different problems and should not be conflated. Pagination splits one logical listing across sequential pages — page 1, 2, 3 of the same set. Faceted navigation generates new URL combinations from filters and sorts — color, size, price, brand — and it is the single most-reported source of crawl waste, because a handful of filters multiply into a combinatorial explosion of near-duplicate URLs.

The handling differs. Paginated pages generally want to be crawled and often indexed, each self-canonical. Facet URLs usually do not: the standard approach is to block unwanted parameter combinations in robots.txt, expose only item pages plus one unfiltered listing, and return HTTP 404 for empty or nonsensical filter combinations rather than redirecting them (which creates soft 404s). Crawlinx flags URLs blocked from crawling as robots.blocked. The full treatment is in our faceted navigation crawl traps guide, and the wider economics of both patterns are in the crawl budget guide — crawl waste in 2026 is dominated by faceted navigation, action parameters, and irrelevant URL parameters, so getting facets under control is usually higher-leverage than optimizing pagination.

How Crawlinx detects pagination problems

Crawlinx maps the crawled URL graph and checks the signals that make or break a paginated series: canonicals pointing at redirects (canonical.to_redirect) or noindex targets (canonical.to_noindex), pages with no crawlable outbound links (links.no_outlinks), content buried at excessive click depth (links.click_depth), noindex pages that are still linked as navigation (budget.noindex_linked), and URLs blocked from crawling (robots.blocked). See where these sit in the full technical SEO audit checklist.

Takeaway

Forget rel=next/prev — Google dropped it in 2019. Give each paginated page a unique, crawlable URL and a self-referencing canonical to itself, never to page 1. Link the series with real anchors, not JavaScript buttons. Offer a fast view-all page only when the set is small, and back any infinite scroll with real paginated URLs. Keep pagination distinct from faceted navigation, where the crawl-control playbook is the opposite.