En mars 2019, Google a confirmé via le compte Twitter de Google Search Liaison que Googlebot n'utilisait plus rel="prev" et rel="next" comme signal de pagination — et ne les utilisait en réalité plus depuis « plusieurs années ». Pour les sites e-commerce à 10 000+ URLs paginées, cette révélation a laissé un vide technique réel. Sept ans plus tard, la question reste mal résolue dans beaucoup d'architectures.
Ce que rel=prev/next faisait réellement — et pourquoi ça ne suffit plus
rel="prev" et rel="next" étaient des signaux dans le <head> HTML qui indiquaient à Google la relation séquentielle entre pages paginées. Leur but : consolider les signaux de ranking vers une série cohérente plutôt que de traiter chaque page /products?page=3 comme une page orpheline.
Ce qui fonctionnait
<!-- Page 2 d'une catégorie produit -->
<head>
<link rel="prev" href="https://store.example.com/chaussures?page=1" />
<link rel="next" href="https://store.example.com/chaussures?page=3" />
<link rel="canonical" href="https://store.example.com/chaussures?page=2" />
</head>Google interprétait cette chaîne pour comprendre que les pages 1 à N formaient un ensemble. Les signaux d'autorité (liens internes, backlinks) étaient théoriquement consolidés. La page 1 bénéficiait d'un boost en tant que « tête de série ».
Ce qui a changé
Google a arrêté d'interpréter ces balises, mais n'a jamais communiqué de remplacement direct. La raison probable : Googlebot est devenu suffisamment intelligent pour détecter les patterns de pagination via l'analyse des URLs et des liens internes. Les ?page=, /page/2/, et les liens "suivant/précédent" dans le corps de la page suffisent dans la majorité des cas.
Mais « suffisent dans la majorité des cas » n'est pas « fonctionnent parfaitement pour un catalogue de 45 000 produits répartis sur 900 pages de catégorie ». La disparition de rel=prev/next a rendu la maîtrise de la pagination plus dépendante de l'architecture de liens internes et de la stratégie de crawl. Aucun raccourci déclaratif ne compense plus une architecture défaillante.
Pour un rappel complet sur les balises <head> qui restent interprétées par les moteurs, consultez le guide sur les meta tags SEO.
Les vrais problèmes de pagination en 2026
La pagination n'est pas un problème cosmétique. C'est un problème de crawl budget, de dilution d'autorité et de contenu dupliqué. Décomposons.
Explosion du crawl budget
Prenons un cas concret : un site e-commerce mode avec 18 000 produits, répartis dans 120 catégories. Chaque catégorie affiche 24 produits par page. Cela génère environ 750 pages de pagination. Ajoutez les filtres (taille, couleur, prix) et vous atteignez facilement 5 000+ URLs paginées.
Googlebot dispose d'un budget de crawl fini pour chaque site. Chaque page /chaussures-femme?page=17&color=rouge consommée est une page produit ou une page stratégique qui ne sera pas crawlée dans cette session. Sur un site de cette taille, l'impact est mesurable : dans la Search Console, vous verrez les pages profondes de pagination avec un crawl datant de plusieurs semaines, alors que vos pages produits critiques stagnent en "Découverte, actuellement non indexée".
Pour une analyse détaillée de ce mécanisme, le guide sur le crawl budget couvre les seuils à surveiller.
Dilution du PageRank interne
Chaque page de pagination ?page=N reçoit du PageRank via le lien interne de la page ?page=N-1. Mais ce PageRank se dilue à chaque étape. La page 30 d'une catégorie reçoit une fraction infinitésimale de l'autorité de la page 1. Les produits situés uniquement sur ces pages profondes sont pénalisés de facto.
Index bloat
900 pages de pagination qui contiennent chacune une liste de 24 titres de produits avec un extrait de 50 caractères — c'est du contenu mince et répétitif. Google peut décider de ne pas les indexer, mais il doit quand même les crawler pour le constater. Pire : si ces pages sont indexées, elles peuvent gonfler votre index inutilement et diluer la qualité perçue de votre domaine.
Stratégie 1 : architecture "view-all" avec lazy loading contrôlé
La première alternative sérieuse est la page "view-all" — une seule URL qui liste tous les produits d'une catégorie. Google a historiquement recommandé cette approche quand elle est techniquement viable.
Quand c'est applicable
Pour des catégories de 200 à 500 produits maximum. Au-delà, le poids de la page et le temps de rendu deviennent prohibitifs. Un catalogue de 500 fiches produit avec images, titres et prix pèse facilement 2-3 MB de HTML pur — sans compter les assets.
Implémentation avec intersection observer
L'idée : charger le HTML complet côté serveur (pour que Googlebot voie tous les produits), mais ne rendre visuellement que les éléments visibles pour l'utilisateur via un lazy rendering JavaScript.
<!-- /chaussures-femme — page view-all, SSR complet -->
<main>
<div class="product-grid">
<!-- Les 500 produits sont dans le HTML source -->
<article class="product-card" data-lazy-render>
<a href="/chaussures-femme/nike-air-max-90">
<img src="/images/placeholder.svg"
data-src="/images/nike-air-max-90.webp"
alt="Nike Air Max 90 - Blanc/Rose"
loading="lazy"
width="300" height="300" />
<h3>Nike Air Max 90</h3>
<span class="price">129,00 €</span>
</a>
</article>
<!-- × 499 autres -->
</div>
</main>// lazy-render.ts — affiche progressivement les cartes produit
// Les 48 premières sont visibles immédiatement, le reste est rendu
// au scroll via IntersectionObserver
const INITIAL_VISIBLE = 48;
const cards = document.querySelectorAll<HTMLElement>('.product-card[data-lazy-render]');
cards.forEach((card, index) => {
if (index >= INITIAL_VISIBLE) {
card.style.contentVisibility = 'hidden';
card.style.containIntrinsicSize = '0 350px'; // hauteur estimée
}
});
const observer = new IntersectionObserver(
(entries) => {
entries.forEach((entry) => {
if (entry.isIntersecting) {
const el = entry.target as HTMLElement;
el.style.contentVisibility = 'visible';
el.style.containIntrinsicSize = 'auto';
// Charger les images réelles
const img = el.querySelector('img[data-src]') as HTMLImageElement;
if (img?.dataset.src) {
img.src = img.dataset.src;
delete img.dataset.src;
}
observer.unobserve(el);
}
});
},
{ rootMargin: '200px 0px' } // pré-chargement 200px avant le viewport
);
cards.forEach((card, index) => {
if (index >= INITIAL_VISIBLE) {
observer.observe(card);
}
});Le point critique : content-visibility vs display:none
content-visibility: hidden (et son cousin content-visibility: auto) est fondamentalement différent de display: none pour les moteurs de recherche. Le contenu avec content-visibility: hidden reste dans le DOM et est accessible au parsing HTML — Googlebot le voit. display: none est plus risqué : bien que Google affirme indexer le contenu masqué, il lui accorde potentiellement moins de poids.
L'utilisation de content-visibility: auto est la meilleure option en 2026, supportée par tous les navigateurs modernes. Elle permet au navigateur de skip le rendu des éléments hors viewport tout en gardant le contenu parsable. Bonus : cela améliore votre score INP en réduisant le travail de rendu initial.
Pour les images, combinez loading="lazy" natif avec le pattern data-src comme filet de sécurité. Les bonnes pratiques de lazy loading détaillent les pièges à éviter — notamment pour le LCP de la première ligne de produits.
Trade-off
Cette approche ne fonctionne pas pour les catégories de 2 000+ produits. Le HTML source serait trop volumineux — au-delà de la limite de taille que Googlebot traite efficacement. Pour ces cas, il faut une vraie stratégie de pagination.
Stratégie 2 : pagination classique avec maillage interne optimisé
Pour la majorité des sites avec de gros volumes, la pagination classique reste la solution la plus robuste. L'enjeu n'est plus le balisage rel=prev/next — c'est la qualité du maillage interne autour des pages paginées.
Structure de liens : le pattern "première + dernière + fenêtre glissante"
Le pattern de navigation optimal n'est pas 1 2 3 ... 47. C'est une fenêtre glissante qui garantit que chaque page de pagination est accessible en moins de 3 clics depuis la page 1.
<!-- Navigation de pagination — page 15 sur 47 -->
<nav aria-label="Pagination" class="pagination">
<a href="/chaussures-femme">1</a>
<span class="ellipsis">…</span>
<a href="/chaussures-femme?page=13">13</a>
<a href="/chaussures-femme?page=14">14</a>
<span class="current" aria-current="page">15</span>
<a href="/chaussures-femme?page=16">16</a>
<a href="/chaussures-femme?page=17">17</a>
<span class="ellipsis">…</span>
<a href="/chaussures-femme?page=24">24</a>
<span class="ellipsis">…</span>
<a href="/chaussures-femme?page=47">47</a>
</nav>Le lien vers la page médiane (ici 24) est le détail que 90% des implémentations ratent. Sans lui, la page 47 est à (47-15)/2 ≈ 16 clics de la page courante. Avec des points de passage intermédiaires (pages 1, 12, 24, 36, 47), aucune page n'est à plus de ~6 sauts de toute autre page. Cela réduit la profondeur de crawl de manière significative.
Canonicalisation des pages paginées
Chaque page paginée doit avoir un canonical auto-référent. Ne canonicalisez jamais ?page=3 vers ?page=1 — c'est une erreur fréquente qui empêche Google d'accéder aux produits listés uniquement sur la page 3.
<!-- CORRECT : canonical auto-référent sur chaque page paginée -->
<link rel="canonical" href="https://store.example.com/chaussures-femme?page=3" />
<!-- INCORRECT : ne faites JAMAIS ça -->
<link rel="canonical" href="https://store.example.com/chaussures-femme" />Ce point est détaillé dans le guide sur les URLs canoniques. L'erreur de canonical sur les pages paginées est l'une des plus destructrices en SEO technique — elle peut désindexer des milliers de produits silencieusement.
Gestion du noindex sur les pages paginées
Le débat revient régulièrement : faut-il mettre noindex sur les pages 2+ ? La réponse courte : non, dans la majorité des cas.
Si vous ajoutez <meta name="robots" content="noindex"> sur /chaussures-femme?page=5, Google continuera de crawler cette page (noindex n'empêche pas le crawl), mais n'indexera pas les liens internes vers les produits de cette page avec le même poids. Vous perdez un chemin d'accès vers ces produits. Pour approfondir les implications du noindex, consultez le guide meta robots.
La seule exception : si vos pages paginées rankent sur des requêtes où elles ne devraient pas (cannibalisation avec la page 1 de catégorie). Dans ce cas, le noindex est un patch — mais le vrai correctif est d'améliorer la page 1 pour qu'elle soit la réponse évidente. Le guide sur la cannibalisation détaille les signaux à surveiller.
Stratégie 3 : l'infinite scroll fait correctement (oui, c'est possible)
L'infinite scroll a une réputation désastreuse en SEO, et cette réputation est méritée dans 95% des implémentations. Mais une implémentation hybride — infinite scroll pour l'utilisateur, pagination classique pour les bots — fonctionne.
Le principe : pushState + URLs paginées
L'idée est de servir des pages paginées classiques côté serveur, et de transformer l'expérience en infinite scroll côté client via JavaScript et l'API History.
// infinite-scroll-seo.ts
// Charge dynamiquement les produits au scroll tout en mettant à jour l'URL
class SEOInfiniteScroll {
private currentPage: number;
private maxPage: number;
private loading = false;
private productGrid: HTMLElement;
private sentinel: HTMLElement;
constructor(config: { currentPage: number; maxPage: number }) {
this.currentPage = config.currentPage;
this.maxPage = config.maxPage;
this.productGrid = document.querySelector('.product-grid')!;
// Sentinel element en bas de la grille
this.sentinel = document.createElement('div');
this.sentinel.className = 'scroll-sentinel';
this.sentinel.setAttribute('aria-hidden', 'true');
this.productGrid.after(this.sentinel);
this.initObserver();
}
private initObserver(): void {
const observer = new IntersectionObserver(
([entry]) => {
if (entry.isIntersecting && !this.loading && this.currentPage < this.maxPage) {
this.loadNextPage();
}
},
{ rootMargin: '400px 0px' }
);
observer.observe(this.sentinel);
}
private async loadNextPage(): Promise<void> {
this.loading = true;
const nextPage = this.currentPage + 1;
const url = new URL(window.location.href);
url.searchParams.set('page', String(nextPage));
try {
// Fetch la page paginée complète, extraire seulement les produits
const response = await fetch(url.toString(), {
headers: { 'X-Requested-With': 'XMLHttpRequest' }
});
// Le serveur renvoie du HTML partiel si header X-Requested-With présent,
// ou la page complète sinon (pour Googlebot)
const html = await response.text();
const parser = new DOMParser();
const doc = parser.parseFromString(html, 'text/html');
const newProducts = doc.querySelectorAll('.product-card');
newProducts.forEach((product) => {
this.productGrid.appendChild(document.importNode(product, true));
});
// Mettre à jour l'URL sans recharger la page
window.history.pushState(
{ page: nextPage },
'',
url.toString()
);
this.currentPage = nextPage;
} catch (error) {
console.error('Failed to load page:', error);
} finally {
this.loading = false;
}
}
}
// Initialisation
const scrollLoader = new SEOInfiniteScroll({
currentPage: parseInt(
new URLSearchParams(window.location.search).get('page') || '1'
),
maxPage: 47 // injecté par le serveur dans un data attribute ou variable globale
});Le point crucial : que voit Googlebot ?
Googlebot reçoit la page HTML paginée classique — avec la navigation <nav> contenant les liens vers les pages précédentes et suivantes. Le JavaScript d'infinite scroll s'exécute côté client uniquement. Même si Googlebot exécute le JavaScript (ce qu'il fait via Chromium headless), le scroll n'est pas déclenché, donc les pages suivantes ne sont pas chargées dynamiquement.
Résultat : Googlebot suit les liens <a href> de la pagination classique, crawle chaque page paginée individuellement, et indexe le contenu normalement. L'utilisateur, lui, profite d'un scroll infini fluide.
Vérifiez ce que Googlebot voit réellement en utilisant l'outil d'inspection d'URL de la Search Console. Le guide de test du rendu Google explique comment automatiser cette vérification avec l'API URL Inspection.
Le piège du "Load More" sans lien HTML
Variante fréquente : un bouton "Charger plus" qui déclenche un appel AJAX sans jamais mettre à jour l'URL. C'est catastrophique. Googlebot ne clique pas sur les boutons. Si les produits des pages 2+ ne sont accessibles que via JavaScript, ils sont invisibles pour le crawl.
Le minimum vital : un <a href="/chaussures-femme?page=2"> stylé en bouton. Le JavaScript intercepte le clic et charge le contenu dynamiquement, mais le lien HTML sous-jacent est crawlable.
Stratégie 4 : réduire le besoin de pagination par la taxonomie
La meilleure page paginée est celle qui n'existe pas. Avant d'optimiser la pagination, posez-vous la question : votre catégorie "Chaussures femme" avec 47 pages a-t-elle besoin d'exister sous cette forme ?
Faceted navigation indexable
Plutôt que 47 pages de /chaussures-femme?page=N, créez des sous-catégories indexables :
/chaussures-femme/running/— 80 produits, 4 pages/chaussures-femme/baskets/— 120 produits, 5 pages/chaussures-femme/sandales/— 60 produits, 3 pages
Chaque sous-catégorie cible une intention de recherche distincte, concentre le PageRank sur moins de pages paginées, et réduit la profondeur de crawl. Les 47 pages deviennent une quinzaine de sous-catégories avec 3 à 5 pages chacune — toutes accessibles en 2-3 clics depuis la homepage.
Quand ne pas le faire
Si les filtres ne correspondent pas à des intentions de recherche réelles (couleur exacte, pointure), ne les indexez pas. Une URL /chaussures-femme/pointure-38?page=2 est du pur index bloat. Bloquez ces combinaisons via robots.txt ou meta robots, et gardez la pagination uniquement sur les catégories à valeur SEO.
Monitoring : détecter les régressions de pagination avant qu'elles n'impactent le trafic
La pagination est un système fragile. Un déploiement peut casser un lien de navigation, un changement de tri peut modifier le contenu de chaque page paginée, un filtre activé par défaut peut créer des milliers d'URLs paramétrées non prévues.
Signaux d'alerte dans la Search Console
Exportez le rapport de couverture et filtrez sur vos patterns d'URL paginées. Les métriques à surveiller :
- Pages "Découverte, actuellement non indexée" : si ce nombre explose sur vos URLs paginées, Googlebot les trouve mais ne juge pas utile de les indexer. Soit le contenu est trop mince, soit le crawl budget est saturé.
- Dernière date de crawl : si vos pages
/categorie?page=30+n'ont pas été crawlées depuis 45+ jours, votre maillage interne est probablement trop profond. - Pages "Explorée, actuellement non indexée" : Google a crawlé la page mais a choisi de ne pas l'indexer. Souvent un signe de contenu trop similaire entre pages paginées.
Audit automatisé avec Screaming Frog
Configurez un crawl ciblé sur vos patterns de pagination :
# Configuration Screaming Frog — crawl des pages paginées
# Include : uniquement les URLs de pagination
# Configuration > Include > Regex:
.*[?&]page=\d+.*
# Exporter les métriques suivantes :
# - Crawl Depth (profondeur depuis la homepage)
# - Unique Inlinks (nombre de liens internes uniques)
# - Status Code
# - Canonical Link Element
# - Indexability
# Seuils d'alerte :
# Crawl Depth > 8 → problème d'architecture
# Unique Inlinks < 2 → page quasi-orpheline
# Canonical != Self-referencing → erreur de configuration
Lancez ce crawl après chaque mise en production touchant les templates de catégorie ou le système de pagination. Un canonical qui pointe soudainement vers la page 1 au lieu d'être auto-référent peut désindexer des centaines de produits en quelques semaines.
Sitemap et pagination
Incluez vos pages paginées stratégiques dans le sitemap XML. Les pages 1 de chaque catégorie sont prioritaires, mais les pages 2 à 5 méritent aussi d'y figurer — elles contiennent des produits à valeur SEO. Au-delà de la page 5, l'inclusion dans le sitemap dépend de votre volume : si vous avez 900 pages paginées, ne saturez pas le sitemap avec toutes les pages 6+.
Scénario de régression réel
Un retailer mode français avec 15 000 produits et 180 catégories a perdu 23% de trafic organique sur ses pages catégories en 3 semaines. La cause : un déploiement front avait remplacé les liens <a href> de pagination par des <button> déclenchant du JavaScript. Googlebot ne suivait plus les liens de pagination. Les produits des pages 2+ ont progressivement disparu de l'index.
Le problème a été identifié 18 jours après le déploiement — uniquement parce qu'un SEO a remarqué la baisse dans la Search Console. Un outil de monitoring comme Seogard, configuré pour vérifier la présence de liens de pagination crawlables dans les templates de catégorie, aurait détecté la régression en quelques heures au lieu de 18 jours.
La correction (rétablir les <a href> avec href valides, interceptés par JavaScript pour le comportement client) a pris 2 heures. La récupération du trafic a pris 6 semaines.
Edge cases et FAQ technique
Pages paginées et Core Web Vitals
Les pages de listing sont souvent les pires élèves en Core Web Vitals. Chaque carte produit avec image constitue un candidat LCP et chaque chargement d'image tardif provoque du CLS. Veillez à dimensionner vos images avec width et height explicites, et chargez les images above-the-fold sans loading="lazy".
Paramètres d'URL et Google Search Console
L'outil de gestion des paramètres d'URL a été retiré de la Search Console. Vous ne pouvez plus indiquer à Google que ?page= est un paramètre de pagination. Cela renforce l'importance d'une architecture de liens propre : c'est votre seul levier pour guider le crawl.
Pagination et hreflang
Sur un site multilingue, chaque page paginée a besoin de ses propres annotations hreflang. /fr/chaussures?page=3 doit pointer vers /en/shoes?page=3, pas vers /en/shoes. L'erreur est courante et crée des signaux contradictoires pour Googlebot.
rel=prev/next : faut-il le retirer ?
Non. Ces balises ne causent aucun tort — elles sont simplement ignorées par Google. Bing les interprète peut-être encore (Microsoft n'a pas communiqué clairement sur le sujet). Le coût de maintenance est nul si elles sont générées automatiquement par votre CMS. Gardez-les.
La mort de rel=prev/next n'a pas créé de nouveau problème — elle a révélé que la pagination reposait depuis toujours sur la qualité du maillage interne et l'architecture d'information. Les sites qui avaient une structure de liens solide n'ont rien remarqué en 2019. Les autres traînent encore des régressions silencieuses dans leurs pages profondes. Auditez vos patterns de pagination, vérifiez que chaque page paginée est crawlable et auto-canonicalisée, et mettez en place un monitoring continu pour détecter les cassures avant qu'elles ne coûtent du trafic.