Un blog qui publie depuis deux ans a forcément des pages 2, 3, 4 de ses archives. Google les crawle, les indexe parfois, et la question revient sans cesse : faut-il les laisser telles quelles, les canoniquer sur la page 1, ou les bloquer ? La réponse dépend de ce que ces pages contiennent réellement.
Sommaire
- Pourquoi la pagination pose problème en SEO
- Canonical sur la page 1 : la fausse bonne idée
- Self-referencing canonical : la bonne pratique 2026
- rel= »next »/ »prev » : pourquoi Google les ignore depuis 2019
- Enrichir les pages paginées plutôt que les cacher
- Cas particuliers : filtres, recherche interne, infinite scroll
Pourquoi la pagination pose problème en SEO
Soyons précis : la pagination en elle-même n’est pas un problème. Le problème, c’est ce qu’on en fait mal. Un site WordPress avec 40 articles génère mécaniquement des archives sur plusieurs pages, sur la home, sur les catégories, sur les tags, parfois sur les auteurs. Chacune de ces pages est une URL crawlable, avec un contenu quasi identique (mêmes extraits, même sidebar) à sa voisine.
Google traite ça correctement dans l’immense majorité des cas : il comprend qu’il s’agit d’une série paginée et évite le duplicate content pur. En revanche, il arbitre lui-même quelle page indexer, et ce n’est pas toujours celle que vous auriez choisie. Sans intervention de votre part, une page 3 d’archive peut se retrouver indexée à la place de la page 1, ou pire, absorber du budget de crawl sans jamais apporter de trafic.
Canonical sur la page 1 : la fausse bonne idée
C’est le réflexe le plus répandu, et c’est une erreur. Poser une balise <link rel="canonical"> pointant systématiquement vers la page 1 sur toutes les pages suivantes revient à dire à Google : « ignore le contenu des pages 2, 3, 4 ». Or ces pages contiennent des articles différents de la page 1. Google finit par déprioriser leur crawl, ce qui peut retarder l’indexation de vos publications récentes reléguées en page 2 après quelques mois.
Donnée fraîche
Google a officiellement clarifié en 2019 (via John Mueller) que les balises rel="next"/rel="prev" ne sont plus utilisées pour comprendre la pagination : chaque page est traitée comme une URL indépendante, avec ses propres signaux de qualité et de pertinence.
Self-referencing canonical : la bonne pratique 2026
La règle qui fonctionne, et qui est celle que j’applique systématiquement en audit : chaque page paginée pointe sa balise canonical vers elle-même. La page 2 se canonique elle-même, la page 3 aussi. C’est le comportement par défaut de Yoast SEO et de RankMath depuis plusieurs versions ; vérifiez simplement qu’aucune configuration manuelle ne l’écrase.
- Vérifier le canonical réelInspectez le code source de vos pages /page/2/, /page/3/ : le canonical doit contenir la même URL que celle affichée dans la barre d’adresse, jamais l’URL de la page 1.
- Contrôler le title et la meta descriptionYoast et RankMath ajoutent automatiquement « Page 2 sur 8 » au title des pages paginées. Ne le supprimez pas : ça évite un duplicate title pur entre les pages de la série.
- Laisser l’indexation ouverte, sauf exceptionNe mettez jamais un
noindexglobal sur toutes les pages 2+ : vous couperiez l’accès à du contenu légitime que Google pourrait vouloir indexer, notamment sur un blog volumineux.
rel= »next »/ »prev » : pourquoi Google les ignore depuis 2019
Beaucoup de guides continuent de recommander l’ajout de ces balises dans le <head>. Ce n’est plus utile pour Google, qui s’appuie désormais sur l’analyse de la structure de liens internes et du contenu pour comprendre qu’une série de pages appartient au même ensemble. Ça reste en revanche un signal accessibilité utile pour certains lecteurs d’écran : vous pouvez les garder sans risque, mais n’attendez plus d’effet SEO direct.
Ce qui compte réellement, c’est la cohérence du maillage : chaque page paginée doit être atteignable depuis un lien crawlable (pas uniquement du JavaScript côté client), et la numérotation doit rester stable dans le temps pour ne pas générer de 404 en cascade quand un article est supprimé.
Enrichir les pages paginées plutôt que les cacher
Sur les sites où la pagination fait vraiment mal au SEO, ce n’est presque jamais un problème technique : c’est un problème de contenu. Une page 5 d’archive avec dix extraits de 20 mots chacun n’a aucune raison d’être indexée sur une requête concurrentielle. Deux options s’offrent à vous : réduire le nombre de pages en affichant plus d’articles par page (12 à 15 au lieu de 5), ou accepter que les pages profondes de la pagination restent en dehors du top des résultats, ce qui est normal.
| Situation | Action recommandée |
|---|---|
| Page 2, 3 d’une catégorie active | Laisser indexable, canonical self-referencing |
| Page 8+ d’une vieille archive | Laisser en place, ne pas forcer un noindex : Google la déprioritise naturellement |
| Pagination générée par un filtre AJAX sans URL propre | Vérifier qu’une URL crawlable existe, sinon le contenu reste invisible |
Cas particuliers : filtres, recherche interne, infinite scroll
Sur un blog e-commerce ou avec des filtres de catégorie combinés, la pagination peut se démultiplier avec des paramètres d’URL. Là, la règle change : ces combinaisons doivent être bloquées au crawl via un robots.txt correctement configuré, sinon vous générez un nombre infini d’URLs paginées à faible valeur qui diluent le budget de crawl.
L’infinite scroll (défilement infini en JavaScript) pose un problème différent : sans URLs individuelles pour chaque « page » chargée dynamiquement, Googlebot ne voit souvent que le premier lot de contenu. Si vous l’utilisez, assurez-vous qu’une pagination classique reste accessible en parallèle, ne serait-ce que pour le crawl.
Cette logique de pagination rejoint directement celle des pages d’archives WordPress : les catégories, tags et dates génèrent toutes leur propre pagination, avec les mêmes arbitrages à faire page par page.
En pratique
La pagination n’est un problème que si elle est ignorée. Un audit rapide (canonical self-referencing, title différencié, pas de blocage inutile) suffit dans 90 % des cas à neutraliser le sujet. Sur les sites avec des taxonomies mal structurées, la pagination amplifie souvent un problème déjà présent en amont : mieux vaut corriger la racine avant de patcher les symptômes. Si le doute persiste sur votre configuration, faites appel à un spécialiste SEO WordPress pour un contrôle ciblé plutôt que de multiplier les réglages au hasard.
Faut-il mettre un noindex sur les pages 2, 3, 4 des archives ?
Non par défaut. Le noindex global sur la pagination coupe l’accès à du contenu légitime. Réservez-le à des cas précis : pagination générée par des filtres à faible valeur, ou pages dupliquées par un bug technique identifié.
Le canonical doit-il pointer vers la page 1 ou vers la page elle-même ?
Vers elle-même (self-referencing). Chaque page paginée contient un contenu distinct : la canoniquer vers la page 1 revient à demander à Google de l’ignorer, ce qui peut retarder l’indexation d’articles récents.
Les balises rel= »next » et rel= »prev » servent-elles encore au SEO ?
Non. Google a confirmé en 2019 ne plus les utiliser pour interpréter la pagination. Elles restent utiles pour l’accessibilité mais n’ont plus d’effet direct sur le crawl ou l’indexation.
Combien d’articles afficher par page pour limiter les problèmes de pagination ?
Entre 10 et 15 sur un blog classique. Ce réglage (Réglages > Lecture sur WordPress) réduit mécaniquement le nombre de pages paginées à gérer sans sacrifier l’expérience de lecture.
L’infinite scroll remplace-t-il avantageusement la pagination classique ?
Pas pour le SEO seul. Sans URLs individuelles crawlables pour chaque lot de contenu chargé, Googlebot peut ne voir que le premier écran. Gardez une pagination classique accessible en parallèle si vous l’utilisez.
Pour aller plus loin
Une pagination mal gérée est rarement isolée : elle traduit souvent une architecture de contenu qui n’a pas été pensée pour l’échelle. C’est exactement le type de diagnostic que je mène en audit, avec les corrections techniques qui vont avec.
À propos de l’auteur
Aymeric Maingé
Consultant SEO senior avec plus de 10 ans d’expérience, côté agence et annonceur. J’accompagne des sites WordPress, e-commerce et lead gen sur des problématiques de SEO technique, de performance web, de Core Web Vitals et d’expérience utilisateur. Mon approche croise audit terrain, priorisation métier et recommandations actionnables pour les équipes marketing et IT. Votre expert SEO WordPress.
Méthodologie utilisée
Analyse basée sur l’inspection du code source de pages paginées réelles, la documentation officielle Google sur la pagination et les clarifications publiques de John Mueller sur rel= »next »/ »prev ». Recommandations vérifiées sur des configurations Yoast SEO et RankMath courantes.
À lire aussi
– Comment sécuriser son fichier .htaccess pour améliorer le SEO et la sécurité de WordPress ?
– Faut-il indexer les archives auteurs sur WordPress ?
– Comment éviter la création de pages inutiles par les plugins et thèmes WordPress ?
– WordPress crée trop de pages faibles : comment assainir l’indexation ?