Les PWA sont-elles vraiment indexables par Google ou le # va-t-il tout gâcher ?

Pourquoi Google insiste-t-il sur le standard web des PWA ?

Google rappelle que les PWA utilisent des technologies web classiques (HTML, CSS, JavaScript) et non un framework propriétaire fermé. Cette base standard garantit théoriquement que Googlebot peut lire et indexer le contenu exactement comme n'importe quelle page web.

Le moteur ne fait pas de distinction technique entre une PWA et un site traditionnel. Ce qui compte pour l'indexation, c'est la capacité du crawler à récupérer le contenu, pas l'étiquette « Progressive Web App ». L'engagement utilisateur « immersif » mentionné par Google concerne l'expérience (notifications push, mode hors ligne, installation), pas le SEO.

Qu'est-ce que ce problème de symbole # exactement ?

Les URL avec fragments # (hash) posent un souci historique en SEO. Traditionnellement, tout ce qui suit le # n'est pas envoyé au serveur lors d'une requête HTTP. Le fragment reste côté client et sert à la navigation interne dans la page.

Dans les architectures single-page applications (SPA), certains développeurs utilisent le routing par hash (#/about, #/products) pour changer de vue sans recharger la page. Googlebot ignore ce qui suit le #, donc ces sections ne seront jamais crawlées ni indexées si elles ne sont accessibles que par ce biais.

Comment Google crawle-t-il réellement une PWA ?

Le moteur attend que chaque « page » ou vue importante dispose d'une URL unique et propre, sans fragment. L'architecture idéale repose sur le History API HTML5 (pushState), qui permet de manipuler l'URL sans rechargement tout en conservant des chemins standards (/about, /products).

Si la PWA génère du contenu dynamiquement via JavaScript, Googlebot doit pouvoir exécuter le JS et attendre le rendu complet. Google sait faire ça depuis des années, mais ça reste plus lent et plus fragile qu'un rendu serveur. Les erreurs JavaScript ou les timeouts peuvent bloquer l'indexation partielle ou totale.

• Les PWA sont indexables si elles respectent les standards HTML/CSS/JS classiques
• Les URL avec # masquent le contenu : Googlebot ignore tout ce qui suit le fragment
• Le routing doit utiliser le History API (pushState) pour créer des URL propres sans hash
• Le rendu JavaScript doit être rapide et fiable : erreurs JS = contenu invisible
• Aucune différence de traitement entre PWA et site classique du point de vue crawl/indexation

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

Oui et non. Sur le papier, Google a raison : une PWA bien codée s'indexe normalement. En pratique, les PWA mal architecturées posent des problèmes chroniques. Les équipes produit privilégient souvent l'expérience mobile sans consulter le SEO, et on se retrouve avec du routing par hash, du lazy-loading cassé, ou des meta tags dynamiques mal injectés.

Les audits terrain montrent que beaucoup de PWA perdent du trafic organique après migration depuis un site classique. Pas parce que Google ne peut pas les indexer, mais parce que l'implémentation JavaScript introduit des régressions : contenu rendu trop tard, liens internes invisibles au premier crawl, balises canoniques manquantes ou dupliquées. [A vérifier] systématiquement avec un audit JavaScript SEO avant toute mise en prod.

Quelles nuances faut-il apporter sur le rendu JavaScript ?

Google sous-entend que tout fonctionne « facilement » si les standards sont respectés. C'est optimiste. Le rendering JavaScript reste une opération coûteuse pour Googlebot, qui peut différer l'indexation de plusieurs jours voire semaines sur les sites à faible crawl budget.

Les sites e-commerce en PWA subissent parfois des délistages temporaires de pages produits lors des montées de charge (soldes, Black Friday) parce que le crawler n'arrive pas à rendre tout le catalogue dans les temps. Le rendu serveur (SSR) ou la génération statique (SSG) restent les seules vraies garanties d'indexation rapide et stable.

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

Google ne précise rien sur les PWA complexes avec authentification obligatoire. Si le contenu principal nécessite un login, Googlebot ne pourra pas y accéder même si les URL sont propres. Certains sites mettent tout le catalogue derrière un mur de connexion « pour l'expérience PWA », ce qui est un suicide SEO pur et simple.

Autre cas limite : les PWA qui utilisent service workers pour servir du contenu caché différent selon le contexte (offline vs online, A/B test agressif). Google peut détecter du cloaking involontaire si le contenu servi au crawler diffère trop de celui montré à l'utilisateur. Soyons honnêtes, beaucoup de dev ne pensent pas à ça quand ils configurent leur stratégie de cache service worker.

Que faut-il faire concrètement pour une PWA indexable ?

Première priorité : éliminer tout routing par hash. Migre vers le History API (pushState/replaceState) pour que chaque vue dispose d'une URL propre. Teste avec l'outil d'inspection d'URL de la Search Console pour vérifier que Googlebot voit bien le contenu final rendu.

Ensuite, implémente un pré-rendering ou du SSR pour les pages critiques (pages catégories, fiches produits, landing pages SEO). Les solutions comme Rendertron, Prerender.io ou Next.js en mode hybride permettent de servir du HTML statique aux crawlers tout en conservant l'expérience PWA côté client. C'est du boulot supplémentaire mais c'est la seule façon de garantir une indexation rapide et stable.

Quelles erreurs éviter absolument ?

Ne jamais lancer une PWA en production sans avoir audité le rendu JavaScript avec le Mobile-Friendly Test et l'outil d'inspection d'URL. Les erreurs JS qui passent inaperçues en dev (timeouts réseau, dépendances CDN bloquées) explosent en prod quand Googlebot crawle avec des quotas serrés.

Autre erreur classique : oublier les balises meta dynamiques. Beaucoup de PWA injectent title, description et canonicals via JavaScript après le premier paint. Si le bot crawl avant l'injection complète, tu te retrouves avec des pages indexées sans title ou avec des duplicates. Injecte ces balises critiques côté serveur ou via SSR, jamais uniquement en client-side.

Comment vérifier que mon site PWA est conforme ?

Lance un crawl complet avec Screaming Frog en mode JavaScript activé et compare avec un crawl JS désactivé. Les écarts te montrent exactement ce que Googlebot risque de rater. Vérifie aussi les logs serveur pour repérer les hits de Googlebot qui renvoient du 200 mais avec un contenu vide ou partiel.

Utilise Google Search Console pour monitorer les erreurs de rendu dans la section Couverture. Les pages marquées « Explorée, actuellement non indexée » ou « Détectée, actuellement non indexée » signalent souvent des problèmes de rendu JavaScript ou de crawl budget insuffisant pour traiter tout le contenu dynamique.

• Migrer tout routing # vers History API avec URL propres
• Implémenter SSR ou pré-rendering pour les pages stratégiques SEO
• Tester chaque template critique avec l'outil d'inspection d'URL Google
• Injecter title, meta description, canonical côté serveur, jamais uniquement en JS client
• Crawler le site avec Screaming Frog JS activé/désactivé pour repérer les écarts
• Monitorer Search Console pour détecter les erreurs de rendu ou d'indexation différée