Rel Next

Rel next is an HTML attribute that tells machines 'this page has a next page in a sequence'. Think of it as a signpost pointing from page 1 to page 2, page 2 to page 3, and so on. Google originally used this signpost to group paginated pages together, consolidating ranking signals into one set. That changed around 2019: Google announced it no longer uses rel next or rel prev for indexing or pagination. Each page is now treated independently. So why do I still add it? Three reasons. First, it documents the intended page order in the code—useful for future developers or migrations. Second, some smaller search engines and crawlers may still honor it. Third, it's a zero-effort addition if you generate it server-side. For example, on an e-commerce category with 10 product listing pages, I add rel="next" on pages 1 through 9 and rel="prev" on pages 2 through 10. The first page only has rel="next", the last only rel="prev". This costs me nothing and might help one day. The decision rule: If you have a paginated series with at least two pages, add rel next and rel prev. If you have only one page, skip it. Don't overthink it.

Rel next still matters in a few scenarios, but not for the reason you might think. The primary use case is for sites with complex [pagination](/pagination/) structures, especially those using [canonical tags](/canonical-tag/) incorrectly. Here's a specific case: a client ran a blog archive with 200 pages, each showing 10 posts. Every page had a canonical pointing to page 1, intending to consolidate link equity. That was a mistake. With Google's independent indexing, page 2 onward would get deindexed or treated as duplicates. The correct approach: each page canonicalizes to itself, and rel next/prev documents the order. Rel next matters when you need to help other systems—like archive.org or your own internal tools—understand the sequence. It also matters if you use [technical SEO](/technical-seo/) audits where you verify HTML structure. An edge case: infinite scroll that updates the URL (via history.pushState) can still benefit from rel next/prev because the browser can't infer the sequence from JS alone. But if your infinite scroll doesn't change the URL, rel next won't help. Decision rule: Use rel next only when each page in the series has a unique URL and you want to signal ordering to any parser reading your HTML. If you use load-more buttons without changing the URL, you cannot use rel next meaningfully.

I made several mistakes with rel next over the years. The biggest: I believed it passed link equity from later pages back to the first, like a reverse canonical. I would set up paginated series and expect PageRank to flow to page 1, ignoring the need for internal links. That's not how it works. Google has always said it's a hint, not a directive, and with the deprecation it's completely irrelevant for ranking. Second, I used rel next as a replacement for crawlable navigation. I would add the tags in the head but omit 'Next' and 'Previous' links in the content, assuming bots would follow rel next. They might have, but users couldn't—bad UX. Third, I thought rel next could fix [duplicate content](/duplicate-content/) issues in paginated sections. For example, a product listing page with one sentence of description repeated across all pages. I assumed rel next would tell Google to consider the series as one entity, preventing duplicate penalties. Wrong. Google now indexes each page independently, and duplicate content is judged per page. The fix is to add unique content on each page or use [canonical URLs](/canonical-url/) properly—but not via rel next. A real example: a news site had 50 pages of article links, each nearly identical. I added rel next/prev, but traffic to pages 2+ remained zero. After adding a summary paragraph per page, rankings improved. Rel next didn't help. Now I tell clients: treat paginated pages like separate landing pages. Rel next is just a courtesy for humans and lesser crawlers.