Pagination and infinite scroll: what gets indexed

Two claims get repeated constantly in technical SEO advice, and both trace back to real, dated statements from Google rather than to inference: rel=next/rel=prev has done nothing at Google for years, and infinite scroll can quietly hide content from the index unless it is built a specific way. Neither is a guess. Both are things Google has said, in writing, more than once.

How rel=next/prev was retired#

The pagination markup rel=“next” and rel=“prev” was introduced by Google in 2011 to hint that a sequence of component pages belonged to one series. On March 21, 2019, Google Webmasters (the account now known as Google Search Central) announced it was retiring the tags as an indexing signal, and Google’s John Mueller added a detail that mattered more than the retirement itself: Google had not been using rel=next/prev in indexing “for a number of years” before that announcement. The signal had quietly stopped mattering long before anyone said so publicly, a sequence documented at the time by Search Engine Roundtable.

Google’s own current documentation confirms the same position without hedging. Its pagination best practices page states it directly: “Google no longer uses these tags, although these links may still be used by other search engines.” That single sentence is the entire status of rel=next/prev at Google today. Leaving the markup in an existing site does no harm, since other search engines may still use those links, but adding it now for Google’s benefit accomplishes nothing. What Google asks for instead is unglamorous and structural: a unique URL per page, sequential <a href> links between them, and a canonical tag on each page pointing at itself rather than at page one.

Infinite scroll’s real risk#

Infinite scroll fails for a more basic reason than pagination markup ever mattered: Google Search does not interact with your page, in Google’s own words. A page that only loads its next batch of content when a human scrolls to the bottom is, from Googlebot’s perspective, a page that stops after the first batch.

Google’s lazy-loading guidance states it plainly: methods should not “rely on user actions, such as scrolling or clicking,” to load content, “as Google Search does not interact with your page.” A loading mechanism gated on a scroll or click listener therefore gives Search nothing to rely on. The fix Google documents is not to load content on scroll at all, but to load it based on viewport visibility, using the IntersectionObserver API or an equivalent, which fires independently of any user action Googlebot would have to fake.

That handles content visibility, but it does not by itself solve indexing, because a page that still lives at one URL cannot be linked to, cited, or ranked as its later chunks separately. Google’s documented fix for that half of the problem is the one worth building to: give each content chunk its own unique, persistent URL, its example is a page parameter like ?page=12, and call the History API to update the visible URL once that chunk becomes the primary content on screen. That is not a workaround bolted on by SEO practitioners; it is Google’s own stated recommendation for making infinite scroll compatible with indexing at all, and it is the same underlying requirement rel=next/prev was trying, and failing, to serve a decade earlier: a discrete, crawlable URL behind every distinct piece of content.

Why we care#

Both claims collapse to one requirement, and it has not changed even as Googlebot’s own rendering ability has: content needs a real, discrete URL to be indexed as its own thing. Rel=next/prev never changed that requirement, it was markup layered on top of URLs that already existed, which is exactly why Google could drop it silently for years before anyone noticed. Infinite scroll without real URLs violates the requirement directly, not through a markup gap but by never giving Googlebot a URL to land on for the content past the first load. The practical fix is the one Google itself documents: unique URLs per chunk, discovered through normal links rather than a scroll event, with the History API layered on top for the user experience. Anything built that way gets both the paginated URL structure engines have always needed and the continuous-scroll feel users expect, without betting indexing on Googlebot doing something its own documentation says it does not do.