Pagination et rel=next/prev et : non, rien n'a changé, finalement !

Ecrit par
le


Google nous a gratifié il y’a deux semaines d’une séquence de communication maladroite à propos des balises rel=[next/prev]. J’ai attendu quelques jours avant de vous en parler, au cas où des clarifications supplémentaires viendraient infirmer/clarifier/nuancer les propos de Google. Ce qui n’a pas manqué de se produire avec une clarification apportée au SEO Camp’us par Vincent Courson (merci Vincent).
Vous trouverez plus d’infos sur les propos de Vincent ici :
https://www.search-foresight.com/seo-campus-qa-vincent-courson-olivier-andrieu/
Le temps est donc venu de faire le point, et de préciser qu’elle est désormais la recommandation à propos de l’implémentation des balises rel=[next/prev] par Google.

L’annonce du 21 mars 2019 : les balises rel=[next/prev] ne sont plus un signal d’indexation , et ceci, depuis des mois
Il semble que Gary Illyes, l’un des porte paroles de Google, soit la personne qui a détecté que, bien que les balises rel=[next/prev] soient recommandées officiellement pour faire indexer les contenus paginés comme s’il s’agissait d’une seule page, elles n’étaient en réalité pas utilisées du tout. Et ceci depuis des mois.
L’annonce officielle sur Twitter parle juste sur un ton badin d’un nettoyage de printemps : « alors que nous étions en train d’évaluer nos signaux d’indexation, nous avons décidé de retirer les rel=next/prev ». Et de continuer en recommandant de réaliser des pages « viewall », c’est à dire des pages présentant tout le contenu sur une seule page, au lieu de la fragmenter en plusieurs morceaux reliés par une pagination.

Sauf que personne ne comprend vraiment ce que Google appelle un signal d’indexation (c’est probablement une information que Google peut utiliser pour savoir quoi indexer dans une page web). Et que dans la plupart des cas, les pages « view all » son trop lourdes pour être implémentées.
Une communication mal comprise
L’annonce, ainsi que le retrait des pages de support sur les rel=[next/prev], a produit un émoi certain. Interrogé sur le sujet, John Mueller dans un tweet précise que « Google ne les utilise pas du tout ».
Le problème, c’est que la majorité des gens ont compris que Google ne supportait pas les balises next/prev, et qu’il fallait les retirer ! Sauf que … ce n’est pas ça du tout!
Rétropédalage : laissez les balises next/prev en place !
Face aux réactions des webmasters, un peu dérouté d’apprendre qu’on leur pousse une reco depuis des années pour rien, mais en oubliant de leur dire quoi faire exactement, John Mueller a rectifié les choses : ok, Google n’utilise plus ce signal d’indexation, mais cela reste une bonne pratique de les avoir dans une pagination, notamment parce que c’est par exemple nécessaire selon les normes d’accessibilité !
Qui plus est, Vincent Courson a apporté une précision importante jeudi dernier : les urls contenues dans les balises rel=[next/prev] sont exploitées par Googlebot pour explorer les sites. Bref, elles sont supportées côté crawl, et pas côté indexation. La nuance est importante.
C’est quoi la reco du coup ?
Du coup la recommandation ne change pas :
Si vous avez des contenus paginés, il faut ajouter des balises rel=[next/prev]. Cela reste une bonne pratique. Les autres moteurs comme Bing ont expliqué qu’ils exploitaient l’information contenue dans ces balises, et Google s’en sert pour découvrir les urls des pages incluses dans une pagination.
Ce qui change juste, c’est que le « gain » espéré côté indexation (à savoir que Google « concatène » virtuellement les fragments d’une pagination en une page unique) n’existe pas. Comme ce mécanisme était ignoré de la plupart des gens, cela ne devrait créer une frustration que chez les experts en référencement (du coup on se dit qu’une communication plus habile était possible).
Nous aborderons de façon complète les recommandations pour bien gérer les contenus paginés lors de notre prochain petit déjeuner le 18 avril : inscrivez-vous, il reste encore des places, mais elles partiront vite.
Inscrivez-vous au petit déjeuner du 18 avril :
https://www.search-foresight.com/matinee-conference-seo-sea-et-petit-dejeuner-le-18-avril-paris/
En attendant, voici quelques bonnes pratiques:

  • implémentez les balises rel=[next/prev]. Prenez garde à les implémenter correctement, notamment assurez vous que les urls dans ces balises soient bien les « vraies » urls affichées ailleurs dans la navigation
  • créez autant que possible des moyens d’accéder aux contenus sans avoir besoin de les découvrir par une pagination : par exemple via une catégorisation plus complète et plus fine
  • optimisez vos liens de pagination (les liens sur les numéros de page), pour éviter d’avoir des pages trop profondes dans votre pagination
  • laissez Google découvrir vos paginations : pas de noindex sur les pages paginées, ne les bloquez pas dans le robots.txt, pas de canonical depuis les pages paginées vers la première page etc…
  • si vous voulez implémenter une long scrolling page : c’est possible, mais uniquement en utilisant la méthode pushstate() comme décrit dans cette demo : https://pushstate.search-foresight.com/infinite.php
  • surveillez dans vos logs si toutes vos pages paginées sont bien crawlées. Si ce n’est pas le cas, ce n’est pas forcément grave, mais cherchez à savoir si cela empêche la découverte des urls présentes dans ces pages non crawlées, et corrigez le problème :créez un chemin alternatif pour que Google trouve ces pages et/ou utilisez le sitemap XML. Vous pouvez aussi essayer d’agir pour que Google change son comportement de crawl et explore TOUTES les pages paginées, mais c’est souvent plus difficile.

Notez-bien que ces recos sont les mêmes depuis de nombreuses années : en dépit de l’émoi suscité par les annonces de « retrait » effectuées par Google, rien n’a changé !