Faut-il vraiment masquer le contenu cumulatif des paginations infinies à Google ?

Pourquoi Google insiste-t-il sur la séparation du contenu par page ?

La déclaration de Martin Splitt vise un problème précis : quand une pagination infinie charge dynamiquement tous les items dans une seule URL, Google peine à découvrir et indexer les contenus profonds. Le bot voit une seule page qui cumule 200 produits, alors que l'URL affiche ?page=1.

Dans ce cas, l'algorithme peut décider que toutes les pages paginées sont des doublons de la première et appliquer une balise canonical implicite. Résultat : les items 101-200 ne sont jamais indexés, car Google ne crawle jamais les URLs ?page=11 à ?page=20.

Qu'est-ce que ça change pour une pagination en JavaScript ?

Beaucoup de sites modernes utilisent une pagination infinie côté client : au scroll, un appel fetch() charge les items suivants et les injecte dans le DOM. C'est fluide pour l'utilisateur, mais catastrophique pour le crawl si le code HTML initial ne contient que les 10 premiers items.

Google recommande donc de maintenir une double logique : servir une pagination classique avec des URLs distinctes (?page=2, ?page=3) au bot, tout en offrant une expérience cumulative en JavaScript côté client. Techniquement, cela passe par une détection user-agent ou par une architecture SSR qui génère des pages statiques paginées.

Comment Google détecte-t-il le contenu « unique » d'une page ?

Le moteur analyse le HTML brut servi par le serveur, avant tout rendu JavaScript. Si /produits?page=2 retourne exactement le même contenu HTML que /produits?page=1 parce que le JS charge tout dynamiquement, Google conclut qu'il s'agit d'un doublon.

En revanche, si ?page=2 contient dans son HTML initial uniquement les items 11-20, le bot identifie un contenu distinct et indexe cette URL séparément. C'est ce signal de contenu unique qui empêche la canonicalisation automatique.

• Chaque page paginée doit avoir son propre lot d'items dans le HTML initial, avant tout chargement JS
• Une pagination infinie sans URLs distinctes ou sans SSR risque de cannibaliser l'indexation
• La balise rel="next" / rel="prev" n'est plus officiellement supportée, mais la logique reste valable : Google crawle les pages suivantes uniquement si elles existent côté serveur
• Les sites e-commerce avec des milliers de produits doivent arbitrer entre UX fluide et crawlabilité — ou implémenter les deux en parallèle

Cette recommandation est-elle vraiment nouvelle ou simplement mal appliquée ?

Soyons honnêtes : Google répète cette consigne depuis des années. Mais l'adoption massive de React, Vue, et autres SPA a rendu le problème plus aigu. Beaucoup de devs front-end implémentent des paginations infinies sans se soucier du crawl, et découvrent six mois plus tard que 80 % de leur catalogue n'est pas indexé.

Ce qui est intéressant ici, c'est que Martin Splitt assume explicitement le découplage UX / bot. Pendant longtemps, Google prétendait que Googlebot rendait le JavaScript « comme un vrai navigateur ». Mais la réalité terrain montre que le budget de rendu JS est limité, et que les sites qui comptent dessus pour la pagination se font régulièrement ignorer.

Quels sont les cas où cette règle ne s'applique pas strictement ?

Si tu as un blog avec 30 articles au total, une pagination infinie ne pose aucun problème — Google crawlera les 30 URLs de toute façon. Le risque apparaît dès que tu dépasses quelques centaines d'items et que les pages profondes (?page=15+) ne reçoivent jamais de crawl.

De même, certains sites utilisent une pagination hybride : les 5 premières pages sont servies en SSR classique, puis un infinite scroll prend le relais. C'est un compromis acceptable si les items critiques (top ventes, nouveautés) sont dans les premières pages. [A vérifier] — Google n'a jamais publié de seuil officiel de profondeur de crawl pour la pagination, mais les observations terrain montrent un drop-off marqué après 10-15 pages si le maillage interne est faible.

Y a-t-il une contradiction avec la gestion des facettes et filtres ?

Oui, et c'est un vrai casse-tête. Google recommande de limiter le crawl des URLs de filtres (couleur, taille, prix) pour ne pas gaspiller le crawl budget, mais en même temps d'exposer toutes les pages de pagination. La logique : la pagination est une séquence linéaire nécessaire pour accéder au contenu profond, alors que les facettes créent une explosion combinatoire d'URLs souvent redondantes.

Concrètement, tu peux bloquer /produits?couleur=rouge&taille=M en robots.txt ou via noindex, tout en laissant /produits?page=8 ouvert. Mais attention : si un produit n'apparaît que dans une combinaison de filtres + pagination profonde, il risque de ne jamais être crawlé. Dans ce cas, un sitemap XML bien structuré devient indispensable.

Comment auditer l'état actuel de ta pagination ?

Commence par un crawl Screaming Frog ou Oncrawl en simulant Googlebot (user-agent, respect du robots.txt, rendu JS désactivé dans un premier temps). Compare le nombre d'URLs paginées découvertes avec le nombre total théorique. Si tu as 500 produits et 50 par page, tu dois voir 10 URLs ?page=X dans le crawl.

Ensuite, ouvre Search Console et filtre les URLs indexées contenant le paramètre de pagination. Si tu vois seulement ?page=1 et ?page=2 alors que tu en as 20, c'est que Google ne crawle pas au-delà. Vérifie aussi les rapports de couverture : les pages profondes sont-elles marquées « Détectées, actuellement non indexées » ? Si oui, c'est un signal de manque de PageRank interne ou de contenu jugé trop similaire.

Quelle architecture technique privilégier pour concilier UX et SEO ?

La solution la plus robuste reste le Server-Side Rendering (SSR) avec des URLs paginées classiques. Next.js, Nuxt, ou même du PHP/Python côté serveur permettent de générer des pages HTML distinctes pour chaque numéro de page. L'expérience utilisateur reste fluide grâce à des transitions JS, mais le bot reçoit un HTML complet.

Si tu es bloqué avec une SPA full client-side, implémente une détection user-agent : sers une version paginée statique à Googlebot, et la version infinite scroll aux vrais utilisateurs. C'est techniquement du cloaking, mais Google l'autorise explicitement si le contenu reste identique — seule la navigation diffère. Documente cette logique dans ton fichier de spécifications techniques pour éviter les malentendus avec l'équipe de développement.

Quelles erreurs techniques provoquent le plus souvent une canonicalisation non désirée ?

Première erreur classique : oublier de mettre une balise canonical auto-référente sur chaque page paginée. Si /produits?page=3 n'a pas de <link rel="canonical" href="/produits?page=3">, Google peut décider arbitrairement de la canonicaliser vers /produits.

Deuxième piège : les paramètres d'URL mal configurés dans Search Console. Si tu as défini page comme paramètre de tri plutôt que de pagination, Google peut ignorer ces URLs. Va dans Paramètres d'URL (section Exploration) et vérifie que page est bien marqué comme « Paginate » — même si Google a officiellement déprécié cet outil, certaines configurations héritées restent actives.

Troisième erreur : ne pas maintenir la cohérence du contenu. Si ?page=2 affiche les items 11-20 aujourd'hui, mais 15-24 demain à cause d'un tri dynamique ou de l'ajout de nouveaux produits, Google peut considérer le contenu comme instable et le désindexer. Dans ce cas, ajoute un paramètre de tri fixe dans l'URL (?sort=date&page=2) pour garantir la reproductibilité.

• Vérifier que chaque ?page=X retourne un HTML initial distinct, même sans JS
• Ajouter une balise rel="canonical" auto-référente sur toutes les pages paginées
• Crawler le site avec JS désactivé pour simuler le comportement de Googlebot
• Comparer le nombre d'URLs paginées indexées dans Search Console avec le nombre théorique
• Implémenter un sitemap XML paginé si le crawl naturel ne couvre pas toutes les pages
• Monitorer les pages « Détectées, non indexées » dans Search Console — c'est souvent un signe de canonicalisation implicite