Une URL accessible ne couvre qu’une partie du diagnostic SEO technique. Une page de tarifs ou de produit peut répondre en HTTP 200 et être indexable alors qu’un robot ne peut pas récupérer les données nécessaires à son contenu principal. Le navigateur habituel peut masquer ce problème.
Le cas suivant décrit une correction observée chez Sitelemetry le 12 septembre 2026. Il est établi qu’un test en direct de Google a ensuite affiché les cartes tarifaires. Cela ne démontre ni une indexation effective ni une amélioration du classement, du trafic ou des ventes.
Périmètre de cet audit
Ce qui peut être mesuré
- Réponses et indications d’indexation de l’URL publique exacte, avec les règles robots.txt correspondantes.
- Ressources publiques nécessaires au contenu essentiel de la page.
- Preuves avant et après du test Google en direct, avec suivi distinct des étapes ultérieures.
Ce qu’il ne prouve pas
- Une requête statique ne remplace pas les systèmes de rendu et d’indexation de Google.
- Un test en direct réussi ne garantit pas l’indexation ni sa date.
- Aucune hausse du classement, du trafic ou du chiffre d’affaires n’est démontrée par cette correction.
Les étapes manuelles peuvent être réalisées sans abonnement. Sitelemetry propose les audits SEO dans ses offres payantes ; l’inspection d’URL dans Search Console exige un accès approprié à la propriété.
Le cas concret de la page de tarifs
Chez Sitelemetry, /pricing répondait en HTTP 200 et pouvait être indexée. Pourtant, le catalogue tarifaire manquait dans le test Google en direct. La page dépendait de la ressource publique /api/plans, bloquée par la règle générale Disallow: /api/. Le chargement réussi du document HTML ne suffisait donc pas à restituer tout son contenu.
Le 12 septembre 2026, l’exception ciblée Allow: /api/plans$ a été ajoutée. Le test Google suivant a affiché les cartes tarifaires et indiqué que la page était indexable ; une demande d’indexation a ensuite été envoyée. C’est une preuve de correction du rendu, pas d’indexation déjà obtenue ou de visites supplémentaires. L’ouverture ne concernait pas les ressources privées des comptes.
Séparer trois questions différentes
Le robot peut-il récupérer l’URL ? Peut-il charger les ressources nécessaires et afficher le contenu important ? Le moteur décide-t-il ensuite d’indexer la page ? Ces questions sont liées, mais chacune demande une réponse et des preuves distinctes.
Google précise les limites de robots.txt : bloquer l’exploration n’est pas un moyen fiable de retirer une URL connue des résultats. Le robot doit pouvoir lire une instruction noindex ; une interdiction simultanée peut l’en empêcher. Consultez la documentation sur le blocage de l’indexation. Les données confidentielles nécessitent, séparément, de véritables contrôles d’accès. Ni robots.txt ni noindex ne protège les informations contre un accès non autorisé.
Examiner la page et ses dépendances
- Contrôlez l’URL exacte : redirections, statut, type de contenu et indications d’indexation dans le HTML comme dans les en-têtes HTTP.
- Lisez le robots.txt de la bonne origine et les règles visant le robot concerné. Un simple
Allow: /ne résout pas toutes les règles de chemins plus spécifiques. - Comparez le HTML initial au navigateur normal. Identifiez JavaScript, feuilles de style et données publiques nécessaires aux contenus décisifs.
- Dans le test Google en direct, examinez HTML rendu, image de la page et ressources en échec. Vérifiez le contenu réel, pas seulement un statut global favorable.
Un audit statique n’est pas le moteur de rendu de Google. Les bases du SEO JavaScript de Google décrivent ces étapes de traitement. Lorsqu’une preuve manque, conservez-la comme vérification ouverte.
Appliquer la modification minimale adaptée
Vérifiez d’abord que la ressource doit être publique et qu’elle est nécessaire au contenu. Dans ce cas, il s’agissait du catalogue public des offres, pas de données clients. Voici le fragment pertinent :
User-agent: *
Disallow: /api/
Allow: /api/plans$Ce fragment n’est pas un robots.txt complet à recopier tel quel. Google utilise la règle correspondante la plus spécifique ; $ marque la fin de l’URL. Les variantes avec paramètres et les chemins enfants ne sont donc pas automatiquement couverts. Vérifiez ce comportement dans la spécification officielle des règles. N’ouvrez pas indistinctement toute l’API. Selon l’architecture, fournir les contenus essentiels directement dans le HTML peut être préférable. Authentification et permissions restent nécessaires.
Retester avec Google et nommer précisément le résultat
Confirmez d’abord que robots.txt est accessible et que la ressource exacte fournit les données publiques attendues. Relancez ensuite le test en direct et vérifiez l’apparition des vraies cartes tarifaires, pas seulement d’un espace réservé ou d’un indicateur de chargement. Notez la date du test, le contenu visible et les erreurs de ressources restantes.
Une demande d’indexation peut suivre si elle convient à l’état de la page. Gardez toutefois le statut d’indexation séparé du résultat en direct. Une récupération réussie et un rendu correct ne signifient pas que l’URL est déjà indexée. Répéter les demandes n’offre aucune garantie de date ou de classement. L’affirmation étayée ici est que le test a pu afficher le catalogue auparavant absent.
Prioriser la prochaine action selon son effet
Traitez en priorité les pages dont le contenu manquant empêche une décision importante, comme comparer des offres ou comprendre un produit. Un affichage des prix défectueux mérite une correction sans prétendre à de grands volumes de recherche. Examinez les modèles connexes pour retrouver la même dépendance au lieu d’ajouter des autorisations au hasard.
Prévoyez aussi des liens internes accessibles et un sitemap adapté. Selon la documentation Google sur les sitemaps, un sitemap aide à découvrir les URL sans garantir exploration ni indexation. Distinguez donc présence dans le sitemap, réponse HTTP, rendu et preuve d’indexation. Aucune étape isolée ne garantit impressions, clics ou achats. Le rapport reste ainsi vérifiable et la prochaine action précise.
| Observation | Priorité selon le contexte | Preuve à confirmer | Action suivante |
|---|---|---|---|
| Le rendu omet des prix essentiels | Élevée sur la page de décision concernée | Contenu du test en direct et dépendance publique bloquée | Appliquer la correction ciblée justifiée et retester |
| Un chemin API privé est interdit | Pas intrinsèquement un défaut SEO | Déterminer si le contenu public dépend de cette ressource | Conserver les contrôles d’accès ; ne pas ouvrir les données privées |
| HTTP 200 sans preuve d’indexation | État à examiner séparément | Contenu rendu et état réel d’indexation | Contrôler l’indexation à part ; ne pas annoncer un gain supposé |
Questions fréquentes
HTTP 200 signifie-t-il que Google voit tout le contenu ?
Non. Le document HTML peut être accessible alors que des scripts, styles ou données publiques sont bloqués. Vérifiez aussi le contenu rendu et ses ressources.
Faut-il autoriser tous les chemins API aux robots ?
Non. Identifiez la ressource publique nécessaire et autorisez seulement le périmètre adapté. Les données privées exigent toujours des contrôles d’accès efficaces.
La correction Sitelemetry a-t-elle déjà augmenté le trafic organique ?
Ce cas ne le démontre pas. Il documente le rendu corrigé dans le test Google en direct et une demande d’indexation ultérieure, sans hausse établie du classement ou du trafic.
Sources et lectures
- Google : introduction à robots.txtdevelopers.google.com
- Google : spécification des règles robots.txtdevelopers.google.com
- Google : bases du SEO JavaScriptdevelopers.google.com
- Google : empêcher l’indexation avec noindexdevelopers.google.com
- Google : présentation des sitemapsdevelopers.google.com
Rédigé par l’équipe Sitelemetry et vérifié par rapport au périmètre du produit et aux sources primaires citées. Les exemples sont illustratifs, sauf mention explicite d’un cas observé.
