sfw/fix
rel=prev / rel=next low

rel='prev' / rel='next' Pagination No Longer Supported

Google stopped using rel=next/prev as an indexing signal years ago, so leaning on it to consolidate paginated series does nothing.

What you see

<link rel="next" href="https://example.com/blog?page=2"/>
<link rel="prev" href="https://example.com/blog?page=1"/>
SEO audit: "rel=next/prev present — no longer used by Google"

What’s actually happening

Your paginated archive (?page=2, ?page=3 …) still carries rel=prev/rel=next in the head, and you're assuming Google reads it to treat the series as one set and float page 1 to the top. It doesn't. Google confirmed in 2019 it had already dropped these as an indexing signal years earlier. So each paginated URL stands on its own — and if pages 2+ are thin lists of links with near-identical titles and meta, they sit in the index competing as low-value duplicates of page 1.

Common causes

  • Carrying over a pre-2019 pagination pattern that assumed Google consolidated the series via rel=next/prev.
  • An SEO plugin or framework that still injects rel=prev/next by default, giving a false sense the pagination is 'handled'.
  • Paginated pages with duplicated <title>/meta description and no self-canonical, so they read as thin duplicates once Google treats each independently.
  • A canonical on page 2+ pointing back at page 1 — which hides the deeper pages' content (and their links to products/articles) from the index entirely.
  • Confusing rel=next/prev (an indexing hint Google ignores) with the still-valid browser feature — they're unrelated now.

How to fix it

  1. Stop relying on rel=next/prev to consolidateTreat the tags as inert for Google. You can leave them (Bing and accessibility tools still read them, and they cause no harm) or remove them — but either way, don't count on them to merge a series. The decision that matters is how each paginated URL behaves on its own.
  2. Self-canonical each paginated pagePut a self-referencing rel=canonical on every page in the series: ?page=2 canonicals to ?page=2, not to page 1. Canonicalizing deeper pages to page 1 is the common mistake — it tells Google to ignore those pages, so the items only linked from page 3+ never get discovered.
  3. Make each page individually useful and distinctDifferentiate titles and meta ('Blog — Page 2'), keep the items crawlable as real <a href> links, and make sure every important destination is reachable within a few clicks. Component pages should earn their place, not duplicate page 1.
  4. Keep paginated URLs crawlableDon't noindex page 2+ and don't block ?page= in robots.txt as a reflex — that can strand the only crawl path to deeper content. If a parameter genuinely creates duplicates, canonicalize it rather than blocking it.
  5. Offer a view-all where it fitsFor a series short enough to load fast, a single 'view all' page (with paginated pages canonicalizing to it) is the cleanest consolidation Google actually honors. Skip it if it would make the page slow.

Stop it recurring

Design pagination so every page is self-canonical, crawlable, and individually useful — not dependent on any link relation Google has retired.

Related errors