Gérer la pagination d'un site avec des balises rel next prev : le guide

Pagination SEO : ce que les balises rel next prev font encore (et ce qu'elles ne font plus)

J'ai passé des années à croire dur comme fer que rel="next" et rel="prev" réglaient tous les problèmes de pagination d'un site. Puis un jour, en auditant un e-commerce de 40 000 références, j'ai réalisé que le site avait ses balises parfaitement posées depuis 2017 — et que Google s'en fichait éperdument. Le trafic sur les pages 2, 3 et 4 n'avait pas bougé d'un iota depuis des mois.

Alors, on les garde ou on les jette ? Franchement, la réponse tient en une phrase : ces balises ne font plus rien pour l'indexation, mais elles restent utiles dans certains cas précis. Ce n'est pas une question de "pour ou contre", c'est une question de contexte.

À quoi servaient ces balises, et pourquoi ça a changé

Quand Google les a introduites, on était encore dans une époque où le moteur luttait ouvertement contre le contenu dupliqué. Deux pages qui affichent les mêmes produits dans un ordre légèrement différent, c'est du contenu quasi identique à ses yeux. Ajouter un signal dans le head semblait être la solution propre.

Le principe était simple : indiquer à l'algorithme que la page 2 n'est pas une copie de la page 1, mais une suite logique. Une espèce de "regarde, c'est la même liste, juste plus loin".

L'abandon de 2019, et ce qui a suivi

En 2019, Google a annoncé que rel="next" et rel="prev" ne seraient plus utilisés comme signaux d'indexation. Pas supprimés du HTML : juste ignorés par le moteur. La différence est importante.

Je me souviens très bien du fil de discussions qui a suivi. Des dizaines de personnes expliquant que ça allait tout casser. Spoiler : rien ne s'est cassé. Les sites qui avaient investi dans une pagination propre ont continué à bien ranker. Ceux qui comptaient uniquement sur ces balises pour éviter la duplication, eux, ont pris le mur. Logique.

Depuis, la vraie recommandation côté Google est simple et vieille comme le web :

• Utiliser des liens <a href> classiques entre les pages paginées, bien visibles dans le corps de la page
• Ne pas mettre de noindex sur les pages 2+ (erreur classique, on y revient)
• S'assurer que chaque page paginée a un canonical qui pointe vers elle-même

Voilà. Toute la "stratégie pagination" moderne tient là-dedans.

Faut-il continuer à mettre les balises rel next prev ?

Ma réponse, et je la défends bec et ongles : oui, mais sans y croire une seconde pour le SEO.

Pourquoi les garder alors ? Parce qu'elles coûtent zéro, ne cassent rien, et restent lues par des outils tiers. Bing les a longtemps considérées (il en a gardé une interprétation partielle). Des crawlers d'audit, des agrégateurs de contenu, des lecteurs spécialisés peuvent aussi s'en servir pour comprendre la structure séquentielle.

Ce n'est plus du SEO. C'est de l'hygiène de code.

Un exemple concret de head propre

Voici ce que je mets systématiquement sur les sites que je gère, page 3 d'une liste par exemple :

<head>
  <link rel="canonical" href="https://exemple.com/boutique?page=3">
  <link rel="prev" href="https://exemple.com/boutique?page=2">
  <link rel="next" href="https://exemple.com/boutique?page=4">
</head>

Et dans le corps de la page, les liens visibles :

<a href="?page=2">Précédent</a>
<a href="?page=4">Suivant</a>

Le canonical auto-référent, c'est le point vraiment important. Sans lui, certains CMS un peu paresseux font pointer le canonical de la page 3 vers la page 1. Résultat : Google désindexe les pages suivantes, et vous perdez tout le maillage interne qui alimentait ces URLs. Je l'ai vu sur un site de recettes — près de 60 % des pages paginées étaient sorties de l'index à cause d'un canonical mal configuré. Un cauchemar à rattraper.

Les vraies erreurs de pagination que je vois tout le temps

Après avoir audité plusieurs dizaines de sites, trois erreurs reviennent en boucle.

Mettre en noindex les pages 2 et suivantes

Cette astuce circule depuis des années sous prétexte de "lutter contre le duplicate content". Sauf qu'elle coupe le robot à la page 1. Les articles, produits ou fiches qui n'apparaissent qu'en page 4 deviennent inaccessibles pour l'indexation. Le bot peut toujours suivre les liens, mais si la page est en noindex, les URLs qu'elle référence voient leur découverte ralentie.

Sur un site de 8 000 recettes que j'ai repris, cette erreur datait de l'ancien prestataire. 12 000 URLs profondes étaient invisibles. Trois semaines après retrait du noindex, le trafic organique a grimpé de 18 %.

Des URLs qui changent à chaque filtre

Le combo pagination + filtres, c'est la plaie du e-commerce. Si "couleur=rouge&page=2" et "page=2&couleur=rouge" génèrent deux URLs distinctes, vous créez de la duplication à la chaîne. La règle : un seul ordre de paramètres, stable, et un canonical cohérent. Sur une boutique de cosmétiques, on avait dénombré plus de 400 000 combinaisons d'URLs paginées à cause de ça. Google en explorait une fraction, avec un budget de crawl totalement gaspillé.

La pagination infinie sans pagination réelle

Le scroll infini, c'est joli. Mais si vous n'ajoutez pas une vraie structure paginée derrière (URLs accessibles, liens <a href>), le contenu au-delà du premier écran n'existe pas pour les crawlers. Oui, ça paraît basique. Non, ce n'est pas appliqué partout.

Comparaison des approches de pagination

Pour y voir clair, voici comment les principales techniques se comportent aujourd'hui :

Approche	Effet sur l'indexation	Effet sur le budget de crawl	Complexité technique
Canonical auto-référent	Fort, indispensable	Sain	Faible
Liens HTML précédent/suivant	Fort, améliore la découverte	Bon	Faible
rel="next" / rel="prev"	Nul depuis 2019	Nul	Très faible
noindex sur pages 2+	Négatif, coupe l'accès	Négatif	Faible
Scroll infini sans URLs paginées	Quasi nul	Mauvais	Moyen

Que faire au-delà de la page 10 ?

Question que personne ne pose, et pourtant. Au-delà d'un certain seuil, les pages de pagination profonde n'apportent plus grand-chose. Sur un catalogue de 40 000 produits, la page 47 n'a aucun intérêt pour un utilisateur — et encore moins pour Google.

Ma règle perso : jusqu'à la page 5, on laisse tout indexable. Au-delà, tout dépend du contenu. Pour un blog avec 200 articles, les pages profondes contiennent des liens vers des articles anciens qui méritent d'être découverts. Pour un e-commerce avec tri par défaut, les pages 10+ sont du pur gaspillage.

Trois options dans ce cas :

• Ajouter un noindex, follow sur les pages très profondes (au-delà d'un seuil, pas avant)
• Proposer un tri pertinent qui pousse les contenus à valeur en surface
• Exposer des sitemaps segmentés pour forcer la découverte des contenus enfouis

Cette dernière astuce est sous-utilisée. Un sitemap dédié aux contenus profonds, mis à jour régulièrement, règle souvent le problème d'indexation sans toucher à la pagination elle-même.

Alors, on garde ou on supprime ?

Je garde. Systématiquement. Coût zéro, bénéfice marginal mais réel sur les outils tiers, et zéro risque de pénalité. Ce serait dommage de s'en priver juste par principe.

Ce qui compte vraiment dans une pagination en 2026, ce n'est ni rel="next" ni rel="prev". C'est la solidité de trois piliers : un canonical propre, des liens HTML cliquables, et une vraie stratégie de seuil pour ne pas gaspiller votre budget d'exploration.

La prochaine fois que quelqu'un vous dit que ses pages 2+ ne sont pas indexées à cause d'un manque de rel="next", demandez-lui de vérifier son canonical. Dans 9 cas sur 10, le coupable est là. J'y mettrais ma main à couper.