Pourquoi vos liens en JavaScript ruinent-ils votre crawl budget et comment y remédier ?

Qu'est-ce qu'un pseudo-protocole et pourquoi bloque-t-il le crawl ?

Un pseudo-protocole comme javascript: n'est pas une URL au sens strict. C'est une instruction côté client qui déclenche une action JavaScript. Quand Googlebot rencontre un lien de type <a href="javascript:openPage()">, il ne peut pas l'interpréter comme une destination crawlable.

La raison ? Les crawlers HTTP classiques ne lisent que les attributs href contenant des URLs valides (http://, https://, chemins relatifs). Tout ce qui relève d'une exécution JavaScript — même si un navigateur moderne peut le traiter — représente une couche d'abstraction que Googlebot ignore au premier passage. Résultat : la page cible n'est jamais découverte via ce lien, elle n'hérite d'aucun PageRank interne, et elle reste orpheline aux yeux du moteur.

Cette limitation concerne-t-elle uniquement Googlebot ou tous les crawlers ?

Tous les crawlers majeurs (Bing, Yandex, même les bots spécialisés comme Semrush ou Ahrefs) partagent cette contrainte. Ils parcourent le graphe de liens HTML — pas le graphe d'événements JavaScript. Même si Google exécute parfois du JS via son moteur de rendu, il le fait en deux temps : crawl HTML, puis rendu différé.

Si votre lien n'existe pas dans le HTML initial, il ne sera jamais découvert lors du crawl. Il peut éventuellement apparaître après rendu, mais ça reste aléatoire et coûteux en ressources. Autant dire que vous misez sur un second passage incertain plutôt que sur une découverte garantie.

Pourquoi certains sites utilisent-ils encore des liens JavaScript ?

Héritage technique, principalement. Des frameworks anciens (jQuery, AngularJS 1.x) généraient des liens via des handlers d'événements onclick plutôt que des href. Certains développeurs pensaient aussi contourner le crawl volontairement — pour du contenu premium ou des pages de pagination qu'ils ne voulaient pas indexer.

Sauf que cette approche crée plus de problèmes qu'elle n'en résout. Vous perdez le contrôle du maillage interne, vous fragmentez votre architecture, et vous forcez Google à deviner vos intentions. Bref, c'est une dette technique qui coûte cher en visibilité organique.

• Les crawlers ne suivent que les href HTML valides — pas les pseudo-protocoles comme javascript:
• Les liens sans href cassent le maillage interne et empêchent la transmission de PageRank
• Le rendu JavaScript différé ne compense pas une architecture HTML défaillante
• Tous les bots (Google, Bing, Ahrefs, Semrush) partagent cette limitation
• Utiliser des pseudo-protocoles est une dette technique SEO héritée de pratiques obsolètes

Cette recommandation est-elle cohérente avec les observations terrain ?

Totalement. On voit encore des sites — notamment des SPA (Single Page Applications) mal configurées — où des centaines de liens internes ne sont pas crawlables. Les audits Screaming Frog ou Oncrawl révèlent régulièrement des graphes de liens incomplets, avec des pages orphelines qui existent dans le sitemap XML mais qu'aucun lien interne ne relie.

Le problème, c'est que beaucoup de frameworks front-end (React, Vue) génèrent par défaut des routeurs JavaScript sans fallback HTML. Si vous ne configurez pas un rendu côté serveur (SSR) ou une hydratation correcte, vos liens restent invisibles pour Googlebot au moment du crawl initial. Et attendre le second passage, c'est espérer que Google daigne allouer du crawl budget supplémentaire — ce qui n'arrive pas toujours.

Quelles nuances faut-il apporter à cette déclaration ?

Google peut exécuter du JavaScript et découvrir des liens injectés dynamiquement. Mais ça reste un processus coûteux, lent et non garanti. Le rendu JS intervient dans une file d'attente séparée, souvent des jours après le crawl HTML initial. Si votre crawl budget est serré (gros site, pages profondes), ces liens JS peuvent simplement ne jamais être traités.

Autre point : même quand Google rend le JS, il ne garantit pas que tous les événements soient déclenchés. Un lien caché derrière un onclick sans href peut parfaitement passer inaperçu si l'événement n'est pas simulé. Bref, miser sur le rendu JS pour compenser un HTML bancal, c'est jouer à la roulette russe avec votre indexation.

[A vérifier] Google n'a jamais publié de données claires sur le taux de succès du rendu JS ni sur le délai moyen entre crawl HTML et rendu. On sait juste que ça existe, mais pas à quel point c'est fiable pour un site moyen.

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

Si vous gérez une application web pure (type SaaS en zone membre) où l'indexation publique n'est pas un objectif, vous pouvez vous permettre des liens purement JavaScript. Mais dès qu'il y a un enjeu SEO — blog, pages produits, landing pages —, c'est non négociable : chaque lien doit avoir un href HTML valide.

Même pour les sites en SSR ou pré-rendu, vérifier que le HTML final contient bien des <a href="..."> reste essentiel. Ne partez jamais du principe que "le framework gère ça" — testez avec un curl ou un crawler headless pour voir ce que Googlebot reçoit vraiment.

Que faut-il auditer en priorité sur votre site ?

Commencez par un crawl complet avec Screaming Frog ou Oncrawl en mode "Spider". Exportez tous les liens et filtrez ceux dont le href commence par javascript:, # (ancre vide), ou qui n'ont carrément pas d'attribut href. Ces liens cassent votre maillage interne et bloquent le flux de PageRank.

Ensuite, comparez le nombre de pages découvertes par le crawler avec le nombre total de pages dans votre sitemap XML ou votre CMS. Un écart important signale des pages orphelines — souvent causées par des liens JavaScript non crawlables. Identifiez-les et créez des chemins HTML propres pour les relier à votre arborescence.

Comment corriger les liens JavaScript existants ?

La solution la plus simple : remplacez vos liens JavaScript par des href HTML standards. Si vous devez conserver une interaction JS (animation, tracking), gardez le href et ajoutez un gestionnaire d'événement qui empêche le comportement par défaut (event.preventDefault()) tout en exécutant votre logique. Comme ça, le lien reste crawlable même si le JS ne charge pas.

Pour les SPA, configurez un rendu côté serveur (SSR) ou un pré-rendu statique. Next.js, Nuxt.js, ou des services comme Prerender.io génèrent du HTML statique que Googlebot peut crawler directement. Testez toujours avec l'outil d'inspection d'URL de la Search Console pour vérifier que Google voit bien vos liens.

Quels outils utiliser pour valider la conformité de vos liens ?

L'outil d'inspection d'URL de la Search Console vous montre exactement ce que Googlebot voit. Comparez la version rendue avec le HTML brut : si vos liens n'apparaissent que dans la version rendue, c'est qu'ils dépendent du JS et que vous avez un problème de crawlabilité.

En complément, utilisez des crawlers headless comme Puppeteer ou Playwright pour simuler le comportement de Googlebot avec et sans JS. Ça vous permet de détecter les écarts et de prioriser les corrections. Automatisez ces tests en CI/CD pour éviter les régressions après chaque déploiement.

• Crawler votre site en mode Spider et identifier tous les liens sans href valide ou avec pseudo-protocoles
• Comparer le nombre de pages crawlées avec le nombre de pages dans votre sitemap XML
• Remplacer les href="javascript:" par des URLs valides et conserver le JS en complément si nécessaire
• Configurer SSR ou pré-rendu pour les SPA (Next.js, Nuxt, Prerender.io)
• Tester systématiquement avec l'outil d'inspection d'URL de la Search Console
• Automatiser les tests de crawlabilité en CI/CD pour prévenir les régressions