Robots.txt et rendu JavaScript : pourquoi les sites SPA ont des problèmes de crawl
Les applications monopage, les sites rendus en JavaScript et les configurations WordPress headless partagent une vulnérabilité commune : ils dépendent de l'exécution JavaScript pour produire leur contenu. Si un robot ne rend pas le JavaScript, il voit une page vide. Et si le robots.txt empêche un robot d'accéder aux fichiers JavaScript, même les robots capables de rendu ne peuvent pas faire leur travail.
Comment les robots modernes gèrent le JavaScript
Googlebot rend le JavaScript. Il utilise un navigateur Chromium headless pour exécuter les scripts et traiter le DOM, puis indexe le contenu rendu. Le contenu généré par les frameworks JavaScript — React, Vue, Next.js, Nuxt — est donc généralement indexable par Google.
Toutefois, le rendu de Googlebot a une limitation clé : il opère en deux vagues. Dans la première, Google récupère le HTML brut. Dans la deuxième, qui peut survenir des heures ou des jours plus tard, il rend le JavaScript. Ce délai signifie que le contenu généré dynamiquement est indexé plus lentement que le HTML statique.
La plupart des robots IA ne rendent pas le JavaScript du tout. GPTBot, ClaudeBot, CCBot et les autres récupèrent typiquement la réponse HTML brute sans exécuter les scripts. C'est pourquoi le robots.txt reste la couche de contrôle la plus fiable pour les robots IA.
Le piège du blocage CSS et JavaScript
C'est l'une des erreurs robots.txt les plus fréquentes et elle frappe les sites JavaScript les plus durement. Si le robots.txt bloque des chemins comme /wp-content/themes/, /wp-includes/ ou /static/js/, on empêche Googlebot d'accéder aux scripts et feuilles de style nécessaires au rendu des pages.
Le résultat : Googlebot récupère le HTML, tente de le rendre, échoue parce que les scripts requis sont bloqués, et indexe la page sur la base du HTML statique existant — qui pour un site rendu en JavaScript peut être rien de significatif.
Ce qu'il faut autoriser dans le robots.txt pour les sites JavaScript
Pour tout site dépendant du rendu JavaScript, le robots.txt doit explicitement autoriser l'accès à toutes les ressources de scripts et de feuilles de style. L'approche la plus sûre est de ne bloquer aucun chemin sous les répertoires d'assets.
Si l'on doit restreindre l'accès à des répertoires d'assets spécifiques, utiliser des chemins précis plutôt que des patrons larges. Bloquer /wp-content/plugins/plugin-specifique/admin/ plutôt que /wp-content/plugins/.
L'interaction avec les meta robots
Sur les sites rendus en JavaScript, l'interaction entre robots.txt et meta robots devient plus complexe. Si la directive noindex est injectée par JavaScript plutôt que présente dans le HTML statique, les robots qui ne rendent pas le JavaScript ne la verront jamais.
Pour les robots IA spécifiquement, un noindex injecté par JavaScript n'a aucun effet. Seul le robots.txt — vérifié avant toute récupération de HTML — fonctionne de manière fiable pour les robots qui ne rendent pas le JavaScript.
Recommandations pratiques
Le principe est : bloquer les points de terminaison, pas les assets. Les pages d'administration, les résultats de recherche et les chemins de panier devraient être bloqués. Les bundles de scripts, les feuilles de style et les fichiers de polices devraient rester ouverts.
Better Robots.txt gère cela à travers ses paramètres de ressources et assets, qui assurent que les chemins de scripts et de feuilles de style restent accessibles tout en bloquant les points de terminaison réellement à faible valeur.