How to Handle Pagination for SEO

Pagination — splitting a long list of items across numbered pages — is everywhere, on blog archives, category listings and search results. Done badly, it hides your deeper content from Google; done well, it lets every item be discovered and indexed. The modern best practice is straightforward: give each paginated page a self-referencing canonical and treat it as its own indexable page, link between pages with real crawlable anchors (not JavaScript-only buttons), and do not canonicalise pages 2, 3 and beyond to page 1. Note that Google deprecated rel=prev/next as an indexing signal, so the old advice no longer applies. This guide explains the current approach, the view-all decision, and the infinite-scroll and faceted-navigation pitfalls.

It builds on canonical fundamentals — see what are canonical tags and how to use them.

What pagination is and why it matters for SEO

Pagination divides a long collection into a sequence of pages: a blog with 200 posts might show 20 per page across ten pages; an e-commerce category with 500 products might span many paginated pages. Users click "next" or a page number to move through the set.

The SEO stakes are about discovery and indexing. Search engines find pages by following links, so the items on page seven of your archive are only discoverable if Google can crawl its way there through your pagination. If your pagination is broken — links that engines cannot follow, or deeper pages collapsed into page one — then the content on those deeper pages may never be discovered or indexed, no matter how good it is. Conversely, well-built pagination acts as a discovery network that funnels crawlers to every item. So pagination is not a cosmetic UI concern; it is part of your site's crawl architecture, and getting it wrong can silently bury large portions of your content.

The big change: rel=prev/next is deprecated

For years, the standard advice was to mark up paginated series with rel="prev" and rel="next" link elements, telling Google the pages formed a sequence. That advice is out of date. Google confirmed it stopped using rel=prev/next as an indexing signal — and, notably, said it had not used it for some time before announcing this, meaning many sites were relying on a signal that did nothing.

What this means in practice:

• Do not rely on rel=prev/next to communicate pagination to Google. It has no effect on indexing.
• You may keep the markup if you wish, because some browsers and accessibility tools still use it for prefetching and navigation — but understand it does nothing for Google's indexing.
• The modern approach replaces it with crawlable links plus self-referencing canonicals, covered next.

If your pagination strategy still centres on rel=prev/next, it is built on a deprecated foundation and should be updated.

The modern best practice

Today's approach treats a paginated series as a set of distinct, individually indexable pages connected by crawlable links. Three rules capture it.

Self-referencing canonicals on each page

Each paginated page should carry a canonical that points to itself, including the page parameter. Page two's canonical is page two's URL; page three's is page three's. This declares each page as its own master version. The critical anti-pattern — covered in detail below — is canonicalising every page to page one, which tells Google the deeper pages are duplicates of page one and can hide their content.

Crawlable pagination links

The "next", "previous" and numbered links must be real HTML anchors with href attributes that point to the paginated URLs. A search engine follows <a href="/blog?page=2"> to reach page two; it generally cannot follow a <button> that loads page two purely via JavaScript with no real URL. Crawlable links are what let engines walk the entire series — this is the single most important mechanical requirement.

Each page returns its content

Each paginated URL should return its items in the HTML (server-rendered or static), so a crawler that does not execute JavaScript still sees the content. If page two's items only appear after client-side script runs, crawlers that skip JavaScript see an empty page.

Get these three right and Google can discover, crawl and index every item in the series — which is the whole goal.

Approach-to-tradeoff comparison

Different pagination patterns suit different situations. Here is how the main approaches compare.

Approach	Pros	Cons / cautions
Paginated pages (self-canonical)	Each page light; whole series indexable; modern standard	Items spread across pages; needs crawlable links
View-all page	All items on one URL; consolidates signals; great UX if fast	Can be slow on long lists; hurts Core Web Vitals if heavy
rel=prev/next	Still used by some browsers/AT	Ignored by Google for indexing — do not rely on it
Infinite scroll (alone)	Smooth UX	Deeper content often undiscoverable without crawlable URLs
Infinite scroll + History API + paginated URLs	Smooth UX and crawlable	More engineering; must keep URLs and content in sync
Canonical all pages to page 1	(none worth it)	Deeper pages' content can be deindexed — avoid

The two rows to internalise: the self-canonical paginated approach is the reliable default, and canonicalising everything to page one is the mistake to never make.

View-all versus paginated

A recurring decision is whether to also offer a view-all page — a single URL showing every item — alongside or instead of pagination. There are real tradeoffs.

A view-all page is often what users prefer (no clicking through pages) and it consolidates all the content and its signals onto one URL. Google has historically liked serving a view-all page to users when one exists and loads well. But on a long list, a view-all page can become enormous and slow, hurting load time and Core Web Vitals — and a page that takes too long to load is a poor experience and a weaker SEO candidate, undermining the benefit.

The sensible rule:

• If the full list is modest and loads quickly, a view-all page is a strong option, and you can canonicalise paginated pages to it.
• If the list is long and a view-all page would be heavy and slow, stick with paginated pages, each self-canonical, to keep every page fast and indexable.

Let performance decide. A fast view-all is great; a slow one is a liability, and pagination is the better answer.

Infinite scroll done right

Infinite scroll — where new items load automatically as you near the bottom — is a popular UX pattern and an SEO trap when implemented naively. If content simply appears via JavaScript with no addressable URLs, search engines often cannot reach the deeper items, because there is nothing to crawl to. The content effectively does not exist for indexing.

The fix is to back infinite scroll with crawlable paginated URLs:

• Maintain real paginated URLs (?page=2, ?page=3) that return their content server-side for crawlers.
• As the user scrolls and a new chunk loads, update the visible URL using the History API (pushState) so each chunk corresponds to an addressable page.
• Ensure those paginated URLs work as direct entry points — if someone (or a crawler) loads ?page=3 directly, it returns page three's content.

Done this way, users get smooth infinite scroll and search engines get a crawlable, indexable series underneath. Infinite scroll and good SEO are compatible — but only when there is real pagination beneath the experience.

Faceted navigation: the parameter explosion

E-commerce and large catalogues add another wrinkle: faceted navigation, the filters for colour, size, price, brand and so on. Each filter combination can generate a unique parameterised URL, and combinations multiply fast — a handful of filters can spawn thousands or millions of URLs. Left unmanaged, this creates an explosion of near-duplicate, low-value pages that waste crawl budget and dilute signals.

Handling it requires judgement about which filtered views deserve to be indexed:

• Genuinely useful, high-demand filter combinations (a category people actually search for, like "red running shoes") may warrant being indexable, with a self-referencing canonical.
• Low-value or redundant combinations should be canonicalised to their base category or kept out of the index, so they do not bloat it.
• Use robots.txt or parameter handling carefully to stop crawlers wasting effort on infinite filter permutations — but remember that blocking a URL in robots.txt stops Google seeing its canonical too, so coordinate the signals (see what are canonical tags and how to use them).

Faceted navigation is where pagination and canonicalisation meet, and it rewards a deliberate plan over letting the system generate URLs unchecked.

How to check your pagination

Verifying pagination health is mostly about confirming crawlability and correct canonicals.

• View the page source of a category or archive and confirm the pagination links are real <a href> anchors pointing to the paginated URLs, not JavaScript-only controls.
• Load a deep page directly (for example ?page=4) and confirm it returns its content in the HTML.
• Check the canonical on pages two and beyond — it should self-reference, not point to page one.
• Crawl the site with an SEO crawler and confirm it can reach the deeper pages by following pagination, and that paginated pages are not all canonicalised to page one.
• Use Search Console's URL Inspection on a deep paginated URL to see whether Google indexes it and which canonical it selected.

A broad site audit, StackOptic included, can surface crawlability and canonical issues alongside the rest of your technical SEO so pagination problems show up in context rather than in isolation.

Common mistakes

• Relying on rel=prev/next for indexing — Google ignores it.
• Canonicalising pages 2+ to page 1, which can deindex the items only reachable on the deeper pages. This is the most damaging pagination error.
• JavaScript-only pagination with no crawlable URLs, so engines cannot reach deeper pages.
• Infinite scroll with no paginated URLs behind it, hiding most of the content.
• Unmanaged faceted navigation generating endless indexable parameter URLs.
• A view-all page that is too slow, trading indexing for a Core Web Vitals problem.
• Noindexing deeper pages reflexively, which can hide content you actually want found.

Where to start

Start by confirming the one thing that matters most: can Google crawl to your deeper pages? View the source of a paginated section and check that "next" and the page numbers are real <a href> links, then load a deep page directly to confirm it returns its content. Next, check the canonical on page two — if it points to page one, change it to self-reference, because that single fix can restore indexing for a lot of buried content. Then look at any infinite scroll or faceted navigation for the traps above. That sequence — verify crawlable links, fix page-one canonicalisation, then address infinite scroll and facets — resolves the pagination issues that most often hide content, and it ensures every item you publish can actually be discovered and indexed.

Go deeper

• The canonical rules behind it: what are canonical tags and how to use them.
• Help Google discover pages: how to create an XML sitemap and submit it.
• Control crawling sensibly: how to write a robots.txt file.
• The on-page basics: how to write a title tag and meta description.

Want crawlability, canonical and indexing issues flagged automatically? Analyse any URL with StackOptic — one report covering technical SEO, performance and more, free, no sign-up.