Dans Webflow, nous intégrons robots.txt au processus de publication. Les réglages se trouvent dans Site settings → SEO → Indexing.
Nous vérifions la production avant modification
Nous ouvrons /robots.txt et cherchons blocages trop larges, mauvais domaine et lignes Sitemap: dupliquées.
Nous tenons compte du sitemap automatique
Avant d’ajouter une ligne, nous vérifions si Webflow l’a déjà créée. Les architectures reverse proxy ou multi-site demandent aussi de vérifier l’option documentée de remplacement.
Sauvegarder ne suffit pas : nous publions
Nous modifions, sauvegardons, faisons publish, puis rechargeons la réponse. Si elle reste ancienne, nous examinons cache et routage de domaine.
Content-Signal reste une autre couche
Content-Signal concerne des préférences d’usage IA ; robots.txt concerne le crawl. Nous gardons ces mécanismes distincts.
Nous testons avant release
Nous utilisons le tester et le validator. Les previews privés utilisent authentification.
Content-Signal n’est pas un standard robots.txt
Webflow documente le header Content-Signal pour des préférences comme ai-train=no, search=yes ou ai-input=no, tout en précisant qu’il repose sur une extension proposée et non sur un standard accepté. robots.txt répond à la question d’accès du crawler ; Content-Signal exprime une préférence d’usage lorsque le destinataire la prend en charge.
Sitemap, publication et domaine doivent rester cohérents
Webflow ajoute souvent le sitemap automatiquement. Avant une ligne manuelle, nous vérifions sa présence et le domaine canonique. Avec reverse proxy ou architecture multi-site, nous confirmons quelle couche sert réellement /robots.txt et /sitemap.xml.
Sauvegarder n’est pas publier. Le test final se fait après publication sur le domaine public ; staging et custom domain sont contrôlés comme des origines distinctes.
