Does rel="next"/"prev" Still Matter for Pagination SEO?

Google confirmed on March 21, 2019 that it had retired rel="next" and rel="prev" as an indexing signal, and that it had already stopped relying on the tags years before making the announcement. A large amount of pagination advice still circulating treats these tags as something worth implementing carefully. They aren't anymore. What actually determines whether Google can find and index a paginated series now comes down to plain, crawlable links and correctly-used canonical tags, not a markup pair most sites spent years perfecting for no ranking benefit.

What rel="next" and rel="prev" Used to Do

Google introduced rel="next" and rel="prev" in a September 2011 Webmaster Central blog post, as a way for a site to explicitly mark the relationship between pages in a paginated series, for example page 2 of a product category pointing back to page 1 with rel="prev" and forward to page 3 with rel="next". The stated purpose was to help Google's indexing systems understand that a series of URLs represented one logical sequence, which the company said could help consolidate indexing properties across the set and, in some cases, surface a more useful page from within the series in search results.

For roughly eight years, this was standard, widely-recommended technical SEO practice. Countless CMS plugins, ecommerce platforms, and hand-rolled pagination templates added the tags automatically, on the understanding that they were a meaningful signal Google's indexing pipeline actually consumed.

The March 2019 Retirement, and Why It Caught People Off Guard

Google's announcement came through its Webmaster Central Twitter account on March 21, 2019, and the wording was direct: "As we evaluated our indexing signals, we decided to retire rel=prev/next. Studies show that users love single-page content, aim for that when possible, but multi-part is also fine for Google Search." The statement was widely reported at the time by outlets including Search Engine Roundtable, Search Engine Journal, and Search Engine Land, all of whom carried the same core wording from Google's account.

What made the announcement land awkwardly was timing. Google's own John Mueller had discussed rel=next/prev as a still-relevant tactic in a Webmaster Central hangout just two days earlier, on March 19, 2019, before the retirement was confirmed publicly. Google also clarified separately that the underlying change wasn't new: the tags had already stopped being used as an indexing signal for a period of time before the tweet, meaning a meaningful stretch of the SEO industry had been maintaining tags that were no longer doing anything, without knowing it. Google removed its original 2011 support documentation for the tags following the announcement, and reporting from that period noted the original blog post was subsequently marked as no longer reflecting current guidance.

What Google Actually Recommends Now

Google's current pagination documentation, last updated December 10, 2025, doesn't mention rel=next/prev at all. Instead, it lays out best practices built entirely around ordinary crawlable links and correct URL and canonical handling:

• Link pages sequentially with real <a href> tags. Google states plainly that this "can help Googlebot find subsequent pages," and recommends also linking from every page in a collection back to the first page, since that gives Google a hint the first page might be the better landing page for the series.
• Give each page its own unique URL, for example using a ?page=n query parameter, since Google treats each URL in a paginated sequence as a separate page.
• Never canonicalize every page in a series back to page one. Google's documentation is explicit: "Don't use the first page of a paginated sequence as the canonical page." Each page needs its own canonical URL, pointing to itself. This is a common, damaging mistake, since a blanket rule treating page one as canonical for the whole series tells Google to drop every other page from independent ranking eligibility. See canonical tags and canonicalization explained for how canonical signals work more broadly.
• Don't use URL fragments (the part after a #) for page numbers. Google ignores fragment identifiers entirely, and if a link to the next page differs from the current URL only after the #, Googlebot may not follow it at all, assuming it has already retrieved that page.
• Titles and descriptions don't need to be unique per page in a paginated sequence, which removes one piece of unnecessary optimization work some sites still spend time on.

Put together, these current rules point the same direction: Google's guidance no longer treats a paginated series as one consolidated unit the way rel=next/prev was originally meant to help with. Each page gets its own canonical URL rather than deferring to page one, and each is discovered through its own link rather than a declared sequence relationship. A weak page 4 of a category listing has no documented mechanism left for inheriting ranking strength from a strong page 1 just because they're part of the same series; that consolidation was specifically what rel=next/prev was retired without a replacement for.

Choosing Between Pagination, Load More, and Infinite Scroll

Google's documentation frames this as a genuine UX decision with real tradeoffs on both sides, not a solved question with one correct answer:

The deciding factor Google actually calls out for indexing purposes has nothing to do with which pattern looks best. It's whether Google's crawler can reach every chunk of content through a real link. Google's documentation states this mechanically: "Google generally crawls URLs found in the href attribute of <a> elements," and that its crawlers "don't 'click' buttons and generally don't trigger JavaScript functions that require user actions to update the current page contents." A load-more button wired only to a JavaScript click handler, with no underlying crawlable link, is functionally invisible to Googlebot no matter how well it works for a human visitor. See JavaScript SEO for the broader mechanics of what Googlebot does and doesn't execute.

Making Infinite Scroll Indexable

Infinite scroll is the pattern most likely to accidentally hide content from Google, because its whole premise, content appearing automatically as a user scrolls, mirrors exactly the kind of user-triggered JavaScript interaction Google's crawler doesn't perform. Google's own guidance on fixing lazy-loaded content sets out a specific method for making infinite scroll indexable rather than avoiding it outright:

1. Give every chunk of content its own persistent, unique URL. Absolute page numbers work, for example ?page=12; Google specifically warns against relative values like ?date=yesterday, since those don't reliably point to the same content on a later visit.
2. Link sequentially between the individual chunk URLs using real <a href> links, the same requirement that applies to standard pagination.
3. Update the visible URL using the History API once a new chunk becomes the primary content the user is viewing. This lets a person refresh, share, or link back to the exact scroll position they were at, and gives Google a stable URL to crawl for that specific chunk.
4. Load content based on viewport visibility, not user action, using the browser's built-in lazy-loading, the IntersectionObserver API, or an equivalent library. Google is explicit that content should load "whenever it is visible in the viewport" rather than waiting on a scroll or click event it won't simulate.
5. Verify the result with the URL Inspection Tool in Search Console, checking the rendered HTML to confirm the content actually appears there rather than only in the live, JavaScript-driven page a browser shows.

A site that implements infinite scroll without this underlying URL structure isn't just missing a nice-to-have. It's effectively hiding every page beyond the first from Google entirely, since there's no crawlable path into the rest of the content at all.

Avoiding the Duplicate-Content Trap Filters and Sorting Create

Paginated collections often support filters or alternate sort orders, for example ?order=price on a category page. Google's guidance here is specific: these variant URLs shouldn't be left open to indexing by default, since they return the same underlying list of results in a different order, which reads to Google as duplicate or near-duplicate content spread across many indexed URLs for no real benefit. The two mechanisms Google names for handling this are a noindex robots meta tag on the variant URLs, or discouraging crawling of the matching URL pattern through robots.txt. See robots.txt and AI crawlers for how path-based rules in robots.txt actually work, and crawl budget and log files for why letting a large number of filter and sort permutations get crawled and indexed can quietly consume crawl budget that would otherwise go toward genuinely new or updated pages.

A Practical Pagination Checklist

For a site auditing its existing paginated content:

1. Stop treating rel="next"/"prev" as a task. Don't add it to new pagination, and don't spend engineering time removing it from old pagination either; it's inert either way as far as Google is concerned.
2. Confirm every paginated page has a self-referencing canonical, not one pointing back to page one.
3. Check that "next page" links are real <a href> elements, visible in the page's rendered HTML, not only wired to a JavaScript click handler with no underlying link.
4. Give infinite scroll and load-more implementations real, unique URLs per chunk, verified through the URL Inspection Tool's rendered HTML view.
5. Block or noindex filter and sort-order URL variants rather than letting every permutation get crawled and indexed as a separate near-duplicate page.

Related: canonical tags and canonicalization explained, JavaScript SEO, crawl budget and log files, crawling vs. indexing.