Table of contents
Most technical SEO advice on pagination you'll find today is at least seven years out of date. It still tells you to add rel="prev" and rel="next" tags, a signal Google stopped using in 2019. Meanwhile, the actual problem, crawl budget disappearing into page 40 of a blog archive, goes unaddressed.
Pagination SEO is the practice of structuring multi-page content, blog archives, ecommerce category pages, comment threads, so that search engines can crawl, index, and rank it correctly. Get it wrong, and Google spends its crawl budget on page 47 of your site instead of the pages that actually make money.
Key Takeaways
- Google deprecated rel=prev and rel=next as a ranking signal in 2019 (confirmed by Google over X on March 21, 2019) — if you're still adding them to new pages, you're doing unnecessary work with zero SEO benefit.
- A GSQI case study found that 67 percent of one site's indexed URLs were pagination pages, yet those pages drove only 0.3 percent of total clicks (via thestacc.com, 2026) — a massive amount of index space producing almost no traffic.
- Each paginated URL now stands on its own for ranking purposes; Google no longer consolidates ranking signals across a paginated series the way it did before 2019.
- Infinite scroll and "Load More" pagination are invisible to Googlebot unless a parallel, crawlable HTML version exists — the crawler cannot scroll or click.
- Never noindex paginated pages. Doing so eventually causes Google to stop following the links on them, which can orphan products or articles that only exist on those deeper pages.
- Bing still uses rel=prev/next for discovery, so if the tags already exist on your site, there's no need to remove them, just no reason to add them to new pages.
What Is Pagination SEO?
Pagination SEO is the discipline of structuring paginated URLs, canonical tags, and internal links so search engines can crawl, index, and rank multi-page content correctly. It applies anywhere content is broken into a numbered sequence: ecommerce category listings, blog archives, forum threads, and paginated comment sections all rely on the same underlying mechanics.
The stakes are real. Paginated pages increase the total number of URLs on a site, which can dilute link equity and confuse search engines about which page in a series actually deserves to rank, if pagination isn't implemented with SEO best practices in mind.
A Brief, Necessary History of rel=prev/next
In 2011, Google rolled out rel="prev" and rel="next" link attributes specifically to help it recognize when URLs belonged to the same paginated series, consolidating indexing signals and link equity into a single page in the sequence. It became a well-known best practice, and thousands of development hours went into implementing it correctly across the web.
On March 21, 2019, Google announced over X (formerly Twitter) that it had stopped using rel="prev" and rel="next" as a ranking signal (Amsive, 2025; href="https://searchengineland.com/google-no-longer-supports-relnext-prev-314319" rel="nofollow" target="_blank">Search Engine Land's original coverage notes Google's John Mueller said the deprecation had actually happened "a number of years" before the announcement itself), and had in fact stopped relying on them internally some time before that announcement. The deprecation caught much of the SEO industry off guard. Google's systems had simply gotten better at recognizing paginated content through link structure and content patterns alone, making the explicit tag redundant. Bing still processes the tags for discovery purposes, but Google does not, and hasn't for years.
Old Approach vs. Modern Approach
| Factor | rel=prev/next (deprecated) | Self-Referencing Canonical (current) |
|---|---|---|
| Google support | None since 2019; provides no ranking signal | Fully supported, current best practice |
| How it works | Tags declare a page's position in a series | Each page canonicalizes to itself, with real HTML links between pages |
| Consolidation | Attempted to merge ranking signals across the series | Each page ranks independently on its own merit |
| Bing support | Still used for discovery | Also supported |
| Action needed | Remove from new builds; no need to strip from old ones | Implement on every new paginated series |
| Common mistake paired with it | Assuming it replaces the need for internal links | Skipping self-referencing canonicals in favor of canonicalizing to page 1 |
If your site already has rel="prev" and rel="next" tags implemented, there's no urgent reason to rip them out; they aren't hurting anything, and W3C still recommends them for accessibility. There's just no reason to spend new development time adding them going forward.
Why Most Pagination Problems Actually Happen
At SMX Advanced 2023, John Mueller of Google confirmed three implementation options that all currently hold up as valid pagination SEO approaches: a self-referencing canonical tag on every page in the series paired with real sequential links, a single "View All" page that consolidates the entire series with every paginated URL canonicalizing back to it, and simply allowing each page to be indexed and crawled on its own without any canonical trick at all.
What doesn't hold up: canonicalizing every page in a series back to page 1. That tells search engines the deeper pages aren't worth indexing at all, which can cut off the PageRank flowing to the products, articles, or listings only accessible from those pages. Amazon and other large-catalog sites typically avoid this exact mistake by using standard sequential pagination with unique, indexable URLs for each page in a category listing.
Crawl Depth Is the Problem Rel=Prev/Next Never Actually Solved
Even before the 2019 deprecation, rel="prev" and rel="next" only ever provided "previous" and "next" links, with no direct path to page 1 or the final page in a series. That means Google has to crawl a series sequentially to reach deep content: reaching page 50 requires 49 intermediate crawls if only prev/next links exist.
The fix is straightforward: include links to page 1 and the last page in every pagination block, along with a handful of intermediate page numbers (1, 2, 3… 25… 48, 49, 50), so crawlers can jump deep into a series in just a few hops instead of dozens. It's also worth adding the first 5 to 10 pages of any major paginated series to your XML sitemap (via thestacc.com, 2026), since Google relies on sitemaps as a discovery mechanism and won't find deep pages efficiently through link crawling alone.
Infinite Scroll and "Load More": Where Pagination Quietly Breaks
Infinite scroll loads new content automatically as a user scrolls, which feels clean from a user experience standpoint but creates a real problem for crawlers. Googlebot renders JavaScript, but rendering is resource-intensive and isn't guaranteed on every crawl, and content that only appears after a scroll event or a "Load More" click may never get indexed at all if there's no alternative path to it.
The remedy is the same regardless of which interaction pattern triggers new content: implement a parallel, standard paginated version of the same content, accessible through real links in the HTML, not JavaScript-only buttons. Google's own guidance on lazy-loaded content recommends giving each content chunk a persistent, unique URL, using absolute page numbers like ?page=12 rather than relative values, so search engines and users can consistently find and share the same content. That gives crawlers a reliable path to everything the infinite-scroll or load-more version also shows human users.
Hash-Based URLs Have the Same Problem, for a Different Reason
Infinite scroll isn't the only way JavaScript quietly breaks pagination. Some sites change the URL when a user clicks to page 2, but only through a hash fragment (example.com/products#page=2) rather than a real URL change. href="https://developers.google.com/search/docs/specialty/ecommerce/pagination-and-incremental-page-loading" rel="nofollow" target="_blank">Google's own pagination documentation confirms Google's crawler doesn't treat a URL fragment identifier as a distinct URL, which means the content behind it may never get indexed as a separate page at all, the same outcome as infinite scroll, just a different root cause. The fix here is real URL changes for each paginated state via the HTML5 History API, with server-side rendering or static generation available as a fallback so crawlers don't depend on JavaScript execution to see the link.
For ecommerce sites specifically, faceted navigation (filtering by size, color, price range, and so on) can multiply paginated URLs into the thousands. Controlling that sprawl through Google Search Console's parameter handling or a robots.txt rule prevents Googlebot from burning crawl budget on near-duplicate filter combinations, while still leaving your core paginated series fully crawlable.
Is Your Pagination SEO-Ready?
Pagination SEO tool
Is your pagination SEO-ready?
Check off what's already true for your site. Your score updates as you go.
0 of 5
Check off items above to see how ready your pagination setup is.
How Many Items Per Page?
There's no universal number, but Google's own ecommerce documentation suggests 24 to 48 items per page as a reasonable range (via thestacc.com, 2026). Fewer items per page creates more paginated pages overall and more crawl demand across the series; more items per page reduces the number of pages but risks slower load times if images or content are heavy.
SEO Tools for Auditing Pagination
Google Search Console is the essential starting point: check the Page Indexing report to see how many paginated URLs are actually indexed versus excluded, and review crawl stats to spot whether Googlebot is spending disproportionate time on deep pagination pages instead of higher-value content. A site crawler like Screaming Frog or Sitebulb can map an entire paginated series at once, flagging missing self-referencing canonicals, JavaScript-only pagination links, or pages that are accidentally noindexed.
Common Pagination SEO Mistakes
The most common one, by a wide margin, is still implementing rel="prev" and rel="next" on new sites under the belief that it helps rankings. It doesn't, and hasn't since 2019.
Canonicalizing every paginated page back to page 1 is a close second. It looks like good housekeeping but actually tells Google the deeper pages have no independent value, which risks both orphaning content and creating a duplicate content signal Google has to resolve on its own, not always in your favor.
Relying on infinite scroll or "Load More" with no crawlable fallback is the quieter mistake. It works fine for human users, but if the only path to page 3 of a listing is a scroll event, Google may never index it.
And leaving paginated URLs out of the XML sitemap entirely forces Google to discover them only through link crawling, which is slower and less reliable than including at least the first several pages of each major series directly.
Frequently Asked Questions
Does rel=prev/next still matter for SEO?
No, not for Google. It was deprecated as a ranking signal in 2019. Bing still uses it for discovery, so there's no harm in leaving it if it's already implemented, but there's no SEO reason to add it to a new build.
Should paginated pages be set to noindex?
Generally, no. Noindexing paginated pages can cause Google to eventually stop following the links on them, which risks orphaning any content only accessible from those deeper pages. Self-referencing canonicals are the safer default.
Does infinite scroll hurt SEO?
It can, if there's no alternative path to the content. Googlebot doesn't scroll or click "Load More" buttons the way a human does, so any content that's only accessible that way may never get indexed unless a parallel, crawlable paginated version exists.
How many products or posts should each paginated page show?
Google's ecommerce guidance suggests 24 to 48 items per page as a reasonable range, though the right number depends on page weight and how heavy the content on each item is.
Do I need unique title tags for every page in a paginated series?
It's good practice but not strictly required for indexing. What matters more is that each page has a self-referencing canonical, real crawlable links to other pages in the series, and isn't blocked or noindexed.
The Bottom Line on Pagination SEO
The single most valuable thing most sites can do for pagination SEO in 2026 is stop implementing a fix for a problem that hasn't existed since 2019. Rel=prev/next isn't the issue; unmanaged crawl depth, JavaScript-only pagination links, and accidental noindex tags are. Fix those, and paginated content stops quietly draining crawl budget away from the pages that actually drive revenue.
Start with a Search Console indexing check on your largest paginated series and confirm whether self-referencing canonicals are actually in place. That's a workable starting point regardless of site size.
Ready to Fix What's Actually Draining Your Crawl Budget?
Auditing canonical tags, crawl depth, and JavaScript rendering across an entire paginated site structure is exactly the kind of technical SEO work that's easy to get wrong without dedicated attention. Web Tonic's growth marketing team handles the technical SEO audits and fixes covered in this guide as part of a full-funnel approach, so crawl budget goes toward the pages that actually convert.
More from Web Tonic: growth marketing services, data & analytics.
Sources: amsive.com · thestacc.com · searchengineland.com · developers.google.com
