L'infinite scroll tue-t-il l'indexation mobile si vous n'utilisez pas pushState ?

Pourquoi Google insiste-t-il sur la correspondance URL-contenu ?

Le principe est simple : Googlebot ne scrolle pas. Quand un utilisateur fait défiler une page à l'infini, de nouveaux contenus se chargent via JavaScript sans que l'URL ne change. Pour le crawler, cette page reste une entité unique avec une seule adresse.

Or Google fonctionne par URLs. Chaque contenu doit avoir sa propre adresse pour être indexé, classé et servi dans les résultats de recherche. Si 50 articles se chargent au fur et à mesure du scroll mais partagent tous la même URL, Googlebot n'en verra qu'un seul lors de son passage.

Qu'est-ce que pushState et pourquoi est-ce crucial ici ?

pushState est une méthode JavaScript (History API) qui permet de modifier l'URL affichée dans la barre d'adresse sans recharger la page. Quand l'utilisateur scrolle et qu'un nouveau bloc de contenu apparaît, pushState met à jour l'URL pour refléter ce changement.

Cette technique crée une correspondance dynamique URL-contenu. Chaque section de votre infinite scroll obtient son URL unique. Si un utilisateur partage le lien ou revient via l'historique, il retombe exactement sur le contenu qu'il consultait. Pour Google, chaque URL devient indexable séparément.

Que se passe-t-il sans cette mise à jour d'URL ?

Sans pushState ou équivalent, votre infinite scroll devient un gouffre d'indexation. Google crawle la page initiale, trouve peut-être quelques éléments chargés en JavaScript si le rendu le permet, mais rate la majorité du contenu qui ne se charge qu'au scroll.

Pire : même si JavaScript Rendering Service (JRS) exécute votre code, il n'a aucun moyen de découper logiquement le contenu en unités indexables. Vous vous retrouvez avec une seule page massive, diluant la pertinence thématique et rendant impossible le positionnement granulaire sur des requêtes spécifiques.

• URLs statiques obligatoires : chaque segment de contenu doit avoir son adresse propre
• pushState ou replaceState : méthodes recommandées pour mettre à jour l'URL dynamiquement
• Accessibilité du contenu : chaque URL doit charger directement le contenu correspondant, pas juste la page d'accueil
• Crawlabilité indépendante : Googlebot doit pouvoir accéder à chaque URL sans simuler un scroll utilisateur
• Cohérence navigation-indexation : l'expérience utilisateur et la structure crawlable doivent s'aligner parfaitement

Cette directive est-elle alignée avec les observations terrain ?

Totalement. Les sites qui ont migré vers l'infinite scroll sans gérer les URLs ont systématiquement vu leur indexation s'effondrer. On observe des pertes de 40 à 70% des pages indexées sur des sites e-commerce ou médias qui ont déployé l'infinite scroll en mode « quick & dirty ».

Google ne crawle pas comme un humain. Il ne déclenche pas d'événements scroll, ne simule pas le comportement utilisateur au-delà de l'exécution JavaScript basique. Si votre contenu dépend d'un scroll physique pour se charger et n'a pas d'URL dédiée, il n'existe pas pour le moteur.

Quelles nuances faut-il apporter à cette recommandation ?

pushState n'est pas la seule solution. Vous pouvez aussi utiliser replaceState selon votre logique de navigation, ou implémenter une pagination classique en fallback pour les crawlers. L'essentiel est que chaque chunk de contenu soit accessible via une URL directe.

Attention aussi au budget crawl. Si pushState génère 500 URLs pour une seule page catégorie, vous fragmentez votre crawl budget. Sur un gros site, ça peut devenir contre-productif. Il faut trouver le bon niveau de granularité : ni trop grossier (une URL pour 50 articles), ni trop fin (une URL par paragraphe).

Dans quels cas cette approche pose-t-elle problème ?

Sur les sites à faible autorité ou budget crawl limité, multiplier les URLs via pushState peut diluer le PageRank interne et ralentir l'indexation globale. Si Google crawle 100 pages par jour sur votre site et que vous créez 300 URLs supplémentaires, il faudra des semaines pour tout indexer.

Autre piège : les URLs générées par pushState doivent être servies côté serveur. Si un utilisateur accède directement à example.com/categorie/page-3 et que le serveur renvoie une 404 parce que cette URL n'existe que côté client, vous êtes mort. Le serveur doit reconnaître ces URLs et charger le bon contenu, quitte à faire du server-side rendering ou du pré-rendering.

Comment implémenter pushState correctement pour l'infinite scroll ?

Première étape : définir une logique de segmentation. Décidez à quel moment déclencher pushState. Typiquement, quand un nouveau bloc de contenu (article, produit, section) devient visible à l'écran. Utilisez l'Intersection Observer API pour détecter le moment précis.

Ensuite, mettez à jour l'URL avec history.pushState() en passant un objet d'état, un titre, et la nouvelle URL. Exemple : quand l'utilisateur arrive sur le 3e bloc d'articles, pushState change l'URL de /blog à /blog/page-3. Côté serveur, assurez-vous que /blog/page-3 charge directement ce contenu sans nécessiter de scroll.

Quelles erreurs éviter absolument ?

Erreur classique : générer des URLs qui ne fonctionnent pas en accès direct. Si pushState crée /categorie#item-15 mais que cette URL renvoie simplement la page catégorie sans scroller jusqu'à l'item 15, Google ne verra que la première page. L'ancre # n'est pas une URL distincte pour le moteur.

Deuxième erreur : ne pas gérer le bouton retour. Si l'utilisateur scrolle, que pushState met à jour l'URL, puis qu'il clique sur « précédent » et tombe sur une page cassée, vous détruisez l'UX. Implémentez un listener sur popstate pour restaurer le bon état de la page.

Comment vérifier que l'implémentation fonctionne côté SEO ?

Utilisez l'outil Inspection d'URL dans Search Console. Testez chaque URL générée par pushState. Vérifiez que Google peut la rendre, que le contenu principal apparaît, et que les liens internes sont crawlables. Si la version rendue est vide ou incomplète, votre implémentation est défaillante.

Ensuite, surveillez le rapport de couverture. Si vous déployez pushState et que des centaines d'URLs passent en « Détectée, actuellement non indexée », c'est soit un problème de budget crawl, soit un souci de qualité de contenu, soit une mauvaise gestion des canonicals. Chaque URL générée doit avoir son propre canonical pointant sur elle-même, pas sur la page racine.

• Implémenter pushState ou replaceState avec Intersection Observer pour détecter les nouveaux blocs
• Assurer que chaque URL générée est servie correctement côté serveur (SSR ou pré-rendering)
• Tester chaque URL en accès direct dans un navigateur et avec l'outil Inspection d'URL
• Gérer l'événement popstate pour que le bouton retour fonctionne sans casser l'expérience
• Vérifier les canonicals : chaque URL doit s'auto-canonicaliser, pas pointer vers la racine
• Monitorer le rapport de couverture et le budget crawl pour détecter toute anomalie post-déploiement