Pagination Has Changed — And Most Sites Haven't Caught Up
Google dropped support for rel="next" and rel="prev" back in 2019, and a lot of SEOs are still pretending that didn't happen. The old pagination signals are dead. Google's John Mueller confirmed they hadn't been using them for years before the announcement anyway.
So what do we actually do for paginated content in 2026? It depends on your implementation — and there are three common patterns, each with different SEO implications.
Traditional Pagination (Page 1, 2, 3...)
The classic approach: discrete pages with numbered links at the bottom. Each page has its own URL like /blog?page=2 or /blog/page/2/.
This is still the most SEO-friendly pattern, and here's why: each paginated page is a separate, crawlable URL. Googlebot can discover and index content on page 5 by following the pagination links. It doesn't need to execute JavaScript or interact with the page.
Best Practices for Traditional Pagination
- Don't noindex paginated pages — Google needs to crawl them to find the content on deeper pages
- Don't canonical all paginated pages to page 1 — this tells Google to ignore pages 2+ entirely, and the content on those pages won't be indexed
- Each page should have a self-referencing canonical
- Include paginated pages in your sitemap
- Keep page numbers reasonable — if you have 500 pages of results, that's a sign you need better category structure or filtering, not better pagination
One thing I'd argue strongly: use clean URL patterns. /blog/page/2/ is better than /blog?page=2. The clean URL version is easier to manage in analytics, robots.txt, and canonical tags.
Infinite Scroll
Infinite scroll loads new content as the user scrolls down. It's popular for social feeds and some e-commerce sites, but it's terrible for SEO out of the box.
The problem is straightforward: Googlebot doesn't scroll. When it loads a page with infinite scroll, it only sees the initially loaded content. Everything that would load on scroll is invisible to the crawler.
The Hybrid Fix
The standard solution is to implement infinite scroll for users while maintaining crawlable paginated URLs in the background. Here's how it works:
- Create traditional paginated URLs that work without JavaScript:
/products/page/1/,/products/page/2/, etc. - On the front end, intercept these page loads and instead append content via infinite scroll
- Update the browser URL using the History API as the user scrolls past page boundaries
- Include pagination links in the HTML source (they can be hidden from visual users) so Googlebot can follow them
Google themselves recommended this approach in their "Infinite scroll search-friendly recommendations" documentation. The key is that the paginated URL structure exists and returns content server-side, even if users never see the traditional pagination UI.
Load More Buttons
The "Load More" button is a middle ground — it's better than infinite scroll because there's a clear user action, but it has the same fundamental SEO problem. Content loaded via a "Load More" click is typically injected via AJAX and doesn't exist in the initial HTML.
The fix is identical to infinite scroll: maintain crawlable paginated URLs underneath. The "Load More" button can trigger either a full page navigation (simplest, most SEO-friendly) or an AJAX load that also updates the URL via the History API.
Which Approach Works Best?
| Pattern | User Experience | SEO Friendliness | Implementation Effort |
|---|---|---|---|
| Traditional pagination | Good | Excellent | Low |
| Load More + paginated fallback | Very good | Good (if done right) | Medium |
| Infinite scroll + paginated fallback | Excellent for browsing | Good (if done right) | High |
| Infinite scroll alone | Great for users | Poor | Low |
The "View All" Page Question
Some sites create a "view all" page that shows every item on a single page. The old advice was to canonical all paginated pages to the view-all page. With the death of rel=next/prev, does this still make sense?
Generally, no. View-all pages create problems:
- Slow load times — a page with 500 products is going to be huge
- Poor Core Web Vitals — massive DOM size, slow rendering
- Google may not fully render extremely large pages
I'd only recommend a view-all page for small collections (under 50 items) where the full list genuinely fits on a single fast-loading page. For everything else, stick with paginated pages and make sure each one loads quickly.
Handling Paginated Content in Sitemaps
Include all paginated URLs in your sitemap. Yes, all of them. Page 47 of your blog archive might seem unimportant, but it contains links to articles that Google needs to discover. If you exclude it from the sitemap and it's poorly linked internally, those articles might not get crawled.
That said, don't include parameter-based pagination if you also have path-based pagination. Pick one canonical pattern and stick with it:
# Pick one:
https://example.com/blog/page/2/ (path-based - preferred)
https://example.com/blog?page=2 (parameter-based)Practical Testing
After implementing any pagination approach, test it:
- Disable JavaScript in your browser and verify paginated pages still render content
- Use Google's URL Inspection Tool on a paginated page to see what Googlebot renders
- Check your crawl stats in Search Console — are paginated pages being crawled?
- After a few weeks, search for content that only appears on deeper paginated pages — if it's not indexed, your implementation isn't working
Pagination SEO isn't complicated once you accept one principle: Googlebot needs to reach every piece of content through a crawlable link path that doesn't require JavaScript interaction. How you present that to users is a UX decision — how you present it to crawlers is a technical SEO decision, and they can be different.