Pagination et SEO : les 4 réglages qui décident de l'indexation

Une boutique de 400 références, un blog de 200 articles, un annuaire de 3 000 fiches : dans les trois cas, les pages de liste sont la seule route par laquelle Google atteint le détail. Quand cette route est mal pavée, le symptôme est toujours le même — une partie du catalogue n'apparaît jamais dans les résultats, sans qu'aucune alerte ne se déclenche.

Ce que la pagination décide réellement

Une page de liste n'a pas vocation à se positionner. Son travail est ailleurs : elle transporte le robot jusqu'aux pages qui, elles, doivent ressortir. Chaque lien qu'elle porte est une invitation à crawler, et chaque page de liste que le robot n'atteint pas emmène avec elle les vingt ou trente fiches qu'elle était seule à lier.

C'est pour cette raison qu'un problème de pagination ne se voit pas dans le classement d'une page de liste, mais dans le nombre de fiches indexées. Sur un catalogue de 400 produits, une pagination qui s'arrête de fait à la page 2 laisse 340 fiches hors du radar. Elles répondent en 200, elles sont parfaitement rédigées, et personne ne les trouve.

Le contrôle tient en deux minutes : comparez le nombre de fiches que vous avez au nombre de pages indexées que la Search Console vous annonce dans son rapport d'indexation. Un écart de plus de 20 % mérite qu'on regarde la pagination avant toute autre hypothèse, avant même de se demander pourquoi telle page n'est pas indexée.

Quatre réglages suffisent, et ils se vérifient dans cet ordre :

• une URL réelle et atteignable par page
• une canonique qui pointe vers la page elle-même
• des liens vers les premières et dernières pages
• une page « tout voir » seulement si la liste est courte

Réglage 1 — une URL réelle par page

La page 2 doit avoir sa propre adresse, atteignable directement, et servie par le serveur sans que le navigateur ait à exécuter quoi que ce soit. Trois formes fonctionnent : /categorie/?page=2, /categorie/page/2/, /categorie-2/. Google les traite toutes correctement.

Deux formes ne fonctionnent pas. Un fragment — /categorie/#page2 — n'est jamais une URL distincte pour un moteur : tout ce qui suit le dièse est ignoré. Et une pagination qui n'existe qu'à travers un bouton « charger la suite » en JavaScript, sans lien correspondant dans le HTML servi, revient à ne pas avoir de pagination du tout. Le défilement infini n'est pas interdit, mais il doit doubler des liens réels que le robot peut suivre.

Le test qui tranche : affichez le code source servi par le serveur, pas l'inspecteur du navigateur, et cherchez-y la chaîne page=2. Si elle n'y est pas, votre pagination n'existe que pour les humains.

Sur une boutique, c'est le point qui départage le plus souvent deux catalogues comparables : la version « charger la suite » indexe les trente premiers produits, la version paginée les indexe tous. Le reste de la méthode e-commerce est dans notre guide SEO pour boutique en ligne.

Réglage 2 — chaque page se déclare elle-même

La canonique de la page 3 pointe vers la page 3. C'est le réglage le plus souvent faux, et l'erreur est toujours bien intentionnée : on veut « consolider » vers la page 1, alors on fait pointer toutes les pages vers elle.

Le résultat est l'inverse de celui recherché. En déclarant que la page 3 est un doublon de la page 1, on demande à Google d'arrêter de s'en occuper — donc de crawler moins souvent les liens qu'elle porte, donc de découvrir plus lentement les fiches qui n'apparaissent que là. On économise des pages dans l'index, on perd des produits.

Même raisonnement pour le noindex posé sur les pages 2 et suivantes : Google finit par considérer qu'une page durablement noindex ne mérite plus de visite fréquente, et l'effet se propage aux liens qu'elle porte. Laissez les pages paginées indexables. Elles ne sortiront jamais sur une requête, et ce n'est pas leur rôle.

Une exception existe : une liste triée qui produit plusieurs fois le même contenu sous des URL différentes (tri par prix, par date, par popularité). Là, une seule version se déclare canonique et les autres pointent vers elle — ce n'est plus de la pagination, c'est du tri, et les deux cas se traitent différemment.

Réglage 3 — un maillage qui ne fait pas marcher le robot en file indienne

Une pagination qui n'affiche que « précédent » et « suivant » oblige le robot à parcourir vingt pages l'une après l'autre pour atteindre la vingtième. Chaque saut coûte une visite, et le budget de crawl d'un site de PME n'est pas extensible : les dernières pages sont visitées rarement, parfois jamais.

La parade tient en une ligne de gabarit : afficher aussi les premières et les dernières pages, plus quelques numéros autour de la page courante. Le classique 1 … 4 5 [6] 7 8 … 20 ramène n'importe quelle page à deux ou trois clics de l'accueil au lieu de vingt.

Deux compléments valent mieux qu'une pagination plus longue : des filtres qui produisent des listes plus courtes et thématiques, et un lien depuis chaque fiche vers deux ou trois fiches proches. Le second est souvent plus rentable, parce qu'il crée des routes qui ne dépendent plus des pages de liste : c'est exactement ce que fait un maillage interne pensé.

Réglage 4 — la page « tout voir », seulement si elle tient

Quand la liste complète compte quelques dizaines d'éléments, une page unique sans pagination est la solution la plus simple : un seul document, un seul crawl, tous les liens au même endroit. C'est le cas de la plupart des blogs de PME.

Au-delà de deux ou trois cents éléments, elle devient contre-productive : la page pèse lourd, se charge mal sur mobile, et le temps de chargement que vous perdez là coûte davantage que ce que la simplification rapporte. Dans ce cas, on garde la pagination, et la page « tout voir » n'a pas lieu d'être.

Si vous en maintenez une en plus de la pagination, faites-en une page indexable à part entière, et liez-la depuis la première page de liste. Ne faites pas pointer les canoniques des pages paginées vers elle : c'est la même erreur qu'au réglage 2, avec une cible différente.

Ce qui n'a plus cours

Trois conseils circulent encore et n'ont plus de valeur opérationnelle. Le premier est rel="prev" / rel="next" : Google a indiqué en mars 2019 qu'il ne s'en servait plus depuis plusieurs années. Les poser ne casse rien, mais bâtir sa pagination autour d'elles, c'est régler un problème que personne ne lit.

Le deuxième est le blocage des pages paginées dans le robots.txt. Interdire le crawl d'une URL n'empêche pas son indexation, et surtout coupe la route vers les fiches : c'est le contraire de ce qu'on veut. Le robots.txt sert à autre chose.

Le troisième est la réécriture des balises title en « Catégorie — page 2 ». Elle ne nuit pas, elle ne sert à rien non plus : ces pages ne visent aucune requête. Le temps passé là se place mieux sur les fiches.

Le contrôle à faire une fois, puis tous les trimestres

Prenez une catégorie qui compte au moins cinq pages. Ouvrez la page 3, inspectez son URL dans la Search Console et lisez deux choses : l'état d'indexation, et la canonique retenue par Google. Si la canonique annoncée est celle de la page 1, vous tenez la cause. Le détail des rapports est dans notre guide de la Search Console.

Recoupez ensuite avec les journaux du serveur, ou avec le rapport de statistiques d'exploration : repérez la page paginée la plus profonde que Googlebot a visitée dans les trente derniers jours. Si le robot s'arrête à la page 2 alors que vous en avez douze, le problème n'est pas une balise, c'est la profondeur — retour au réglage 3, et accessoirement une question de budget de crawl.

Ce contrôle prend une demi-heure et vaut d'être refait après chaque refonte de gabarit : la pagination fait partie des choses qu'on casse sans le voir, parce que rien ne cesse de s'afficher.

Questions fréquentes