Does rel=next/prev still work with noindex pages?

Why does this statement illuminate a common blind spot?

The rel=next and rel=prev tags were historically used to signal to Google that a series of pages forms a coherent set, like pages 1, 2, 3 of a product category. The initial idea: concentrate ranking signals on the first page or on a canonical version, avoid spreading PageRank, and prevent duplicate content.

However, since March 2019, Google officially announced it no longer uses these tags for indexing consolidation. They remain theoretically useful for understanding site structure but have no direct impact on ranking. Mueller's comment adds another layer: if you place a noindex on paginated pages, Google often completely ignores these relational attributes.

What is the technical problem behind this signal conflict?

The noindex directive explicitly instructs Google not to include a page in its index. The rel=next/prev tags, on the other hand, structure a set of pages that are supposed to be indexable. When both coexist, Google receives contradictory instructions: index this series… but do not index it.

In this case, the noindex directive prevails systemically. Google cannot "understand" the structure of a pagination when its components are excluded from its index. The crawler can still discover the URLs via links, but it will not process the grouping signals you intended to establish.

In what scenarios does this situation concretely occur?

Some e-commerce or editorial sites apply a noindex on pages 2, 3, 4… to concentrate SEO value on page 1. They simultaneously add rel=next/prev, thinking they are guiding Google to the canonical version. This is a legacy of old best practices, now obsolete.

Other configurations mix canonical + noindex + rel=prev/next, creating a stack of directives that Google drastically simplifies: it ignores everything except the noindex. The risk: losing potentially useful crawl signals, with no real gain since the relational tags have been largely useless since 2019.

• The rel=next and rel=prev tags no longer directly influence indexing or ranking since 2019.
• A noindex directive effectively cancels any attempt to structure via these attributes.
• The signal conflict generates an interpretative uncertainty on the search engine side, with Google always favoring the most restrictive directive.
• If you want to maintain a readable pagination structure, all pages of the series must remain indexable.
• Removing rel=next/prev from noindex pages changes nothing: they are already ignored for consolidation.

Is this statement consistent with real-world observations?

Yes, absolutely. Since the March 2019 announcement confirming the abandonment of rel=next/prev as an indexing signal, tests show that Google treats each pagination page as an independent entity. Adding a noindex to pages 2+ simply excludes them, with the relational tags having no residual influence.

In practice, many sites continue to use rel=next/prev out of habit or because WordPress plugins generate them automatically. But crawl budget data and indexing rates show that these tags do not trigger any particular processing on the Googlebot side. The noindex remains the deciding factor, while rel=prev/next becomes just markup noise.

What nuances should be added to this rule?

Mueller specifies "not always taken into account," suggesting that in some marginal cases, Google could still interpret these tags even in the presence of noindex. But no public data supports this scenario. [To be verified]: it's impossible to know if this concerns legacy situations, transitional bugs, or undocumented exceptions.

Furthermore, if you use rel=canonical instead of noindex, the situation differs slightly. A canonical points to a preferred version while allowing indexing of the source page. But even then, rel=next/prev provides no concrete benefit: Google independently determines which page to show in the SERPs without relying on these attributes since 2019. In short, their real utility is virtually nil.

In what cases does this rule not apply at all?

If all your paginated pages remain indexable (no noindex, no canonical to page 1), the rel=next/prev tags do not harm… but they no longer help either. Google crawls and indexes each page independently, evaluating its own content, backlinks, and user engagement.

Some argue that these tags still facilitate understanding of the structure for third-party engines or screen readers. This argument is valid in terms of accessibility but beyond the strict SEO perimeter. For Google, it's been a ignored signal for a long time. If you maintain rel=next/prev, do it for legacy compatibility or internal governance reasons, not for a ranking gain.

What should be done practically on a paginated site?

First, audit existing directives. Use a crawler (Screaming Frog, OnCrawl, Botify) to list all pages featuring both rel=next/prev and noindex. If you find this combination, you already know that the relational tags are ignored: it's best to remove them to clarify the markup.

Next, choose a clear strategy. Either you index all pagination pages (useful if each page contains unique content, advanced filters, or long-tail keywords), or you concentrate indexing on page 1 via canonical or noindex on the following pages. In the latter case, rel=next/prev becomes redundant: remove them from the code.

What mistakes should be avoided during migration or cleanup?

Never allow noindex + canonical + rel=prev/next to coexist on the same page. This stack of directives generates confusion, slows down Googlebot’s interpretation, and can lead to indexing bugs if one of the tags is malformed. Always prioritize signal simplicity: one main directive, a minimal markup.

Another classic trap: removing rel=next/prev without checking internal links. If your pagination relies solely on these tags for discovering pages 2+, their removal can isolate URLs. Ensure every page remains accessible via standard HTML links, ideally in the footer or through an infinite scroll “See more” component.

How can I verify that my site complies after adjustments?

Check the actual indexing with a site:votredomaine.com/categorie?page= query in Google. If pages 2+ appear when you have set a noindex, it means the directive is not being read (blocked by robots.txt, served in JavaScript after the first render). Correct the delivery of the meta tag or the HTTP header X-Robots-Tag.

Also, monitor the crawl budget in the Search Console, under Crawl Stats. If Googlebot continues to heavily crawl noindexed pages, it means it discovers them elsewhere (XML sitemap, external links). Remove these URLs from the sitemap, and add a disallow in robots.txt if needed to save budget.

• Run a complete crawl to identify pages with both rel=next/prev and noindex.
• Decide on a single strategy: total pagination indexing or focus on page 1.
• Remove rel=next/prev from noindex pages to eliminate conflicting signals.
• Ensure each paginated page remains discoverable via HTML links if you remove relational tags.
• Check actual indexing with targeted site: queries in Google.
• Monitor the crawl budget post-modification to detect any residual waste.