Google peut-il vraiment indexer un site à une seule page en JavaScript ?

Pourquoi Google précise-t-il que JavaScript et CSS ne doivent pas être bloqués ?

Parce que Googlebot a besoin d'exécuter votre code pour comprendre ce qu'il y a sur la page. Si votre robots.txt bloque /scripts/ ou /styles/, le moteur voit un squelette HTML vide. Pas de rendu, pas de contenu, pas d'indexation.

Concrètement, le crawler doit charger et interpréter le JavaScript pour générer le DOM final. C'est ce qu'on appelle le rendering. Sans accès aux ressources, impossible de déclencher ce processus. Google le rappelle parce que trop de sites bloquent encore bêtement ces fichiers par précaution d'un autre âge.

Les sites one-page posent-ils des problèmes spécifiques pour le SEO ?

Oui, plusieurs. L'absence de hiérarchie URL classique complique la segmentation des intentions de recherche. Vous ne pouvez pas ranker sur dix mots-clés différents avec une seule URL, sauf à bourrer de contenu non structuré.

Le maillage interne devient impossible dans sa forme traditionnelle. Pas de lien profond entre sections, donc pas de distribution de PageRank interne. Les anchor links (#section) ne créent pas de nouvelles pages pour Google, même si l'UX change côté utilisateur.

Google indexe-t-il réellement tout le contenu chargé dynamiquement ?

En théorie oui, en pratique c'est nettement plus flou. Le rendering a un coût en ressources, et Google n'accorde pas le même budget crawl à tous les sites. Un site autoritaire avec 100 000 visiteurs/jour ? Aucun souci. Un nouveau blog one-page ? Vous êtes en bas de la liste d'attente.

La recommandation de Google de "tester" avant de s'y fier complètement n'est pas anodine. Ils admettent implicitement que le système n'est pas infaillible. Les délais de rendering peuvent atteindre plusieurs jours sur des sites peu prioritaires, voire ne jamais se déclencher si le contenu est jugé redondant.

• Autorisez explicitement JavaScript et CSS dans robots.txt — aucune exception
• Testez avec l'outil d'inspection d'URL de Search Console pour vérifier le rendu réel
• Privilégiez le server-side rendering (SSR) ou la génération statique si vous voulez garantir l'indexation
• Segmentez le contenu avec des balises sémantiques claires (section, article, h1-h6) même dans une architecture one-page
• Ne comptez pas sur le routing côté client (Vue Router, React Router) pour créer des "pages" distinctes aux yeux de Google

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

Partiellement. Google indexe effectivement des sites JavaScript depuis des années, ce n'est pas nouveau. Mais la fiabilité reste très inégale selon l'architecture technique et l'autorité du domaine. Les gros sites e-commerce en React ou Vue s'en sortent bien ; les petits projets one-page galèrent souvent.

Le vrai problème n'est pas l'indexation brute, c'est le ranking. Un site one-page manque de signaux contextuels pour se positionner sur des requêtes variées. Google préfère des URLs distinctes qui répondent à des intentions spécifiques. Vous pouvez indexer votre SPA, mais vous allez peiner à concurrencer des sites avec une arborescence classique sur des termes compétitifs. [À vérifier] : Google n'a jamais publié de data comparative sur les performances de ranking entre one-page et multi-pages à contenu équivalent.

Quelles nuances faut-il apporter à cette position officielle ?

Google dit "capable de traiter", pas "traite efficacement". La nuance compte. Le rendering reste une étape coûteuse et non garantie. Sur des sites à faible priorité, Googlebot peut très bien crawler sans renderer, stockant le HTML brut et remettant l'exécution JS à plus tard... ou jamais.

Autre point : la notion de "performance SEO" reste floue dans leur formulation. Performance de crawl ? De rendu ? De ranking ? Ils ne précisent pas. Cette ambiguïté permet à Google de se dédouaner si votre one-page ne performe pas : "Ah, mais on avait dit de tester avant !"

Dans quels cas cette approche one-page est-elle vraiment risquée ?

Sites multi-thématiques, e-commerce avec catalogue large, blogs à forte production de contenu : oubliez le one-page. Vous perdez toute granularité de ciblage et tout espoir de longue traîne structurée. Google ne va pas deviner que votre section #services mérite de ranker sur "audit SEO Paris" alors que l'URL est votresite.com/.

Même problème pour les sites nécessitant du maillage interne complexe. Pas d'URLs distinctes = pas de possibilité de diriger le jus de lien vers des pages stratégiques. Vous créez un goulot d'étranglement pour le PageRank.

Que faut-il vérifier avant de valider une architecture one-page ?

Testez le rendu réel avec l'outil d'inspection d'URL de Search Console. Comparez le HTML brut et le HTML rendu : si des sections entières manquent dans la version rendue, vous avez un problème de rendering. Ne vous fiez pas aux simulateurs tiers, seul l'outil officiel reflète ce que voit vraiment Googlebot.

Vérifiez aussi le délai de rendering dans les logs. Si Google met 5 jours à renderer une page, votre contenu frais sera obsolète avant même d'être indexé. Pour un site d'actualité ou e-commerce avec promo flash, c'est rédhibitoire.

Comment optimiser un site one-page pour maximiser ses chances ?

Implémentez du server-side rendering (SSR) ou de la génération statique avec Next.js, Nuxt ou équivalent. Vous servez du HTML déjà rendu, Google n'a plus qu'à lire. Le rendering côté serveur élimine 90% des problèmes d'indexation JavaScript.

Structurez le contenu avec des balises schema.org adaptées. Un site one-page peut utiliser plusieurs types de schema imbriqués (Organization, FAQPage, Product, Article) pour compenser l'absence de segmentation par URL. Aidez Google à comprendre où commence et où finit chaque "bloc sémantique".

Quelles erreurs éviter absolument avec cette architecture ?

Ne bloquez jamais JavaScript et CSS dans robots.txt, même partiellement. Certains bloquent des libs tierces par souci de "propreté" : erreur fatale. Google a besoin de tout charger pour garantir un rendu fidèle.

Évitez les frameworks qui changent l'URL côté client sans History API propre. Si votre SPA utilise des hash fragments (#/page1, #/page2) pour simuler des pages, Google voit une seule URL. Utilisez le mode history avec des vraies URLs ou assumez le one-page pur.

• Vérifiez robots.txt : aucune ligne Disallow sur /js/, /css/, /assets/
• Testez le rendu dans Search Console sur toutes les sections critiques du site
• Implémentez SSR ou pré-rendering si votre audience et votre budget le permettent
• Ajoutez des schemas structurés pour compenser l'absence de hiérarchie URL
• Surveillez le temps de rendering dans les rapports de crawl : au-delà de 48h, c'est un signal d'alarme
• Prévoyez un sitemap XML même pour une seule page, avec sections annotées si possible