Pages paginées non indexées : stratégies modernes de pagination pour Google
Google a déprécié rel=prev/next et ton contenu paginé est sorti de l'index. Découvre les stratégies modernes de pagination qui fonctionnent avec le comportement actuel d'indexation de Google.
Dans ce guide
La pagination est partout sur le web. Les archives de blog, les pages de catégorie e-commerce, les listings de résultats de recherche, les index de fils de discussion de forum, les archives d'actualités et les galeries d'images utilisent toutes la pagination pour diviser de grands ensembles de contenu en pages gérables. Pendant des années, l'approche standard était d'implémenter des balises rel=prev et rel=next pour dire à Google qu'un ensemble de pages formait une série paginée. Google comprenait alors la relation et consolidait les signaux d'indexation de manière appropriée.
En mars 2019, Google a confirmé qu'il n'utilisait plus rel=prev/next comme signal d'indexation depuis des années. Cette annonce a pris l'industrie SEO au dépourvu parce que de nombreux sites avaient construit toute leur stratégie de pagination autour de ces balises. L'impact pratique a été immédiat : sans rel=prev/next, Google traite chaque page paginée comme une page indépendante et autonome plutôt que comme une partie d'une série connectée.
Ce changement signifie que la page 2 de ton archive de blog est évaluée par Google entièrement sur ses propres mérites. Si la page 2 affiche une liste d'extraits d'articles de blog sans contenu introductif unique, sans en-tête unique et sans contexte expliquant de quoi parle la page, Google voit une page thin avec des extraits de contenu recyclés. Il ne devrait pas être surprenant que Google choisisse souvent de ne pas indexer ces pages.
Les conséquences vont au-delà des pages paginées elles-mêmes. Le contenu qui n'apparaît que sur des pages de pagination plus profondes devient plus difficile à découvrir pour Google. Si un produit ou un article de blog n'est pas mis en avant sur la page 1 d'un listing et n'est lié depuis nulle part ailleurs, il peut effectivement devenir orphelin et Google peut ne jamais l'explorer. Cela fait de la pagination non seulement un problème de page de listing mais un problème de découverte de contenu pour tout ton site.
Ce guide couvre les stratégies modernes de pagination qui fonctionnent avec le comportement actuel d'indexation de Google, traite les défis spécifiques de l'infinite scroll et des patterns Load More, et fournit des corrections concrètes pour récupérer le contenu perdu quand rel=prev/next a cessé de fonctionner.
Ce qui a changé quand Google a déprécié rel=prev/next
Pour comprendre l'état actuel de l'indexation de la pagination, il est utile de savoir ce que rel=prev/next était censé faire et ce que Google fait réellement maintenant.
Rel=prev/next était un ensemble d'éléments link HTML qui disaient à Google qu'une série de pages étaient connectées comme une séquence paginée. L'intention était que Google consolide les pages et comprenne que la page 1, la page 2, la page 3, et ainsi de suite, formaient un ensemble continu. En théorie, Google traitait la série comme une seule entité logique, consolidant l'équité de lien et potentiellement n'affichant que la première page dans les résultats de recherche tout en comprenant que le contenu se poursuivait sur les pages suivantes.
Quand Google a révélé qu'il n'avait pas utilisé ces signaux depuis des années, l'implication était claire : Google s'était appuyé sur d'autres signaux pour comprendre la pagination. Ces signaux incluent les patterns d'URL (Google peut détecter les patterns de pagination courants comme ?page=2 ou /page/2/), les structures de liens internes (les liens séquentiels entre les pages suggèrent une pagination), et l'analyse de contenu (les pages avec des templates similaires et différents sous-ensembles de contenu suggèrent une liste paginée).
Le changement pratique de comportement est que Google évalue désormais chaque page paginée indépendamment. La page 1 de ta catégorie avec un paragraphe introductif unique, de forts liens internes et 20 produits mis en avant peut être indexée. La page 2, qui affiche les 20 produits suivants sans contenu unique, est évaluée comme une page autonome et peut ne pas être indexée parce qu'elle n'offre pas assez de valeur unique à elle seule.
Cette évaluation indépendante signifie que les pages paginées au-delà de la page 1 sont rarement indexées sauf si elles ont une proposition de valeur unique. Les éléments listés sur la page 2 sont différents de la page 1, mais le template, la navigation, les méta-informations et la structure générale sont identiques. Du point de vue de Google, la page 2 est une variation thin de la page 1.
La perte de la consolidation rel=prev/next signifie aussi que l'équité de lien n'est plus consolidée à travers les pages paginées. Avant, un backlink pointant vers la page 3 de ta catégorie aurait pu bénéficier à toute la série paginée. Maintenant, cette équité de lien reste sur la page 3 seule. Si la page 3 n'est pas indexée, l'équité de lien est effectivement gaspillée.
La recommandation actuelle de Google pour la pagination est de s'assurer que les pages de contenu individuelles importantes (produits, articles, posts) soient directement liables depuis ton sitemap et depuis d'autres pages de ton site, plutôt que de dépendre de la pagination comme seul chemin de découverte. La pagination est désormais principalement une fonctionnalité d'expérience utilisateur plutôt qu'une fonctionnalité SEO.
Infinite scroll : le problème du contenu invisible
L'infinite scroll remplace la pagination traditionnelle par un pattern où le nouveau contenu se charge automatiquement quand l'utilisateur fait défiler la page vers le bas. Les utilisateurs vivent un flux fluide et sans fin. D'un point de vue SEO, l'infinite scroll est l'un des patterns de pagination les plus problématiques parce que le crawler de Google ne fait pas défiler.
Quand Googlebot charge une page avec infinite scroll, il traite le HTML initial et tout contenu rendu par JavaScript qui apparaît au premier chargement. Il ne déclenche pas d'événements de défilement, ce qui signifie que tout contenu qui se charge quand l'utilisateur fait défiler au-delà d'un certain seuil est complètement invisible pour Google. Si ta page de catégorie affiche 20 produits au chargement initial avec infinite scroll pour les 200 produits restants, Google ne voit que 20 produits.
Cela a des conséquences sévères pour la découverte de contenu. Les produits ou articles qui n'apparaissent que via infinite scroll n'ont aucun chemin de crawl depuis la page de catégorie. S'ils ne sont pas liés depuis d'autres pages ou inclus dans le sitemap, Google peut ne jamais les découvrir. Même s'ils sont dans le sitemap, la page de catégorie elle-même ne fournit pas le lien interne vers ces éléments, affaiblissant leur importance perçue.
La correction recommandée est d'implémenter l'infinite scroll en parallèle avec des URLs paginées traditionnelles. Cette approche hybride fournit l'expérience utilisateur fluide de l'infinite scroll tout en donnant à Google des pages paginées explorables avec de vraies URLs. L'implémentation fonctionne ainsi : crée des URLs paginées traditionnelles (/category/page/2/, /category/page/3/) qui affichent les mêmes ensembles de contenu que chaque segment d'infinite scroll. Quand un utilisateur fait défiler et que du nouveau contenu se charge, utilise l'API History pour mettre à jour l'URL du navigateur vers l'URL paginée correspondante. Si l'utilisateur rafraîchit ou partage l'URL, il voit la version paginée avec le contenu jusqu'auquel il avait défilé.
Google recommande spécifiquement cette approche pushState pour l'infinite scroll. Les URLs paginées servent de points d'ancrage que Google peut explorer, tandis que l'infinite scroll fournit l'expérience utilisateur attendue par tes visiteurs. Sans les URLs paginées sous-jacentes, l'infinite scroll cache entièrement à Google tout le contenu au-delà du premier ensemble visible.
Une approche alternative pour les ensembles de contenu plus petits est de charger tout le contenu sur une seule page sans aucune pagination ou chargement basé sur le défilement. Si ta catégorie a 50 produits ou moins, rendre tous ces produits sur une seule page élimine entièrement le problème de pagination. Cette approche n'est pas viable pour les catégories avec des centaines ou des milliers d'éléments en raison des contraintes de performance, mais elle fonctionne bien pour les collections plus petites.
Boutons Load More : mieux que l'infinite scroll, mais toujours problématiques
Les boutons Load More sont un terrain intermédiaire entre la pagination traditionnelle et l'infinite scroll. L'utilisateur voit un ensemble initial de contenu et clique sur un bouton pour charger du contenu supplémentaire sur la même page. D'un point de vue d'expérience utilisateur, Load More est souvent préféré à la pagination traditionnelle parce qu'il garde l'utilisateur sur la même page et maintient la position de défilement.
Cependant, les boutons Load More ont le même problème SEO fondamental que l'infinite scroll : Google ne clique pas sur les boutons. Le contenu chargé par un bouton Load More est déclenché par un événement de clic, et le renderer de Google ne simule pas les interactions de clic. Le contenu derrière le bouton Load More est invisible pour Google sauf si des mesures spécifiques sont prises.
La correction reflète la solution de l'infinite scroll : implémente des URLs paginées traditionnelles à côté de la fonctionnalité Load More. Chaque segment Load More devrait correspondre à une URL paginée explorable. Inclus des liens vers ces URLs paginées quelque part dans le HTML (ils peuvent être cachés du design visuel en utilisant CSS) pour que Google puisse les découvrir et les explorer. Certaines implémentations placent les liens paginés dans une balise noscript afin qu'ils soient disponibles pour les crawlers qui n'exécutent pas JavaScript pendant que le bouton Load More apparaît pour les navigateurs avec JavaScript activé.
Une autre approche consiste à rendre le contenu Load More dans la réponse HTML initiale mais à le cacher visuellement avec CSS. Quand l'utilisateur clique sur Load More, JavaScript révèle le contenu caché plutôt que de le récupérer depuis le serveur. Cette approche garantit que Google voit tout le contenu dans le HTML initial sans avoir besoin d'interagir avec aucun bouton. Cependant, cela ne fonctionne que pour des quantités modérées de contenu caché (charger 200 produits dans du HTML caché augmente significativement le poids de la page et le temps de chargement).
Une troisième approche consiste à implémenter Load More avec des URLs paginées qui se chargent progressivement. La page initiale se charge avec le premier ensemble de contenu et un bouton Load More. Cliquer sur le bouton utilise AJAX pour récupérer et afficher le prochain ensemble de contenu et met simultanément à jour l'URL vers la prochaine page paginée (/page/2/). Chaque URL paginée rend son ensemble de contenu spécifique côté serveur, donc Google peut explorer /page/2/ directement et voir ce contenu sans avoir besoin de cliquer sur aucun bouton. Le bouton Load More est une amélioration progressive pour les utilisateurs, tandis que la structure d'URL paginée sous-jacente est la fondation explorable pour Google.
Stratégie des balises canonical pour les séries paginées
Les balises canonical sur les pages paginées sont l'un des sujets les plus débattus en SEO technique. La question est de savoir si la page 2, la page 3 et les pages suivantes devraient avoir des balises canonical pointant vers la page 1 ou si chaque page devrait avoir une canonical auto-référencée.
Faire pointer toutes les pages paginées vers la page 1 comme canonical dit à Google que la page 1 est la version définitive et que les autres pages sont secondaires. Cette approche est appropriée quand tu ne veux pas ou n'as pas besoin que les pages plus profondes soient indexées et quand tous les éléments individuels sont découvrables par d'autres moyens (sitemap, liens directs). L'avantage est la simplicité : Google n'indexe que la page 1, et tu ne t'inquiètes pas des problèmes de thin content sur les pages plus profondes. Le risque est que les éléments n'apparaissant que sur les pages plus profondes peuvent perdre les signaux de liens internes du listing paginé.
Les canonicals auto-référencées sur chaque page paginée disent à Google que chaque page est sa propre entité distincte. Cette approche est appropriée quand chaque page paginée cible un contenu différent ou quand tu veux que Google indexe toutes les pages de la série. L'avantage est que chaque page conserve sa propre équité de lien et peut potentiellement apparaître dans les résultats de recherche. Le risque est que Google peut voir les pages plus profondes comme du thin content et choisir de ne pas les indexer de toute façon.
La recommandation pragmatique pour la plupart des sites est une approche hybride. La page 1 obtient une canonical auto-référencée et ton effort d'optimisation (contenu introductif unique, balises meta appropriées, éléments mis en avant). Les pages 2 à 5 obtiennent des canonicals auto-référencées mais sont traitées comme secondaires (priorité d'optimisation plus faible, acceptation que certaines peuvent ne pas être indexées). Les pages 6 et au-delà obtiennent des balises canonical pointant vers la page 1 parce qu'un contenu à cette profondeur est peu susceptible d'être indexé sur ses propres mérites et le crawl budget est mieux dépensé ailleurs.
Quelle que soit la stratégie canonical, assure-toi que chaque page d'élément individuel (produit, post, article) soit incluse dans ton sitemap XML avec une URL directe. Le sitemap fournit un chemin de découverte indépendant qui ne dépend pas de la pagination. Même si Google n'indexe jamais la page 7 de ta catégorie, les produits qui apparaissent sur la page 7 peuvent toujours être découverts et indexés via le sitemap.
Impact de la pagination profonde sur le crawl budget
La pagination profonde, où un listing de contenu s'étend sur des dizaines ou des centaines de pages, est l'un des drains de crawl budget les plus significatifs sur les sites web riches en contenu. Chaque page paginée est une URL que Google peut tenter d'explorer, d'évaluer et potentiellement d'indexer. Un site avec 100 catégories, chacune avec 20 pages de pagination, génère 2 000 URLs de listing paginées en plus des URLs de pages de contenu réelles.
L'ordonnanceur de crawl de Google doit décider comment allouer ses ressources de crawl limitées à travers toutes ces URLs. Quand les pages de listing paginées sont plus nombreuses que les pages de contenu réelles, Google peut dépenser la majeure partie de son crawl budget sur les pages de listing plutôt que sur le contenu que tu veux réellement indexer. C'est particulièrement problématique pour les sites e-commerce où les pages de produits sont le contenu générateur de revenus, mais Google passe son temps à explorer et ré-explorer la pagination des listings de catégorie.
Le signal diagnostique pour le gaspillage de crawl budget de pagination se trouve dans les statistiques de crawl de Google Search Console. Si tu vois un volume élevé de pages explorées mais un faible pourcentage de pages indexées, le gonflement de la pagination peut en être la cause. Exporte les URLs que Google explore le plus fréquemment et vérifie quel pourcentage sont des URLs de listing paginées par rapport aux pages de contenu réelles.
Plusieurs stratégies réduisent l'impact de la pagination profonde sur le crawl budget. Premièrement, limite la profondeur de la pagination explorable. Utilise robots.txt pour bloquer l'exploration des pages paginées au-delà d'une certaine profondeur (par exemple, bloque /page/6/ et plus profond). Alternativement, ajoute des balises noindex,follow aux pages profondes pour que Google ne les indexe pas mais puisse toujours suivre les liens vers les éléments individuels. Deuxièmement, réduis le nombre d'éléments par page pour réduire la profondeur totale de pagination. Afficher 50 éléments par page au lieu de 20 transforme une catégorie de 20 pages en une catégorie de 8 pages. Troisièmement, implémente une page Voir Tout pour les catégories où le poids de la page le permet, éliminant entièrement la pagination.
Pour la pagination dynamique qui change fréquemment (nouveaux produits ajoutés quotidiennement, éléments tendance remaniés), garde ton sitemap comme mécanisme principal de découverte plutôt que de te fier à la pagination. Le sitemap fournit une liste complète de toutes les URLs de contenu individuelles que Google peut explorer à son propre rythme, indépendamment de la façon dont ces URLs apparaissent dans les listings paginés un jour donné.
Une autre technique consiste à prioriser le crawl budget vers la page 1 de chaque catégorie en renforçant les liens internes vers la page 1 et en affaiblissant les liens vers la pagination plus profonde. La navigation de ton site lie à la page 1 de chaque catégorie. Les liens internes depuis les articles de blog et autre contenu pointent vers la page 1. Les sections de produits ou d'articles mis en avant sur la page d'accueil lient à la page 1. Ces forts liens internes signalent à Google que la page 1 est l'URL de listing la plus prioritaire pour chaque catégorie.
Guide étape par étape
Auditer l'implémentation actuelle de la pagination sur ton site
Explore ton site et identifie tous les patterns d'URL paginées. Les patterns courants incluent /page/2/, ?page=2, /p2 et ?start=20. Compte le nombre total d'URLs de listing paginées par rapport aux URLs de pages de contenu réelles. Vérifie quelles pages paginées sont actuellement indexées en utilisant l'opérateur « site: » avec les patterns d'URL de pagination. Identifie quelles catégories ou sections ont la pagination la plus profonde. Documente le comportement actuel des balises canonical, les règles robots.txt et le statut noindex pour les pages paginées. Cet audit de référence révèle l'étendue de ton problème de pagination et guide la priorisation.
Vérifier les chemins de découverte de contenu au-delà de la pagination
Assure-toi que chaque page de contenu individuelle (produit, article, post) soit découvrable via au moins un chemin autre que la pagination. Vérifie que toutes les URLs de contenu sont dans ton sitemap XML. Vérifie que les pages de contenu reçoivent des liens internes depuis d'autres contenus (sections de produits connexes, sections d'articles connexes). Lance une analyse de pages orphelines pour trouver les pages de contenu qui ne sont découvrables que via une pagination profonde et n'ont aucun autre lien interne. Pour le contenu orphelin, ajoute des liens internes depuis les pages connexes ou les sections mises en avant pour créer des chemins de découverte alternatifs.
Implémenter des URLs explorables pour l'infinite scroll ou Load More
Si ton site utilise l'infinite scroll ou les boutons Load More, implémente des URLs paginées sous-jacentes qui correspondent à chaque segment de contenu. Utilise l'API History pour mettre à jour l'URL du navigateur quand les utilisateurs font défiler ou cliquent sur Load More. Assure-toi que chaque URL paginée rende son contenu côté serveur sans nécessiter d'interaction JavaScript. Teste en accédant directement à /page/2/ dans un navigateur et en vérifiant que le bon ensemble de contenu est affiché. Inclus ces URLs paginées dans ton HTML (comme liens de pagination dans le footer ou dans un bloc noscript) pour que Google puisse les découvrir sans exécuter JavaScript.
Configurer les balises canonical sur les pages paginées
Implémente ta stratégie canonical choisie. Pour la plupart des sites, utilise des canonicals auto-référencées sur les pages 1 à 5 et une canonical pointant vers la page 1 pour les pages 6 et au-delà. Vérifie les balises canonical en affichant le code source des pages paginées à différentes profondeurs. Assure-toi que les URLs canonical utilisent le bon protocole (HTTPS) et le bon format de domaine (www ou non-www, correspondant à ton format d'URL préféré). Si ton CMS génère automatiquement les balises canonical, vérifie que les balises automatiques sont correctes pour les pages paginées, car certaines plateformes CMS auto-référencent incorrectement toutes les pages paginées quelle que soit la profondeur.
Optimiser la page 1 de chaque série paginée
Puisque la page 1 est la page de pagination la plus susceptible d'être indexée, investis dans la rendre aussi forte que possible. Ajoute du contenu introductif unique (description de catégorie, guide d'achat, vue d'ensemble du sujet) qui n'apparaît que sur la page 1. Assure-toi que la page 1 a une balise title unique et optimisée pour les mots-clés, ainsi qu'une meta description. Mets en avant tes éléments les plus importants sur la page 1 via une curation manuelle ou un tri algorithmique. Ajoute des données structurées (schema ItemList) à la page 1 pour aider Google à comprendre le format de listing. Renforce les liens internes pointant vers la page 1 depuis la navigation, les fils d'Ariane et les pages de contenu.
Contrôler le crawl budget dépensé sur la pagination profonde
Implémente des contrôles de crawl budget pour la pagination profonde. Ajoute des balises noindex,follow aux pages paginées au-delà de la page 5 (ou ton seuil choisi). Cela permet à Google de suivre les liens sur les pages profondes pour découvrir les éléments de contenu individuels tout en empêchant les pages profondes elles-mêmes de consommer le quota d'index. Pour la pagination très profonde (page 20+), envisage d'ajouter des règles disallow dans robots.txt pour empêcher entièrement l'exploration, en te fiant à ton sitemap pour la découverte de contenu au-delà de cette profondeur. Surveille les statistiques de crawl dans Search Console après l'implémentation des contrôles pour vérifier que le crawl budget passe des pages de listing aux pages de contenu.
Soumettre les pages paginées clés et le contenu individuel pour indexation
Après avoir implémenté les corrections de pagination, soumets la page 1 de chaque catégorie ou section importante via l'outil d'inspection d'URL de Google Search Console. Pour les pages de contenu individuelles qui n'étaient auparavant découvrables que via une pagination profonde, soumets-les via IndexBolt pour t'assurer que Google les indexe quelle que soit leur position dans la pagination. Surveille l'indexation à la fois des pages de listing et des pages de contenu individuelles au cours des semaines suivantes. Si les pages de contenu restent non indexées malgré leur présence dans le sitemap et leurs liens internes directs, examine si les pages elles-mêmes ont des problèmes de qualité ou techniques au-delà du contexte de pagination.
Problèmes courants et comment les résoudre
Les produits/articles sur la page 2+ ne sont pas indexés bien que les éléments de la page 1 le soient
Cause : Les éléments sur la page 1 reçoivent de forts signaux de liens internes depuis la page de catégorie (qui est elle-même bien liée depuis la navigation). Les éléments sur les pages plus profondes reçoivent des signaux plus faibles parce que les pages paginées sur lesquelles ils apparaissent ont moins d'autorité et sont explorées moins fréquemment. De plus, si les pages paginées au-delà de la page 1 ne sont pas indexées, Google découvre les éléments sur ces pages moins fréquemment que les éléments sur la page 1.
Solution : Assure-toi que toutes les URLs de pages de contenu individuelles soient dans ton sitemap XML, fournissant un chemin de découverte indépendant de la pagination. Ajoute des liens internes vers les éléments importants depuis des contextes non paginés : sections de produits connexes, mentions dans les articles de blog, éléments mis en avant sur la page d'accueil et widgets de cross-sell. Envisage de faire tourner les éléments mis en avant pour que différents produits apparaissent sur la page 1 au fil du temps. Utilise IndexBolt pour soumettre les URLs d'éléments individuels qui sont bloqués sur des pages profondes et ne sont pas indexés de manière organique.
Un site avec infinite scroll n'a que le premier lot d'éléments indexé
Cause : Google ne peut pas faire défiler, donc seuls les éléments rendus dans le chargement initial de la page sont visibles pour Google. Les éléments chargés par des requêtes JavaScript déclenchées par le défilement sont invisibles. Sans URLs paginées sous-jacentes, Google n'a aucun moyen d'accéder au contenu au-delà du premier lot visible. Les éléments au-delà du premier chargement par défilement n'existent effectivement pas du point de vue de Google.
Solution : Implémente des URLs paginées en parallèle de l'infinite scroll en utilisant l'approche pushState de l'API History. Chaque segment de défilement devrait correspondre à une URL paginée explorable. Inclus des liens de navigation paginée dans le HTML pour que Google puisse les suivre. Vérifie que chaque URL paginée rende son ensemble de contenu côté serveur. Après l'implémentation, soumets les URLs paginées via IndexBolt ou Search Console pour accélérer la découverte par Google de la nouvelle structure d'URL.
Toutes les pages paginées affichent « Doublon, Google a choisi une URL canonique différente » dans Search Console
Cause : Google traite les pages paginées comme des doublons les unes des autres ou de la page 1. Cela se produit quand les pages paginées ont des balises title identiques, des meta descriptions identiques, un contenu introductif identique, et ne diffèrent que par les éléments listés. Google les voit comme des variations de la même page plutôt que comme des pages distinctes, et choisit l'une d'elles (généralement la page 1) comme canonical.
Solution : Si tu veux que les pages paginées soient indexées indépendamment, différencie-les. Ajoute des numéros de page aux balises title (« Chaussures de course - Page 2 sur 8 »). Crée des meta descriptions uniques pour chaque page paginée ou supprime les meta descriptions des pages 2+ pour laisser Google les générer à partir du contenu. Affiche le contenu introductif uniquement sur la page 1. Si tu n'as pas besoin que les pages profondes soient indexées, définis explicitement des balises canonical sur les pages 2+ pointant vers la page 1 et accepte que seule la page 1 sera indexée.
Le contenu des boutons Load More disparaît de l'index de Google avec le temps
Cause : Le contenu derrière les boutons Load More qui était auparavant accessible via des chemins alternatifs (ancien sitemap, liens directs) peut perdre son indexation à mesure que Google réévalue le site. Si le contenu Load More n'est pas accessible sans interaction JavaScript et que les chemins alternatifs ne sont plus maintenus, Google n'a aucun moyen actuel d'accéder au contenu et peut désindexer les éléments précédemment indexés dont il ne peut plus vérifier l'existence.
Solution : Implémente des URLs paginées rendues côté serveur que Google peut explorer directement. Assure-toi que ces URLs sont dans ton sitemap et liées depuis le HTML de la page de listing. Vérifie que la suppression de JavaScript de la page permet toujours l'accès à tout le contenu via les URLs paginées. Après la correction, soumets les URLs d'éléments affectés via IndexBolt pour restaurer l'indexation du contenu précédemment désindexé.
Astuces pro
La pagination ne devrait pas déterminer si ton contenu est indexé. IndexBolt soumet les URLs de pages de contenu individuelles directement à Google, contournant entièrement le chemin de découverte par pagination. Que tes produits soient sur la page 1 ou la page 50, IndexBolt s'assure qu'ils soient tous indexés. Soumets ta liste complète d'URLs de contenu et laisse chaque page atteindre Google quelle que soit sa position dans la pagination.
100 crédits gratuits. Aucune carte bancaire requise. Résultats en moins de 24 heures.
Questions fréquentes
Google supporte-t-il encore rel=prev/next ?+
Non. Google a confirmé en mars 2019 qu'il n'avait pas utilisé rel=prev/next comme signal de classement ou d'indexation depuis plusieurs années. Inclure ces balises dans ton HTML ne cause pas de dommage, mais cela n'apporte aucun bénéfice pour Google. D'autres moteurs de recherche (Bing) peuvent encore utiliser ces balises, donc les garder ne fait pas de mal, mais tu ne devrais pas t'y fier pour l'indexation Google. Ta stratégie de pagination pour Google doit être basée sur les balises canonical, les directives noindex, l'inclusion dans le sitemap et la qualité du contenu plutôt que sur les signaux rel=prev/next.
Devrais-je créer une page « Voir Tout » au lieu d'utiliser la pagination ?+
Une page Voir Tout qui liste chaque élément sur une seule page est la solution la plus simple pour Google parce qu'elle élimine entièrement la pagination. Google a déclaré qu'il préfère généralement les pages Voir Tout quand elles sont techniquement faisables. Cependant, les pages Voir Tout ne sont pratiques que pour les ensembles de contenu plus petits (moins de 100 éléments). Pour les catégories avec des centaines ou des milliers d'éléments, une page Voir Tout serait trop lente à charger, trop gourmande en ressources à rendre et trop accablante pour les utilisateurs. Pour les grands ensembles de contenu, utilise l'approche hybride de la pagination traditionnelle combinée à un sitemap XML complet.
Jusqu'à quelle profondeur devrais-je permettre à Google d'explorer ma pagination ?+
Il n'y a pas de réponse universelle, mais une directive pratique est de permettre l'indexation des trois à cinq premières pages et de mettre en noindex (tout en autorisant le follow) les pages plus profondes. Le seuil exact dépend de la qualité de tes pages paginées et du crawl budget de ton site. Si ton site a une forte autorité et que Google explore agressivement, tu peux autoriser une indexation plus profonde. Si ton site a un crawl budget limité, restreins l'indexation à la page 1 uniquement et fie-toi à ton sitemap pour la découverte de contenu. La métrique clé est de savoir si les pages paginées plus profondes génèrent réellement des impressions de recherche. Vérifie dans Search Console si des URLs de page 5+ reçoivent des impressions. Sinon, les mettre en noindex économise du crawl budget sans impact sur le trafic.
Mon infinite scroll utilise AJAX pour charger le contenu. Google peut-il voir le contenu chargé par AJAX ?+
Google peut rendre le contenu chargé par JavaScript, y compris les réponses AJAX, mais seulement si le chargement du contenu est déclenché par le rendu initial de la page plutôt que par une interaction utilisateur (défilement, clic). Le contenu AJAX qui se charge automatiquement au chargement de la page est visible pour Google. Le contenu AJAX qui se charge en réponse à un événement de défilement ne l'est pas, parce que le renderer de Google ne fait pas défiler. Si ton infinite scroll déclenche des requêtes AJAX basées sur la position de défilement, ce contenu est invisible pour Google. Implémente des URLs paginées sous-jacentes avec du contenu rendu côté serveur comme fondation, et superpose l'expérience AJAX d'infinite scroll par-dessus pour les utilisateurs.
L'ordre des éléments dans la pagination est-il important pour le SEO ?+
L'ordre des éléments est important principalement parce que les éléments sur la page 1 reçoivent significativement plus d'attention de crawl et de valeur de liens internes que les éléments sur les pages plus profondes. Google est plus susceptible d'explorer et d'indexer le contenu de la page 1 que le contenu de la page 10. Si tu as des éléments de haute priorité que tu veux indexer et visibles, assure-toi qu'ils apparaissent sur la page 1 via une curation manuelle, un épinglage ou des algorithmes de tri qui font remonter les éléments importants en premier. Pour l'e-commerce, trier par best-seller, mieux noté ou plus récent fait souvent naturellement remonter les produits les plus pertinents sur la page 1. Évite le tri aléatoire qui change à chaque chargement de page, car Google peut avoir des difficultés à évaluer un contenu de page incohérent.
Devrais-je ajouter du contenu unique à chaque page paginée pour aider à son indexation ?+
Ajouter du contenu unique à chaque page paginée n'est ni pratique ni nécessaire pour la plupart des sites. Concentre ton effort d'optimisation de contenu sur la page 1, qui est la plus susceptible d'être indexée et la plus importante pour le trafic de recherche. Pour les pages 2 à 5, des balises title différenciées avec des numéros de page suffisent. Pour les pages plus profondes, mets-les en noindex et ne t'inquiète pas du contenu unique. Les éléments individuels listés sur ces pages devraient chacun avoir leur propre contenu unique sur leurs propres URLs. La page de listing paginée est un mécanisme de navigation, pas une destination de contenu. Investis ton effort de création de contenu dans les éléments individuels plutôt que dans les pages de listing.