Canonical et pagination : éviter les pièges d'indexation

Vous avez tous les voyants au vert dans votre CMS : canonical renseignée, sitemap à jour, contenu unique. Et pourtant, dans Search Console, les pages 4, 5 et 6 de vos catégories ne reçoivent presque jamais de visites. Le problème n'est pas votre contenu. C'est la manière dont vous avez configuré la canonical sur vos pages paginées, et les moteurs de recherche vous le font payer.

Je le vois passer en audit à chaque fois, ou presque. Un développeur bien intentionné, un plugin SEO qui applique un réglage "par défaut" sans réfléchir, et voilà des dizaines de pages profondes rayées de l'index. La pagination et la balise canonical sont deux mécanismes simples pris isolément. Combinés, ils forment l'un des pièges d'indexation les plus fréquents et les plus silencieux du référencement technique.

Pagination et canonical : le piège d'indexation qui coûte des pages entières

Prenons une catégorie de blog avec 12 pages de 20 articles. Sur la page 1, le plugin pose une canonical vers elle-même. Très bien. Puis, sur les pages 2 à 12, il applique un réglage « consolider vers la page principale » et pointe la canonical vers la page 1.

Résultat : vous venez de dire au moteur que les pages 2 à 12 sont des doublons de la page 1. Il les exclut de l'index. Et tout le contenu situé au-delà des 20 premiers articles devient invisible. Sur un site d'e-commerce ou un blog actif, cela peut représenter 80 % de votre catalogue.

Pourquoi cette erreur arrive-t-elle si souvent ?

Parce qu'elle part d'une intention logique. La personne qui configure se dit : « la page 2 n'est qu'une vue différente de la même liste, donc elle est une variante de la page 1 ». Sauf que ce raisonnement ne tient pas. La page 2 n'affiche pas les mêmes articles. Ce sont des contenus distincts. Une canonical qui pointe ailleurs déclare un doublon là où il n'y en a pas.

La règle est simple, et je la répète à chaque audit : une page paginée se déclare elle-même. La page 2 pointe vers la page 2, la page 3 vers la page 3. Point. Si votre plugin ne le fait pas par défaut, désactivez l'option et corrigez à la main.

Comment vérifier que vos canonicals sont correctes ?

Trois vérifications suffisent sur un site de taille moyenne :

• Ouvrez une page 2 dans le navigateur, affichez le code source (Ctrl+U), cherchez la balise rel="canonical" et vérifiez qu'elle pointe vers l'URL que vous êtes en train de consulter.
• Répétez l'opération sur la dernière page de la série. C'est souvent là que les choses cassent.
• Dans Search Console, utilisez l'inspection d'URL sur une page profonde et regardez le champ « URL canonique déclarée par l'utilisateur ».

Le test en direct de l'outil vous montre aussi l'URL canonique que Google a retenue. Si elle diffère de la vôtre, vous avez un problème de signal.

Une pagination doit-elle être indexée, oui ou non ?

Oui. Et cette réponse tranche avec ce qu'on lit parfois.

La pagination remplit une fonction de découverte : elle permet au robot de suivre des liens vers les contenus profonds. Si vous la désindexez ou si vous consolidez par canonical, le robot peut toujours suivre les liens (il ne les ignore pas forcément), mais il n'indexera pas les pages cibles aussi facilement. Or ce sont ces cibles qui portent vos articles, vos fiches produit, vos pages profondes.

Sur un projet dont je suivais le suivi, une catégorie comptait 340 articles répartis sur 17 pages. Le plugin consolidait toutes les canonicals vers la page 1. Après correction — canonical auto-référente sur les 17 pages — le nombre d'URL indexées de cette catégorie est passé de 21 à 340 en six semaines. Le trafic organique de la catégorie a presque triplé sur la période. La correction elle-même a pris une heure.

L'erreur inverse : mettre du noindex sur la pagination

C'est l'autre travers, et il vient d'une peur ancienne : celle du contenu dupliqué. Sauf que la pagination n'est pas du contenu dupliqué. Ce sont des vues différentes de la même collection, avec des contenus distincts affichés. Le moteur sait le gérer.

Poser un noindex sur les pages 2 et suivantes coupe la découverte des contenus profonds. Franchement, je n'ai jamais vu ce choix améliorer quoi que ce soit. Je l'ai vu en revanche faire chuter le nombre d'URL indexées d'un site de e-commerce de 40 %.

rel=next/prev : ce qui marche encore, ce qui ne marche plus

Il faut trancher ce point, parce qu'on lit tout et son contraire. Certains articles le présentent encore comme « la méthode efficace pour la pagination ». C'est faux sur le plan de l'indexation.

Depuis 2019, Google a officiellement indiqué ne plus utiliser rel="next" et rel="prev" comme signal d'indexation. Les deux balises ne servent plus à regrouper des pages en une série reconnue par le moteur. Beaucoup de plugins continuent pourtant de les injecter en les présentant comme une solution.

Alors, faut-il les supprimer ? En pratique, elles restent utiles dans deux cas :

• Elles aident certains robots (y compris Bing, plus tolérant sur le sujet) à comprendre la structure d'une série.
• Elles documentent une pagination pour l'humain qui lit le code — un bénéfice de maintenance, pas de référencement.

Si votre CMS les génère déjà, laissez-les. Ne comptez pas dessus pour régler un problème d'indexation. Le signal qui compte, c'est la canonical.

Tableau des signaux : ce qui compte, ce qui ne compte plus

Signal	Effet sur l'indexation	Recommandation
Canonical auto-référente	Fort — déclare la page comme unique	À appliquer sur toutes les pages paginées
Canonical vers page 1	Négatif — exclut la page de l'index	À proscrire
noindex sur pagination	Négatif — coupe la découverte	À éviter
rel=next/prev	Nul depuis 2019	Facultatif, jamais une solution
URL structurée /page/2/	Positif — lisibilité et crawl	À privilégier
URL avec paramètre ?page=2	Neutre à risque	Acceptable, mais moins propre

URL, filtres et tris : distinguer ce qui doit être indexé

La pagination mérite d'être indexée. Les filtres et les tris, non. Nuance essentielle, et souvent confondue.

Un filtre « couleur=rouge » ou un tri « prix croissant » génère des URL très proches de la page de catégorie, avec des contenus quasi identiques. Si vous laissez ces URL indexables, vous créez des centaines de variantes qui diluent votre budget de crawl et multiplient les signaux contradictoires.

Quelle structure d'URL choisir pour la pagination ?

Deux formats dominent : ?page=2 (paramètre) et /page/2/ (segment de chemin). Les deux fonctionnent. Le second est plus lisible, se partage mieux et évite les collisions avec d'autres paramètres. Je privilégie toujours /page/. Et je m'assure que les fragments # ne sont jamais utilisés pour la pagination, un fragment n'étant pas envoyé au serveur.

Pour les filtres, posez un noindex ou une canonical vers la catégorie mère (ici, la canonical vers la catégorie est légitime, parce que la page filtrée est bien une variante). Ce qui est interdit pour la pagination est correct pour les filtres. La différence tient à la nature du contenu affiché.

Diagnostiquer le problème dans Search Console

Un signal clair dans l'interface : le rapport « Pages » de Search Console, section « Non indexées ». Deux motifs doivent vous alerter :

1. « Autre page avec balise canonical » — Google a trouvé votre page, mais une autre URL se déclare comme sa version canonique. C'est le symptôme typique d'une canonical mal configurée.
2. « Explorée, actuellement non indexée » — le robot est passé, a lu la page, mais a choisi de ne pas l'indexer. Souvent lié à la qualité ou à un excès de signaux contradictoires.

L'arbre de décision est simple. Cliquez sur une URL concernée, ouvrez l'inspection d'URL, comparez « URL canonique déclarée par l'utilisateur » et « URL canonique sélectionnée par Google ». Si les deux diffèrent, vous tenez votre cause. Corrigez la balise, puis demandez une réindexation via le test en direct.

Que se passe-t-il si canonical et noindex se contredisent ?

Les deux signaux s'annulent. Une page portant à la fois noindex et une canonical vers une autre URL envoie un message contradictoire : « ne m'indexe pas » d'un côté, « considère plutôt cette autre page comme ma version canonique » de l'autre. Le robot, face à cette incohérence, peut ignorer les deux et faire ce qu'il veut. Dans mon expérience, il choisit souvent la solution la plus radicale : ne rien indexer du tout.

Choisissez un seul signal. Si la page ne doit pas être indexée, mettez noindex et laissez la canonical auto-référente. Si elle doit l'être, retirez le noindex et gardez la canonical auto-référente. Ne mélangez jamais.

Questions fréquentes sur l'indexation et la pagination

Quelles sont les raisons pour lesquelles une page web peut ne pas être indexée par un moteur de recherche généraliste ?

Pour comprendre, il faut distinguer trois étapes : la découverte, l'indexation et le classement. Une page peut échouer à n'importe laquelle.

Les causes les plus fréquentes : la page n'est pas découverte (aucun lien entrant, sitemap absent), elle est bloquée par une balise noindex ou un fichier robots.txt, une canonical pointe vers une autre URL, le contenu est jugé trop proche d'une autre page, ou la page n'a pas encore été explorée. Un site peut parfaitement exister sur Internet sans être visible dans les moteurs, c'est même un phénomène courant sur les sites récents.

Quel code source pour ne pas référencer une page ?

La balise à utiliser est <meta name="robots" content="noindex">, placée dans la section <head> de la page. C'est la méthode la plus fiable, car elle est lue au niveau de la page elle-même. Attention : ne combinez pas noindex avec un blocage via robots.txt. Le robot ne pourra pas lire le noindex s'il ne peut pas accéder à la page. Et ne confondez pas avec rel="canonical", qui n'est pas un outil de désindexation.

Qu'est-ce que le principe de l'indexation ?

L'indexation est l'étape où le moteur analyse une page explorée et l'enregistre dans sa base pour pouvoir la proposer en résultats. Elle intervient après la découverte (via les liens ou le sitemap) et avant le classement (qui décide de la position). Une page non indexée ne peut pas être classée, quelle que soit sa qualité. C'est pourquoi une erreur de canonical sur une page paginée est si coûteuse : elle empêche l'entrée dans l'index de tout un contenu qui existe pourtant.

Comment désindexer une page sur Google ?

La méthode propre : ajoutez un noindex, puis attendez que le robot repasse (ou demandez une réindexation via l'inspection d'URL). Le retrait de l'index prend quelques jours à quelques semaines. Une méthode plus rapide existe via l'outil de suppression d'URL dans Search Console, mais elle est temporaire (environ six mois). Pour retirer du contenu définitivement, le noindex reste la solution durable.

La checklist que je déroule avant chaque mise en production

Rien de spectaculaire, mais ces vérifications évitent 90 % des incidents d'indexation liés à la pagination :

• Chaque page paginée porte une canonical auto-référente. Vérifié sur la page 2 et sur la dernière page.
• Aucune canonical ne pointe vers la page 1 d'une série.
• La pagination n'est pas en noindex.
• Les filtres et les tris sont en noindex ou en canonical vers la catégorie mère.
• Aucune page ne combine noindex et canonical vers une autre URL.
• Le sitemap ne contient que des URL canoniques et indexables.

Un dernier point, souvent négligé : ne faites pas confiance à votre plugin SEO sur ce terrain. Les réglages « par défaut » de nombreux plugins appliquent des règles pensées pour du contenu dupliqué classique, pas pour la pagination. Vérifiez le code source. C'est fastidieux. C'est aussi la seule manière de savoir ce que votre site raconte réellement aux robots.

Et si vous ne devez retenir qu'une chose de tout ceci : la pagination est un contenu, pas un doublon. Tant que cette idée n'est pas claire, les erreurs de canonical reviendront. Une fois qu'elle l'est, tout le reste en découle.