Un blog de soixante articles, à douze par page, compte cinq pages. La première en liste douze ; on n’atteint les quarante-huit autres que par la pagination. Si le robot d’un moteur de recherche ne peut pas la suivre, vos anciens articles ne sont accessibles que par votre sitemap et par les liens qui pointent vers eux depuis ailleurs, et un moteur de recherche a peu de raisons de bien classer un article vers lequel rien ne pointe.
La plupart des paginations de blog sont construites d’une façon que les robots ne peuvent pas suivre, ou leur disent de ne pas s’en donner la peine. J’ai trouvé l’une de ces erreurs sur mon propre blog en le reconstruisant ce mois-ci. Voici les quatre plus courantes, ce qu’il faut faire à la place, et une checklist à la fin.
Erreur n° 1 : « Charger plus » sans URL
Un bouton « Charger plus » ou un défilement infini qui récupère la page suivante en JavaScript est agréable à utiliser, et invisible pour les robots. La documentation de Google indique qu’il n’explore en général que les URL présentes dans le href des éléments <a>, que ses robots ne cliquent pas sur les boutons, et que la recherche Google ne fait pas défiler la page et n’interagit pas autrement avec elle.
Si le seul moyen d’atteindre l’article 13 est de cliquer sur « Charger plus », alors pour un robot, l’article 13 n’est lié nulle part sur votre blog.
À la place : donnez une URL à chaque page, /blog?page=2 ou /blog/page/2, et pointez vers elle avec un vrai <a href>. Un bouton « Charger plus » peut toujours s’y ajouter : affichez les liens de pagination dans le HTML, et laissez JavaScript intercepter le clic pour ajouter la page suivante sur place. Les robots suivent le lien ; les visiteurs ont le bouton.
Erreur n° 2 : une pagination faite de boutons
Le même problème, sous une autre forme :
<button onClick={() => setPage(page + 1)}>Suivant</button>Il change ce que la page affiche sans changer l’URL. Les robots ne peuvent pas le suivre, un visiteur ne peut ni partager la page trois ni y revenir, et le bouton Retour la saute purement et simplement.
À la place : la pagination, c’est de la navigation, donc faites-en des liens. Dans un framework à rendu serveur, cela veut aussi dire que la page ?page=2 est rendue sur le serveur, avec les articles dans le HTML : c’est ce que lit un robot.
Erreur n° 3 : toutes les pages canoniques vers la première
Celle-ci ressemble à une bonne pratique, et c’est pour ça qu’on la voit partout :
<!-- sur /blog?page=2, /blog?page=3, ... -->
<link rel="canonical" href="https://example.com/blog" />Une balise canonical dit : « cette page est un doublon ; la vraie est là-bas ». La page deux n’est pas un doublon de la page un : elle liste d’autres articles. Dire le contraire à un moteur de recherche l’invite à retirer la page deux de son index, et avec elle les seuls liens vers ces articles.
Les recommandations de Google sur la pagination le disent explicitement : n’utilisez pas la première page d’une série comme page canonique, donnez plutôt à chaque page sa propre URL canonique.
J’avais ce bug. Jusqu’à cette version, chaque page de mon propre blog sur kookee.dev, ?page=2 compris, déclarait /blog comme URL canonique. Désormais, chaque page non filtrée est canonique vers elle-même : la page un vers /blog, la page deux vers /blog?page=2.
À la place : une canonical auto-référente sur chaque page de la série.
Erreur n° 4 : noindex sur les pages après la première
La version plus ancienne du même réflexe : écarter de l’index les pages de liste « pauvres » avec noindex, follow, pour que les articles soient indexés et pas les listes.
Le piège, c’est le follow. John Mueller, de Google, a expliqué qu’une page laissée assez longtemps en noindex finit par être abandonnée complètement, et que ses liens ne sont plus suivis : noindex, follow finit donc par fonctionner comme noindex, nofollow. Or ces liens sont le chemin vers vos anciens articles.
À la place : laissez les pages être indexées. Une page de liste avec douze titres d’articles et leurs extraits n’est pas du contenu pauvre, et une recherche sur le sujet d’un article a bien plus de chances d’arriver sur l’article que sur la liste qui pointe vers lui. La documentation de Google précise aussi que les pages d’une série peuvent partager le même titre et la même description : il n’y a donc pas de problème de titres en double à régler.
Et les filtres ?
Les tags, les catégories, la recherche et les ordres de tri multiplient vos URL : /blog?tag=react&page=3&q=hooks est aussi une page. Elles n’ont pas toutes besoin d’être dans un index, et un robot qui parcourt toutes les combinaisons passe son temps sur votre site de la façon la moins utile qui soit.
Deux options raisonnables :
Rendre les vues filtrées canoniques vers la liste non filtrée. C’est ce que je fais :
/blog?tag=reactet/blog?tag=react&page=2déclarent/blogcomme URL canonique, tandis que les pages non filtrées sont canoniques vers elles-mêmes. Chaque article reste accessible par la série non filtrée, et les combinaisons restent à l’écart.Donner leurs propres chemins aux filtres que vous voulez voir classés. Si une page de tag est une page d’atterrissage à part entière, traitez-la comme telle : à
/blog/tag/react, avec une canonical auto-référente et sa propre pagination, et gardez les filtres en paramètres d’URL pour tout le reste.
Les recommandations de Google autorisent aussi le noindex sur les vues filtrées et triées autrement. Quel que soit votre choix, appliquez-le aux filtres, pas à la pagination de la liste principale.
rel="next" et rel="prev"
Google a annoncé en 2019 qu’il ne les utilisait plus. Sa documentation note que d’autres moteurs de recherche peuvent encore s’en servir, mais ils ne remplacent pas les liens sur la page.
Quelles pages lier
Une barre de pagination avec tous les numéros de page ne tient pas la distance, et une barre avec seulement « Précédent » et « Suivant » met la page quarante à quarante clics. Le compromis courant : la première page, la dernière, et une de chaque côté de la page en cours, avec des points de suspension pour chaque trou.
‹ Précédent 1 … 6 [7] 8 … 15 Suivant ›Avec un lien vers la dernière page, visiteurs et robots sautent directement à vos plus anciens articles, et la série se parcourt par les deux bouts. La pagination ne garantit pas pour autant qu’un robot atteigne tout, et c’est le rôle du sitemap : listez-y chaque article, avec un lastmod qui reprend la date de sa dernière modification importante.
Deux détails d’accessibilité ont leur place dans le même composant :
Enveloppez-le dans un
<nav>avec un libellé comme « Pagination », et marquez la page en cours avecaria-current="page".Aux extrémités, affichez « Précédent » et « Suivant » comme du texte désactivé, pas comme des liens vers nulle part ou vers la page où l’on se trouve déjà.
Une checklist
Chaque page de la liste a sa propre URL, et ses articles sont dans le HTML rendu côté serveur.
La pagination est faite de liens
<a href>. Un bouton « Charger plus », si vous en avez un, enrichit ces liens au lieu de les remplacer.Chaque page de la liste non filtrée a une canonical auto-référente. La page deux n’est pas canonique vers la page un.
Pas de
noindexsur les pages de la liste principale.Les vues filtrées et triées sont canoniques vers la liste non filtrée, ou en noindex, ou promues en vrais chemins si vous voulez qu’elles soient classées.
Le sitemap liste chaque article.
Le composant React Pagination de Kookee affiche ce schéma sous forme de liens : la première et la dernière page, une page de chaque côté de la page en cours, des points de suspension, une navigation avec libellé et des extrémités désactivées. Il fonctionne dans un Server Component et avant le chargement de JavaScript, et getPaginationItems vous donne la même fenêtre de pages pour votre propre balisage. Consultez Créer un blog avec les composants React pour une page de liste complète, avec filtres par tag et recherche.