Pagination SEO Après rel=next/prev : Le manuel honnête

Cherchez « pagination SEO » et la première page est un musée. Des guides actualisés le trimestre dernier vous font toujours passer par rel="next" et rel="prev" — des balises que Google a reconnu en mars 2019 ne pas utiliser comme signal d’indexation « depuis un certain temps. » Le résultat organique du haut pour cette requête est la propre documentation de Google, une Réponse IA se trouve au-dessus, et le conseil en dessous hésite toujours sur une balise qui est morte plus longtemps que la plupart des sites qui la lisent. Ce que rien de cela ne répond, c’est la question que la personne qui cherche se pose vraiment : avec le raccourci de balisage disparu, que dois-je vraiment faire avec la page 2 jusqu’à la page 40 ?

Ce guide répond à cette question de la manière honnête : la pagination a cessé d’être un problème de balisage et est devenue un problème d’architecture. Vous choisissez délibérément l’un des trois modèles — série paginée, scroll infini, afficher tout — vous le mettez en œuvre pour que les crawlers puissent atteindre chaque élément sans se noyer dans des URL quasi-dupliquées, et ensuite vous faites la partie que tout autre guide omet : vous vérifiez dans Search Console que l’indexation s’est réellement améliorée. C’est un rayon de notre pilier SEO agentique, et il s’appuie sur la même discipline trouver → corriger → vérifier que le guide frère sur l’audit technique SEO orienté repo — la pagination n’est que la couche de cet audit où la légende a le plus mal vieilli.

La balise que tout le monde recommande encore est morte en 2019

L’historique importe parce qu’il explique pourquoi le conseil qui circule est si confus. Pendant des années, rel="next"/rel="prev" était la réponse officielle : annotez la série, et Google traiterait l’ensemble paginé comme une séquence libre, consolidant les signaux vers la première page. Puis en mars 2019, le compte Search Central de Google a annoncé — rétroactivement — que l’annotation n’avait pas été utilisée dans l’indexation depuis des années. Pas « nous l’abandonnons. » C’était déjà disparu, et personne en dehors de Google ne l’avait remarqué, parce que le web a continué de fonctionner.

Ce non-événement porte la vraie leçon. La pagination n’a jamais fonctionné à cause du balisage ; elle fonctionnait quand l’architecture sous-jacente était solide — des URL uniques, de vrais liens, des canoniques sensées — et échouait quand ce n’était pas le cas, avec ou sans balise. La retraite n’a pas changé ce que Google récompense. Elle a supprimé la confortable illusion qu’un élément <link> dans l’en-tête pouvait camoufler une architecture qui piège les crawlers ou inonde l’index de fines variantes. Il n’y a pas de raccourci à réinstaller. Il n’y a que l’architecture.

Google a retiré rel=next/prev des années avant de le dire à quelqu’un, et les classements n’ont pas cligné. Le balisage ne portait jamais le poids. C’était l’architecture — et l’architecture seule compte encore.

Ce que Google demande réellement maintenant

La documentation actuelle de pagination de Google — la page qui surclasse tous les blogs SEO sur cette requête — est courte et sans ambiguïté, et la plupart de celle-ci contredit la légende qui a survécu à 2019. Chaque page dans une série est traitée comme une page séparée, point final. De ce seul fait, les règles découlent : chaque page a besoin de sa propre URL accessible aux crawlers, les pages doivent se lier les unes aux autres séquentiellement pour qu’un crawler puisse parcourir la série, et — la règle que la plupart des sites inversent — la page 2 et au-delà ne doivent pas se canonicaliser à la page 1. Google le recommande explicitement contre, parce qu’une canonique pointant vers la page 1 indique au crawler que les pages plus profondes sont des doublons, et les éléments listés seulement sur ces pages peuvent silencieusement perdre leur chemin de crawl.

Remarquez la forme des échecs dans la colonne de gauche : chacun d’eux essaie de faire disparaître la pagination — masquer les pages profondes, les réduire à la page 1, les bloquer. La guidance documentée va dans l’autre direction : rendre la série lisible. Des URL réelles, de vrais liens, une adresse honnête par page. Ennuyeux, et correct.

Trois modèles, un choix délibéré

Chaque surface de listage — archive de blog, page de catégorie, résultats de recherche, grille de produits — est l’un des trois modèles. L’erreur n’est pas de choisir le mauvais ; c’est d’en hériter d’un thème ou d’une bibliothèque de composants et de ne jamais vérifier ce qu’il fait aux crawlers.

Série paginée — le défaut ennuyeux qui fonctionne

Pages numérotées, URL uniques, liens séquentiels. C’est le modèle autour duquel la documentation de Google est écrite, et celui par lequel commencer en cas de doute. La barre de mise en œuvre est basse mais spécifique : ?page=2 ou /page/2 comme URL réelle rendue côté serveur, une canonique auto-référencée sur chaque page, les liens suivant/précédent dans l’HTML (non injectés au clic), et la page 1 vivant à l’URL propre — avec ?page=1 canonicalisée ou redirigée vers elle pour que la racine ne concurrence pas son propre doublon. Les titres doivent différencier (« Page 3 de … »), ce qui ne coûte rien et arrête les pages paginées de se cannibaliser mutuellement pour le terme de tête.

Scroll infini — invisible sans URL réelles

Googlebot ne scrolle pas et ne clique pas sur « charger plus. » Le contenu qui n’existe qu’après un événement de scroll est du contenu qui n’existe pas, en ce qui concerne le crawling. La correction documentée par Google est le chargement paginé : tandis que l’utilisateur scrolle, mettez à jour l’URL avec l’API History pour que chaque segment de contenu ait une adresse (?page=4), et rendez ces mêmes adresses accessibles comme des liens simples pour les clients qui ne lancent pas votre gestionnaire de scroll — ce qui inclut le crawler. Si votre scroll infini ne peut pas être parcouru page par page avec JavaScript désactivé, tout ce qui se trouve sous le premier viewport est de la décoration. Sur un site que nous avons audité, une refonte de catégorie a remplacé les pages numérotées par un bouton de chargement supplémentaire ; rien d’autre n’a changé, et les éléments plus profonds du catalogue sont tombés graduellement de l’index — pas pénalisés, juste inaccessibles.

Afficher tout — excellent jusqu’à ce que ce ne soit plus le cas

Une page, chaque élément, aucune série à gérer. Pour les petits ensembles, c’est vraiment la réponse la plus propre : aucun risque de doublon, pas de problème de profondeur de crawl, une URL accumulant tous les signaux. Le mode d’échec est la physique. Une page « afficher tout » avec deux mille produits est lente pour les utilisateurs et lourde pour le rendu, et les Core Web Vitals vont le dire. La règle honnête : afficher tout quand l’ensemble complet se rend assez vite que vous seriez heureux d’y arriver depuis un résultat de recherche vous-même ; une série paginée dès que ce n’est pas le cas. Si vous exécutez les deux, choisissez-en une comme surface canonique et soyez cohérent quant à celle vers laquelle les liens internes pointent — exécuter deux routes parallèles vers les mêmes éléments est comment vous remettez à Google une énigme de duplication qu’il résoudra sans vous consulter.

Les deux modes d’échec : doublons fins et pièges de crawl

Chaque bug de pagination qui importe débouche sur l’un des deux problèmes. Le premier est la duplication fine : les mêmes éléments accessibles à plusieurs adresses. Les variantes triées (?page=2&sort=price), les variantes filtrées, le doublon ?page=1 de la racine, les paramètres de session chevauchant chaque lien de pagination. Chaque variante est une page que Google doit récupérer, rendre et dédupliquer — et quand il choisit les canoniques à l’échelle, il choisit parfois la vôtre à tort. Le correctif est la soustraction : canonicalisez les variantes de tri et de filtre à l’ordre par défaut, gardez les paramètres hors des liens de pagination, et laissez exactement une adresse par page de la série exister.

Le second est le piège de crawl : la pagination multipliée par la navigation à facettes. Vingt filtres fois cinquante pages fois quatre ordres de tri égale quatre mille URL pour une catégorie — un espace qu’un crawler peut errer pendant des semaines sans découvrir un seul nouvel élément. C’est le motif derrière la plupart des piles « Découverts — actuellement non indexés » sur les grands sites : pas un jugement de qualité, juste un crawler avec patience finie rencontrant un espace d’URL sans fond. Les pages profondes de votre série honnête entrent alors en compétition pour l’attention de crawl avec des milliers de fines permutations junk, et perdent.

La liste de contrôle de pagination orientée repo

Comme avec l’audit technique plus large, la façon la plus rapide d’auditer la pagination n’est pas une exportation de crawl — c’est de lire la source. La logique de pagination vit dans une poignée de fichiers : la route qui prend le paramètre de page, la fonction de métadonnées qui émet la canonique, le composant qui rend les liens de page. Un bug là est un bug sur chaque page que le modèle rend, et vous pouvez le savoir d’une lecture de fichier. Le crawl reste le recours pour les sites que vous ne pouvez pas lire, et la vérification que ce que le code préconise est ce que le serveur sert.

Vérifier que l’indexation s’est réellement améliorée

Voilà la moitié qu’aucun guide de pagination ne livre. Les correctifs de pagination sont inhabituellement faciles à déclarer terminés — le code fusionné, la canonique a l’air correcte en view-source — et inhabituellement difficiles à évaluer à l’œil, parce que la récompense est distributionnelle : les éléments qui étaient inaccessibles commencent à gagner des impressions, des semaines plus tard, à travers des centaines de requêtes de longue traîne que personne n’observe. Si vous ne vous engagez pas sur une métrique avant que la correction ne soit expédiée, vous ne saurez jamais si elle a fonctionné, et « fait » restera à jamais sans examen.

La discipline est le même contrat de preuve qui parcourt notre méthode de boucle fermée. Avant la correction : enregistrez la conclusion en tant que tâche, nommez la métrique qui la jugera — pour la pagination, c’est presque toujours les impressions sur les URL affectées, parce que l’accessibilité se montre d’abord comme étant affichée à tout avant de se montrer en tant que clics — et définissez une cible. Expédiez avec un horodatage et la PR. Attendez ensuite environ trois semaines : Google doit recrawler la série, re-découvrir les éléments, et accumuler assez de données de requête des deux côtés du changement pour qu’une comparaison signifie quelque chose. Relisez la métrique, filtrée aux URL d’éléments de page profonde, et écrivez le verdict : confirmé, régressé, ou inconclusif. Les chiffres d’indexation de page dans Search Console donnent une lecture de support — « Découvert — actuellement non indexé » s’écoule est ce qu’un piège de crawl dénoué ressemble — mais les impressions sur les pages que vous avez libérées sont le chiffre qui prouve que les éléments ne sont pas seulement indexés mais affichés.

Lancez-le de cette façon et la pagination cesse d’être un débat de légende et devient une entrée dans l’histoire mesurée de votre site : sur ce site, dérouler le piège de crawl à facettes confirmé ; la consolidation ?page=1 lisait inconclusif. Les chiffres qui peuvent porter ce poids — et lesquels sont de la vanité — sont le sujet du guide frère sur les KPI SEO.

Pagination dans une page de résultats zéro clic

Une autre raison de s’en soucier en 2026 : la requête que cet article vise — 260 recherches par mois, difficulté modeste — porte déjà une Réponse IA, et c’est le cas d’une part croissante des requêtes de longue traîne auxquelles répondent vos éléments de catalogue profond. Les réponses IA sont assemblées à partir de pages que les moteurs pouvaient crawler, indexer et classifier avec confiance. Un élément bloqué derrière un événement de scroll ou orphelin par une canonique vers page 1 n’est pas juste non classé — il est non citant, dans chaque moteur de réponse à la fois. Le travail de chemin de crawl peu glamour dans cette liste de contrôle est les frais d’entrée pour le territoire couvert dans notre guide sur le SEO zéro clic : vous ne pouvez pas être cité à partir d’une page qu’aucun moteur n’a jamais atteinte.

Si vous voulez que la moitié « trouver » s’exécute contre votre propre propriété, le rapport SEO gratuit connecte votre Search Console et affiche où l’accessibilité vous coûte — les sections gagnant des impressions sur la page 1 d’une série et le silence en dessous. Et si vous préférez que la boucle entière s’exécute comme un système — les conclusions archivées, les corrections expédiées, les verdicts d’indexation lus trois semaines plus tard — réservez un appel.