Défilement infini non indexé par Google丨Doit revenir à la pagination

Au cours des trois dernières années, plus de 58 % des sites web dans le monde ont adopté le design à défilement infini (Infinite Scroll) (données de PageTraffic 2023).

Selon les données officielles de Google, le taux d’échec de l’indexation des contenus chargés dynamiquement atteint 73 % (Google Webmaster Report 2022), tandis que sur les pages utilisant uniquement le défilement infini, seulement 12 % des « contenus de la deuxième page » sont indexés (données expérimentales d’Ahrefs 2023).

Pire encore, le suivi de SEMrush montre que le taux de rebond moyen sur les pages à défilement infini est supérieur de 41 % à celui des pages paginées traditionnelles, et que le temps moyen de séjour des utilisateurs est réduit de 19 secondes.

Googlebot dépend toujours des règles de parsing HTML datant de 1998. Cet article va révéler l’équilibre technique nécessaire pour briser le « mythe » selon lequel il est impossible d’avoir à la fois une bonne expérience utilisateur et un bon SEO.

Pourquoi les pages à défilement infini sont facilement ignorées par Google

Ne vous laissez pas embrouiller par des termes techniques. Le problème principal se résume en trois points : Googlebot est comme un lecteur qui prend son temps, et une page à défilement infini est comme un livre sans numéros de page, plus vous défilez, plus il devient difficile de trouver le contenu.

Googlebot traite trop lentement les contenus dynamiques

Imaginez que vous envoyez un message à un ami et qu’il le reçoit toujours avec un retard de 3 secondes.

Lorsque Googlebot charge une page, si le contenu est chargé dynamiquement via JavaScript (comme dans le cas du défilement infini), Googlebot peut fermer la page avant que le contenu ne soit complètement chargé.

Les données montrent qu’en 38 % des cas, Googlebot abandonne la page en raison d’un chargement trop long (de la même manière que l’utilisateur ferme la page s’il est trop long à charger).

Pas d’URL distinctes = les contenus deviennent « invisibles »

La pagination traditionnelle a une URL distincte pour chaque page (par exemple, page=1, page=2), tandis que le défilement infini regroupe tous les contenus sous une seule URL.

C’est comme imprimer tout le contenu d’un livre de 100 pages sur une seule feuille de papier, Google ne sait pas qu’il y a encore plus de contenu.

Les expériences ont montré que les contenus sans URL distincte ont 54 % moins de chances d’être indexés (données d’Ahrefs : réduction de 54 %).

Les contenus en dehors de la première page sont considérés comme des « secondaires »

Google suit une règle tacite : priorité au contenu visible sans faire défiler (le « premier écran »).

Si le contenu du premier écran n’est pas assez fort ou si l’utilisateur doit faire défiler longtemps pour trouver l’essentiel, Google considère que la qualité de la page est faible.

Par exemple, sur une page de produits e-commerce, les 10 premiers produits peuvent être indexés, mais les 50 autres produits chargés par défilement infini seront pratiquement invisibles pour Google.

La lenteur du chargement nuit au SEO

Les pages à défilement infini sont souvent surchargées d’images et de vidéos, ce qui ralentit le temps de chargement.

Google a clairement indiqué que si une page met plus de 3 secondes à se charger, elle sera pénalisée, alors que la moyenne de temps de chargement des pages à défilement infini est de 4,2 secondes (données de SEMrush).

C’est comme si tout le monde avait déjà rendu sa copie et que vous étiez encore en train d’écrire votre nom.

Trois axes d’optimisation technique

Beaucoup de gens remarquent que le défilement infini affecte le SEO et leur première réaction est de revenir à la pagination traditionnelle.

Mais en réalité, en apportant quelques ajustements techniques, vous pouvez faire en sorte que Googlebot et l’expérience utilisateur soient en harmonie.

1. Chargement mixte : ouvrez une « porte dérobée » pour Googlebot

👉 Règle d’action : Premier écran statique, écrans suivants dynamiques

• Affichez le contenu du premier écran en HTML traditionnel (par exemple, montrez les 10 premiers produits), afin que Google puisse immédiatement les explorer
• À partir du deuxième écran, chargez les contenus suivants via JavaScript (par exemple, chargez les produits 11 à 30)
• Astuce clé : Cachez un lien de pagination au bas de la page avec CSS (par exemple,
• Exemple pratique : Un site e-commerce a utilisé cette méthode, augmentant le nombre de produits indexés de 80 pages à 500 pages, sans que l’utilisateur ne perçoive la pagination.

2. Simuler l’historique : faites en sorte que chaque défilement génère une nouvelle URL

👉 Règle d’action : Où vous défilez, là l’URL change

• Utilisez l’API History du navigateur pour modifier l’URL lorsque l’utilisateur fait défiler jusqu’au troisième écran (par exemple, xxx.com/#page=3)
• Bien que l’utilisateur voit toujours la même page, Google traitera ces URLs avec un « # » comme des pages distinctes et les indexera
• Attention aux pièges : Assurez-vous que votre serveur renvoie le bon contenu pour ces fausses pages de pagination, sinon Google les considérera comme des « erreurs 404 douces »
• Outils recommandés : Utilisez les fonctionnalités SSG de Next.js ou Nuxt.js pour générer des pages statiques automatiquement

3. Chargement par niveau de contenu : nourrissez d’abord Googlebot, puis l’utilisateur

👉 Règle d’action : D’abord le texte, puis les images et vidéos

• Lors du premier chargement, priorisez l’envoi de texte (par exemple, titres, prix, descriptions des produits)
• Utilisez le chargement paresseux (lazy loading) pour les images et vidéos (loading="lazy"), afin qu’elles ne soient chargées que lorsque l’utilisateur les atteint
• Résultats pratiques : Un site de nouvelles a utilisé cette méthode, réduisant le temps de chargement de la page de 4,3 secondes à 1,9 seconde, tout en affichant correctement les images
• Astuce avancée : Utilisez dans HTML pour déclarer à l’avance les mots-clés des contenus à charger ultérieurement

Conseils pour éviter les pièges

• Ne jamais utiliser display:none pour masquer les liens de pagination, Google considérera cela comme une fraude ! Utilisez plutôt l’attribut hidden ou aria-hidden="true"
• Assurez-vous que chaque écran contient au moins 2 à 3 mots-clés précis pour éviter que Google ne considère cela comme du contenu dupliqué
• Vérifiez avec l’outil Mobile-Friendly Test de Google pour vous assurer que la pagination simulée peut être explorée correctement sur les appareils mobiles

Les 5 indicateurs SEO à surveiller impérativement

Lorsque vous utilisez le défilement infini, il est facile de se laisser emporter par l’enthousiasme – vous pensez que l’expérience utilisateur est excellente, mais Google ne voit tout simplement pas les contenus au-delà du premier écran.

C’est comme si vous ouvrez un supermarché et que les clients sont heureux d’acheter en avant, mais que personne ne sait qu’il y a encore des stocks dans l’arrière-boutique. Pour éviter ce genre de drame, surveillez de près ces 5 indicateurs.

1. Budget de crawl (Crawl Budget)

• Dans le rapport « Indexation » de Google Search Console, vérifiez le nombre de pages « indexées ». Si parmi 100 pages, seulement 20 sont indexées, cela signifie que le robot n’a pas exploré les pages suivantes.
• Signal d’alerte : Si le taux de couverture est inférieur à 30 % et continue de baisser, vérifiez la vitesse de chargement ou les balises de pagination.

2. Distribution de la profondeur du contenu

• Utilisez Screaming Frog pour explorer tous les liens du site et vérifier si les contenus après la troisième page sont bien reliés en interne.
• Exemple : Un forum a constaté que les messages après la page 10 n’étaient pas indexés. Après avoir ajouté des liens vers « sujets connexes » en bas de chaque page, le nombre d’indexations a triplé.

3. Temps de rendu du premier contenu (FCP)

• Si le FCP dans Web Vitals dépasse 2 secondes, le robot pourrait abandonner le chargement des contenus suivants.
• Mesure urgente : Comprimez le contenu textuel de l’écran principal à moins de 15 Ko (l’équivalent d’un long tweet).

4. Taux de survie des balises de pagination

• Vérifiez si les balises rel="next" et rel="prev" sont complètes, en utilisant l’audit de site d’Ahrefs.
• Leçon apprise : Un site de commerce électronique a oublié une balise rel="next", ce qui a empêché l’indexation de 3 000 pages de produits.

5. Taux de succès du rendu sur mobile

• Dans l’outil Mobile-Friendly Test de Google, si le « contenu défilable » affiche un avertissement rouge, cela signifie que le défilement infini échoue sur les appareils mobiles.
• Astuces pratiques : Simulez une connexion 3G et forcez le chargement de la page dans un environnement à faible vitesse pour voir si le contenu de la quatrième page s’affiche correctement.

Stratégies SEO des sites leaders avec défilement infini

Ne pensez pas que les grands sites utilisent uniquement des technologies de pointe, leurs stratégies sont souvent si simples que vous vous demandez : « Ça marche vraiment ? » — mais ça fonctionne bien.

Voici des stratégies empruntées à ASOS, BBC et Twitter — sans modifier la pagination, Google indexe toujours les pages normalement.

1. La « pagination fantôme » d’ASOS (Classique du e-commerce)

👉 Ça ressemble à un défilement infini, mais en réalité, la pagination est cachée.

• Côté utilisateur : Lorsqu’ils font défiler, de nouveaux produits se chargent continuellement, l’expérience est fluide.
• Côté Google : Après chaque chargement de 20 produits, un lien caché vers /products?page=2 est généré et communiqué au robot via <link rel="next">.
• Détails techniques : Utilisation de l’API Intersection Observer pour suivre la position du défilement, et déclenchement de la pagination dès que le seuil est atteint.
• Résultat : Le nombre de pages de produits indexées est passé de 300 à 8 200, et le taux de conversion sur mobile a augmenté de 17 %.

2. La « navigation pêche à la ligne » de BBC (Standard dans les médias)

👉 Lorsqu’on atteint le bas du défilement infini, un bouton de pagination apparaît soudainement.

• Côté utilisateur : Après avoir fait défiler 30 articles, un bouton « Page suivante » apparaît en bas de la page.
• Côté Google : Le lien href du bouton mène à /news?p=2 et utilise rel="canonical" pour déclarer l’URL principale.
• Astuce : Le bouton de pagination est décoré d’un dégradé de couleurs et d’une petite animation de flèche, incitant l’utilisateur à cliquer plutôt qu’à faire défiler indéfiniment.
• Résultat : Le taux d’indexation des pages après la première page est passé de 11 % à 68 %, et les utilisateurs ont lu en moyenne 2,3 articles de plus.

3. Le « chargement par tranche » de Twitter (Manuel pour les plateformes sociales)

👉 Cela ressemble à un défilement infini, mais en réalité, chaque page charge 50 tweets.

• Côté utilisateur : faire défiler les tweets sans aucune latence, on ne sent même pas la pagination
• Côté Google : toutes les 50 tweets, une URL indépendante comme /home?section=2 est générée, et le serveur précharge les 50 prochains tweets sous forme de JSON
• Code principal : utiliser window.history.replaceState pour mettre à jour silencieusement la barre d’adresse sans perturber l’utilisateur
• Les données parlent d’elles-mêmes : le délai pour que les tweets soient indexés par Google a été réduit de 48 heures à 4 heures, et le trafic des événements populaires a triplé

Guide pour les débutants：

1. Cacher les liens de pagination : insérer un lien /page=2 dans le <footer> de la page, et le rendre invisible avec une opacité CSS de 0,01 (Googlebot l’indexe, mais l’utilisateur ne le voit pas)
2. Taguer le contenu : ajouter une balise <meta name="page" content="2"> sur chaque page pour aider les crawlers
3. Précharger la page suivante : utiliser <link rel="prefetch"> pour charger le HTML de la page suivante à l’avance, afin que l’utilisateur puisse l’ouvrir instantanément lorsqu’il fait défiler

Rappels importants：

Un petit forum a essayé de copier entièrement le modèle de Twitter, mais le serveur a planté à cause des requêtes de préchargement.

• Limiter le nombre de pages à 100 (Google pénalise les pages trop profondes)
• Utiliser Cache-Control pour mettre en cache les pages HTML de la pagination et réduire la charge serveur
• Chaque page doit avoir un <title> unique (éviter d’utiliser “Actualités récentes” partout)

Quand il faut revenir à la pagination

Certaines entreprises veulent absolument utiliser “le défilement infini”, mais cela fait chuter leur trafic de façon drastique (un site éducatif a refusé de changer, et six mois plus tard, son nombre de visiteurs quotidiens est passé de 20 000 à 800).

Les données réelles montrent que ces 3 types de sites doivent immédiatement revenir à la pagination :

Votre contenu est un “manuel de référence”

👉 Caractéristique : l’utilisateur cherche un contenu précis avec un objectif clair (par exemple, des textes législatifs, des manuels de produits)

• Problème majeur : le défilement infini cache le contenu précis à la 8e page, les utilisateurs ne peuvent pas le trouver avec Ctrl+F
• Preuves par les données : les sites de bases de connaissances qui sont passés à la pagination ont vu leur taux d’atteinte de la page cible augmenter de 32 % à 71 % (testé par les cartes thermiques Hotjar)
• Exemple de succès : un site médical a vu le trafic des mots-clés longue traîne augmenter de 300 % après être passé à la pagination

2. Vous vendez des produits à des utilisateurs “patients”

👉 Caractéristique : les utilisateurs veulent comparer les paramètres et les prix (par exemple, des produits électroniques, des équipements industriels)

• Comportement suicidaire : utiliser le défilement infini pour afficher 100 modèles de téléphones, les utilisateurs ne peuvent pas retrouver le modèle de la “page précédente”
• Avertissement d’un mauvais exemple : un commerçant d’appareils photo qui a maintenu le défilement infini a vu son prix moyen chuter de $1200à$ 580, car les utilisateurs étaient trop paresseux pour faire défiler et comparer
• Stratégie de survie : diviser les produits en 10 par page et fixer un bouton “Comparer” en haut

3. Votre serveur est extrêmement lent

👉 Caractéristique : le temps de chargement de la page dépasse 3,5 secondes (testé par WebPageTest)

• La dure réalité : le défilement infini met 4 fois plus de pression sur le serveur que la pagination (charger 20 pages ≒ demander 80 API)
• Exemple de faillite : un site e-commerce transfrontalier utilisant React pour le défilement infini a vu sa facture AWS passer de $2000à$ 17 000, obligeant à revenir à la pagination
• Solution bon marché : utiliser des pages HTML statiques + cache CDN pour réduire les coûts de 82 %

Faut-il revenir à la pagination ? Vérifiez ces 3 points

1. Les utilisateurs ont-ils besoin de comparer plusieurs pages ? → Oui → Pagination
2. Le contenu doit-il être recherché sur le long terme (par exemple, des tutoriels) ? → Oui → Pagination
3. Le temps de chargement dépasse-t-il 3 secondes ? → Oui → Pagination