Pagination infinie et SEO : rendre le défilement explorable

Le chargement automatique au défilement s'est imposé sur les catalogues et les fils d'actualité parce qu'il supprime un clic et allonge le temps passé sur la page. Du point de vue d'un moteur de recherche, il produit exactement l'effet inverse de celui recherché : un robot ne fait pas défiler, ne déclenche aucun événement de position, et ne voit donc jamais que le premier lot d'éléments. Sur un catalogue de cinq mille références affichées par vingt, cela signifie que quatre mille neuf cent quatre vingt d'entre elles n'existent pas. Le problème se corrige sans renoncer à l'effet, à condition de comprendre précisément ce qui est cassé et de conserver un chemin d'exploration parallèle.

Ce que le défilement infini casse réellement

La description du problème mérite d'être précise, parce que les corrections partielles sont nombreuses et qu'elles ne traitent pas toutes le même symptôme. Trois conséquences distinctes se cumulent, et elles n'ont pas la même gravité selon le type de site. Le sujet est indissociable de la façon dont un moteur répartit ses passages, question développée dans notre article sur le budget de crawl de Googlebot et ses principes.

Les éléments non chargés n'existent pas

C'est la conséquence la plus évidente et la plus coûteuse. Les liens vers les fiches situées au delà du premier lot ne figurent nulle part dans le document, ni avant ni après exécution du code, puisqu'ils ne sont produits qu'en réaction à un geste de l'utilisateur. Un moteur qui exécute pourtant le JavaScript n'a aucun moyen de déclencher ce geste. La découverte de ces fiches dépend alors entièrement d'autres chemins, plan de site ou liens depuis d'autres pages, chemins qui n'existent pas toujours. Sur une boutique récente, sans historique ni liens entrants, la conséquence est immédiate : le catalogue reste invisible pendant des mois.

La profondeur devient infinie

Même lorsque les fiches sont découvertes par un autre moyen, leur position dans le maillage devient indéterminée. Une fiche accessible uniquement après trente défilements n'est liée depuis aucune page réelle, ce qui la prive de la valeur transmise par les liens internes. Elle est connue et sans appui, situation qui se traduit par une exploration rare et un positionnement faible. La mesure de cette profondeur devient d'ailleurs impossible avec les outils habituels, qui suivent des liens et non des gestes. Le tableau de profondeur obtenu affiche alors un site apparemment très plat, ce qui donne une fausse impression de bonne santé.

Aucune adresse à partager

Un visiteur ayant fait défiler jusqu'au milieu de la liste ne peut pas envoyer cette position à quelqu'un, ni la retrouver après un retour en arrière. Cette limite pénalise l'usage autant que le référencement, et elle produit un effet secondaire connu : le retour depuis une fiche produit ramène en haut de la liste, ce qui exaspère les acheteurs. Les corrections apportées à ce défaut, restauration de la position par un état d'historique, ouvrent d'ailleurs la voie à la solution complète. Le travail nécessaire pour restaurer la position au retour est en effet très proche de celui qui produit de véritables adresses paginées.

Les statistiques deviennent illisibles

Une page unique portant des dizaines de lots successifs enregistre une seule consultation quel que soit le volume parcouru. Comparer la performance des différentes portions du catalogue devient impossible, et les indicateurs de sortie perdent tout sens. Cette conséquence n'est pas directement liée au référencement et elle prive l'équipe des données qui permettraient d'arbitrer. Elle se corrige en même temps que le reste, ce qui plaide pour une reprise globale plutôt que pour des rustines. Retrouver des consultations par page permet en outre de repérer les portions du catalogue que personne n'atteint jamais.

Le rendu devient coûteux

Une liste ayant accumulé plusieurs centaines d'éléments dans le document finit par peser sur la mémoire et sur la fluidité, particulièrement sur les appareils mobiles anciens. Les mesures de performance en pâtissent, avec un effet sur la stabilité visuelle et sur la réactivité aux interactions. Ce coût est rarement anticipé lors du choix du mécanisme, et il devient visible quand les utilisateurs signalent des ralentissements. La virtualisation de la liste règle ce point sans rien changer au problème d'exploration. Elle mérite d'être mise en place pour elle même, en gardant à l'esprit qu'elle ne fait rien gagner du côté des moteurs.

Ce qui n'est pas cassé

Il faut aussi rappeler ce qui fonctionne, pour ne pas surcorriger. Le premier lot est parfaitement exploré et indexé, et la page de liste elle même se positionne normalement. Les fiches déjà connues du moteur restent visitées par les chemins existants. Le problème porte sur la découverte des nouveaux contenus et sur la valeur transmise, pas sur une disparition brutale de ce qui est déjà en place. Cette nuance explique pourquoi le défaut passe souvent inaperçu pendant des mois sur un site établi. Il se révèle en général au moment d'un renouvellement important du catalogue, quand les nouvelles références ne décollent pas.

Les solutions qui fonctionnent vraiment

Trois approches existent et une seule règle l'ensemble des symptômes. Les deux autres ont leur place dans des contextes précis et il vaut mieux savoir laquelle on choisit et pourquoi, plutôt que de découvrir ses limites après coup. La question rejoint directement les arbitrages décrits dans notre article sur la pagination et l'usage de la balise canonique.

Le bouton menant à une adresse réelle

Remplacer le déclenchement automatique par un bouton portant une véritable adresse vers la page suivante constitue la correction la plus simple. Le script intercepte le clic, charge les éléments et empêche la navigation ; le robot, lui, suit l'adresse et découvre la page suivante. Le comportement observé par le visiteur change peu, un clic remplaçant un défilement, et l'exploration redevient complète. C'est la solution retenue par la plupart des grands catalogues, précisément parce qu'elle ne coûte presque rien. Le lien peut rester visuellement identique au bouton d'origine, la seule contrainte portant sur la présence d'une adresse valide dans le document.

La pagination conservée en parallèle

Le défilement automatique peut être maintenu tel quel si une pagination classique existe ailleurs, dans le pied de page de la liste ou dans un plan dédié. Cette solution conserve intégralement l'effet recherché et demande de produire des pages numérotées réellement accessibles. Elle suppose que ces pages soient liées depuis un endroit visible par un robot, ce qui exclut de les cacher derrière un autre mécanisme dynamique. Sa mise en place est décrite plus bas. Son principal avantage tient à ce qu'elle ne demande aucun arbitrage avec les équipes chargées de l'expérience, puisque rien ne change à l'écran pour le visiteur.

La mise à jour de l'adresse au défilement

Modifier l'adresse affichée au fur et à mesure du défilement, par le mécanisme d'historique du navigateur, permet de partager une position et de revenir au bon endroit. Cette technique améliore nettement l'usage et elle ne résout pas la découverte : le robot ne défile toujours pas et ne verra jamais ces adresses. Elle constitue un complément utile, jamais une réponse. La confondre avec une solution est l'erreur la plus fréquemment commise sur ce sujet. Les adresses ainsi produites peuvent en revanche être réutilisées telles quelles par la pagination parallèle, ce qui évite d'en inventer de nouvelles.

Le plan de site comme filet

Un plan de site XML listant l'ensemble des fiches permet leur découverte indépendamment du maillage. C'est un filet de sécurité indispensable et insuffisant : les pages découvertes par cette seule voie reçoivent peu de valeur interne et sont explorées rarement. Il doit accompagner une correction du maillage, jamais la remplacer. Beaucoup de sites s'en contentent et constatent que les fiches sont indexées sans jamais recevoir de visites. L'indexation n'est en effet qu'une condition d'entrée, la position dépendant ensuite très largement du maillage interne.

Le rendu côté serveur des premières pages

Sur une application construite entièrement côté navigateur, produire côté serveur les premières pages de chaque liste supprime le problème pour la partie du catalogue qui compte le plus. Cette approche demande un travail réel et elle apporte un gain de vitesse d'affichage qui la rend rentable au delà de la seule exploration. Elle se combine parfaitement avec le défilement automatique pour les lots suivants. C'est la solution la plus complète sur les catalogues volumineux. Elle permet de concentrer l'effort sur les premières pages de chaque famille, qui concentrent l'essentiel du potentiel commercial.

Ce qu'il ne faut pas faire

Placer l'intégralité du catalogue dans une seule page, pour être certain que tout soit vu, produit un document énorme, lent, et dont la pertinence thématique se dilue. Masquer les éléments suivants par une règle de style plutôt que de les charger à la demande donne le même résultat. Enfin, générer des liens invisibles vers toutes les fiches dans un bloc caché relève d'une pratique déconseillée et facilement détectable. Aucune de ces trois voies ne constitue une solution acceptable. Elles ont en commun de traiter le symptôme, la présence des liens dans le document, en ignorant ce qui fait leur valeur, à savoir un chemin réellement praticable.

Mettre en place la pagination parallèle

C'est la voie la plus souvent retenue parce qu'elle ne touche pas au comportement existant. Sa mise en place demande une poignée de décisions techniques, chacune ayant des conséquences sur l'exploration. Le mécanisme de chargement différé des visuels, très présent sur ces listes, mérite au passage une attention particulière, sujet que nous traitons dans notre article sur le lazy loading et son intérêt en référencement.

Produire de vraies pages numérotées

Chaque page doit répondre à une adresse propre, renvoyer un code de succès et afficher son lot d'éléments sans dépendre d'un script. Le paramètre de numéro de page dans l'adresse est la convention la plus répandue et la mieux comprise. Ces pages doivent être accessibles directement, y compris avec le JavaScript désactivé, ce qui constitue le test le plus simple pour vérifier qu'elles fonctionnent. Ce point se vérifie en trente secondes et il est régulièrement défaillant. Une page qui renvoie une liste vide sans script indique que le rendu dépend entièrement du navigateur, situation à corriger avant toute autre chose.

Lier ces pages entre elles

Une pagination affichant seulement la page suivante crée une chaîne linéaire très profonde. Afficher les premières pages, les dernières et quelques voisines réduit fortement la profondeur moyenne et améliore la répartition de la valeur. Sur une liste de deux cents pages, ce simple changement peut diviser par cinq le nombre de sauts nécessaires pour atteindre les dernières. Le rendu visuel de cette pagination importe peu, seule sa présence dans le document compte. Un bloc discret en bas de liste remplit parfaitement son office sans perturber la maquette validée.

Choisir la canonique avec soin

Chaque page paginée doit porter sa propre adresse canonique et non celle de la première page. Faire pointer toutes les pages vers la première est une erreur classique qui revient à demander au moteur d'ignorer l'ensemble des pages suivantes, donc les fiches qu'elles contiennent. Cette pratique a été explicitement déconseillée et elle persiste sur beaucoup de sites. Le contrôle prend quelques secondes sur une page en milieu de liste. Il suffit de comparer l'adresse déclarée en canonique à celle affichée dans la barre du navigateur.

Gérer les titres et les descriptions

Les pages paginées portent souvent le même titre et la même description, ce qui produit des doublons signalés dans les outils. Ajouter la mention du numéro de page suffit à les différencier sans effort éditorial. Ces pages n'ont pas vocation à se positionner elles mêmes et leur rôle est de faire circuler l'exploration, ce qui justifie de ne pas y consacrer un travail rédactionnel important. Une règle générique appliquée automatiquement convient parfaitement. La plupart des extensions de référencement proposent cette variable, ce qui réduit l'intervention à un réglage.

Décider de l'indexation

Interdire l'indexation des pages paginées tout en autorisant leur exploration est un choix défendable sur les catalogues où ces pages n'apportent aucune valeur en résultat. La directive doit alors permettre le suivi des liens, faute de quoi la correction annule son propre effet. Beaucoup de sites appliquent une directive trop large et bloquent involontairement l'exploration qu'ils cherchaient à rétablir. Ce détail mérite une vérification explicite après mise en place. Le contrôle consiste à lire la directive présente sur une page paginée et à s'assurer qu'elle autorise bien le suivi des liens.

Rendre la pagination visible aux robots

Placer la pagination dans un bloc chargé après coup ou dans un menu déroulant dynamique reproduit exactement le problème que l'on cherchait à résoudre. Elle doit figurer dans le document initial, sous forme de liens réels. Un contrôle du code source, et non de l'inspecteur du navigateur, tranche la question immédiatement. Cette confusion entre les deux vues est la source d'erreur la plus fréquente lors des vérifications rapides. Les deux affichages se ressemblent beaucoup et ne décrivent pas du tout le même état du document.

Vérifier le résultat et arbitrer

La correction se mesure, elle ne se suppose pas, et les outils nécessaires sont ceux qui servent déjà à surveiller le site. Aucun investissement particulier n'est nécessaire, seulement un relevé avant intervention pour disposer d'un point de comparaison.

Explorer sans exécuter le code

Un outil d'exploration configuré pour ignorer le JavaScript donne le nombre d'adresses accessibles à la première analyse. Avant correction, ce nombre correspond au premier lot ; après correction, il doit approcher le nombre total de fiches. Cette comparaison constitue la preuve la plus directe que le travail a porté. Elle prend quelques minutes sur un catalogue de taille moyenne. Conserver l'export obtenu avant correction permet de documenter le gain avec des chiffres plutôt qu'avec une impression.

Croiser avec les journaux du serveur

Les journaux montrent quelles adresses le robot demande effectivement. L'apparition progressive des pages paginées et des fiches profondes dans ces demandes confirme la découverte réelle, ce qu'aucune simulation ne peut garantir. Ce suivi se mène sur quelques semaines et il constitue la vérification définitive. Il permet aussi de constater si l'exploration se répartit correctement ou se concentre sur les premières pages. Une concentration persistante signale en général une pagination trop linéaire, corrigeable en affichant davantage de numéros.

Suivre l'indexation dans les rapports

Le nombre de pages connues et indexées, relevé avant et après, donne la mesure du gain. Ces rapports se mettent à jour avec un décalage de plusieurs jours à plusieurs semaines, ce qui impose de la patience. Un catalogue important peut mettre deux mois à voir l'ensemble de ses fiches prises en compte. Annoncer ce délai avant l'intervention évite les interrogations en cours de route. La courbe progresse rarement de façon régulière, ce qui rend les relevés hebdomadaires peu informatifs comparés à un relevé mensuel.

Mesurer l'effet sur l'usage

Le remplacement du défilement automatique par un bouton modifie le comportement des visiteurs, généralement de façon marginale et parfois favorablement, le clic marquant une intention. Suivre le nombre de fiches consultées par session et le taux de mise au panier permet de trancher sur des données plutôt que sur des impressions. Si l'effet est négatif, la pagination parallèle sans modification du défilement reste disponible. Cet arbitrage se fait en connaissance de cause. Prévoir la mesure avant le déploiement, et non après, est la seule façon de disposer d'une comparaison exploitable.

Surveiller le poids des pages

Une pagination classique produit des pages plus légères qu'un défilement ayant accumulé des centaines d'éléments. Le gain sur les indicateurs de performance est souvent significatif sur mobile, avec un effet mécanique sur les mesures d'expérience. Ce bénéfice collatéral mérite d'être mesuré et documenté, car il aide à justifier l'intervention auprès des équipes qui tenaient au défilement. Les chiffres convainquent mieux que les principes.

Documenter le choix retenu

Écrire en quelques lignes pourquoi telle solution a été choisie, quelles adresses ont été créées et quelles directives ont été posées évite que le travail ne soit défait lors d'une refonte graphique. Ce type de correction est invisible à l'écran et il disparaît facilement lors d'un changement de gabarit. Une note dans la documentation technique du projet suffit. C'est le meilleur moyen d'éviter de refaire le même chantier dans deux ans.