Pourquoi vos boutons HTML sabotent-ils votre crawl budget ?

Qu'est-ce qu'un bouton HTML et pourquoi Googlebot l'ignore-t-il ?

Un bouton HTML (<button>) est un élément interactif conçu pour déclencher une action — soumettre un formulaire, ouvrir une modale, lancer un script. Il n'a jamais été pensé comme un vecteur de navigation. Googlebot, lui, cherche des liens hypertextes (<a href="...">) pour découvrir et indexer vos pages.

Quand un développeur utilise <button onclick="navigateTo('/page')"> avec du JavaScript pour simuler un lien, il crée un trou noir pour le crawler. Pas d'attribut href, pas de signal HTML natif : Googlebot passe son chemin. Peu importe que le bouton fonctionne parfaitement côté utilisateur — pour le moteur, il n'existe pas.

Pourquoi certains sites tombent-ils dans ce piège ?

L'erreur vient souvent d'une confusion entre design et sémantique. Les équipes front veulent un bouton visuellement distinct (couleur, relief, animation) et optent pour <button> par réflexe. Elles ajoutent ensuite un onClick JavaScript pour gérer la navigation, pensant que Google « comprendra » l'intention.

Les frameworks JavaScript modernes (React, Vue, Angular) aggravent le problème en facilitant la création de composants bouton cliquables sans passer par des balises <a>. Le résultat : des sites SPA (Single Page Applications) truffés de boutons-liens invisibles pour Googlebot, avec un taux de découverte catastrophique des pages profondes.

Quelle différence entre un lien stylisé et un bouton JavaScript ?

Un lien HTML classique (<a href="/categorie/produit">) est crawlable nativement — Googlebot lit l'URL, suit le lien, indexe la destination. Vous pouvez le styliser avec CSS (background, border-radius, padding) pour qu'il ressemble pixel pour pixel à un bouton, sans perdre sa fonction de navigation.

Un bouton avec JavaScript (<button onclick="router.push('/produit')">) fonctionne pour l'utilisateur, mais impose à Google d'exécuter le JS pour détecter l'URL cible. Problème : Google limite le rendering budget et ne garantit pas l'exécution complète du JavaScript sur toutes les pages. Résultat : certaines URLs ne sont jamais découvertes.

• Balise <a> avec href : crawl garanti, indexation immédiate, passage du PageRank.
• Bouton <button> + JavaScript : crawl aléatoire, découverte retardée ou nulle, aucun passage d'autorité.
• Stylisation CSS sur un lien : conserve tous les bénéfices SEO d'un lien natif avec l'apparence d'un bouton.
• Progressive enhancement : toujours partir d'un <a> fonctionnel, puis enrichir avec JS si nécessaire.
• Audit régulier : traquer les boutons-liens dans le code source et les remplacer systématiquement.

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

Absolument — et elle confirme ce qu'on constate depuis des années sur les sites SPA mal configurés. Les audits de crawl révèlent régulièrement des pages orphelines accessibles en navigation utilisateur mais absentes du rapport de couverture Search Console. La cause ? Des composants bouton sans href.

J'ai vu des sites e-commerce perdre 40 % de leurs fiches produits de l'index parce que la navigation par catégorie reposait sur des <button> React avec history.push(). Googlebot crawlait la homepage, trouvait zéro lien sortant, et s'arrêtait là. Un switch vers des <Link> Next.js (qui compilent en <a> HTML) a suffi pour récupérer l'indexation en deux semaines.

Quelles nuances faut-il apporter à cette règle ?

Google peut parfois découvrir des URLs via JavaScript — mais c'est un pari risqué. Le rendering dépend du crawl budget, de la priorité de la page, de la charge serveur. Sur un site de 10 000 pages, toutes ne seront pas rendues. Miser sur le JS pour la navigation, c'est jouer à la roulette russe avec votre indexation.

Autre point : les liens internes en JavaScript ne transmettent pas de PageRank de manière garantie. Google a confirmé que les liens découverts après rendering « peuvent » passer du jus, mais sans préciser les conditions. [À vérifier] : aucune étude publique ne quantifie la perte de PageRank sur liens JS vs. liens HTML natifs. Mon intuition terrain ? Une déperdition de 20-30 % minimum.

Dans quels cas un bouton reste-t-il acceptable ?

Un <button> est légitime pour des actions non-navigables : soumettre un formulaire (type="submit"), ouvrir une modale, toggler un menu déroulant, lancer un filtre AJAX. Dès que l'action change l'URL ou mène vers une nouvelle page, c'est un lien, pas un bouton.

Exemple concret : un bouton « Ajouter au panier » qui ouvre une popin sans changer de page ? <button> parfait. Un bouton « Voir le produit » qui redirige vers /produit/123 ? <a href="/produit/123"> stylisé en bouton. La sémantique HTML compte — elle détermine ce que Googlebot voit.

Que faut-il faire concrètement sur un site existant ?

Première étape : un audit du code source. Utilisez Chrome DevTools ou un crawler type Screaming Frog en mode « Render JS » vs. « HTML seul ». Comparez les deux : si des liens n'apparaissent qu'après rendering, ils reposent sur du JavaScript. Identifiez tous les <button> avec onClick qui déclenchent une navigation.

Ensuite, refactorez systématiquement ces boutons en <a href="...">. Conservez les classes CSS existantes pour garder le design intact. Si vous utilisez React/Vue, privilégiez les composants <Link> ou <router-link> qui génèrent des balises <a> valides en HTML. Vérifiez ensuite dans le code source rendu (Ctrl+U) que les href sont bien présents.

Quelles erreurs éviter lors de la migration ?

Ne vous contentez pas d'ajouter un href sur un <button> — ça reste invalide en HTML5. Un bouton ne peut pas avoir d'attribut href. La seule solution valide : remplacer <button> par <a> et appliquer vos styles CSS (display: inline-block, padding, background, etc.).

Autre piège : laisser un preventDefault() JavaScript qui bloque la navigation native du lien. Si vous enrichissez un <a> avec du JS (analytics, animations), assurez-vous que le clic par défaut fonctionne sans JavaScript. Progressive enhancement : le lien doit marcher même si le script plante.

Comment vérifier que la correction a fonctionné ?

Crawlez votre site avec Screaming Frog en mode « HTML only » (JavaScript désactivé). Tous vos liens de navigation critiques doivent apparaître. Si une page n'est découverte qu'en mode « Render JS », elle reste vulnérable. Vérifiez aussi le rapport de couverture Search Console : les pages précédemment orphelines doivent être réindexées sous 2-4 semaines.

Testez le passage de PageRank interne avec un outil comme Oncrawl ou Botify. Les pages profondes accessibles uniquement via des boutons JS devraient voir leur score d'autorité interne augmenter après migration vers des <a>. Si ce n'est pas le cas, vérifiez que les anciens boutons n'ont pas été remplacés par des liens nofollow par erreur.

• Auditer le code source pour repérer les <button onClick> de navigation.
• Remplacer tous les boutons-liens par des <a href> avec classes CSS identiques.
• Vérifier que les href sont visibles dans le HTML brut (Ctrl+U).
• Crawler en mode « HTML seul » pour confirmer la découverte des pages critiques.
• Monitorer le taux d'indexation dans Search Console post-migration.
• Tester le comportement sans JavaScript (navigation doit rester fonctionnelle).