Guides robots.txt par plateforme

Squarespace robots.txt : comment nous travaillons avec les contrôles gérés

Notre processus pour Crawlers, /search, noindex par page, sitemap automatique et limites de Squarespace.

Par Robots.txt Tools Editorial TeamDernière vérification le 2026-10-012 min de lecture

Méthode éditoriale : ce guide documente le processus de vérification de l’équipe éditoriale Robots.txt Tools. La première personne décrit cette méthode et ne revendique ni mission client ni étude de cas personnelle.

Squarespace robots.txt : comment nous travaillons avec les contrôles gérés

Squarespace gère une grande partie de robots.txt. Nous utilisons donc les contrôles supportés plutôt qu’un workflow de fichier raw inexistant.

Nous reconnaissons le traitement de /search

Une exclusion /search peut être un comportement normal de la plateforme.

Crawlers gère la visibilité globale

Pour une décision à l’échelle du site, nous utilisons Crawlers et vérifions ensuite la sortie publiée.

noindex est plus précis par page

Une URL publique individuelle utilise le contrôle noindex/indexation. Le privé reste derrière mot de passe ou contrôle d’accès.

Le sitemap est automatique

Nous ouvrons le sitemap généré et contrôlons les URL canoniques, sans essayer de maintenir manuellement le XML.

Nous contrôlons la sortie réelle

Nous vérifions /robots.txt, /sitemap.xml, le checker et le tester.

Les crawlers de recherche et d’IA sont séparés

Squarespace expose désormais des réglages distincts pour les crawlers de recherche et les bots IA connus. Pour une page publique individuelle, nous privilégions noindex; pour le site entier, le réglage Crawlers ; pour le privé, mot de passe ou contrôle d’accès. Le blocage IA reste une demande gérée par la plateforme, pas une garantie contre tous les bots présents ou futurs.

Les exclusions gérées ne sont pas forcément des erreurs

Des chemins comme /search et certains paramètres peuvent être exclus volontairement. Avant de “corriger” une alerte, nous la comparons à la documentation Squarespace. Puisque le fichier est généré, une règle inattendue se cherche dans Crawlers, visibilité de page, collections ou autres réglages supportés, pas dans un fichier serveur à remplacer.

Les collections demandent une vérification dédiée

Une décision d’indexation au niveau d’une collection peut affecter les éléments associés. Nous listons donc les pages qui doivent rester visibles avant de modifier un réglage global, puis nous contrôlons le sitemap automatique pour vérifier que les URL publiques restent cohérentes avec Crawlers et les options de page. Une URL inattendue doit être expliquée par le réglage qui la génère, pas masquée par une règle supplémentaire.

Guides associés