Faut-il vraiment s'inquiéter de la duplication de produits en scroll infini ?

Pourquoi cette question de duplication revient-elle sans cesse ?

Le scroll infini a longtemps fait débat dans la communauté SEO. Le principe est simple : quand l'utilisateur scrolle jusqu'en bas de la page 1, les produits de la page 2 se chargent automatiquement en dessous. Résultat : la page 1 contient désormais les produits de la page 1 ET de la page 2.

Le problème théorique ? Si Googlebot crawle cette page après le chargement dynamique, il voit deux fois les mêmes produits — une fois sur /categorie?page=1 et une autre fois dans le DOM étendu de la page 1 devenue hybride. Beaucoup de SEO ont craint un signal de contenu dupliqué ou une dilution du crawl budget.

Que dit exactement Mueller sur ce mécanisme ?

John Mueller coupe court : pour un site e-commerce, ce n'est pas un problème. Google cherche les liens vers les pages produits. Les trouver en double sur plusieurs pages paginées est acceptable, voire attendu dans une architecture de listing classique.

Il précise que le risque de contenu mixte — qui concerne surtout les sites de news ou les blogs où un article pourrait apparaître dans plusieurs flux — ne s'applique pas aux listes de produits. Un produit est un produit, qu'il soit listé page 1 ou page 2. L'ambiguïté sémantique n'existe pas comme pour un article éditorial.

Quels sont les cas où cette tolérance ne s'applique pas ?

Mueller mentionne explicitement les articles de news et les contenus éditoriaux. Ici, la logique change : si un article est présent dans plusieurs flux (homepage, catégorie, tag), Google peut hésiter sur l'URL canonique à indexer.

Pour les produits, cette hésitation n'existe pas : la fiche produit a une URL unique et stable. Les pages catégories ne sont que des points d'accès, pas des contenus concurrents. Google sait distinguer la destination finale (la fiche) du chemin pour y arriver (le listing).

• Scroll infini en e-commerce : duplication de produits dans les listings acceptable
• Contenus éditoriaux mixtes : risque réel de confusion sur l'URL canonique à indexer
• Prérequis : fiches produits avec URLs uniques, canonicals corrects, architecture cohérente
• Crawl budget : reste à surveiller sur gros catalogues (réduire les URLs paginées inutiles reste pertinent)

Cette déclaration est-elle cohérente avec les observations terrain ?

Oui, globalement. Sur la majorité des sites e-commerce que j'ai audités, le scroll infini bien implémenté ne cause pas de chute de visibilité organique. Les fiches produits continuent d'être indexées normalement, les pages catégories aussi.

Mais — et c'est un gros mais — ça suppose une implémentation technique propre. Si le scroll infini charge les produits uniquement en JavaScript sans rendu côté serveur ni fallback HTML, Googlebot peut rater des liens. Si les canonicals sont mal configurés, ou si les URLs paginées ne sont pas cohérentes, les problèmes peuvent apparaître. Mueller parle d'un cas idéal, pas d'un site codé au lance-pierre.

Quelles nuances faut-il apporter à ce discours ?

Première nuance : crawl budget. Même si Google tolère la duplication, ça ne signifie pas qu'il va crawler indéfiniment des milliers de pages paginées avec des produits dupliqués. Sur un gros catalogue (50 000+ produits), multiplier les URLs accessibles via pagination + scroll infini peut gaspiller du crawl budget sans apporter de valeur.

Deuxième nuance : l'expérience utilisateur et les Core Web Vitals. Un scroll infini mal optimisé (rechargement lourd, layout shift, temps de réponse serveur élevé) peut dégrader les métriques de performance — et ça, Google ne le tolère pas. [A vérifier] : l'impact réel du scroll infini sur le CLS et le LCP varie énormément selon l'implémentation, et Google n'a jamais donné de seuil précis.

Dans quels cas cette règle ne s'applique-t-elle pas ?

Concrètement, si tu gères un site éditorial (blog, média, plateforme de contenu), cette tolérance ne s'applique pas. Un article qui apparaît dans 5 flux différents (homepage, catégorie, tag, auteur, recherche) peut créer de la confusion pour Google — surtout si les canonicals ne pointent pas tous vers la même URL.

Autre cas : les marketplaces multi-vendeurs. Si un même produit est listé par plusieurs vendeurs avec des URLs différentes, le problème n'est plus la duplication dans les listings, mais la duplication du contenu produit lui-même. Là, Google peut effectivement choisir une URL au détriment d'une autre. Ce n'est pas ce dont parle Mueller ici.

Que faut-il faire concrètement sur un site e-commerce ?

D'abord, auditer l'implémentation technique du scroll infini. Vérifie que Googlebot peut accéder aux produits chargés dynamiquement — soit via rendu JavaScript, soit via des URLs paginées classiques en fallback. Un test avec Google Search Console (inspection d'URL, affichage rendu) permet de valider ce point.

Ensuite, assure-toi que les canonicals des pages catégories pointent bien vers elles-mêmes (pas vers la page 1 si tu es sur la page 2, sauf stratégie volontaire de consolidation). Les fiches produits doivent avoir des canonicals auto-référencés. Pas de boucles, pas d'incohérences.

Quelles erreurs éviter absolument ?

Erreur classique : implémenter le scroll infini sans URLs paginées accessibles. Si tout repose sur du JavaScript et que les liens vers ?page=2, ?page=3 n'existent nulle part dans le code HTML, Googlebot peut rater une partie du catalogue. Le scroll infini doit être une surcouche UX, pas un remplacement de la pagination.

Autre piège : ne pas gérer le state dans l'URL. Si un utilisateur scrolle jusqu'à la page 5, partage l'URL, et que le destinataire atterrit sur la page 1, c'est un problème d'UX — mais aussi de crawl. Google peut mal interpréter la structure. Utilise pushState ou replaceState pour mettre à jour l'URL en fonction du scroll.

Comment vérifier que mon site est conforme à cette logique ?

Première étape : crawl ton site avec Screaming Frog ou Oncrawl en mode JavaScript activé. Compare le nombre de produits détectés avec un crawl HTML classique. Si des produits disparaissent en mode HTML-only, tu as un problème de fallback.

Deuxième étape : vérifie dans Google Search Console le nombre de pages catégories indexées. Si tu vois des milliers de pages ?page=X indexées sans raison, c'est que ton robots.txt ou tes canonicals ne font pas leur job. Ajuste avec des directives noindex ou des canonicals consolidés si nécessaire.

• Tester le rendu JavaScript avec Google Search Console (inspection d'URL)
• Vérifier que les URLs paginées existent en HTML (fallback crawlable)
• Auditer les canonicals des pages catégories et fiches produits
• Mesurer l'impact sur Core Web Vitals (CLS, LCP) après implémentation du scroll infini
• Crawler le site en mode JS-on et JS-off pour comparer la couverture
• Surveiller le crawl budget via les logs serveur (pages paginées vs fiches produits)