Should you still use rel=prev/next for SEO pagination?

What does this recommendation from Google really mean?

The tags rel="prev" and rel="next" are HTML attributes placed in the of paginated pages. They explicitly tell Google that a series of pages (page 1, 2, 3, etc.) belongs to a single cohesive logical content. A typical example is an article divided into several pages, an e-commerce category with hundreds of products, or a forum with long discussion threads.

Google explains that these tags facilitate the crawling and processing of pages as a set. This way, the engine can consolidate signals: incoming links to different pages in the series, total content, authority. Without these tags, Google may treat each page as an isolated entity, potentially diluting SEO signals across the various paginated pages.

The problem? This statement completely ignores that Google announced in 2019 that it had stopped using rel=prev/next for ranking. The official documentation still mentions these tags for crawling, but their real impact remains unclear. We find ourselves with a recommendation that seems contradictory to observed practices.

• rel=prev/next are theoretically meant to group paginated pages into a cohesive set
• Google claims this improves crawling and signal consolidation (links, content)
• Since 2019, these tags are no longer officially used for ranking, but Google continues to mention them for crawling
• The confusion persists: should they still be implemented or not?
• No quantitative data provided by Google on the actual impact of these tags today

Is this recommendation still relevant?

The short answer: not really. Google explicitly stated in March 2019 that rel=prev/next were no longer used as ranking signals. John Mueller even specified that these tags had become optional. Yet, Google continues to publish documentation that mentions them as if they were relevant for crawling.

In reality, field tests show that the absence of these tags does not negatively impact the ranking of well-structured paginated sites. Major e-commerce sites have largely abandoned rel=prev/next without noticing a drop. Google has become intelligent enough to understand pagination through other signals: URL structure, internal links, navigation patterns, JavaScript pagination. [To be verified]: Google claims these tags still help with crawling, but no public metric confirms this.

What are the real alternatives today?

If rel=prev/next are no longer critical, several strategies work better in practice. Infinite scrolling with lazy loading combined with a clean URL structure (/page/2, /page/3) allows Google to naturally discover pages. Using a "View All" page remains a solid option: it consolidates all content onto a single URL, eliminating signal fragmentation.

High-volume content sites (forums, marketplaces) often use a traditional pagination with enhanced internal linking: links to the first page, last page, and adjacent pages. Google follows these links and reconstructs the logical structure without needing specific tags. The XML sitemap also plays a key role: listing all paginated pages ensures their discovery, even if the crawler does not follow every pagination link.

In what cases can these tags still be useful?

Let's be honest: if you have already implemented rel=prev/next and everything works, there is no need to urgently remove them. They do not harm. However, implementing them today on a new project is likely a waste of development time. Efforts would be better spent on clean JavaScript pagination, solid internal linking, or a well-thought-out "View All" strategy.

A borderline case: long articles split into several pages (a practice in decline). If you maintain this format, rel=prev/next can theoretically help Google understand that the pages form a whole. But honestly, a single page with lazy loading or a clickable table of contents offers a better user experience and simpler SEO. [To be verified]: the differential impact of using these tags or not remains impossible to measure with certainty.

What should you actually do with pagination on your site?

First step: audit your current pagination. Use Google Search Console to check how many paginated pages are indexed and if they are receiving traffic. If your /page/2, /page/3, etc. pages generate impressions but few clicks, it’s a sign of SEO signal dilution. In that case, rethinking the structure is a priority, not adding outdated tags.

If you have an e-commerce site with paginated categories, favor traditional pagination with clean URLs (/category/shoes?page=2) and clear internal linking. Add self-referencing canonical links on each paginated page (canonical pointing to itself) to avoid confusion. Google will understand the structure without rel=prev/next.

What technical mistakes should you absolutely avoid?

Classic error: putting a canonical link to page 1 on all paginated pages. It seems logical (to consolidate signals), but Google will then only index the first page, making the others invisible. Users arriving via internal search or external links to page 2 will land on an unindexed page. Bad idea.

Another trap: combining rel=prev/next with noindex on paginated pages. It is contradictory. If you don’t want these pages to be indexed, own it with noindex and remove the pagination tags. If you want them indexed, leave them indexable without noindex. Mixing both creates unnecessary confusion for Google and dilutes your SEO efforts.

How can you check if your pagination is properly managed?

Use Screaming Frog or Sitebulb to crawl your site and spot inconsistencies: paginated pages canonical pointing to page 1, pagination loops, orphan pages. Also check in Google Search Console the ratio of discovered pages to indexed pages. If 80% of your paginated pages are discovered but only 20% are indexed, it’s a sign of wasted crawl budget.

Test the loading speed of paginated pages with PageSpeed Insights. Slow pagination (especially in JavaScript) slows down crawling and degrades UX. Finally, manually check some paginated pages in the URL Inspection Tool of Search Console to see how Google actually renders them. Sometimes, JavaScript scripts break pagination on the Googlebot side.

• Audit paginated pages in Search Console: traffic, indexing, impressions
• Favor traditional pagination with clean URLs and self-referencing canonicals
• Never combine canonical to page 1 + indexing of subsequent pages
• Avoid noindex on paginated pages if you want them crawled
• Crawl the site with Screaming Frog to detect technical inconsistencies
• Check the loading speed and Googlebot rendering of paginated pages