Faut-il bloquer les scripts JavaScript dans le robots.txt ?

Pourquoi Google insiste-t-il sur l'accès aux scripts JavaScript ?

Le moteur de recherche a longtemps galéré avec le rendu JavaScript. Pendant des années, les sites en React ou Vue.js devaient ruser avec du SSR ou du prerendering pour être correctement indexés. Aujourd'hui, Googlebot est capable d'exécuter du JS, mais cela reste coûteux en ressources.

Si vous bloquez un script dans le robots.txt, vous interdisez à Google de le télécharger et de l'exécuter. Résultat : le contenu qui dépend de ce script n'est tout simplement pas crawlé. Google ne voit qu'une coquille vide HTML, sans les éléments chargés dynamiquement.

Quels scripts peut-on bloquer sans risque ?

Tous les scripts qui n'impactent pas le contenu indexable. Analytics, heatmaps, chat widgets, publicités, scripts de tracking marketing : ces fichiers peuvent être bloqués sans conséquence sur votre visibilité organique.

En revanche, dès qu'un script génère du contenu textuel, des liens internes, des URL de produits ou des éléments de navigation, il doit rester accessible. Un exemple classique : une carte Google Maps qui affiche des liens vers vos points de vente. Si le script qui charge ces liens est bloqué, Google ne voit aucun lien.

Comment identifier les scripts critiques pour l'indexation ?

Utilisez la Search Console et son outil d'inspection d'URL. Comparez la vue brute du HTML (ce que Googlebot reçoit en première lecture) avec la vue rendue (après exécution du JavaScript). L'écart entre les deux révèle ce qui dépend du JS.

Vous pouvez aussi désactiver JavaScript dans Chrome DevTools et recharger votre page. Tout ce qui disparaît est potentiellement invisible pour Google si le script correspondant est bloqué dans le robots.txt. Cette méthode est rapide mais approximative : Google exécute du JS, mais avec des contraintes de timeout et de rendu qui peuvent différer de votre navigateur.

• Bloquer sans risque : Google Analytics, Google Tag Manager (si utilisé uniquement pour du tracking), Hotjar, Facebook Pixel, scripts publicitaires.
• Ne jamais bloquer : scripts de navigation, de filtres produits, de lazy loading de contenu textuel, de génération de liens internes.
• Zone grise : scripts qui chargent des images (moins critique pour le texte, mais peut impacter les featured snippets visuels).
• Méthode de test : bloquez le script, attendez quelques jours, inspectez l'URL dans Search Console pour voir si le rendu est intact.
• Alternative au blocage : réduire la taille des scripts, charger en différé, utiliser du SSR partiel.

Cette déclaration est-elle cohérente avec les pratiques observées ?

Oui, elle correspond exactement à ce qu'on observe sur le terrain. Les sites qui bloquent leurs bundles React/Vue dans le robots.txt perdent régulièrement des positions organiques sur les pages concernées. Google ne devine pas : si le contenu n'est pas dans le DOM rendu, il n'existe pas.

Ce qui est intéressant, c'est que Mueller reste vague sur le concept de "contenu essentiel". Essentiel pour qui ? Pour l'indexation textuelle ? Pour les liens ? Pour les Core Web Vitals ? Cette imprécision laisse une marge d'interprétation que les SEO doivent combler par l'expérimentation. [A vérifier] : Google a-t-il un seuil quantitatif au-delà duquel un script devient "essentiel" ? Aucune donnée officielle là-dessus.

Quelles nuances faut-il apporter à cette affirmation ?

Premier point : bloquer un script n'est pas la seule façon de gérer le crawl budget. On peut aussi utiliser des headers HTTP Cache-Control, optimiser la taille des fichiers, ou regrouper les scripts. Le robots.txt est un outil brutal qui coupe tout accès.

Deuxième point : Mueller parle de "liens vers des magasins dans une carte", mais il ne précise pas si ces liens doivent être dans le HTML initial ou s'ils peuvent être découverts via le rendu JavaScript. En pratique, les liens découverts uniquement après exécution de JS sont moins bien pris en compte que ceux présents dans le HTML source. Pas bloquants, mais moins puissants pour le maillage interne.

Dans quels cas cette règle ne s'applique-t-elle pas ?

Si vous utilisez du Server-Side Rendering (SSR) ou du Static Site Generation (SSG), vos scripts côté client peuvent être bloqués sans impact sur l'indexation. Le contenu est déjà dans le HTML initial, le JavaScript ne sert qu'à ajouter de l'interactivité côté utilisateur.

Autre cas : les Progressive Web Apps (PWA) qui séparent clairement le shell applicatif du contenu indexable. Si le contenu critique est servi en HTML pur et que le JS ne gère que l'interface utilisateur, le blocage est sans conséquence. Mais attention : combien de sites respectent vraiment cette séparation ? [A vérifier] sur vos propres projets avant de bloquer quoi que ce soit.

Que faut-il faire concrètement sur son robots.txt ?

Commencez par auditer vos règles existantes. Trop de sites bloquent des répertoires entiers (/js/, /scripts/) par habitude, sans savoir ce qui s'y trouve. Listez tous les scripts bloqués et identifiez ceux qui génèrent du contenu indexable.

Ensuite, utilisez l'outil d'inspection d'URL de la Search Console pour comparer le HTML brut et le rendu final. Si un script bloqué fait disparaître du contenu ou des liens, débloquez-le immédiatement. Inversement, si un script de tracking ou d'analytics est bloqué et que le rendu est identique, vous pouvez le laisser bloqué pour économiser du crawl budget.

Quelles erreurs éviter absolument ?

Ne bloquez jamais un répertoire entier sans audit préalable. Certains sites bloquent /assets/ ou /static/ en pensant ne bloquer que des images, mais ces dossiers contiennent souvent des bundles JavaScript critiques. Résultat : des pages entières deviennent invisibles.

Autre erreur classique : bloquer les scripts de lazy loading. Si votre contenu principal est chargé en différé via IntersectionObserver et que le script est bloqué, Google ne voit qu'un loader ou un placeholder. Le contenu textuel disparaît purement et simplement des résultats de recherche.

Comment vérifier que mon site est conforme après modification ?

Après avoir modifié le robots.txt, attendez que Google le recrawle (généralement quelques heures). Ensuite, forcez une réindexation de quelques pages représentatives via la Search Console. Inspectez le rendu HTML pour vérifier que tous les éléments critiques sont présents.

Suivez vos positions organiques pendant 2 à 3 semaines après la modification. Une chute brutale sur des requêtes principales indique qu'un script essentiel a été bloqué. Dans ce cas, revenez en arrière immédiatement et analysez les logs serveur pour identifier le script fautif.

• Lister tous les scripts actuellement bloqués dans le robots.txt
• Tester le rendu de 10 pages clés avec et sans ces scripts (Search Console + Chrome DevTools)
• Débloquer tout script qui génère du contenu textuel, des liens internes ou des URL de produits
• Conserver le blocage des scripts purement analytics ou marketing (GA, GTM, pixels)
• Monitorer les positions organiques pendant 3 semaines après modification
• Documenter les règles du robots.txt avec des commentaires expliquant pourquoi chaque script est bloqué