
Ouvrir restaurant-lhemicycle-toulouse.com
L’Hémicycle
restaurant bistronomique, Toulouse.
août 2026 : 77 clics pour appeler et 74 sur Réserver, comptés un par un.
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.
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.
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.
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
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é.
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é.
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.
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.
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.
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.
mots servis par l’accueil de ce site avant qu’une ligne de JavaScript s’exécute
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.

Ouvrir restaurant-lhemicycle-toulouse.com
restaurant bistronomique, Toulouse.
août 2026 : 77 clics pour appeler et 74 sur Réserver, comptés un par un.

é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.
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.
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.
Ç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.
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.
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.
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
Je ne serai pas le bon si
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
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.
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.
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.
On en parle ?
C’est Maxim au bout, pas un standard.