Beaucoup de sites modernes servent une page vide à qui ne sait pas exécuter de JavaScript. Pas un bug exotique : le comportement par défaut d'une application React livrée telle quelle. Je l'ai découvert sur mon propre site, où une centaine d'articles étaient en ligne, lisibles dans mon navigateur, et absents du HTML que le serveur envoyait réellement.
Le test, deux minutes
Récupère le HTML brut d'une de tes pages sans passer par un navigateur. Un curl, ou l'outil de récupération de page de ton assistant — l'essentiel est qu'il ne rende pas le JavaScript. Puis cherche dedans un paragraphe précis de ton texte.
Deux issues possibles. Soit tu le trouves, et tout va bien. Soit tu tombes sur une coquille de quelques lignes, un <div id="root"> vide et un <script>, et c'est tout.
Si ton texte n'est pas dans le HTML livré, il n'existe pas pour un robot qui ne rend pas le JavaScript.
Fais-le sur trois URL, pas une : la page d'accueil, une page de rubrique, un article. Les trois ne se comportent pas forcément pareil.
« Mais Google m'indexe bien »
C'est l'objection qui fait perdre le plus de temps, et elle est fondée : Googlebot sait rendre le JavaScript. Il le fait dans une seconde passe, plus tardive et plus coûteuse pour lui, mais il le fait. Ton site peut donc être correctement indexé et illisible pour tout le reste.
Or les robots des assistants — ceux d'OpenAI, d'Anthropic, de Perplexity — se comportent comme un simple récupérateur de HTML. Pas de navigateur, pas d'exécution, pas de seconde passe. Ce qu'ils voient, c'est ce que ton serveur envoie du premier coup.
La conséquence est brutale et silencieuse : tu passes des mois à écrire pour être citable par les modèles, à aligner ton positionnement et tes données structurées, et tout ce travail porte sur du contenu auquel ils n'accèdent jamais. Pire, chaque page sert la même coquille : du point de vue d'un récupérateur, ton site entier a un seul titre et aucun texte.
Ce n'est pas une pénalité. C'est un problème d'existence.
Trois façons d'en sortir
Le rendu serveur (SSR). Le serveur construit le HTML à chaque requête. C'est la réponse la plus complète, et la plus lourde : il faut un serveur qui tourne, et ça se paie en complexité.
La génération statique (SSG). Le HTML de chaque page est produit une fois, au build, et déposé sur l'hébergement comme un fichier. Pour un site de contenu dont les pages changent quand on publie et pas quand on visite, c'est le meilleur rapport effort/résultat. C'est ce que j'ai choisi.
Le pré-rendu par un service tiers, qui intercepte les robots et leur sert une version rendue. Ça fonctionne, ça évite de toucher au code, et ça ajoute une dépendance externe sur un point critique. Je garde ça pour les cas où le build n'est pas modifiable.
Un mot sur le coût réel de la bascule, parce que c'est ce qui bloque les gens : dans mon cas, elle n'a pas touché aux pages. Elle a touché aux deux fichiers d'entrée — l'application n'exporte plus un composant mais une liste de routes, et le point d'entrée appelle le générateur au lieu du rendu navigateur. Les pages, les composants, le contenu : rien à réécrire. Compte une demi-journée de bricolage, pas une refonte.
Générer n'est pas servir
Là est le piège qui m'a coûté le plus de temps, et personne ne te prévient.
Le build a généré mes cent onze pages correctement. Mis en ligne, chaque URL renvoyait pourtant le contenu de la page d'accueil. Sans erreur, sans 404, sans rien dans les journaux.
L'explication est une option de nommage. Le générateur produisait faq.html et blog/mon-article.html. L'hébergement, lui, cherchait un fichier à l'adresse /faq ; ne trouvant rien, il appliquait son repli prévu pour les applications monopages et servait index.html. Autrement dit : il me servait la page d'accueil pour tout. Une fois le générateur passé en sortie imbriquée — faq/index.html, blog/mon-article/index.html — l'hébergement a trouvé ses fichiers et tout s'est aligné.
La leçon se généralise : un build vert ne prouve rien. Le seul juge, c'est le HTML que renvoie l'URL publique après déploiement. Vérifie-la, pas le journal de build.
Le réflexe à prendre
Ajoute deux minutes à la fin de chaque mise en ligne. Un appel sans JavaScript sur trois URL, et trois choses à contrôler sur chacune : son propre titre, son h1, un paragraphe de son corps de texte.
Attention au cache des outils de récupération, qui gardent souvent une page un quart d'heure : ajoute un paramètre bidon à l'URL, ?v=2, pour être sûr de lire le déploiement que tu viens de faire et pas le précédent.
Ce contrôle tient en un signet et il te dit quelque chose qu'aucun tableau de bord ne te dira : ce que le web voit de toi quand il ne fait pas l'effort de rendre ta page. Si tu n'en fais qu'un aujourd'hui, fais-le sur ton article le plus utile. C'est celui dont l'absence te coûte le plus cher.