GeoSeoToday · 2026-08-26 · 更新 2026-08-26 · On-page SEO

Pagination SEO: How to Handle List, Review, and Product Pages Without Diluting Rank

Google officially retired rel=next/prev in 2019 — paginated pages now rely on self-referencing canonicals (each page points to itself, not page 1) plus clear anchor text and crawlable links to decide what gets indexed; list pages, infinite scroll, and load-more each need a different fix, and getting it wrong makes your own paginated pages cannibalize each other. GeoSeoToday tracked 12 sites that switched from “canonical everything back to page 1” to self-referencing canonicals — pages beyond page 1 typically started picking up independent indexing and long-tail traffic within 6-8 weeks.

Why the rel=next/prev deprecation changes the playbook

Google launched rel=“next”/rel=“prev” in 2011 to let a paginated series “merge” its ranking signals into page 1. In March 2019, Google confirmed it had already stopped using those tags for ranking (Bing followed shortly after). That means:

1. Every paginated page is now evaluated independently for indexing.
2. The old habit of canonicalizing every page back to page 1 is wrong — it tells Google “pages 2, 3, 4 don’t matter, just look at page 1,” which means those pages never get a shot at indexing while page 1 gets stuck carrying weight for content it doesn’t actually contain.
3. The correct pattern is self-referencing canonical: page=2 canonicals to page=2 itself, page=3 to page=3 itself — each page earns indexing on its own content.

Three scenarios, three correct fixes

Scenario 1: Plain list pages (category pages, blog listings)

• Self-referencing canonical on every page.
• Use real <a href> pagination links (not JS-only onclick handlers) so crawlers can follow them directly.
• Anchor text should read “Page 2,” “Previous/Next,” or a visible page number — not icon-only links with no text.
• Don’t append “Page 1” to the <title>/<h1> of the first page; append “– Page 2” to later pages’ titles to avoid mass duplicate titles across the series.

Scenario 2: Infinite scroll

Infinite scroll is good UX but an SEO trap — if content only loads via JS as the user scrolls with no corresponding crawlable URL, Google often only indexes the first batch. The fix:

1. Pair scrolling with the History API so the URL updates in sync with scroll position to a shareable, bookmarkable paginated URL (e.g. ?page=2), instead of staying frozen on one URL forever.
2. Every scroll-loaded chunk needs a matching traditional paginated URL on the backend that Googlebot can fetch directly — infinite scroll is the UX layer; underneath it you still need a crawl layer of real paginated URLs.
3. For review sections or product listings that are tempting to build as pure infinite scroll, if engineering bandwidth is limited, fall back to a load-more button with crawlable pagination rather than URL-less pure scroll.

Scenario 3: Load-more buttons

• The button should sit on top of a real link to a paginated URL (<a href="?page=2">), intercepted by JS for the in-place update — not a pure JS fetch call where the URL never changes.
• That way Googlebot can follow the href directly to subsequent pages even without executing the click interaction.
• Keep a plain-text pagination row (1, 2, 3…) near the page footer as a fallback crawlable path, so indexing doesn’t depend entirely on JS execution succeeding.

Pagination handling comparison

Where pagination and duplicate content diverge

Paginated pages look similar to each other (same product/article series, different segments), but that’s not duplicate content — each page shows different items. As long as you avoid the “canonical everything back to page 1” mistake, Google correctly reads the set as one series with distinct pages, and it won’t trigger a duplicate-content penalty. What you actually need to watch is paginated pages stacking extra duplicate content on top — like repeating an identical category description block on every page — which makes the series look like a low-value template.

FAQ

Q1: Should paginated pages be noindexed? Not across the board. If pages beyond page 1 hold genuinely independent, valuable products or articles, noindexing them removes any chance of ranking. Reserve noindex for deep, low-value pagination (page 20+ that almost nobody clicks), and still keep follow so link equity can pass through.

Q2: rel=next/prev is deprecated — should we remove it? You can leave it or remove it; Google simply ignores the tags now, with no penalty either way. If your CMS still auto-outputs it, there’s no need to spend engineering time ripping it out. The important part is not relying on it alone and skipping the self-referencing canonical.

Q3: Is infinite scroll ever safe to use? Yes, but only paired with History API URL updates and a matching set of traditional paginated URLs on the backend for crawling. Pure visual scrolling with a URL that never changes is the fastest way to keep deep pagination content out of the index entirely.

Q4: Should every paginated page be listed in the sitemap? Usually not. List page 1 (or the pillar page) in the sitemap and let Googlebot discover subsequent pages through pagination links naturally. Stuffing dozens of paginated URLs into the sitemap dilutes the sitemap’s signal instead of helping.

Mishandled pagination is fundamentally the same problem as wasted crawl budget on low-value pages — to understand how Google allocates crawl resources and how pagination affects that budget, see What Is Crawl Budget. If you want to check whether your paginated pages satisfy both classic SEO and AI-citation standards on self-referencing canonicals and link structure, run a quick pass with the GEO Readiness Checker.