Site en JavaScript : le test en 3 minutes et les 5 pertes

Le site a été refait, il est beau, il s'affiche vite. Et dans Google, il n'y a que l'accueil. Vous tapez site:votresite.fr : quatre résultats pour quarante pages. Dans la Search Console, vos pages de service sont rangées en « Explorée, actuellement non indexée ». Celles qui sont indexées ressortent avec un extrait vide, ou avec le texte de votre menu.

Ce n'est en général ni un problème de vitesse ni un problème de budget d'exploration. C'est plus simple et plus brutal : le texte de ces pages web n'existe pas dans le code que le serveur envoie. Il est posé après coup, par JavaScript, dans le navigateur. Google sait le lire. Mais il y a cinq choses qu'il ne verra jamais, et sur un site de PME ce sont toujours les mêmes.

Le test en 3 minutes, sans développeur

Avant toute discussion technique, il faut savoir si votre texte est dans le HTML ou pas. Quatre gestes suffisent, et aucun ne demande d'accès au code.

• Ouvrez la page, puis Ctrl+U pour afficher le code source.
• Avec Ctrl+F, cherchez une phrase entière de votre texte.
• Phrase absente : elle est posée par JavaScript, pas par le serveur.
• Search Console, Inspection de l'URL, onglet « HTML généré ».
• Google : site:votresite.fr suivi de cette phrase entre guillemets.

Ctrl+U (Cmd+U sur Mac) ne montre pas ce que vous voyez à l'écran : il montre ce que le serveur a envoyé, avant que le moindre script ne s'exécute. C'est exactement le point de départ de Googlebot. Si votre phrase y figure, le rendu JavaScript n'est pas la cause de votre problème d'indexation, et il faut chercher ailleurs : les douze causes habituelles sont listées dans pourquoi vos pages ne sont pas indexées.

Si elle n'y figure pas, deuxième geste : dans la Search Console, collez l'URL dans l'inspection, cliquez sur « Tester l'URL en direct », puis ouvrez l'onglet « HTML généré ». Ce bloc de code est le résultat obtenu par Google après exécution des scripts. Votre phrase y est : Google rend votre page correctement, le sujet est clos. Elle n'y est pas : vous avez votre réponse, et la liste des ressources que Google n'a pas pu charger se trouve juste en dessous, dans « Plus d'informations ».

Un piège, au passage, parce qu'il fait perdre des heures : le panneau « Inspecter » de votre navigateur n'affiche pas la même chose que Ctrl+U. Il montre le HTML tel qu'il est après exécution des scripts, balises comprises. Votre texte y apparaît donc toujours, même quand il manque au code source. Les deux vues se ressemblent et ne répondent pas à la même question : c'est Ctrl+U qui dit ce que le serveur a envoyé.

Troisième geste, le plus parlant pour un dirigeant : tapez dans Google site:votresite.fr suivi d'une phrase exacte de la page, entre guillemets. Si la page ne remonte pas sur sa propre phrase, Google ne détient pas ce texte. Et un texte qu'il ne détient pas ne se positionne sur rien.

Ce que Google rend vraiment depuis 2019

« Google ne lit pas le JavaScript » a été vrai, et ne l'est plus. Jusqu'en 2019, Googlebot rendait les pages avec un moteur figé sur Chrome 41, sorti en 2015 : une bonne partie du code moderne lui échappait. En mai 2019, Google a annoncé être passé à une version à jour de Chromium, mise à niveau en continu. Depuis, Googlebot exécute le JavaScript comme un navigateur récent. Refuser React ou Vue au seul motif que « les moteurs de recherche ne les lisent pas » n'est plus un argument.

Ce qui change, en revanche, c'est le calendrier. L'indexation d'une page en JavaScript se fait en trois temps : exploration, rendu, indexation. Entre les deux premiers, il y a une file d'attente. Google explore la page, la met de côté, la rend quand ses ressources le permettent, et c'est seulement à ce moment-là qu'il découvre le texte et les liens. Google n'a jamais publié de délai pour cette file. En pratique, une page dont tout le contenu dépend du rendu entre dans l'index plus tard, et ressort plus tard des mises à jour : un texte corrigé le lundi peut rester affiché dans son ancienne version plusieurs jours dans les résultats de recherche.

La bonne question n'est donc pas « est-ce que Google lit mon JavaScript », mais « qu'est-ce qu'il ne verra pas, même en le lisant ». Cette liste-là est courte, stable, et elle n'a pas bougé depuis des années.

Les cinq pertes qu'on retrouve sur le terrain

Aucune ne demande de refaire le site. Elles demandent de savoir lesquelles vous avez.

1. Googlebot ne clique pas et ne fait pas défiler

Il charge la page dans son navigateur, attend le rendu, et lit le HTML qu'il obtient. Il ne clique sur rien, ne remplit aucun formulaire, ne fait pas défiler l'écran. Tout ce qui apparaît après une action du visiteur sort donc de l'index : la description d'une fiche produit rangée dans un onglet qui se charge au clic, le bouton « voir plus » qui va chercher la suite du texte, le bloc d'avis clients qui n'arrive qu'une fois descendu en bas de page. La règle tient en une ligne : ce qui doit se positionner est dans le HTML au chargement, ce qui se charge à la demande est du confort d'expérience utilisateur, pas du contenu.

2. Les liens qui ne sont pas des liens

Un div porteur d'un onclick, ou un bouton qui change l'écran, n'est pas un lien : Google ne le suit pas. Une navigation entièrement construite comme cela produit des pages orphelines. Plus rien ne pointe vers elles, le sitemap devient leur seul chemin de découverte, et elles ne reçoivent plus la popularité interne qu'un vrai maillage interne leur transmettrait. Un seul cas fonctionne : une balise a avec un attribut href qui contient une vraie URL. Le reste est décoratif. Vérifiez au passage que votre sitemap les contient : c'est le filet de secours en attendant la correction.

3. Les URL en dièse

Google traite /produits#bottes et /produits comme une seule et même URL : ce qui suit le dièse est un repère à l'intérieur d'une page, pas une adresse. Une application qui change d'écran sans changer l'adresse n'a donc qu'une seule page indexable, quel que soit le nombre d'écrans. Le test est immédiat : copiez l'adresse d'un écran, ouvrez-la dans un onglet neuf. Si vous retombez sur l'accueil, cet écran n'existe pas pour les moteurs de recherche. La correction est connue des développeurs sous le nom d'API History : des URL réelles, qui répondent directement.

4. Les scripts bloqués aux robots

Si votre robots.txt interdit un dossier qui contient les fichiers JavaScript ou CSS de la page, Google rend la page sans eux et récupère une coquille. C'est la panne la plus facile à corriger et celle que personne ne va voir : la ligne a souvent été posée des années plus tôt pour « économiser le crawl », par quelqu'un qui n'est plus là. L'inspection d'URL liste les ressources qu'elle n'a pas pu charger. Une seule ligne à retirer suffit parfois à faire réapparaître le texte, et cela ne coûte rien à votre budget d'exploration : un fichier de script pèse infiniment moins lourd que les pages qu'il rend illisibles.

5. Ce qui dépend d'une autorisation ou d'un tiers

Googlebot refuse les demandes d'autorisation du navigateur : position, caméra, notifications. Un contenu qui ne s'affiche qu'après un « autorisez la géolocalisation » n'existe pas pour lui, et c'est le cas classique du sélecteur d'agence ou de point de vente. Même chose derrière un bandeau de consentement bloquant, derrière une connexion, ou derrière une interface tierce lente à répondre : s'il n'obtient rien dans le temps qu'il s'accorde, il indexe ce qu'il a, c'est-à-dire la page vide. Et un lien externe durement obtenu qui pointe vers une page vide ne vous rapporte rien de plus.

CSR, SSR, prérendu : la seule chose à comprendre

Trois sigles reviennent dans toutes les discussions avec un développeur. Ils décrivent qui fabrique le HTML, et rien d'autre.

Mode	Ce que Google reçoit	Pour quelles pages
CSR, rendu côté client	Une page quasi vide et un script	Espace client, configurateur, simulateur
SSR, rendu côté serveur	Le HTML fini, le script reprend ensuite	Pages de service, fiches produit, articles
Prérendu ou génération statique	Du HTML fabriqué à l'avance	Tout ce qui ne change pas à chaque visite

Pour le référencement naturel, SSR et prérendu se valent : dans les deux cas le texte part avec la page et Google n'a rien à attendre. Le CSR n'est pas une faute en soi, c'est un choix qui déplace la charge sur le rendu de Google et sur sa file d'attente.

Et ce choix se fait page par page, jamais site par site. C'est le point que les articles génériques ratent. Les pages qui doivent se positionner — accueil, pages de service, pages ville, articles de blog, fiches produit — passent en SSR ou en prérendu. Le configurateur, le simulateur de devis, l'espace client peuvent rester en CSR : ils n'ont rien à faire dans l'index, et le plus propre est souvent de les mettre en noindex. Un chantier de rendu qui s'attaque à tout le site coûte plusieurs fois celui qui s'attaque aux vingt URL qui comptent.

Ce qui ne marche plus, et ce qu'on vous vendra quand même

Quatre réponses circulent encore. Deux sont mortes, deux sont des pis-aller qu'il faut acheter en connaissance de cause.

L'ancien schéma d'exploration AJAX, reconnaissable au paramètre _escaped_fragment_ dans les URL : Google l'a déclaré obsolète en 2015 et ne le gère plus. S'il traîne encore dans votre site, c'est du code mort qui fabrique des URL en double.

Recopier le texte dans une balise noscript : cela ne remplace pas une page rendue. Et un noscript rempli d'un texte que le visiteur ne voit jamais est, par définition, du contenu caché — exactement ce que l'on évite.

Le service de prérendu tiers posé devant le site : techniquement, cela fonctionne. Mais vous ajoutez un abonnement et un point de panne entre Google et vous. Le jour où le service tombe, Google voit vos pages vides sans que personne ne soit prévenu. À réserver aux cas où le rendu côté serveur est hors de portée, et avec une surveillance.

Mettre le texte seulement dans les données structurées : un balisage schema.org décrit un contenu, il ne le remplace pas. Une page vide avec un JSON-LD parfait reste une page vide. Enfin, demander l'indexation à la main dans la Search Console ne change rien au rendu : vous remettez simplement la même coquille dans la file.

Quoi faire selon votre plateforme

La réponse dépend moins de votre ambition que de ce que votre outil vous laisse changer.

WordPress. Le texte des articles et des pages part en HTML, le rendu n'est donc pas votre sujet global. Le problème est local : un bloc de constructeur de page chargé en JavaScript, un filtre de catalogue, un onglet de fiche produit, un carrousel d'avis. On ne refait pas le site, on sort ces trois ou quatre blocs du JavaScript. Le reste de la liste est dans la checklist WordPress.

Wix, Squarespace, Webflow, Shopify. Le contenu éditorial est servi en HTML, vous n'avez pas de décision de rendu à prendre. Ce qui vous échappe, ce sont les listes filtrées et les facettes, qui fabriquent des URL en masse : le sujet devient alors celui de la pagination et des listes, pas celui du JavaScript. C'est le cas le plus fréquent en e-commerce.

Site sur mesure en React, Vue, Angular, Next ou Nuxt. C'est ici que tout se décide, et c'est une décision de développeur, pas un réglage à cocher. La demande à formuler est précise : activer le rendu côté serveur ou le prérendu sur les routes publiques, et uniquement sur elles. Comptez un chantier avec recette, pas une après-midi. Demandez le devis sur ce périmètre-là, et faites vérifier le résultat page par page.

Une application à l'intérieur d'un site vitrine. Réservation, simulateur, configurateur : laissez-les en CSR, mettez-les en noindex s'ils n'ont rien à positionner, et écrivez à côté une vraie page de contenu qui, elle, se positionnera. C'est la correction la moins coûteuse et la plus rentable des quatre.

Le contrôle, après correction

Un rendu réparé se vérifie, il ne se suppose pas. Dans cet ordre : les trois premiers points sont immédiats, les deux suivants demandent des semaines.

1. Inspection de l'URL en direct : votre phrase apparaît dans l'onglet « HTML généré ».
2. La même inspection ne signale plus de ressource bloquée ou non chargée.
3. La recherche site: sur une phrase exacte remonte bien la page.
4. Dans « Indexation des pages », la catégorie « Explorée, actuellement non indexée » diminue sur les URL concernées, ce qui prend plusieurs semaines.
5. Un mois plus tard, le rapport de performance montre des impressions et des clics sur ces URL, et les extraits affichés dans les résultats correspondent enfin au texte de la page.

Un point d'honnêteté pour finir : réparer le rendu ne vous promet aucune place en particulier. Cela rend vos pages lisibles, ce qui est la condition d'entrée, pas le résultat. Une page lisible mais sans intérêt reste non indexée, et une page lisible sur un sujet déjà tenu par dix concurrents mieux installés n'atteindra pas la première page pour autant. Notez aussi que Google Analytics ne vous dira rien de tout cela : il ne voit que les visiteurs arrivés, jamais les pages que Google n'a pas pu lire. Seule la Search Console répond à cette question. Si vous ne savez pas par quel bout prendre le diagnostic, la checklist d'audit technique le cadre en une demi-journée, et notre page optimisation technique décrit ce que nous prenons en charge sur ce type de chantier. Dernier réflexe utile : ne confondez pas ce problème avec un problème de lenteur. Les deux portent sur le JavaScript, mais ils ne se corrigent pas au même endroit, et la vitesse est une autre affaire.

Questions fréquentes