Official statement
Other statements from this video 25 ▾
- 4:51 Pourquoi Google ne garantit-il aucune augmentation des featured snippets ?
- 5:48 Comment Googlebot calcule-t-il réellement votre budget de crawl ?
- 8:04 HTTP vs HTTPS sans redirection : comment Google gère-t-il vraiment le duplicate content ?
- 8:45 Le JavaScript explose-t-il vraiment votre budget de crawl ?
- 10:26 Google utilise-t-il vraiment vos meta descriptions dans les snippets de recherche ?
- 12:10 Pourquoi les balises rel='next' et rel='prev' échouent-elles sur des pages en noindex ?
- 13:54 Google fusionne-t-il vraiment HTTP et HTTPS en une seule URL canonique ?
- 14:20 Les liens dans les menus déroulants sont-ils vraiment crawlés par Google ?
- 14:20 Les menus déroulants sont-ils vraiment crawlés comme n'importe quel lien interne ?
- 15:06 Les liens site-wide sont-ils vraiment sans danger pour votre SEO ?
- 15:11 Les liens site-wide pénalisent-ils vraiment votre référencement ?
- 16:06 Faut-il vraiment optimiser ses meta descriptions si Google les réécrit ?
- 16:16 Liens internes relatifs ou absolus : y a-t-il vraiment un impact SEO ?
- 16:34 Les liens relatifs pénalisent-ils le SEO par rapport aux absolus ?
- 17:31 Les featured snippets de mauvaise qualité révèlent-ils une faille algorithmique de Google ?
- 20:00 Rel=next/prev fonctionne-t-il encore avec des pages en noindex ?
- 24:11 Les snippets en vedette vont-ils vraiment s'étendre au-delà des définitions ?
- 28:12 Google corrige-t-il manuellement les résultats de recherche grâce aux signalements internes ?
- 28:16 Les rich cards sont-elles vraiment déployées de manière égale dans tous les pays ?
- 30:40 Google indexe-t-il vraiment le contenu de vos iframes ?
- 35:15 Votre budget de crawl fuit-il par des URLs inutiles ?
- 38:04 Faut-il vraiment créer une URL distincte pour chaque filtre produit en e-commerce ?
- 48:11 Que se passe-t-il si votre fichier robots.txt est bloqué ou inaccessible ?
- 48:27 Google indexe-t-il vraiment le JavaScript ou faut-il s'en méfier ?
- 52:57 Google indexe-t-il vraiment le JavaScript comme n'importe quelle page HTML ?
Google confirms that it is technically possible to combine rel=next/prev with noindex on paginated pages. However, this combination removes those pages from search results, which is only acceptable if other pages on your site can capture that traffic. In practice, this strategy can lighten your index without guaranteeing that Google will always understand your pagination structure.
What you need to understand
Why would you want to combine rel=next/prev and noindex?
Mueller's statement addresses a common issue: how to manage hundreds of paginated pages that dilute your crawl budget and clutter Google's index without providing value? Pages 2, 3, 4... of an e-commerce category rarely generate direct organic traffic.
The idea behind this combination is to use rel=next/prev to indicate the logical relationship between pages while applying noindex to exclude them from the SERPs. Theoretically, Google understands the structure without indexing each intermediary page.
What happens technically with this combination?
When you place noindex on a page 2 or 3, Google no longer indexes that page. The rel=next/prev remains present in the code, but its impact becomes unclear since those tags were initially intended to help Google understand pagination for better processing in the index.
Mueller notes that this approach can work "if other pages are intended to take their place." In other words: if your page 1 and product listings capture the traffic that pages 2-3 could have generated, you are not losing anything substantial. Otherwise, you risk cutting access to content that some users were searching for via long-tail queries.
Does Google still crawl these noindex pages?
Yes, at least temporarily. A noindex page remains crawlable and can pass PageRank through its links. However, over time, Google reduces the crawl frequency of noindex pages, especially if they do not receive backlinks and are not regularly updated.
This means your crawl budget may not be as optimized as expected. Google will continue to visit these pages, just less frequently. If you were looking to free up crawl budget, blocking these pages outright in robots.txt would be more drastic, but you would then lose the transmission of internal PageRank.
- rel=next/prev + noindex is technically possible, Google will not return an error
- Noindex pages disappear from the index, which may be desirable for pages 2-10 without SEO value
- The crawl budget is not fully freed up, Google continues to crawl these pages, just less frequently
- Make sure other pages capture potential traffic before mass noindexing
- This strategy is suitable for sites with deep pagination (e-commerce, forums, directories) where intermediary pages are redundant
SEO Expert opinion
Is this statement consistent with what we observe in the field?
Yes and no. On mid-sized e-commerce sites, I have seen this combination work without measurable loss of organic traffic. Page 1 and product listings continue to rank normally. But beware: on editorial sites or forums where pages 2-3 can rank for specific long-tail queries, noindexing these pages can decrease traffic.
Mueller says “if other pages are intended to take their place.” This is vague. Intended how? Automatically by Google? In reality, Google does not magically “replace” a noindex page with another. If no one links to your page 1 with the anchor “women's running shoes page 3,” that ultra-specific query could disappear from your traffic sources.
What nuances should be added to this recommendation?
First, rel=next/prev has been deprecated since March 2019. Google has officially announced that it no longer uses these tags to understand pagination. Therefore combining rel=next/prev and noindex while thinking that Google will “understand” through these tags is illusory. [To be verified]: some SEOs still think these tags have a residual effect, but Google has denied this publicly.
Next, the crawl budget. If your site has fewer than 10,000 pages and receives regular crawls, you probably do not have a crawl budget problem. Noindexing your pages 2-10 to “save” crawl is therefore a false good idea. However, on a site with 500,000 URLs and deep pagination, that may make sense.
In what situations can this strategy pose problems?
If your paginated pages generate organic traffic, even marginally. Check in Search Console: filter by URLs containing “?page=” or “/page/” and look at impressions/clicks over 12 months. If you see non-zero figures, think twice before noindexing.
Another case: sites where pagination is the only way to access certain content. For instance, a forum with old discussion threads accessible only on pages 8-9. Noindexing these pages cuts organic access to these discussions, which can be counterproductive if they have niche SEO value.
Practical impact and recommendations
What should you do concretely if you want to implement this strategy?
Start by auditing your current pagination. Export all paginated URLs from your CMS or via a Screaming Frog crawl. Cross-reference these URLs with Search Console data to identify those that generate impressions and clicks. Only noindex pages that have received no organic traffic in the past 12 months.
Next, ensure your page 1 of each section is well optimized. If you noindex pages 2-10, page 1 must carry the traffic. Make sure it has a relevant title, meta description, and H1, and that sorting/filtering options do not generate indexable duplicate URLs.
What mistakes should be absolutely avoided?
Do not noindex your paginated pages if they receive external backlinks. You would lose the transmission of PageRank. Check in Ahrefs, Majestic, or Search Console for links pointing to your pages 2-10. If you find any, keep those pages indexable and focus instead on a canonicalization or 301 redirect strategy to page 1.
Another classic mistake: noindexing AND blocking in robots.txt. If you do this, Google can no longer crawl the page to see the noindex tag, so the page remains in the index with a “blocked page” mention. Leave these pages crawlable if you want the noindex to be taken into account.
How to check if your implementation is working?
After implementation, monitor the number of indexed pages in Search Console. You should see a gradual decrease in “Coverage > Excluded: Excluded by noindex tag.” This takes 2 to 8 weeks depending on your site's crawl frequency.
Also, monitor overall organic traffic and by section. If you see an unexplained drop after noindexing your paginated pages, it means those pages were capturing long-tail traffic. In that case, reverse your decision and reevaluate your strategy.
- Audit paginated URLs and cross-reference with Search Console data to identify those with no traffic
- Optimize page 1 of each section before noindexing subsequent pages
- Check that no paginated page receives external backlinks before noindexing
- Keep noindex pages crawlable (do not block in robots.txt)
- Monitor the evolution of the index and organic traffic over 8 weeks post-implementation
- Document noindexed URLs to be able to reverse them if necessary
❓ Frequently Asked Questions
Peut-on encore utiliser rel=next/prev en combinaison avec noindex ?
Noindexer les pages 2-10 libère-t-il vraiment du crawl budget ?
Comment savoir si mes pages paginées génèrent du trafic organique ?
Que se passe-t-il si je noindexe une page paginée qui a des backlinks ?
Quelle est la meilleure alternative à noindex pour gérer la pagination ?
🎥 From the same video 25
Other SEO insights extracted from this same Google Search Central video · duration 1h13 · published on 26/06/2017
🎥 Watch the full video on YouTube →
💬 Comments (0)
Be the first to comment.