Should page 2 of your blog archive rank, consolidate, or exist only so Googlebot can reach the articles behind it? That single question decides almost every pagination choice that follows, and the sites that struggle usually never answered it. Their pagination emerged from a CMS default rather than a decision, and the consequences surfaced months later when deep articles stopped getting indexed.
Pagination divides a long list across multiple URLs, and how it is implemented affects crawl reach, where ranking signals land, and whether users can navigate at all. Several patterns are viable in 2026, each working for a different content type and breaking in a different way. This guide covers what pagination has to accomplish, the patterns that hold up, and the implementation details Google’s current documentation actually asks for.
What pagination has to accomplish #
Pagination serves two goals that pull against each other. Every item in a list needs a path that both crawlers and users can follow, and no single page should be so large it loads slowly or overwhelms the reader; a list of ten thousand items on one URL does not load fast, display well, or get scanned. That trade-off sets the pattern. Prioritize accessibility, with every item on a discoverable URL, and you get many pages holding few items each. Prioritize page weight and you get fewer pages, or a structure that does not fully expose the content. A blog with two hundred posts can run twenty per page across ten pages, fifty per page across four, or infinite scroll with no traditional pages at all, and each choice changes what gets indexed and how authority flows.
The patterns that hold up #
Four patterns cover most needs.
Numbered pagination with full URLs. The classic approach: the first page at /category, then /category/page/2, /category/page/3, each a distinct URL returning its own content. Every page is reachable through links and each URL is understood on its own. The detail that decides whether it works is that navigation links must be standard <a href> anchors, not JavaScript-only click handlers. The first page should live at either /category or /category/page/1, consistently one across the whole site, because exposing both produces two URLs with identical content.
Load more and infinite scroll with crawlable URLs behind them. Users see a “Load more” button, or content that loads automatically as they scroll, fetching more without a full reload while the same content also lives at distinct URLs such as /category/page/2 that crawlers can follow. The experience stays smooth and the content stays discoverable, but only if those underlying URLs genuinely exist as server-rendered pages. Google does not click buttons, scroll, or trigger user-action scripts, so a pure client-side pattern where /page/2 has no server-rendered equivalent that resolves for an unauthenticated, script-free fetch hides everything past the initial load.
View-all on a single page. The entire list appears on one URL, often with internal anchors for navigation. All link equity consolidates on that one address and everything is discoverable in a single fetch. The cost is page weight: a view-all page of five thousand items is slow to load, slow to scroll, and can push Largest Contentful Paint and Interaction to Next Paint past reasonable thresholds. How those Core Web Vitals are measured is a separate topic; here it is enough to know view-all trades performance for consolidation.
Why rel=prev/next no longer applies #
Google announced on March 21, 2019 that it had stopped using the rel="prev" and rel="next" link tags as indexing signals. The announcement surprised many practitioners because the tags had been documented as standard practice for years, but Google clarified that it had not relied on them for a long time before saying so publicly. The 2019 date is when Google confirmed the situation, not when the tags first stopped mattering.
The mechanism that replaced them is simpler than the one it retired: each paginated page is evaluated on its own. Page 2 of an archive is a separate URL with its own content, and Google decides whether to index it and how to rank it using the standard factors it applies to any page. New implementations do not need the tags. Leaving them in the HTML if a CMS emits them does no harm, and Bing and some other engines still read them, so removal is optional. The practical implication is that pagination work should focus on making content findable, because there is no explicit pagination signal left to send.
The canonical decision, corrected for current guidance #
This is where a lot of older advice is now wrong, and the mistake is easy to make.
For years the reflexive answer for e-commerce was to canonical every pagination page to page one, on the theory that it consolidates ranking signals and stops the pages from competing. Google’s current pagination documentation explicitly warns against this. The guidance is to give each paginated page its own self-referencing canonical and let it stay indexable. Canonicalizing deep pages to page one tells Google those pages are duplicates of page one, which they are not, and it can suppress discovery and indexing of products or articles that appear only on deeper pages.
The old advice persisted because of the cannibalization worry. A category page at /shoes targets “shoes,” and /shoes/page/2 and /shoes/page/3 hold similar content, so it feels as though indexing all three would split the ranking signal. In practice, deep pagination pages rarely earn meaningful organic traffic on their own, and Google is generally capable of choosing the main category page for the head query without a canonical forcing it. Self-canonical on each page is the pattern Google now asks for.
Where does noindex fit? Google reserves it for duplicate variations of the same list, such as alternate sort orders and filtered views, not for the sequential pagination pages. Applying noindex broadly across /page/2, /page/3, and beyond is the same error as canonicalizing them to page one: it can strand deeper content behind pages Google is told to drop. Keep sequential pages indexable and self-canonical, and use noindex only for the filtered and sorted duplicates pagination sometimes spawns alongside it.
How to implement and verify it #
A few concrete choices separate working pagination from a crawl trap, and each is checkable.
Use real URLs, not fragments. Google ignores the text after a #, so /category#page=2 is not treated as a distinct page and its content may never be crawled. Page numbers belong in the path or a query parameter such as ?page=2, never in a fragment.
Link with crawlable anchors. Google follows URLs it finds in the href attribute of <a> elements, so pagination built purely from click handlers gives it nothing to follow. If the interface is JavaScript-driven, back it with server-rendered <a href> links or expose the full set of paginated URLs through the XML sitemap so nothing depends on a script running.
Keep the canonical strategy uniform. Mixed signals, where some pages self-canonical, some point to page one, and some declare nothing, are worse than any single consistent choice. And keep sort and filter parameters out of pagination URLs: a URL like /category/page/2?sort=newest&filter=red multiplies into a combinatorial space and belongs in its own faceted-navigation handling rather than riding along on pagination.
Verify with the tools that show reality rather than intention. Search Console’s URL Inspection confirms how Google actually treats a given pagination URL, a crawl in Screaming Frog or a similar tool shows the URL space the site is really generating, and a log-file review confirms which pagination pages Googlebot is spending requests on. Do not deploy a robots.txt rule aimed at deep pagination without checking it against these, because wildcard rules are honored by Googlebot but interpreted inconsistently by crawlers that lack wildcard support, and an over-broad rule can hide valuable pages.
Matching the pattern to the site type #
Pagination is one of the few areas where the right answer genuinely depends on the site. For e-commerce category pages, self-canonical sequential pages keep every product reachable and indexable, which matters most when inventory lives several pages deep. For blog and tag archives, the pagination pages are chiefly a discovery mechanism: the full articles sit at their own URLs, so self-canonical still applies while discovery gets reinforced through sitemaps, related-article modules, and links from elsewhere, and no article depends solely on deep pagination to be found. For medium lists, the hybrid works well: pagination as the default view with view-all offered as an option.
Device is a separate axis from all of this. On mobile the visible controls can simplify to previous, next, and a current-page indicator while the underlying URL structure stays identical across breakpoints. The URLs are what affect SEO; the interface can adapt to the device without changing them.
FAQ #
Do I still need rel=prev/next tags? No. Google stopped using them as indexing signals and confirmed this in March 2019. New builds can skip them. If a CMS emits them they cause no harm and some other search engines still read them, so removing them is optional.
Should pagination pages canonical to page one? No. Google’s current guidance is a self-referencing canonical on each paginated page, keeping it indexable. Canonicalizing deep pages to page one can suppress discovery of content that only appears on those deeper pages.
Should I noindex pagination pages? Not the sequential ones. Keep /page/2, /page/3, and the rest indexable and self-canonical. Reserve noindex for duplicate filtered or sorted versions of the same list, not for the pagination sequence itself.
Why is my infinite scroll content not getting indexed? Almost always because the additional content has no crawlable URL behind it. Google does not scroll or click to load more, so each segment needs a real server-rendered URL, reachable through an <a href> link or listed in the sitemap. A fragment such as #page=2 does not count, since Google ignores everything after the #.
Pagination rewards deciding early and implementing consistently, and it punishes drift. Answer the strategic question first, whether these pages should rank, consolidate, or simply expose content, then pick self-canonical sequential URLs as the default, keep the deep pages crawlable and indexable, and confirm with URL Inspection and a crawl rather than trusting the CMS did what you assumed. The retrofit always costs more than the upfront choice.