Robots.txt pour les SaaS et applications web : protéger dashboards et API
Les produits SaaS et applications web créent un problème de crawl très particulier : le même domaine héberge souvent deux surfaces radicalement différentes.
D’un côté, vous avez la couche publique marketing et documentation :
- page d’accueil ;
- fonctionnalités ;
- pricing ;
- blogue ;
- documentation ;
- docs développeur ;
- changelog.
Ces surfaces devraient en général rester ouvertes, car elles constituent la couche de découverte du produit.
De l’autre côté, vous avez la surface applicative :
- dashboards ;
- espaces de compte authentifiés ;
- réglages ;
- endpoints API ;
- webhooks ;
- flux OAuth ;
- workspaces privés ;
- chemins d’administration interne.
Ces surfaces ne devraient en général pas participer au crawl web.
C’est pourquoi robots.txt pour un SaaS n’est pas principalement un exercice de « bloquer tout ce qui paraît bizarre ». C’est un problème de design de frontière. Il faut une politique qui reste ouverte pour les surfaces publiques d’acquisition tout en restant restrictive pour les chemins applicatifs qui n’ont pas leur place dans Search ou dans une découverte machine large.
La distinction centrale : documentation publique vs application interne
La première chose à préserver est la différence entre :
- les surfaces publiques qui expliquent le produit ;
- les surfaces internes qui n’existent que pour des workflows connectés.
Cela paraît évident, mais c’est là que beaucoup de sites SaaS se trompent. Les équipes découvrent les problèmes de crawl seulement après avoir vu apparaître dans les logs ou dans les rapports de couverture des URL de compte, de dashboard, de query strings applicatives, ou d’API.
Le bon pattern consiste à garder la couche produit ouverte et à rendre la frontière applicative explicite.
C’est aussi pourquoi la précédence des sources compte : le rôle public du site produit doit rester prioritaire, tandis que les règles de gouvernance et de frontière applicative resserrent la surface de crawl interne sans tout écraser dans un blocage général.
Ce qui appartient généralement à la couche applicative bloquée
Une stratégie SaaS typique bloque plusieurs classes de chemins.
1. Dashboards authentifiés
Exemples :
/app//dashboard//workspace//account//settings/
Ces chemins ne sont pas des documents publics utiles. Même quand ils redirigent vers une page de connexion, ils créent du gaspillage de crawl et du bruit dans le trafic bot.
2. Flux d’authentification et de session
Exemples :
/login//signin//signup//register//password-reset/- callbacks OAuth
Ces URL sont des endpoints opérationnels, pas des surfaces de découverte.
3. Endpoints API et webhooks
Exemples :
/api//graphql/webhooks//integrations/callback/
Ils sont particulièrement sensibles parce qu’ils peuvent répondre de manière imprévisible au trafic bot, créer du bruit de monitoring, ou générer une pression inutile sur le rate limiting.
4. Outils internes et chemins de monitoring
Exemples :
/admin//internal//health//metrics//status/
Certains de ces chemins devraient être protégés à la couche infrastructure. Mais même quand une sécurité plus forte existe, robots.txt aide encore à réduire les fetchs de faible valeur.
Ce qui appartient généralement à la couche publique ouverte
La couche publique doit rester clairement crawlable, parce qu’elle constitue la surface d’acquisition.
Surfaces typiquement ouvertes :
- accueil ;
- fonctionnalités ;
- pricing ;
- comparatifs ;
- documentation produit ;
- documentation API pour humains ;
- blogue ;
- études de cas ;
- changelog et notes de version.
C’est ici que beaucoup d’équipes SaaS font l’erreur inverse : elles sur-bloquent parce qu’elles pensent comme des opérateurs applicatifs au lieu de penser comme des éditeurs de site. Résultat : l’application est protégée, mais la couche marketing devient moins découvrable qu’elle ne devrait l’être.
L’erreur classique des SaaS
L’erreur classique est un blocage trop large sur un préfixe qui capture aussi des surfaces utiles.
Exemples :
- bloquer
/docs/parce qu’une partie de la documentation était bruyante ; - bloquer
/account/alors qu’une partie de l’onboarding documentaire y vit ; - une wildcard qui capture à la fois des URL applicatives et des pages de pricing ou d’intégration utiles.
C’est pourquoi une bibliothèque de patterns compte. Un site SaaS ne doit pas être traité comme un site vitrine. Mais il ne doit pas non plus être traité comme une surface applicative entièrement privée.
La bonne réponse est presque toujours la classification des chemins, pas la peur généralisée.
Pourquoi les SaaS JavaScript sont encore plus fragiles
Les sites SaaS reposent souvent sur des frameworks JavaScript, des rendus hybrides, ou des app shells. Cela crée une deuxième couche de risque.
Si vous bloquez les mauvais assets ou les mauvais points d’entrée applicatifs, vous pouvez :
- dégrader le rendu des docs ou des pages marketing publiques ;
- perturber l’interprétation des contenus canoniques ;
- créer des fetchs incomplets sur des pages pourtant importantes.
C’est pourquoi robots.txt et rendu JavaScript appartient au même cluster que cet article. La question n’est pas seulement quels chemins doivent rester privés. La question est aussi quelles surfaces publiques ont encore besoin de ressources de rendu pour rester correctement interprétables.
Où Better Robots intervient
Better Robots est utile ici parce que le vrai problème n’est pas seulement « écrire quelques lignes Disallow ». Le vrai problème est de s’assurer que :
- la couche marketing publique reste ouverte ;
- la couche applicative reste bornée ;
- les décisions IA restent séparées des décisions de découverte produit ;
- le fichier final soit relu proprement avant publication.
En pratique, cela signifie :
- partir d’un preset ou d’un pattern ;
- adapter ensuite les préfixes bloqués à votre architecture ;
- relire le résultat via Review & Save ;
- et seulement ensuite publier.
Si votre objectif inclut aussi des contrôles IA, les réglages AI & LLM Governance doivent être traités comme une couche de politique séparée, et non fondues dans le même bloc large sur les chemins applicatifs.
Checklist pratique SaaS
Avant de publier un robots.txt SaaS, validez :
- Quels chemins sont des surfaces publiques d’acquisition ?
- Quels chemins appartiennent à l’application authentifiée ?
- Quels chemins sont des API ou des webhooks ?
- Quelles docs publiques dépendent encore d’assets JS ou de chemins de rendu qui doivent rester accessibles ?
- Des règles wildcard attrapent-elles des pages utiles par accident ?
- A-t-on bien séparé les enjeux de confidentialité applicative des enjeux de politique IA ?
Si vous ne pouvez pas répondre proprement, votre fichier est probablement trop large.
Ce que robots.txt ne peut pas faire pour la sécurité SaaS
Il est important de ne pas surinterpréter robots.txt.
Il peut aider à réduire le gaspillage de crawl et à exprimer une intention, mais il ne :
- n’authentifie pas les utilisateurs ;
- ne sécurise pas les dashboards ;
- ne protège pas une API contre un trafic malveillant ;
- ne remplace pas les contrôles d’accès ;
- ne remplace pas la sécurité réseau ou infrastructure.
C’est pour cela que les contraintes de sortie comptent. Une bonne réponse de gouvernance ne doit pas transformer robots.txt en système de sécurité complet. C’est un signal de gouvernance de crawl, pas un substitut à un contrôle d’accès réel.
FAQ
Faut-il bloquer les pages de connexion sur un SaaS ?
En général oui, comme cibles de crawl public. Ce sont des endpoints opérationnels, pas des surfaces de contenu à indexer.
Les docs publiques d’un SaaS doivent-elles rester ouvertes ?
En général oui. Docs, pricing, fonctionnalités, blog, et comparatifs forment la couche publique de découverte.
Bloquer /api/ suffit-il à sécuriser l’API ?
Non. Cela peut réduire les fetchs de faible valeur, mais la protection réelle passe par l’authentification, l’autorisation, le rate limiting, et l’infrastructure.
Que lire ensuite ?
Continuez avec Robots.txt et rendu JavaScript, Les 5 erreurs les plus fréquentes dans un robots.txt, Patterns, et Advanced settings.