Qu'est-ce que la pagination SEO (et pourquoi c'est encore un sujet en 2026)
Dès que tu as plus de contenu qu'une page ne peut en afficher — liste de produits, archive de blog, résultats de recherche interne — tu dois découper. Trois options existent : la pagination classique (/page/2, /page/3), l'infinite scroll, ou un bouton « voir plus ». Le choix n'est pas cosmétique : il détermine si Google (et maintenant les crawlers IA) accède réellement à ton contenu profond.
Beaucoup de sites pensent avoir réglé le sujet en 2015 avec rel=next/prev, ou en 2022 en passant tout en infinite scroll pour le mobile. Les deux approches ont des angles morts qui, en 2026, coûtent du crawl budget, de l'indexation et — nouveau — de la citabilité par les moteurs IA.
Rel=next/prev : l'histoire d'un signal mort
Google a officiellement arrêté d'utiliser rel="next" et rel="prev" comme signal en 2019. Si tu as encore ces balises sur ton site, elles ne font pas de mal — Bing les lit toujours pour la découverte — mais elles ne compensent aucune erreur structurelle. Beaucoup de développeurs pensent encore, à tort, que ces balises « regroupent » les pages paginées en une seule entité de classement. Ce n'est plus le cas depuis sept ans.
Ce qui compte aujourd'hui : que chaque page paginée soit crawlable indépendamment, retourne un code 200, et porte un lien interne réel (pas juste un onclick JavaScript) vers la suivante.
Canonical self-referencing : l'erreur qui tue tes pages profondes
L'erreur la plus fréquente qu'on voit en audit : canonicaliser /page/2, /page/3, etc. vers /page/1. L'intention est louable — éviter le contenu dupliqué — mais l'effet est inverse de celui recherché. Tu dis à Google que ces pages n'ont aucune valeur propre, ce qui pousse Google à réduire leur exploration, voire à ne plus les indexer du tout.
La bonne pratique : canonical self-referencing. Chaque page paginée pointe vers elle-même. /page/2 canonicalise vers /page/2, pas vers /page/1. C'est contre-intuitif si tu viens du monde du contenu dupliqué au sens strict, mais une série paginée n'est pas un doublon : chaque page contient des éléments distincts.
Pagination vs infinite scroll vs « voir plus »
| Critère | Pagination classique | Infinite scroll | Bouton « voir plus » |
|---|---|---|---|
| Crawlabilité par défaut | Bonne (si liens réels) | Mauvaise (JS + scroll) | Mauvaise (JS + clic) |
| Accès au footer | Oui | Non (repoussé en continu) | Oui (si URL statique) |
| Expérience mobile | Correcte | Très bonne | Bonne |
| Risque de contenu fin | Élevé si peu d'items/page | Faible | Moyen |
| Simplicité de mise en œuvre SEO-friendly | Élevée | Faible (nécessite pushState) | Moyenne |
Le tableau résume l'arbitrage. Aucune option n'est mauvaise en soi ; le problème vient toujours d'une implémentation qui ne pense qu'à l'utilisateur humain et oublie le crawler.
Infinite scroll : pourquoi Googlebot (et les bots IA) ne scrollent pas
Googlebot rend les pages avec un moteur headless, mais il ne simule pas un scroll utilisateur jusqu'en bas d'un flux infini. S'il faut un événement de scroll pour déclencher le chargement du contenu suivant, Googlebot ne verra que le premier lot d'éléments. Conséquence directe : tout ce qui se trouve après le troisième ou quatrième « batch » de contenu n'est simplement jamais exploré.
Le footer devient lui aussi difficile d'accès : dès que l'utilisateur — ou le crawler simulé — s'approche du bas de page, du nouveau contenu se charge et repousse le footer. Chaque lien de navigation, chaque signal de confiance placé en pied de page devient inatteignable.
Rendre l'infinite scroll crawlable
La solution qui fonctionne en 2026 : découper le flux infini en blocs, chaque bloc correspondant à une URL propre avec ses propres balises meta, et utiliser l'API History (pushState) pour que l'URL change réellement quand l'utilisateur scrolle. Concrètement, tu sers en parallèle une version paginée server-side (accessible sans JS) et une expérience infinite scroll côté client pour l'utilisateur humain. C'est la même logique de rendu hybride qu'on retrouve sur les problématiques de rendu JavaScript SSR/SSG/CSR : le crawler doit pouvoir accéder au contenu sans exécuter d'interaction utilisateur.
Pages « voir tout » (view-all) : bonne ou mauvaise idée ?
Une page qui liste tous les éléments sur une seule URL peut sembler être la solution miracle : plus de pagination, plus de canonical à gérer. Le problème apparaît au-delà de quelques centaines d'éléments : temps de chargement qui explose, Core Web Vitals dégradés, et une page si longue que ni l'utilisateur ni le crawler n'en extraient une hiérarchie claire.
Notre recommandation en audit : garder le view-all pour des séries de moins de 200 éléments avec un chargement optimisé (lazy-load des images, pas du contenu texte), et repasser en pagination classique au-delà.
L'angle GEO : ce que voient (ou ne voient pas) les crawlers IA
C'est le point que la plupart des guides SEO classiques passent sous silence. GPTBot, ClaudeBot et PerplexityBot n'exécutent pas de JavaScript lors de leur passe de crawl. Un infinite scroll qui dépend entièrement du JS pour charger le contenu au-delà de la première page est donc invisible pour ces bots — exactement comme pour un navigateur avec JS désactivé.
Concrètement : si ton catalogue produit ou ton centre de ressources repose sur de l'infinite scroll pur, seuls les 15 à 20 premiers éléments existent aux yeux des moteurs de réponse IA. Le reste de ton contenu — souvent le plus spécifique, le plus susceptible d'être cité pour une requête de longue traîne — est structurellement invisible pour ChatGPT, Perplexity ou les AI Overviews de Google. Une pagination server-side classique, elle, reste accessible : chaque page a sa propre URL, son propre contenu extractible.
Mini cas chiffré
Sur un audit récent pour un site e-commerce de ~3 400 références réparties sur des catégories en infinite scroll pur, on a mesuré via Search Console que seules les 60 premières fiches produit de chaque catégorie généraient des impressions organiques — soit environ 4 % du catalogue. Après passage en pagination server-side avec canonical self-referencing (6 semaines de mise en œuvre), le nombre de pages produit indexées a été multiplié par 5, et le trafic organique sur les catégories concernées a progressé de 22 % sur les deux mois suivants. Le simple fait de rendre les pages profondes crawlables — sans aucun autre changement de contenu — a suffi.
Checklist : les erreurs fréquentes à éviter
- Canonicaliser toutes les pages paginées vers la page 1
- Bloquer les pages /page/2 et suivantes via
robots.txten pensant « limiter le contenu dupliqué » - Servir un infinite scroll sans URLs paginées server-side en parallèle
- Oublier de mettre à jour l'URL (pushState) quand le contenu change en infinite scroll
- Avoir moins de 10 items par page paginée (contenu trop fin)
- Ne pas inclure de lien direct vers la première et la dernière page dans le bloc de pagination
FAQ
Faut-il encore ajouter rel=next/prev en 2026 ? Non, ce n'est plus nécessaire pour Google. Si les balises existent déjà, inutile de les retirer, mais ne les ajoute pas sur un nouveau projet — concentre l'effort sur les liens internes réels et le canonical self-referencing.
L'infinite scroll est-il définitivement à éviter ? Non, mais il doit toujours être doublé d'une pagination server-side accessible sans JavaScript, avec des URLs distinctes par bloc de contenu.
Combien d'items par page pagination pour éviter le contenu fin ? Il n'y a pas de règle universelle, mais en dessous de 10-15 éléments avec peu de texte associé, le risque de contenu jugé « thin » par Google augmente nettement.
Faut-il désindexer (noindex) les pages paginées au-delà de la page 3 ? Rarement une bonne idée : ça revient à sacrifier volontairement du contenu potentiellement pertinent. Mieux vaut travailler la profondeur de clic et le maillage interne vers ces pages.
À retenir
La pagination reste un sujet technique à part entière en 2026, avec un enjeu supplémentaire : la lisibilité par les crawlers IA qui n'exécutent pas de JavaScript. Canonical self-referencing, pagination server-side même quand tu affiches de l'infinite scroll côté utilisateur, et un maillage interne clair vers les pages profondes : ce sont les trois leviers qui évitent de perdre du crawl budget et de la citabilité GEO. Pour vérifier où en est ton propre site, obtiens ton score /100 — l'audit détecte automatiquement les pages paginées mal canonicalisées et les zones de contenu invisibles pour les crawlers IA. Tu peux aussi consulter le rapport complet PDF pour un plan d'action détaillé.