# Pagination et SEO : la fin de rel=next/prev, que reste-t-il à faire ? > Google a cessé de tenir compte de rel=next et rel=prev il y a plusieurs années déjà. Pourtant, ces attributs traînent encore dans de nombreux thèmes WordPress. Que faire à la place ? - Auteur : Clément Hadrot - Publié le : 2022-01-19 - Mis à jour le : 2022-01-19 - Catégorie : SEO & GEO - URL : https://wpmoderne.dev.wordpress-developpement.fr/seo/pagination-seo-fin-rel-next-prev/ ## L’essentiel - rel=next et rel=prev ne sont plus pris en compte par Google depuis 2019 - Chaque page paginée doit rester indexable individuellement - Le contenu unique par page compte plus que la balise elle-même En reprenant la maintenance d'un thème WordPress vieux de plusieurs années, j'ai retrouvé dans le fichier `header.php` un appel fidèle à `the_posts_pagination_head()`, une fonction qui génère justement les balises `` et `` pour signaler la page précédente et la page suivante d'une archive. Techniquement, rien de cassé. Sur le plan du référencement en revanche, cette balise n'a plus aucun effet depuis plusieurs années, un fait moins connu qu'il ne devrait l'être. Google a confirmé en mars 2019 qu'il ne tenait plus compte de `rel=next` et `rel=prev` pour comprendre les séquences de pagination, alors même que ces attributs restaient recommandés par la documentation officielle depuis leur introduction presque dix ans plus tôt. Autant dire que la question mérite d'être reposée : que faut-il réellement faire pour la pagination d'une archive WordPress aujourd'hui ? ## Pourquoi Google a abandonné ce signal La logique initiale de `rel=next`/`rel=prev` reposait sur l'idée qu'une série de pages paginées formait un contenu logiquement continu, et que Google devait privilégier l'indexation de la première page comme point d'entrée principal. En pratique, Google a constaté que les moteurs de recherche géraient très bien la pagination sans ce signal explicite, en analysant simplement le contenu réel de chaque page et sa structure de liens. La fonction native `the_posts_pagination_head()` continue pourtant d'exister dans le cœur de WordPress et de générer ces balises quand un thème l'appelle, pour des raisons de compatibilité historique. Leur présence n'est ni nuisible ni utile : elle est simplement devenue neutre pour le référencement. ## Ce qui compte réellement aujourd'hui > L'essentiel à retenir : rel=next et rel=prev ne sont plus pris en compte par Google depuis 2019 ; Chaque page paginée doit rester indexable individuellement ; Le contenu unique par page compte plus que la balise elle-même Sans signal explicite de séquence, chaque page paginée d'une archive (`/blog/page/2/`, `/blog/page/3/`...) est traitée par Google comme une page à part entière, évaluée sur son propre contenu. Trois points deviennent alors déterminants : - Chaque page paginée doit rester indexable, avec une balise canonical auto-référente (vers elle-même, pas vers la page 1), sauf raison précise de faire autrement. - Le contenu de chaque page doit être suffisamment distinct pour justifier son indexation propre : une liste d'articles différente, pas un doublon strict de la page précédente. - Les liens internes vers les pages profondes de pagination doivent rester accessibles, sans dépendre uniquement du bouton « page suivante », pour que l'exploration ne s'arrête pas prématurément. ## Le cas des archives WooCommerce et des facettes Le sujet se complique nettement sur des archives de boutique combinées à des filtres (prix, couleur, marque), qui peuvent générer un nombre quasi infini de combinaisons d'URL paginées. C'est un terrain suffisamment vaste pour mériter un traitement à part entière, mais le principe reste le même : sans `rel=next`/`rel=prev` pour indiquer une séquence, chaque combinaison de filtres et de page doit être pensée individuellement, avec une décision explicite sur son indexation ou non. ## Faut-il retirer the_posts_pagination_head() ? Pas nécessairement. La fonction ne cause aucun tort en soi ; elle ajoute simplement des balises devenues inertes pour Google, sans effet négatif connu sur les autres moteurs de recherche. La retirer relève davantage d'un nettoyage de code que d'une nécessité de référencement : ``` // Dans header.php, retirer cet appel devenu obsolète : // the_posts_pagination_head(); // La navigation reste gérée séparément avec : the_posts_pagination( array( 'mid_size' => 2, 'prev_text' => __( 'Précédent', 'mon-theme' ), 'next_text' => __( 'Suivant', 'mon-theme' ), ) ); ``` Notez la distinction entre `the_posts_pagination_head()` (les balises `` dans le ``, devenues sans effet) et `the_posts_pagination()` (les liens de navigation visibles pour l'utilisateur, toujours pertinents et nécessaires). ## Un audit rapide à faire 1. Vérifier dans le code source d'une archive paginée si `rel="next"` ou `rel="prev"` est encore présent : sans conséquence, mais un bon indicateur de code hérité. 2. Vérifier que chaque page de pagination a bien sa propre balise canonical, pointant vers elle-même. 3. Contrôler dans la Search Console que les pages profondes de pagination sont bien explorées, et pas seulement la première page de chaque archive. > Le jour où j'ai compris que `rel=next`/`rel=prev` ne servait plus à rien pour Google, j'ai arrêté de m'inquiéter pour cette balise et j'ai commencé à regarder la vraie question : est-ce que chaque page paginée mérite d'être indexée telle quelle ? ## En résumé Les attributs `rel=next` et `rel=prev` sont devenus un vestige technique : toujours générés par certains thèmes WordPress, mais sans plus aucun effet sur la façon dont Google traite la pagination depuis 2019. L'attention doit se déplacer vers ce qui compte réellement : une balise canonical correcte par page, un contenu suffisamment distinct d'une page à l'autre, et une exploration qui ne s'arrête pas artificiellement aux premières pages d'une archive.