SEO JavaScript. Le test qui tranche.

Non, et le site que tu lis en ce moment est en React. Le résultat dépend du 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.

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. Sur 1 961 sites français mesurés le 11 septembre 2026, 20 sont concernés : la réponse 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. On peut en revanche 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.

Là, l’enjeu change de taille. 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. Je prends la main entièrement quand plus personne ne maintient le code, ce qui arrive souvent quand le prestataire d’origine est parti sans rien transmettre.