La pagination reste un des sujets où je vois le plus de croyances périmées tourner en boucle. Combien de fois j'ai relu un audit qui recommandait encore de poser du rel=prev/next partout, comme si on était toujours en 2015. Google a abandonné ce signal pour l'indexation en 2019, et il l'ignorait déjà bien avant. Donc si votre stratégie de pagination repose là-dessus, vous bâtissez sur du sable.
Le vrai problème n'a jamais été le balisage. Il est dans la façon dont Googlebot découvre vos pages. Et là, scroll infini ou pagination numérotée, les règles sont les mêmes : ça se crawle par les liens, pas par la magie.
Googlebot ne scrolle pas, ne clique pas#
Le point que je martèle à chaque revue technique : Googlebot crawle via les liens <a href>, et c'est tout. Il ne simule pas le scroll. Il ne clique pas vos boutons JavaScript. Un bouton "Charger plus" qui injecte du contenu sans changer d'URL, pour le bot, ça n'existe pas. Le contenu derrière reste invisible à la découverte.
C'est pour ça qu'un scroll infini monté à la va-vite, sans URL paginées dessous, finit en cul-de-sac. Le contenu n'est pas crawlé, donc pas indexé. Vous avez beau avoir des milliers de fiches produit qui défilent quand l'humain scrolle, si chacune n'est pas atteignable par un <a href> quelque part, Google n'en saura rien.
Une nuance honnête, parce que je déteste les certitudes absolues sur ce terrain. Depuis juillet 2024, Google tente le rendu JavaScript sur toutes les pages crawlées. Donc du contenu injecté en JS peut, parfois, être capturé. Sauf que ce rendu peut être différé de plusieurs jours à plusieurs semaines, et surtout la découverte reste non fiable sans URL paginée. Je ne parierais pas l'indexation de mon catalogue là-dessus. Dire "infinite scroll = invisible pour Googlebot" était vrai au sens strict ; aujourd'hui c'est plus subtil, mais l'absence d'URL crawlable reste le tueur silencieux.
Le canonical, là où ça dérape le plus souvent#
Erreur classique que je débusque dans presque chaque audit e-commerce : chaque page paginée qui pointe son canonical vers la page 1. C'est faux et ça vous flingue l'indexation des pages profondes.
Chaque page paginée doit avoir un canonical vers elle-même. La page 2 se canonicalise vers la page 2. La page 7 vers la page 7. Ce sont des pages distinctes, avec un contenu distinct, et Google doit les traiter comme telles. Si vous les renvoyez toutes vers la page 1, vous dites à Google que seule la page 1 compte, et le reste du listing disparaît des radars.
Le seul cas où une page paginée canonicalise vers autre chose, c'est le pattern View-All. Là, vous avez une page unique qui agrège tout le contenu du listing, et les pages paginées canonicalisent vers cette page agrégée. C'est cohérent : vous dites à Google "la vraie version, c'est celle qui contient tout". Mais ça suppose que la page View-All charge raisonnablement vite, sinon vous échangez un problème d'indexation contre un problème de performance, et là on retombe sur les Core Web Vitals.
La recette Google pour un scroll infini crawlable#
Google a documenté une approche propre, et elle a le mérite d'être simple : le paginate-and-scroll. L'idée, fragmenter votre flux infini en "component pages", chacune avec sa propre URL propre, accessible sans JavaScript.
Concrètement, l'expérience humaine reste le scroll fluide. Mais sous le capot, pendant que l'utilisateur descend, l'URL doit refléter le contenu visible. C'est là qu'intervient pushState, que Google recommande : quand le visiteur passe de la zone "page 2" à la zone "page 3", l'URL bascule vers celle de la component page correspondante. Le bot, lui, attaque directement ces URL via leurs liens.
Et le liant de tout ça, encore une fois, ce sont les <a href>. Chaque page paginée doit lier la suivante via un <a href> réel. C'est ce fil de liens qui permet à Googlebot de remonter toute la profondeur du listing, page après page. Sans ce chaînage, le bot s'arrête à la première page.
Un piège à éviter absolument : le fragment identifier du type #page=2. Pour la pagination, Google l'ignore purement et simplement. Tout ce qui suit le # n'est pas une URL distincte à ses yeux. Si votre scroll infini repose sur des ancres, vous n'avez aucune pagination crawlable, juste une seule URL qui ne mène nulle part côté découverte.
Profondeur, budget de crawl et faux amis#
Il y a un effet de bord que les gens sous-estiment. Une pagination profonde sans bon maillage interne, c'est un problème de crawl depth. Googlebot a un budget de crawl, et s'il doit traverser quarante pages de listing en file indienne pour atteindre la page 41, le budget peut s'épuiser avant. Les pages profondes ne sont jamais visitées. Je creuse ce mécanisme dans mon article sur le crawl budget, parce que c'est exactement là que pagination et économie de crawl se télescopent.
Deux distinctions que je tiens à poser, parce qu'on mélange tout. La pagination numérotée, c'est du contenu légitime à indexer. À ne pas confondre avec les URL de filtres et de tri, du genre ?order=price, qui génèrent des doublons de listing. Sur celles-là, le réflexe sain, c'est le noindex pour éviter de noyer Google sous des variations quasi identiques. Confondre les deux et balancer du noindex sur votre pagination numérotée, c'est l'autodestruction.
Autre cas à part : la pagination des commentaires. Traitement distinct, impact SEO moindre. Ne lui appliquez pas la même rigueur qu'à un listing produit, vous vous compliquez la vie pour rien.
Sur la question de savoir si Google reconnaît tout seul les patterns de pagination depuis l'abandon de rel=prev/next, je reste prudent. C'est une idée répandue, mais je ne l'ai vue documentée nulle part officiellement. Donc je ne construis pas dessus. Je m'appuie sur ce qui est sûr : des liens <a href> propres, des canonical autoréférentiels, des URL crawlables. Le reste, c'est de l'espoir, et l'espoir n'indexe pas.
Ce que je vérifie en priorité#
Quand je débarque sur un site avec un souci de pagination, mon ordre de passage est toujours le même. D'abord, est-ce que les pages profondes sont atteignables par un <a href> ? Ensuite, est-ce que chaque page paginée se canonicalise vers elle-même ? Puis, est-ce que le scroll infini, s'il y en a un, repose sur des component pages avec de vraies URL et non sur des #fragments ? Enfin, est-ce que le budget de crawl tient la profondeur ?
Tout ça tourne autour d'une seule idée : rendre le contenu découvrable par le bot tel qu'il fonctionne réellement, pas tel qu'on aimerait qu'il fonctionne. Le rendu JavaScript de Googlebot s'est étendu, ce qui aide, mais ne dispense de rien. Si vous voulez creuser comment le rendu JS change la donne côté découverte et indexation, j'en parle dans mon papier sur le rendu JavaScript et le SEO. Et pour relier tout ça aux fondamentaux de découverte, l'article sur la crawlabilité et l'indexation pose les bases.
La pagination, ce n'est pas un sujet sexy. Mais c'est souvent elle qui décide si la moitié de votre catalogue existe pour Google, ou pas.
