Votre page 2 existe-t-elle vraiment pour Google ?
Un blog de 300 articles, 10 billets par page : 30 pages de listing. Une boutique de 2 000 références : des dizaines de pages « ?page=N » par rayon. Ces pages ne rankent sur rien, se ressemblent toutes, et pourtant elles décident de la visibilité de tout ce qui se trouve derrière elles. Mal paginer, c'est enterrer vos contenus anciens et vos produits de fond de catalogue.
Dans cet article, vous allez découvrir :
- •Les trois problèmes que la pagination crée pour Google (duplication, profondeur, crawl) et celui qui coûte le plus cher
- •Ce que Google a abandonné avec rel next et rel prev, et pourquoi tant de sites appliquent encore une consigne morte
- •Le pattern qui fonctionne en 2026 : canonical sur soi-même, pages indexables, liens HTML vers toutes les pages
- •Comment traiter le scroll infini et le bouton « voir plus » sans rendre vos contenus invisibles
- •Deux mises en pratique : la pagination d'un blog et celle d'une boutique e-commerce
La pagination n'est pas un détail d'intégration. C'est le chemin par lequel Googlebot atteint la majorité de vos URL. Si ce chemin casse, le reste du SEO ne sert à rien.
Pourquoi la pagination pose problème en SEO
La pagination SEO désigne la façon dont un site découpe une longue liste (articles, produits, avis) en plusieurs pages numérotées, et la manière dont Google découvre, crawle et indexe ces pages ainsi que les contenus qu'elles relient. Le problème n'est jamais la page 2 en elle-même : c'est ce qu'elle fait aux pages situées derrière.
Trois mécanismes se cumulent.
Le contenu quasi dupliqué
Les pages 1, 2, 3 d'une même catégorie partagent le même titre, la même description, la même introduction, le même template. Seule la liste des éléments change. Pour Google, ce sont des pages très proches qui se disputent la même intention de recherche.
Conséquence fréquente : Google choisit lui-même une URL canonique, parfois la page 4 au lieu de la page 1, et les signaux se dispersent. Nous détaillons ce mécanisme dans notre article sur la canonical URL et le contenu dupliqué : la pagination est l'un des cas les plus courants de duplication involontaire.
La profondeur de clic
Un article publié il y a deux ans se trouve en page 18 du blog. Pour l'atteindre, Googlebot doit suivre 18 liens successifs depuis l'accueil. Chaque niveau réduit la fréquence de crawl et le poids transmis. Au-delà de 4 ou 5 clics, une URL est crawlée rarement, mise à jour tardivement et, dans les cas extrêmes, désindexée faute de signaux.
Le point clé : la profondeur se mesure en clics depuis l'accueil, pas en dossiers dans l'URL. Une pagination linéaire (« suivant » uniquement) crée une profondeur égale au numéro de page.
Le budget de crawl
Google alloue à chaque site un volume de requêtes qu'il est prêt à dépenser. Des centaines de pages de listing presque identiques consomment ce budget sans rien apporter. Sur une boutique de taille moyenne, pages paginées, filtres et tris combinés représentent souvent plus d'URL que le catalogue lui-même.
Notre guide complet sur le crawling SEO explique comment lire les logs serveur et le rapport de couverture pour mesurer ce gaspillage. La pagination y figure presque toujours parmi les premiers postes de dépense.
rel next et rel prev : ce que Google a vraiment abandonné
Les attributs rel="next" et rel="prev" sont des balises link placées dans le head qui indiquent à un moteur que des pages forment une séquence. Google a annoncé en mars 2019 qu'il ne les utilisait plus comme signal d'indexation, et qu'il ne les avait en réalité plus exploités depuis plusieurs années.
Ce que cela change concrètement :
- •Google ne consolide plus la série : chaque page paginée est jugée pour elle-même, pas comme un fragment de la page 1.
- •Les balises ne nuisent pas : Bing les lit encore, et elles restent utiles pour l'accessibilité.
- •Elles ne vous sauvent plus : un site qui compte sur rel next et prev pour masquer une pagination défaillante n'a aucun filet. Les liens HTML et la canonical font tout le travail.
Position ferme : en 2026, rel next et prev ne sont plus un levier SEO, ce sont des métadonnées neutres. Le vrai levier, c'est la structure des liens entre vos pages paginées.
À lire aussi : Maillage interne : stratégie SEO complète - La pagination n'est qu'un cas particulier du maillage ; cet article pose la méthode globale pour répartir l'autorité sur un site.
Les bons patterns de pagination SEO en 2026
Un pattern de pagination SEO correct repose sur une règle unique : chaque page paginée est une URL à part entière, accessible par un lien HTML, indexable, et canonique vers elle-même. Tout le reste en découle.
| Élément | Bonne pratique | Erreur fréquente |
|---|---|---|
| Balise canonical | Chaque page pointe vers sa propre URL (/blog/page/3/ vers /blog/page/3/) | Toutes les pages pointent vers la page 1 |
| Indexabilité | Toutes les pages indexables, pas de noindex | noindex sur les pages 2 et suivantes |
| Liens entre pages | Liens HTML classiques, avec href, vers plusieurs pages (première, dernière, voisines) | Boutons JavaScript sans href, ou « suivant » seul |
| Balise title | Titre de la liste suivi de « page N » | Titre identique sur toutes les pages |
| URL | Paramètre ou segment stable et unique par page | URL identique avec chargement en AJAX |
Chaque page paginée est indexable avec une canonical sur elle-même
Le point fait encore débat chez les intégrateurs, et la réponse est pourtant stable depuis 2019 : la page 7 doit déclarer qu'elle est la page 7. Elle n'a aucune valeur de positionnement propre, mais elle est la porte d'entrée vers les 24 produits ou les 10 articles qu'elle liste. Non indexable, elle sera traitée comme une page de seconde zone, crawlée moins souvent.
Jamais de canonical vers la page 1
Canonicaliser toutes les pages vers la première revient à dire à Google : « les pages 2 à 30 sont des copies de la page 1, ignore-les ». Google les ignore, et tout ce qu'elles relient devient quasi orphelin. Les produits visibles seulement en page 6 perdent leur unique lien interne. C'est la plus coûteuse des erreurs de pagination, et plusieurs thèmes et plugins populaires l'installent par défaut.
Des liens HTML vers toutes les pages, pas seulement « suivant »
La profondeur de clic se corrige par la structure des liens. Un bloc de pagination efficace propose au minimum :
- •un lien vers la première page et vers la dernière,
- •les pages voisines (N-2 à N+2),
- •idéalement quelques jalons intermédiaires (10, 20, 30) quand la série est longue.
Avec ce schéma, une page 25 se trouve à 3 clics de la page 1 au lieu de 24. Chaque lien doit être une vraie balise a avec un href complet. Un bouton qui déclenche du JavaScript sans href n'est pas un lien pour Googlebot, même si le rendu final affiche la bonne page.
Scroll infini et bouton « voir plus » : le piège du contenu invisible
Le scroll infini charge les éléments suivants au fil du défilement, sans changer d'URL. Le bouton « voir plus » fait la même chose à la demande. Sur mobile, l'expérience est souvent meilleure. Mais implémentés seuls, ils rendent invisible à Google tout ce qui n'est pas dans le premier chargement.
La raison est mécanique : Googlebot ne scrolle pas et ne clique pas. Il charge la page, exécute le JavaScript dans un délai limité, et prend ce qui est dans le DOM à ce moment-là. Les éléments 25 à 600 d'un rayon, chargés après interaction, n'existent pas pour lui.
La solution n'est pas de renoncer au scroll infini mais de le doubler d'une pagination classique, comme Google le recommande dans sa documentation sur la pagination et le chargement incrémental. Le pattern fonctionne ainsi :
- 1.Des URL paginées existent réellement : /categorie/?page=2, /categorie/?page=3, chacune renvoyant son lot d'éléments en HTML côté serveur.
- 2.Le scroll infini met à jour l'URL : au fil du défilement, l'adresse change via l'History API. L'utilisateur peut recharger, partager, revenir en arrière.
- 3.Un bloc de pagination HTML est présent : en bas de la liste, des liens href vers les pages suivantes. C'est ce bloc que Googlebot suit.
- 4.Le bouton « voir plus » est un vrai lien : son href pointe vers la page suivante ; le JavaScript intercepte le clic pour charger en place, et sans JavaScript le lien fonctionne quand même.
Ce que ce pattern interdit : un « voir plus » sans href, une URL figée pendant tout le défilement, ou des éléments injectés depuis une API JSON que Googlebot ne consulte jamais.
Cas concret : la pagination d'un blog
Prenons un blog de 150 articles répartis en 6 catégories, 12 billets par page. La page /blog/ liste les derniers articles ; chaque catégorie possède sa propre liste paginée.
Ce qui pose problème par défaut : les pages 2 à 13 partagent le même title, le CMS place une canonical vers /blog/ sur toutes, et le bloc de pagination n'affiche que « précédent » et « suivant ». Un article de 2023 est à 11 clics de l'accueil.
La correction, dans l'ordre d'impact :
- •Retirer la canonical vers la page 1 et faire pointer chaque page sur elle-même. Vérifier dans la Search Console que les pages paginées passent de « Google a choisi une URL canonique différente » à « Indexée ».
- •Remplacer « précédent / suivant » par une pagination numérotée avec première, dernière et voisines.
- •Ajouter « page N » dans le title et la meta description.
- •Réduire la dépendance à la pagination : le maillage éditorial (articles liés, « à lire aussi », hubs par thème) doit offrir à chaque article au moins deux chemins d'accès autres que le listing. Un article atteignable uniquement par la page 11 est mal maillé, pagination parfaite ou non.
Le résultat attendu : les articles anciens repassent sous 4 clics et leur fréquence de crawl remonte. Sur un blog, la pagination est un filet de sécurité ; le maillage thématique reste le chemin principal.
Cas concret : la pagination d'une boutique e-commerce
Une boutique propose 1 800 références dans 25 catégories, 24 produits par page, un tri par prix et quatre filtres (taille, couleur, marque, disponibilité). C'est ici que la pagination coûte le plus cher en budget de crawl.
Les trois décisions structurantes :
- 1.Pagination indexable, filtres et tris non indexables. Les pages /chaussures/?page=3 sont des portes vers les produits : indexables, canonical sur elles-mêmes. Les combinaisons /chaussures/?page=3&tri=prix&couleur=rouge ne créent que de la duplication : canonical vers /chaussures/?page=3, ou noindex, et si possible des filtres qui ne génèrent pas d'URL crawlables. Exception : un filtre qui correspond à une vraie intention de recherche (« chaussures rouges ») mérite une page de catégorie dédiée, avec son contenu.
- 2.Produits accessibles autrement que par la pagination. Chaque produit a au moins un lien depuis une sous-catégorie, une page marque ou un bloc « produits similaires ». La pagination seule ne maintient jamais 1 800 fiches à moins de 4 clics.
- 3.Pagination serveur, scroll infini en surcouche. Les pages paginées sont rendues côté serveur avec tous les produits en HTML. Le scroll infini, s'il est souhaité, se greffe dessus selon le pattern décrit plus haut.
Les points de contrôle après mise en ligne : les URL « Explorée, actuellement non indexée » avec paramètres de filtre baissent dans la Search Console ; dans les logs, la part du crawl consommée par les listings recule au profit des fiches produit ; un crawl montre que toutes les fiches en stock sont à moins de 4 clics.
C'est la structure que nous mettons en place dans nos projets de création de site e-commerce : la pagination se décide au moment de l'architecture, pas après la mise en ligne, parce qu'elle conditionne la découverte du catalogue entier.
Les erreurs de pagination qui coûtent le plus cher
Par ordre décroissant de dégâts constatés :
- 1.Canonical de toutes les pages vers la page 1 : des centaines de produits ou d'articles perdent leur seul lien interne reconnu.
- 2.noindex sur les pages 2 et suivantes : même effet, légèrement atténué, souvent recommandé par de vieux articles encore bien positionnés.
- 3.Scroll infini sans URL paginées : seuls les 20 ou 24 premiers éléments existent pour Google.
- 4.Pagination « suivant » seule, ou boutons JavaScript sans href : profondeur de clic égale au numéro de page, ou liens invisibles pour le crawler.
- 5.Paramètres de tri et de filtre crawlables sans canonical : le budget de crawl part dans des combinaisons infinies.
Une seule de ces erreurs suffit à faire chuter l'indexation d'un catalogue. Deux combinées, et la Search Console se remplit de pages « Détectée, actuellement non indexée ».
FAQ : pagination et SEO
Faut-il encore utiliser rel next et rel prev en 2026 ?
Faut-il mettre une canonical vers la page 1 sur les pages paginées ?
Les pages paginées doivent-elles être indexables ?
Le scroll infini est-il mauvais pour le SEO ?
Comment vérifier que ma pagination fonctionne pour Google ?
Paginer, c'est décider ce que Google verra de votre site
La pagination est le sujet le moins visible du SEO technique et l'un de ceux qui pèsent le plus sur l'indexation réelle. Les règles de 2026 sont stables : chaque page paginée est indexable, canonique vers elle-même, reliée aux autres par de vrais liens HTML ; rel next et prev ne sont plus un levier ; le scroll infini et le bouton « voir plus » se greffent sur une pagination serveur, jamais à sa place. Sur un blog, elle sert de filet sous le maillage éditorial. Sur une boutique, elle conditionne la découverte de tout le catalogue.
Votre catalogue ou vos archives disparaissent de l'index sans raison apparente ? Nous auditons votre pagination, vos canonicals et votre profondeur de clic, et nous chiffrons les corrections : demandez un devis.
