Pourquoi vos requêtes API explosent-elles votre crawl budget à votre insu ?

Qu'est-ce que le crawl budget et pourquoi les API le consomment ?

Le crawl budget représente le nombre de ressources que Googlebot accepte d'explorer sur ton site pendant une période donnée. Google ne crawle pas tout, tout le temps — il alloue un quota basé sur la popularité du site, sa fraîcheur, et la charge serveur que son bot génère.

Quand tu utilises du JavaScript côté client, chaque script déclenche souvent plusieurs requêtes API vers ton backend ou des services tiers. Googlebot n'exécute pas seulement le HTML initial — il rend la page complète, execute le JS, et suit ces appels API. Résultat ? Une page devient 6 ressources à crawler au lieu d'une seule.

Quelle est la différence entre rendu serveur et rendu client pour Googlebot ?

En rendu serveur (SSR), le HTML complet arrive pré-assemblé. Googlebot le lit directement, sans exécuter de JavaScript complexe. C'est rapide, c'est propre, une requête HTTP suffit.

En rendu client (CSR), le HTML initial est un squelette vide. Le navigateur télécharge le JS, l'exécute, puis fait 3, 5, parfois 10 requêtes API pour assembler le contenu. Googlebot fait exactement pareil — et chaque appel API compte dans ton quota. Si ton framework React ou Vue charge le contenu produit par produit via des endpoints séparés, tu multiplies mécaniquement le nombre de hits.

À partir de quelle échelle ça devient problématique ?

Martin Splitt donne un exemple chiffré : 10 millions de pages avec 5 API calls chacune = 50 millions de requêtes supplémentaires. C'est colossal. Mais le problème se pose dès quelques centaines de milliers de pages si ton site génère peu de liens entrants ou si Google détecte des lenteurs serveur.

Le crawl budget n'est pas fixe — il s'ajuste dynamiquement. Si ton serveur répond lentement ou retourne des erreurs 5xx, Google réduit son rythme. Ajouter des dizaines de milliers d'appels API à traiter amplifie ce phénomène.

• Chaque requête API compte comme une ressource à crawler, au même titre qu'une page HTML.
• Les sites avec plusieurs millions de pages sont les plus exposés, mais le problème existe dès 100k URLs si l'architecture JS est lourde.
• Le rendu côté serveur (SSR) ou la génération statique (SSG) éliminent ce surcoût.
• Google n'indexe pas plus vite un site CSR — au contraire, le délai entre publication et indexation s'allonge.
• Le monitoring du crawl budget via la Search Console devient crucial pour identifier ce goulot d'étranglement.

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

Oui, et elle confirme ce qu'on voit depuis des années sur les gros sites e-commerce ou d'annonces. Les sites qui ont migré de frameworks full-JS vers du Next.js en SSR ou du Nuxt avec génération statique ont systématiquement observé une accélération du crawl et une meilleure fraîcheur d'indexation.

Le paradoxe, c'est que beaucoup de sites continuent de penser que « Googlebot comprend le JavaScript » signifie « pas de problème à utiliser du JS partout ». Comprendre ne veut pas dire traiter aussi efficacement. Le rendering JS consomme du temps machine, du crawl budget, et introduit de la latence. Les sites avec une forte volumétrie devraient traiter chaque milliseconde de rendering comme un coût réel.

Dans quels cas cette règle ne pose-t-elle aucun problème ?

Si ton site compte moins de 10 000 pages, avec un bon profil de liens et un serveur rapide, le crawl budget n'est probablement pas ta priorité. Google crawlera tout sans difficulté, même si tu fais 10 appels API par page. Le vrai enjeu, c'est l'échelle.

Les sites « one-page » type SaaS avec landing + blog de quelques dizaines d'articles peuvent continuer en full React sans souci. À l'inverse, un pure player e-commerce avec 500k fiches produit qui charge chaque description, prix, et avis client via des endpoints séparés ? C'est un cas d'école de mauvaise architecture pour le SEO.

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

Martin Splitt parle de sites « sensibles au crawl budget », mais il ne définit pas précisément le seuil. [A vérifier] : à partir de combien de pages un site devient-il « sensible » ? 100k ? 500k ? 1M ? Ça dépend aussi du PageRank interne, de la fréquence de mise à jour, du nombre de backlinks.

Autre point : tous les appels API ne se valent pas. Un appel vers ton propre CDN avec une réponse en 20ms a moins d'impact qu'un appel vers un service tiers qui met 800ms à répondre. Google mesure aussi le temps de réponse total — si tes API sont lentes, le bot attendra, et ça réduit mécaniquement le nombre de pages qu'il peut crawler dans le même laps de temps.

Comment auditer l'impact du JavaScript sur mon crawl budget ?

Commence par la Search Console, section « Statistiques d'exploration ». Regarde le nombre total de requêtes crawlées par jour, le temps de téléchargement moyen, et les erreurs serveur. Si tu vois une stagnation du nombre de pages crawlées alors que tu publies régulièrement du contenu, c'est un signal.

Ensuite, utilise les logs serveur. Extrais toutes les requêtes Googlebot et filtre par type de ressource : HTML, JS, API endpoints. Si tu vois que Googlebot tape massivement tes routes /api/*, c'est que le rendering client est actif. Compare le volume de hits sur /api/* vs le volume de hits sur les pages HTML — un ratio supérieur à 3:1 indique un problème structurel.

Quelles solutions techniques mettre en œuvre rapidement ?

Si tu es sur React, Vue ou Angular pur client, la migration vers du SSR ou SSG est la seule vraie solution pérenne. Next.js pour React, Nuxt pour Vue, Angular Universal pour Angular. C'est un chantier, mais c'est structurant pour le SEO à long terme.

À court terme, tu peux consolider les appels API. Au lieu de faire 5 requêtes séparées (produit, prix, stock, avis, recommandations), crée un endpoint unique /api/product-full/{id} qui renvoie tout en une fois. Ça divise par 5 le nombre de hits que Googlebot doit traiter.

Comment prioriser les pages à migrer en SSR ?

Ne migre pas tout d'un coup — commence par les pages à fort volume de recherche : fiches produits bestsellers, catégories principales, articles de blog rankés en top 10. Utilise les données Search Console pour identifier les URLs qui génèrent le plus d'impressions mais ont un CTR faible ou une position moyenne qui stagne.

Les pages de compte utilisateur, panier, checkout peuvent rester en CSR — Google n'a pas besoin de les crawler. Concentre tes efforts sur le contenu indexable à forte valeur SEO. Un site e-commerce de 2M de produits n'a souvent que 200k références qui génèrent 80% du trafic organique — commence par là.

• Auditer les logs serveur pour quantifier les appels API crawlés par Googlebot
• Vérifier le ratio requêtes API / pages HTML dans la Search Console
• Migrer les templates critiques (fiches produit, catégories) vers du SSR ou SSG
• Consolider les endpoints API pour réduire le nombre d'appels par page
• Monitorer l'évolution du crawl budget après chaque changement technique
• Prioriser les pages à forte valeur SEO pour la migration, pas tout le site d'un coup