Pagination d'un blog : ce que nous avons changé sur nos rubriques, et pourquoi

La rubrique référencement naturel SEO de ce blog compte à elle seule plus de cinq cents articles. Répartis par douze, cela fait quarante-trois pages de liste : quarante-trois adresses qui existent uniquement pour permettre de faire défiler des titres, et qui, laissées à elles-mêmes, se présentent à Google comme quarante-trois pages presque identiques. Nous avons revu cette mécanique sur l'ensemble du blog. Voici ce que nous avons changé, pourquoi, et surtout ce qu'il a fallu mettre en face pour que la décision tienne.

Ce qu'une page de liste apporte au lecteur, et ce qu'elle apporte au moteur

Une page de rubrique paginée n'a pas de contenu propre. Elle affiche des titres, des vignettes et parfois deux lignes d'accroche, tous empruntés à des articles qui vivent chacun à leur propre adresse. Sa valeur est réelle mais purement fonctionnelle : elle permet de parcourir, de remonter dans le temps, de tomber sur un sujet qu'on ne cherchait pas. Pour un moteur de recherche, cette même page est un objet embarrassant. Elle ne répond à aucune requête, elle ressemble beaucoup à sa voisine, et elle consomme du budget d'exploration qui serait mieux employé ailleurs. Le problème n'est pas qu'elle soit mauvaise, c'est qu'elle occupe une place qui ne lui revient pas : dans un index, ce sont les articles qui doivent figurer, pas les rayonnages qui les portent. C'est une forme de duplication interne particulièrement sournoise, parce qu'elle ne vient pas d'une erreur de rédaction. Elle est produite par le fonctionnement normal du site, elle grandit toute seule à chaque publication, et personne ne la remarque tant qu'on ne va pas regarder ce que Google a réellement mis dans son index.

Ce que la pagination pèse réellement dans un site

Il est facile de balayer le sujet d'un revers de main : quelques pages de liste, quelle importance ? Nous avons fait le compte sur ce blog. Vingt et une rubriques, mille cinq cent six articles publiés, douze articles par page : cela donne cent trente-huit pages de liste pour les rubriques, auxquelles s'ajoutent cent vingt-six pages pour l'index général du blog, qui reprend l'ensemble des publications dans l'ordre chronologique. Deux cent soixante-quatre adresses au total, soit un cinquième du volume d'articles du site, pour une quantité de contenu original strictement nulle. Ce n'est pas un chiffre théorique : ce sont deux cent soixante-quatre URL qu'un robot découvre, met en file d'attente, télécharge, analyse et compare aux autres. Sur un site de cette taille, l'exploration n'est pas illimitée, et chaque passage consacré à une page de liste est un passage qui n'est pas consacré à un article mis à jour la veille. Comme ces pages changent à chaque publication, un nouvel article en tête décalant tout le reste d'un cran, elles paraissent perpétuellement fraîches et attirent le robot bien plus souvent qu'un article stable. C'est le paradoxe qui rend la situation coûteuse : les pages les moins utiles sont aussi celles qui bougent le plus, donc celles qui appellent le plus de visites. Une pagination laissée en l'état ne se contente pas d'occuper de la place, elle en réclame activement.

Première décision : ne plus répéter le texte de la rubrique sur les pages suivantes

La plupart des blogs affichent, en tête de rubrique, un texte de présentation. Le nôtre aussi : quelques paragraphes qui expliquent ce qu'on trouve dans la rubrique et sous quel angle nous traitons le sujet. Ce texte est écrit pour quelqu'un qui arrive sur la rubrique, il n'a aucune raison d'être relu par quelqu'un qui en est à la page 27. Or c'est exactement ce que fait un thème par défaut : il réaffiche l'introduction sur chaque page de la série. Quarante-trois pages qui partagent le même bloc de texte éditorial, ce n'est plus de la navigation, c'est de la duplication fabriquée à la chaîne. Nous avons donc réservé ce texte à la première page, les pages suivantes ne portant plus que le titre de la rubrique, la liste des articles et la pagination. Le gain est double : elles ne se ressemblent plus par leur contenu éditorial, et le peu de texte qu'elles contiennent, les titres des articles, devient effectivement ce qui les distingue les unes des autres. C'est le geste le plus simple des trois, et à notre sens le plus important. Il ne demande aucune décision technique discutable, seulement de se poser une question de bon sens : ce paragraphe, est-ce que quelqu'un le lit une deuxième fois ?

Deuxième décision : la canonique des pages suivantes désigne l'index de la rubrique

Une fois le texte retiré, il reste des pages de liste qui n'ont toujours pas vocation à être trouvées par une recherche. Nous avons choisi de faire pointer leur balise canonique vers l'index de leur rubrique : concrètement, /blog/seo/page/41/ déclare désormais que l'adresse de référence est /blog/seo/. Le signal se concentre sur une seule URL, celle qui porte le texte de présentation et qui a une chance légitime de se positionner sur le nom de la thématique.

Il faut dire les choses honnêtement : ce n'est pas la recommandation officielle de Google. La documentation préconise une canonique auto-référencée sur les pages paginées, et prévient que canonicaliser vers la page 1 peut empêcher l'indexation de ce qui ne figure que sur les pages suivantes. L'avertissement est justifié, il ne s'applique simplement pas à notre situation. La différence tient à une question : le contenu des pages 2 et suivantes existe-t-il ailleurs ? Chez nous, oui. Chaque article listé possède sa propre adresse, il figure au sitemap XML, il est atteignable par les liens internes, et la page de liste n'est qu'un chemin parmi d'autres. Sur une boutique dont les produits ne seraient accessibles qu'en parcourant les pages de catégorie, la réponse serait non, et la même décision serait une faute. Les trois configurations possibles, canonique vers la page 1, auto-référencée, ou vers une vue complète, ont chacune leur domaine de validité : nous les avons détaillées dans notre article consacré à la configuration de la balise canonique sur les contenus paginés. Ce qui suit ne dit pas laquelle est la bonne dans l'absolu, mais ce qui rend la nôtre défendable ici.

Le maillage interne, sans quoi rien de tout cela ne tient

Retirer les pages de liste de l'index revient à supprimer un chemin d'accès. Si c'était le seul, on aurait simplement rendu invisibles des centaines d'articles anciens : la décision n'est acceptable que parce qu'un autre chemin existe, et qu'il est meilleur. Ce chemin, c'est le maillage interne. Un lien posé dans le corps d'un article vers un article plus ancien vaut infiniment mieux qu'une ligne dans une liste chronologique, car il arrive au moment où le lecteur en a besoin, il porte une ancre qui décrit le contenu visé, et il transmet un signal que la pagination ne transmettait pas. Un article de 2019 qui reçoit trois liens contextuels depuis des textes récents est plus vivant, aux yeux d'un moteur comme d'un lecteur, qu'un article de la semaine dernière relégué en page 2. C'est aussi ce qui évite l'autre écueil, celui de la cannibalisation entre articles proches : quand on relie explicitement deux textes qui se recoupent, on désigne du même coup celui qui doit primer sur la requête, au lieu de laisser Google arbitrer seul. Il y a une contrepartie, et elle est réelle. Ce travail ne se fait pas tout seul : un thème produit la pagination sans qu'on lève le petit doigt, alors que les liens internes, il faut les poser. C'est du temps de rédaction à chaque publication, et une relecture régulière des anciens articles pour les rattacher aux nouveaux.

Le plan de site, filet structurel

Reste le cas des articles que personne n'a encore reliés. Pour eux, nous maintenons un plan de site en HTML : toutes les rubriques, tous les articles, chacun avec un lien direct. Ce n'est pas un doublon du sitemap XML, qui s'adresse aux robots, mais une page de navigation destinée aux humains, qui a l'avantage secondaire de garantir qu'aucun article du site n'est à plus de deux clics de l'accueil, indépendamment de l'état du maillage. Une page orpheline ne peut pas exister tant qu'elle y figure. Nous l'avons organisée en deux temps, les pages fixes d'un côté, les rubriques et leurs articles de l'autre, séparées par le texte qui explique ce que chaque thématique recouvre. Un plan de site qui se contente d'empiler quinze cents liens sans un mot est un fichier, pas une page.

Pourquoi une canonique plutôt qu'un noindex

La question se pose immédiatement : puisque ces pages n'ont pas vocation à être trouvées, pourquoi ne pas simplement les passer en noindex, follow ? La formule est séduisante, elle dit explicitement « ne référence pas ceci, mais suis les liens ». Elle a un défaut connu : une page maintenue en noindex pendant des mois finit par être explorée de moins en moins souvent, et les liens qu'elle porte perdent progressivement de leur poids, si bien que le follow s'érode en pratique même s'il reste écrit dans le code. Pour une page dont la seule fonction est justement de porter des liens vers des articles, c'est un mauvais calcul à long terme. La balise canonique, elle, ne dit pas « ignore cette page » mais « celle-ci et celle-là n'en font qu'une, voici laquelle retenir ». La nuance paraît mince, elle ne l'est pas : le moteur continue de traiter la page comme une page à part entière, il la range simplement sous une autre adresse. Nous revenons plus longuement sur ce mécanisme et ses règles d'emploi dans notre article de fond sur l'usage de rel=canonical face à la duplication. Il existe un troisième compromis, la page « voir tout », qui rassemble la série entière sur une seule adresse : elle règle le problème à la racine, mais devient inutilisable au-delà de quelques centaines d'éléments, car cinq cents articles sur une page, personne ne la charge deux fois.

Un détail qui a son importance : la forme des adresses

Ce blog vient de WordPress, où la pagination s'écrit /rubrique/page/2/, alors que notre CMS actuel emploie en interne une autre forme. Nous avons délibérément conservé la forme historique côté public, avec une traduction faite au niveau du serveur. Ce n'est pas de la nostalgie : une migration produit déjà assez de ruptures, et changer en plus la forme des adresses paginées revient à créer plusieurs milliers de redirections supplémentaires, sur des pages dont on vient précisément de décider qu'elles ne méritaient pas l'attention du moteur. Là où une URL peut rester identique sans coût, elle doit rester identique. Cette forme d'adresse s'accompagnait autrefois d'un balisage dédié, les attributs de liaison entre pages d'une même série, que Google a cessé d'exploiter en 2019 ; il reste utile de comprendre ce qu'ils faisaient et ce qui les a remplacés, et nous avons consacré un article aux balises de pagination et à la façon dont les moteurs les interprètent. Nous avons d'ailleurs fait les frais de cette mécanique : une manipulation malheureuse du fichier de configuration du serveur a fait disparaître ces règles de traduction, et toute la pagination du blog est passée en erreur 404 sans que rien ne le signale, ni le CMS, ni les outils de suivi, puisque ces pages n'apportent aucun trafic. C'est le revers de la médaille, à force de les traiter comme secondaires, on ne les surveille plus. Un contrôle mensuel de quelques adresses paginées coûte deux minutes et évite de découvrir la panne par hasard.

Les autres pages produites par la mécanique du blog

La pagination n'est que la partie visible. Un moteur de blog fabrique, sans qu'on le lui demande, toute une famille de pages dont la logique est identique : des listes d'articles assemblées par un critère, sans texte propre. Les archives d'auteur en sont l'exemple le plus net, puisque sur un site où un seul rédacteur signe l'essentiel des publications, l'archive de cet auteur est une copie quasi conforme de l'index du blog. Nous les redirigeons vers le blog en 301, sans noindex ni canonique : une redirection franche, parce que ces adresses n'ont aucune raison de continuer d'exister. Le raisonnement vaut pour les archives par date, qui regroupent les articles d'un mois sans autre rapport entre eux que le calendrier, et pour les pages d'étiquettes lorsqu'elles doublonnent les rubriques. La question à se poser est toujours la même : cette page répond-elle à une intention de recherche que rien d'autre sur le site ne couvre ? Si la réponse est non, elle relève de la navigation, pas de l'index. La nuance est réelle, cela dit : une page d'étiquette peut parfaitement mériter sa place quand elle correspond à un vrai sujet, transversal aux rubriques, et qu'on l'a dotée d'un texte de présentation. Ce n'est plus alors une page machine, c'est une page éditoriale qui se trouve utiliser le mécanisme des étiquettes. Le critère n'est pas le type de page, c'est ce qu'on a mis dedans.

Ce que nous vérifions ensuite

Une modification de canonique ne se constate pas le lendemain, et trois points méritent d'être suivis dans les semaines qui suivent. Dans la Search Console, si Google suit notre indication, les pages paginées basculent en « Page en double, sans URL canonique sélectionnée par l'utilisateur » et sortent de l'index ; si elles y restent malgré tout, c'est que le signal est contredit ailleurs, généralement par un sitemap qui les liste encore ou par un lien interne qui les traite comme des destinations à part entière. Dans les journaux du serveur, la fréquence de passage sur les pages de liste doit décroître au profit des articles : c'est le seul indicateur qui mesure vraiment le budget d'exploration, tout le reste en est une approximation. Dans le trafic, enfin, il ne doit rien se passer. Les pages de liste n'apportaient pas de visites entrantes, et si le trafic baisse après ce changement, c'est que le maillage interne n'a pas pris le relais : le problème est là, pas dans la canonique.

En résumé

Trois gestes, dans cet ordre : retirer le texte éditorial des pages de liste suivantes, faire pointer leur canonique vers l'index de la rubrique, et compenser par un maillage interne réel doublé d'un plan de site complet. Les deux premiers prennent une heure, le troisième est un travail permanent, et c'est lui qui décide si l'ensemble tient ou s'écroule. Aucune de ces décisions n'améliore un positionnement à elle seule ; elles servent à autre chose, faire en sorte que ce que Google connaît de votre site corresponde à ce que vous avez réellement à offrir, et rien d'autre.