La question revient à chaque audit technique : « Il faut encore mettre des rel=next et rel=prev, ou pas ? » Et à chaque fois, je vois la même scène. Un développeur a lu quelque part que Google avait abandonné ces balises. Il les a retirées du template. Six mois plus tard, les pages 2 à 7 du catalogue ont disparu de l'index. Personne ne comprend pourquoi.
Alors mettons les choses au clair tout de suite : non, rel=next et rel=prev n'aident plus votre classement. Mais l'histoire ne s'arrête pas là, et c'est précisément ce qui piège tout le monde.
Points clés à retenir
- Google a cessé d'utiliser rel=next et rel=prev comme signal de classement en 2019.
- Ces balises restent un indice de crawl utile pour d'autres robots et pour votre propre architecture.
- La vraie solution aujourd'hui repose sur trois piliers : canonical auto-référente, liens
<a href>crawlables, sitemap des pages paginées. - Ne jamais rediriger la canonical d'une page 2 vers la page 1 : c'est la garantie de perdre le contenu profond.
- La décision d'indexer ou non vos pages profondes dépend de la taille de votre catalogue, pas d'une règle universelle.
Ce que font vraiment les balises de pagination
Pendant huit ans, de 2011 à 2019, rel="next" et rel="prev" ont servi à indiquer à Google une séquence : « cette page fait partie d'une série, voici la suivante, voici la précédente ». Le placement se faisait dans le <head> de chaque page.
Ce qu'elles ne faisaient pas, en revanche — et c'est une confusion que je rencontre encore régulièrement — c'est fusionner les pages en une seule entité. Beaucoup pensaient que déclarer une séquence revenait à dire à Google : « traite tout ça comme un article unique ». Faux. Google a toujours traité chaque URL séparément pour l'indexation.
Pourquoi Google a abandonné ces balises
En mars 2019, Google a annoncé publiquement que rel=next et rel=prev n'étaient plus utilisés comme signal de classement. La raison invoquée : les pages web sont devenues plus dynamiques, et la sémantique de ces balises ne correspondait plus à la réalité technique des sites modernes.
Traduction concrète : Google sait désormais reconnaître une pagination tout seul. Il n'a plus besoin qu'on lui tienne la main avec deux balises dans le <head>.
Est-ce que Bing utilise encore rel=next et rel=prev ?
C'est la question qu'on me pose le plus souvent en formation, et honnêtement, personne ne peut y répondre avec certitude. Ce qui est documenté, c'est que l'abandon vient de Google. Pour Bing, la documentation publique est beaucoup plus floue.
Mon avis : gardez-les. Elles ne coûtent rien, elles ne pénalisent pas, et elles restent un signal sémantique propre pour n'importe quel robot qui voudrait comprendre votre architecture. C'est du gras dans la machine, pas un handicap.
La stratégie de remplacement qui fonctionne en 2026
Voici la méthode que j'applique systématiquement, et elle a réglé des problèmes d'indexation sur des catalogues que je croyais condamnés.
Pilier n°1 : la canonical auto-référente
Chaque page paginée doit pointer vers elle-même. Pas vers la page 1. Vers elle-même.
<link rel="canonical" href="https://exemple.fr/categorie?page=2" />Une erreur que j'ai commise sur un projet e-commerce : j'avais fait pointer toutes les canonicals des pages 2 à 9 vers la page principale de la catégorie. Résultat des courses, au bout de quatre mois et demi, seules les pages 1 étaient indexées. Les fiches produits situées en page 5 étaient invisibles. J'ai mis trois semaines à comprendre d'où venait le problème — je cherchais des erreurs de crawl alors que c'était mon propre template qui sabotait l'indexation.
Pilier n°2 : des liens HTML crawlables
La pagination doit reposer sur de vraies balises <a href>. Pas du JavaScript qui déclenche un chargement, pas un bouton avec un événement onclick. Un lien. Google doit pouvoir suivre la chaîne page 1 → page 2 → page 3 sans exécuter une ligne de JavaScript.
Si votre pagination utilise un framework front-end qui génère les liens côté client, vérifiez systématiquement dans la version rendue. C'est là que se cachent 90 % des problèmes que je rencontre.
Pilier n°3 : le sitemap des pages paginées
Le sitemap accélère la découverte des pages profondes. Sur un catalogue de plus de 2000 références, c'est souvent le seul moyen d'obtenir une indexation rapide des pages 6, 7, 8 — celles qu'aucun internaute ne visite jamais.
| Signal technique | Utilité en 2026 | Effort de mise en place |
|---|---|---|
| rel=next / rel=prev | Faible pour le classement, résiduel pour le crawl | Très faible (2 lignes) |
| Canonical auto-référente | Élevée | Faible |
Liens <a href> crawlables | Critique | Moyen |
| Sitemap paginé | Élevée sur gros catalogues | Moyen |
| Noindex sur filtres/paramètres | Critique si mal géré | Faible |
Faut-il indexer les pages 2, 3, 4… ou les bloquer ?
Personne n'a de réponse universelle à cette question, et quiconque vous vend une règle absolue vous raconte des histoires. La décision dépend de deux critères mesurables.
- La taille de votre catalogue : en dessous de 50 résultats, une pagination à 3 pages n'a presque aucune valeur à indexer. Au-dessus de 500, elle devient stratégique.
- La valeur des éléments situés en profondeur : si vos produits les plus rentables sont noyés en page 7, vous avez un problème d'architecture, pas de pagination.
Sur un projet de location d'équipements sportifs, j'ai testé les deux approches. Indexation complète pendant deux mois, puis blocage des pages 2+ pendant deux mois. Différence de trafic organique : -18 % avec le blocage. J'ai remis l'indexation, et je ne l'ai plus jamais retirée sur ce type de catalogue.
Le vrai risque, ce n'est pas d'indexer trop de pages profondes. C'est de créer du contenu quasi identique entre elles — ce qui arrive quand votre pagination ne fait varier que les images et les titres de produits sans aucun texte contextuel.
Comment éviter le contenu dupliqué entre pages paginées
Trois pistes concrètes, testées sur différents projets :
- Varier les balises title. « Catégorie running — page 2 » n'est pas glorieux, mais c'est net.
- Ajouter un bloc de texte différencié en bas de chaque page (même court : 60-80 mots suffisent à marquer la différence).
- Sur les très gros catalogues, préférer le chargement en « voir plus » avec URL distincte plutôt qu'une pagination qui enfouit indéfiniment.
Le code à copier tel quel
Voici ce que je place aujourd'hui dans le <head> de chaque page paginée. Rien de magique, mais c'est propre.
<!-- Page 2 sur 8 -->
<head>
<link rel="canonical" href="https://exemple.fr/categorie?page=2" />
<link rel="next" href="https://exemple.fr/categorie?page=3" />
<link rel="prev" href="https://exemple.fr/categorie" />
</head>Et dans le corps de la page, une pagination HTML classique avec des liens <a href> vers chaque page, y compris les numéros de page. Pas seulement « suivant » et « précédent » : les numéros aident Google à comprendre la structure globale.
Les erreurs qui coûtent cher
Une redirection 301 d'une page paginée vers la page 1. C'est l'erreur numéro un, et elle est fatale : Google reçoit un signal contradictoire (la page existe mais on m'envoie ailleurs) et finit par ne plus crawler la profondeur.
Deuxième classique : la canonical globale sur toutes les pages d'une catégorie. J'ai vu un site où les 12 pages d'une même catégorie pointaient toutes vers la page 1. Résultat, une seule page indexée, et une chute de visibilité de 40 % sur les requêtes longue traîne en quelques semaines.
Troisième : oublier le paramètre ?page= dans le fichier robots.txt ou dans la Search Console. Google finit par voir des milliers d'URL vides et gaspille son budget de crawl à les visiter.
Ce qu'il faut retenir
rel=next et rel=prev ne sont plus une priorité SEO. Mais les retirer sans avoir construit la solution de remplacement, c'est comme enlever un pansement avant que la plaie soit fermée.
En 2026, votre pagination doit être crawlable, canonique et sitemappée. Le reste, c'est du confort technique.
Et si vous devez retenir une seule chose de cet article : avant de toucher à vos balises de pagination, vérifiez d'abord si vos pages profondes sont indexées. Vous serez peut-être surpris du résultat — dans le mauvais sens.
