Maxim, à Toulouse. Ce site est en React, et il est lisible sans lui.

SEO JavaScript. Le test qui tranche.

Le 11 septembre 2026, j’ai appelé 1 961 sites d’entreprises françaises sans exécuter une ligne de JavaScript, comme un robot à son premier passage. 20 ne servent presque rien, soit 1,0 %. Si ton site fait partie des 99 autres, ce n’est pas ton problème et tu peux garder ton argent. Le test pour le savoir prend trente secondes, il est plus bas.

Offerte, sous 48h ouvrées. 30 secondes pour la demander.

Ce que reçoit un robot avant d’exécuter quoi que ce soit

Les deux extraits sont réels. Tu vois le second en entier sur cette page même, avec Ctrl et U.

Un site invisible sans JavaScript

<div id="root"></div>
<script src="/assets/index-a7f3.js"></script>

Zéro mot. Trois des sites mesurés servent exactement ça, et rien d’autre.

Cette page, construite en React elle aussi

<h1>SEO JavaScript.</h1>
<p>Sur 1 961 sites d'entreprises
  francaises appeles le 11 septembre
  2026, 20 ne servent presque rien
  sans JavaScript.</p>

Le texte est déjà là. React n’est pas le problème, ce qui est envoyé au premier passage l’est.

En bref

Le SEO JavaScript est un vrai problème, et il touche un site sur cent. Sur 1 961 sites d’entreprises françaises appelés le 11 septembre 2026 sans exécuter une ligne de JavaScript, 20 ne servent presque rien, dont 3 qui ne servent aucun mot. Le test qui te place d’un côté ou de l’autre prend trente secondes et il est plus bas.

Non, Google ne refuse pas ton JavaScript
Il l’exécute. Sa propre documentation, qui est le premier résultat de cette recherche, décrit le mécanisme en détail : le moteur lit d’abord le HTML envoyé par le serveur, puis met la page dans une file d’attente pour l’exécuter plus tard, quand il a des ressources disponibles. Le contenu qui n’apparaît qu’après cette exécution existe donc pour Google, mais plus tard, et seulement si rien n’a échoué entre-temps. Le vrai risque n’est pas d’être aveugle, c’est d’être en retard et dépendant d’une deuxième étape qui n’est garantie nulle part. J’ai détaillé ailleurs ce qui se passe vraiment entre le moment où une page existe et le moment où Google la montre.
À quelle fréquence le problème arrive vraiment
Une fois sur cent. Le 11 septembre 2026, j’ai appelé 3 096 adresses d’entreprises françaises sans exécuter une ligne de JavaScript, 1 961 ont répondu, et 20 servent moins de 120 mots alors que la médiane est de 679. Presque six sites sur dix chargent pourtant du JavaScript : en charger n’a jamais voulu dire en dépendre. Aucune des sept pages classées sur cette recherche ne donne ce genre de chiffre, elles décrivent toutes le risque sans jamais dire à qui il arrive. C’est la seule chose qui manquait, et c’est celle qui te dit en une ligne si tu es concerné.
Quand ça arrive, c’est grave, et ça se répare une fois
Grave, parce que rien d’autre ne compte : un site qui n’envoie aucun texte n’a ni titre à classer, ni phrase à citer, ni réponse à donner à un moteur d’intelligence artificielle, et tout le travail de contenu passe à la trappe. Réparable, parce que la correction est presque toujours un choix de construction pris une fois, pas un abonnement mensuel : on fait écrire les pages par le serveur, ou on les écrit d’avance au moment de la mise en ligne. Ce site-ci est en React et fait exactement ça. Quelqu’un qui te vend un abonnement pour régler ce problème te vend surtout un abonnement.

Détail vérifiable en trente secondes : le 11 septembre 2026, le bloc « Autres questions » que Google affiche sur cette recherche pose quatre questions, dont aucune ne contient le mot JavaScript. Tape la requête, tu verras la même chose. Le moteur lui-même ne sait pas encore quoi faire de cette intention, ce qui explique pourquoi aucune page de vente ne se classe dessus.

Trente secondes pour te situer.

Trois gestes, dans cet ordre. Le premier suffit dans la plupart des cas, le deuxième tranche quand le premier laisse un doute, le troisième montre le résultat à quelqu’un qui ne lit pas de code. Aucun outil payant, aucun compte à créer sauf pour le deuxième, que tu as déjà si ton site est suivi.

Si le test te met du bon côté et que ton site reste pourtant absent des résultats, la cause est ailleurs, et j’ai listé les raisons qui reviennent vraiment quand un site n’apparaît pas sur Google.

La documentation de Google sur le sujet est le premier résultat de cette recherche, et c’est mérité : elle décrit la file d’attente de rendu mieux que n’importe quelle page d’agence, celle-ci comprise. Lire la source

  1. 1

    Affiche la source de ta page, et cherche une phrase

    Ouvre ta page d’accueil, appuie sur Ctrl et U en même temps (Cmd et U sur un Mac). Une fenêtre s’ouvre avec du code : c’est exactement ce que reçoit un robot avant d’exécuter quoi que ce soit. Appuie sur Ctrl et F, et cherche une phrase que tu vois à l’écran, par exemple ton slogan ou le titre d’un service.

    Le seuil qui tranche

    La phrase ne s’y trouve pas : ton texte n’est pas envoyé, il est fabriqué après coup par le navigateur. Tu es dans le pour cent concerné. Si la phrase y est, tu ne l’es pas, et la suite de cette page ne te concerne que par curiosité.

  2. 2

    Demande à Google ce qu’il voit, lui

    Dans la Search Console de ton site, colle l’adresse de ta page dans la barre d’inspection en haut, puis lance le test en direct et ouvre le HTML testé. Google te montre alors la page telle qu’il l’obtient après avoir exécuté le JavaScript, ce qui n’est pas la même chose que l’étape 1.

    Le seuil qui tranche

    Ton texte est absent aussi de ce HTML-là, ou la capture d’écran du test est blanche : le problème n’est plus un retard, c’est un échec. À ce stade, aucun travail de contenu ne sert à rien tant que ce n’est pas corrigé.

  3. 3

    Coupe le JavaScript et recharge, pour le voir de tes yeux

    Dans Chrome, ouvre les outils de développement avec F12, appuie sur Ctrl, Maj et P, tape « JavaScript », choisis « Disable JavaScript », puis recharge la page. C’est la seule étape qui ne demande de lire aucune ligne de code, et c’est celle qu’on montre à quelqu’un qui décide.

    Le seuil qui tranche

    Tu vois une page blanche, un squelette, ou une roue qui tourne sans fin : c’est ce que ton site envoie au premier passage. N’oublie pas de remettre le réglage comme avant en décochant la case, sinon la moitié du web arrêtera de fonctionner chez toi.

Ce que ce test ne prouve pas, et il faut le dire : une page qui passe les trois étapes peut très bien avoir d’autres problèmes, et une page qui échoue à la première peut rester correctement indexée pendant des mois avant que ça se voie. Il répond à une seule question, mais c’est la première à poser quand un site est construit en JavaScript : est-ce que mon texte part avec la page, oui ou non.

Un site sur cent, et jai compté.

Comment la mesure a été faite, pour que tu puisses la refaire. Le 11 septembre 2026, j’ai appelé une par une 3 096 adresses d’entreprises françaises déjà collectées pour ma prospection, sans navigateur, donc sans exécuter une seule ligne de JavaScript. J’ai compté le texte réellement présent dans le fichier reçu, une fois les scripts et les balises retirés. Le seuil retenu est de 120 mots, et il est large : la médiane est de 679 mots.

adresses appelées sans exécuter de JavaScript
3 096adresses appelées sans exécuter de JavaScript
ont répondu ce jour-là
1 961ont répondu ce jour-là
ne servent presque rien, soit 1,0 %
20ne servent presque rien, soit 1,0 %
mots servis en médiane, pour situer
679mots servis en médiane, pour situer

Les trois cas extrêmes, ouverts dans un vrai navigateur

Trois des 20 ne servent aucun mot, pas un seul. Je les ai ouverts un par un dans un navigateur pour vérifier le contraste, parce qu’une mesure sans navigateur prouve une absence, jamais une présence.

  • Sécurité et vidéoprotection, Provence 0 mot servi622 mots affichés
  • Organisme de formation, diagnostics immobiliers 0 mot servi610 mots affichés
  • Conseil en ressources humaines 0 mot servi373 mots affichés

Je ne publie pas la liste des 20 noms, et ce n’est pas par prudence juridique : ce sont vingt entreprises qui ne m’ont rien demandé, et les afficher ferait une page plus spectaculaire au prix d’un procédé que je reproche ailleurs. Quatre adresses ont d’ailleurs été écartées du décompte avant publication, parce que ce sont des domaines à vendre ou des pages en construction, pas des sites d’entreprise en service. Les compter aurait gonflé le résultat dans le sens qui m’arrange.

4 581

mots servis par l’accueil de ce site avant qu’une ligne de JavaScript s’exécute

Ce site est en React, et il passe son propre test

amiseo.fr est une application React construite avec Vite, exactement la famille d’outils qui inquiète sur cette recherche. Chaque page est écrite en entier au moment de la mise en ligne, donc le texte part avec le fichier. Appuie sur Ctrl et U sur cette page, cherche une phrase que tu vois à l’écran : elle y est. C’est la démonstration la plus courte que je puisse te donner, et elle ne demande de me croire sur rien.

React n’est pas le problème, et aucun outil ne l’est. Le problème est le réglage qui décide qui écrit la page : le serveur au moment de la mise en ligne, ou le navigateur du visiteur une fois arrivé.

Ni l’un ni l’autre n’est une application JavaScript

Je n’ai pas de client en React à te montrer, et je préfère l’écrire que l’arranger. Voici les deux que je peux citer : ce sont des sites que j’ai construits puis mesurés, et c’est tout ce qu’ils prouvent ici. Si tu veux une référence sur une application JavaScript existante, je n’en ai pas encore, et une agence qui en a dix te le dira mieux que moi.

maisonbusquets.com
Le site de Maison Busquets, épicerie fine et caviste à Toulouse, construit et référencé par AmiSEO

Ouvrir maisonbusquets.com

Maison Busquets

épicerie fine et caviste, Toulouse.

Deux fenêtres de quatre semaines qui se touchent, lues dans la Search Console : 199 puis 381 clics venus de Google.

Ce qui fait varier le devis dune application.

Je n’affiche aucun montant, et sur cette recherche ça ne me coûte rien : aucune des sept pages classées n’en affiche non plus, parce qu’aucune n’est une page de vente. La vraie raison reste la même qu’ailleurs : un chiffre annoncé avant d’avoir ouvert ton code n’est pas une information, c’est une accroche qui se renégocie. Voici les quatre choses qui font bouger le devis.

Qui écrit la page, et à quel moment

C’est la première question et elle décide de tout le reste. Soit les pages sont écrites une fois pour toutes au moment de la mise en ligne, soit c’est un serveur qui les écrit à chaque visite, soit personne ne les écrit et c’est le navigateur du visiteur qui s’en charge. Le premier cas est le plus simple et le moins cher à tenir dans le temps, il convient à presque tous les sites d’entreprise. Le deuxième s’impose quand le contenu change en permanence, et il coûte plus cher parce qu’il faut un serveur qui tourne, le surveiller et le payer tous les mois.

Le code qui existe déjà, et qui l’a écrit

Ça change tout, et dans les deux sens. Si ton application est propre et que quelqu’un la maintient, je peux souvent régler le problème sans rien réécrire, en travaillant avec la personne en place plutôt qu’à sa place, et c’est le cas le moins cher de tous. Si le code a été livré par un prestataire parti sans rien laisser, il faut d’abord comprendre ce qu’il fait avant d’y toucher, et ce temps-là se paie. Je regarde le dépôt avant de chiffrer, jamais après : un devis écrit sans avoir ouvert le code est un devis qui se renégocie.

Le nombre d’adresses réelles que ton site doit produire

Invisible à l’écran, décisif sur le devis. Une application vitrine qui tient en six pages et un catalogue de cinq cents fiches qui doivent chacune avoir son adresse, son titre et sa description ne demandent pas le même travail, même si elles se ressemblent quand on les fait défiler. C’est aussi la question qui décide si ton contenu peut être écrit d’avance ou non. Quand je chiffre, je compte des adresses, pas des écrans.

Ce que le métier ne change pas

Je ne garantis aucune position sur Google, pour une application JavaScript pas plus qu’ailleurs, et personne ne peut la garantir. Corriger ce défaut ne fait pas monter un site tout seul : ça le rend lisible, ce qui est une condition, pas un résultat. Je ne fais pas de tarif de sympathie, un travail bradé est un travail expédié. Et je ne prends pas un chantier que je ne peux pas finir : si ton application demande une équipe plutôt qu’une personne, je te le dis au premier échange.

Pas de prix affiché, mais des engagements écrits.

  • Le test des trois étapes passé sur ton site avant le devis, pas après.
  • Un devis écrit, après l’autopsie, jamais avant.
  • Le périmètre et le délai dedans, noir sur blanc.
  • Le réglage expliqué à ton développeur s’il y en a un, pas gardé pour moi.
  • Ce qui est servi sans JavaScript, mesuré avant et après, chiffre à l’appui.
  • Le prix ne bouge plus une fois signé.
  • 50 % à la commande, le solde à la livraison.
  • Le dépôt, le nom de domaine et l’hébergement restent à ton nom.

Avant de comparer deux devis, sache que la plupart des agences n’affichent rien du tout. J’ai relevé ce que 25 agences françaises écrivent vraiment quand elles affichent un prix, et surtout ce que leur page ne dit jamais sur ce qu’il contient.

Et si ton budget et mon devis ne se rencontrent pas, tu le sauras au premier échange, pas au troisième rendez-vous. Tu garderas l’autopsie de ton site, et tu pourras la donner à l’agence ou au développeur que tu choisiras à ma place. C’est fait pour.

On travaille bien ensemble si

  • Le test des trois étapes a échoué chez toi, et tu as la capture pour le montrer.
  • Tu peux me donner accès au code, ou me mettre en lien avec la personne qui l’a écrit.
  • Tu acceptes qu’on mesure ce qui est servi avant et après, et qu’on écrive les deux chiffres.
  • Quelqu’un chez toi tranche les décisions techniques et répond en quelques jours.

Je ne serai pas le bon si

  • Ton site passe le test des trois étapes, et tu veux quand même une prestation dessus.
  • Personne ne peut me donner accès au code, et ça ne changera pas.
  • Tu cherches une équipe disponible en permanence sur un produit en développement continu.
  • Le seul objectif est d’avoir agi sur le sujet, et rien ne sera mesuré après.

La première ligne est la plus importante : un site sur cent est concerné, et je préfère te le dire que te vendre une prestation inutile.

Questions fréquentes

Ce quon me demande avant dy toucher.

Oui, et sa documentation le décrit en détail, c’est d’ailleurs le premier résultat de cette recherche. Le mécanisme se fait en deux temps : Google récupère d’abord le fichier envoyé par ton serveur, puis met la page dans une file d’attente pour exécuter le JavaScript plus tard, quand il a des ressources disponibles. Ce qui n’apparaît qu’après cette exécution existe donc pour lui, mais avec du retard et à condition que rien n’échoue entre-temps. Dire que Google est aveugle au JavaScript est faux depuis des années, et c’est une phrase qu’on lit encore beaucoup, y compris sur des pages classées devant celle-ci.

Non, et le site que tu lis en ce moment est en React. Ce qui compte n’est pas l’outil, c’est le réglage qui décide qui écrit la page et à quel moment. Une application React dont les pages sont écrites d’avance au moment de la mise en ligne envoie son texte comme n’importe quel site : l’accueil de celui-ci sert 4 581 mots avant qu’une ligne de JavaScript s’exécute, tu peux le vérifier avec Ctrl et U. La même application React laissée en réglage par défaut n’envoie qu’un conteneur vide. Même outil, deux résultats opposés.

Le test est écrit en entier plus haut sur cette page, en trois étapes, et il prend trente secondes. Le premier geste suffit dans la plupart des cas : ouvre ta page, appuie sur Ctrl et U, puis cherche avec Ctrl et F une phrase que tu vois à l’écran. Si elle est dans le code affiché, ton texte part avec la page et tu n’es pas concerné. Si elle n’y est pas, tu l’es. Je publie ce test exprès pour qu’il serve même à ceux qui ne me contacteront jamais : sur 1 961 sites français mesurés le 11 septembre 2026, 20 sont concernés, donc la réponse honnête est presque toujours non.

Presque jamais, et c’est la bonne nouvelle. WordPress écrit ses pages sur le serveur avant de les envoyer, donc ton texte part avec le fichier par construction. Les rares cas où ça coince sont des blocs particuliers qui se chargent après coup, par exemple un catalogue, un moteur de recherche interne ou une carte interactive greffés sur une page sinon normale : le reste de la page est visible, cette partie-là ne l’est pas. Le test des trois étapes le montre tout de suite, puisque tu cherches une phrase précise et pas la page entière.

Pas forcément, et c’est souvent la réponse la plus chère qu’on te proposera. Réécrire une application entière pour changer de cadre technique est un chantier lourd, justifié quand le contenu change en permanence ou quand il y a des centaines de pages à produire. Dans beaucoup de cas plus simples, il suffit de faire écrire les pages une fois pour toutes au moment de la mise en ligne, sans changer de cadre ni louer un serveur qui tourne en permanence. Je regarde le code avant de dire lequel des deux s’impose, jamais l’inverse.

Non, tant que tout le monde reçoit la même chose. Tricher, ça consiste à servir un contenu aux moteurs et un autre aux visiteurs, et ça se sanctionne. Écrire les pages d’avance revient à servir exactement le même texte à tout le monde, simplement plus tôt : le visiteur le voit plus vite, le robot aussi. La question mérite d’être posée parce qu’il existe une vieille technique, le rendu différencié selon le visiteur, qui se rapproche dangereusement de la ligne rouge et que je ne propose pas.

Le premier signe arrive en quelques jours sur les pages importantes, et l’image complète met souvent plusieurs semaines, le temps que Google repasse sur l’ensemble du site. Ce délai ne dépend pas de moi et personne ne peut le raccourcir en payant. Ce qu’on peut faire, en revanche, c’est le rendre visible : on relève ce qui est servi avant l’intervention, on le relève après, et on regarde les pages indexées bouger dans la Search Console. Deux chiffres et une courbe, plutôt qu’une promesse.

C’est là que l’enjeu change de taille, et aucune des sept pages classées sur cette recherche ne le dit. Google exécute le JavaScript, avec du retard mais il le fait. Les robots des moteurs de réponse, eux, se contentent le plus souvent du fichier envoyé par ton serveur et n’exécutent rien : un site invisible sans JavaScript n’a pas de seconde chance chez eux, il n’existe simplement pas. Autrement dit, le défaut qui ne coûtait qu’un retard sur Google coûte la totalité de la visibilité sur ces moteurs-là.

Oui, et c’est souvent le meilleur montage, en plus d’être le moins cher. Quelqu’un connaît déjà ton code et le maintient : je diagnostique, j’explique le réglage, je donne les deux chiffres avant et après, et la personne applique. C’est écrit dans mes engagements plus haut, le réglage n’est pas gardé pour moi. Là où je prends la main entièrement, c’est quand plus personne ne maintient le code, ce qui arrive souvent quand le prestataire d’origine est parti sans rien transmettre.

Offerte · Sans engagement · Sous 48h ouvrées

Le test passé sur ton site, par moi.

Donne-moi l’adresse de ton site et tu reçois sous 48 heures ouvrées une vidéo commentée à la main : combien de mots ton site sert avant qu’une ligne de JavaScript s’exécute, ce que Google obtient après exécution, et ce qui manque ensuite. Sans rendez-vous, sans engagement.

30 secondes pour la demander · Offerte

Et si tu confies ce chantier à quelqu’un d’autre, garde les trois étapes plus haut et demande-lui les deux chiffres, avant et après. Elles marchent aussi bien contre moi que pour moi, c’est exactement pour ça qu’elles sont publiées.

Page écrite le . La mesure porte sur 3 096 adresses appelées ce jour-là, et le relevé des pages classées sur cette recherche date du même jour.