Pourquoi Google affiche-t-il des pages vides alors que votre site JavaScript fonctionne parfaitement ?

En quoi les navigateurs et Googlebot traitent-ils robots.txt différemment ?

Les navigateurs modernes ignorent totalement le fichier robots.txt. Quand vous testez votre site dans Chrome, Firefox ou Safari, chaque requête JavaScript vers vos API passe sans filtre. C'est pour ça que votre page affiche correctement la liste de produits, les avis clients ou les données de prix.

Googlebot, lui, respecte strictement les directives robots.txt avant d'exécuter le moindre script. Si une URL d'API est bloquée, le bot n'y touche pas — point final. Le rendu côté Google échoue donc à charger les données dynamiques, et vous vous retrouvez avec du HTML vide dans l'index.

Comment ce blocage crée-t-il des pages fantômes dans l'index ?

Imaginons un site e-commerce qui charge ses fiches produits via fetch('/api/products/12345'). Si robots.txt contient Disallow: /api/, Googlebot télécharge le HTML initial, exécute le JavaScript... mais bloque net la requête API.

Le DOM reste donc squelettique : pas de titre produit, pas de description, pas de prix. Google indexe cette coquille vide. Vous, en testant dans votre navigateur, voyez la page complète et pensez que tout va bien. C'est le piège classique du test manuel qui ne reflète pas la réalité du crawl.

Pourquoi tant de sites bloquent-ils leurs API sans le savoir ?

Beaucoup de robots.txt sont générés automatiquement par des CMS ou frameworks avec des règles « sécuritaires » par défaut. Les développeurs bloquent /api/ en pensant protéger leurs données ou éviter du crawl inutile.

D'autres fois, c'est un reliquat historique : le site était en pur PHP server-side, puis a migré vers React/Vue/Angular sans nettoyer le robots.txt. Résultat : les endpoints critiques restent interdits alors qu'ils sont désormais essentiels au rendu client.

• Les navigateurs ne consultent jamais robots.txt — vos tests manuels passent toujours
• Googlebot bloque toute requête API listée dans Disallow, même pour du rendering JavaScript
• Un robots.txt mal configuré génère des pages vides dans l'index malgré un site fonctionnel
• Le problème est invisible sans test via Search Console ou un outil de rendu Google
• Les frameworks modernes amplifient ce risque en multipliant les appels API côté client

Cette déclaration est-elle cohérente avec ce qu'on observe sur le terrain ?

Absolument. On voit régulièrement des sites SPA ou Jamstack avec des taux d'indexation catastrophiques — 30% de pages indexées alors que le sitemap en liste 10 000. Quand on inspecte via l'outil de test d'URL de Search Console, le rendu HTML affiche des <div id="app"></div> vides.

Le diagnostic ? Un Disallow: /api/ ou Disallow: /_next/data/ dans robots.txt. Les développeurs ne pensent pas « SEO » quand ils configurent ces règles — ils pensent sécurité, performance, ou ils copient-collent un template. Et ça casse l'indexation sans que personne ne s'en rende compte pendant des mois.

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

Premier point : si votre contenu est déjà présent dans le HTML initial (SSR, prérendu, hydratation progressive), bloquer les API a moins d'impact. Google lit le contenu server-side, même si les enrichissements JavaScript échouent ensuite. Mais ça reste un jeu dangereux — certains éléments (prix dynamiques, stock, avis) peuvent manquer.

Deuxième nuance : certains blocs /api/analytics, /api/tracking ou /api/user-prefs n'ont aucun impact SEO et peuvent légitimement rester bloqués. Le problème, c'est qu'on voit souvent des règles Disallow: /api/ trop larges qui tuent tout. [À vérifier] au cas par cas : chaque endpoint doit être évalué pour son rôle dans le rendu visible.

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

Si vous utilisez du server-side rendering strict (Next.js getServerSideProps, Nuxt asyncData côté serveur, PHP classique), robots.txt ne bloque rien puisque les données sont injectées avant l'envoi du HTML. Googlebot reçoit du contenu complet sans exécuter de JavaScript.

Autre exception : les sites qui chargent du contenu non-indexable par design (zones membres, paniers, préférences utilisateur). Là, bloquer /api/ est intentionnel et sans impact SEO négatif. Mais soyons honnêtes — la plupart du temps, c'est un accident de configuration, pas une stratégie réfléchie.

Comment vérifier que vos API ne sont pas bloquées ?

Première étape : ouvrez votre robots.txt et cherchez toute ligne contenant Disallow: /api, Disallow: /_next, Disallow: /data ou équivalent. Si vous trouvez ça, c'est un red flag immédiat.

Ensuite, utilisez l'outil d'inspection d'URL dans Search Console. Cliquez sur « Tester l'URL en direct », puis « Afficher la page explorée » > « Plus d'infos » > « JavaScript ». Comparez le rendu final avec votre page réelle dans Chrome. Si des sections entières manquent (produits, articles, données), vous avez trouvé le coupable.

Quelles erreurs éviter lors de la configuration de robots.txt ?

Ne bloquez jamais un chemin entier comme /api/ sans réfléchir. Si vous devez protéger certains endpoints, listez-les individuellement : Disallow: /api/admin, Disallow: /api/user-settings. Laissez passer ce qui sert au rendu public.

Autre piège classique : les règles en cascade mal ordonnées. Si vous écrivez Disallow: /api/ puis Allow: /api/products, l'ordre compte selon certains bots. Google gère ça correctement, mais autant éviter la confusion — soyez explicite et minimaliste.

Que faut-il faire concrètement pour corriger ce problème ?

Identifiez tous les endpoints API essentiels au rendu de vos pages indexables. Créez une liste : /api/products, /api/posts, /api/categories, etc. Vérifiez qu'aucun de ces chemins n'apparaît dans une directive Disallow.

Si vous devez bloquer certaines API pour des raisons de sécurité, utilisez plutôt une authentification côté serveur (tokens, headers, CORS strict) au lieu de vous reposer sur robots.txt. Ce fichier n'est pas un pare-feu — c'est une indication pour les bots coopératifs.

• Auditer robots.txt et supprimer toute règle Disallow: /api/ trop large
• Tester le rendu JavaScript via Search Console sur 10-20 pages stratégiques
• Comparer le HTML exploré par Google avec le rendu navigateur réel
• Lister les endpoints API critiques et autoriser explicitement leur crawl si besoin
• Mettre en place une alerte de suivi d'indexation pour détecter les chutes brutales
• Documenter dans votre runbook SEO les règles robots.txt et leur justification