In Webflow, noi trattiamo robots.txt come parte del processo di publish. Le impostazioni sono in Site settings → SEO → Indexing.
Controlliamo prima la production
Apriamo /robots.txt e cerchiamo Disallow troppo ampi, dominio errato e righe Sitemap: duplicate.
Consideriamo la sitemap automatica
Prima di aggiungere una riga verifichiamo se Webflow ha già inserito la sitemap. Reverse proxy e multi-site richiedono anche la verifica dell’opzione documentata per sostituirla.
Save non significa publish
Modifichiamo, salviamo, facciamo publish, poi recuperiamo di nuovo il file. Se resta vecchio, analizziamo cache e routing del dominio.
Content-Signal è un livello separato
Content-Signal riguarda preferenze di uso dei contenuti IA; robots.txt riguarda crawler access. Manteniamo separati i due meccanismi.
Testiamo prima del release
Usiamo tester e validator. I preview privati usano autenticazione.
Content-Signal non è uno standard robots.txt
Webflow documenta l’header Content-Signal per preferenze come ai-train=no, search=yes e ai-input=no, ma specifica che deriva da un’estensione proposta e non da uno standard accettato. robots.txt risponde alla domanda di accesso del crawler; Content-Signal esprime una preferenza d’uso dove supportata.
Sitemap, publish e dominio devono essere coerenti
Webflow aggiunge spesso il sitemap automaticamente. Prima di inserire una riga manuale verifichiamo duplicati e dominio canonico. Con reverse proxy o multi-site identifichiamo quale layer serve realmente /robots.txt e /sitemap.xml.
Salvare non equivale a pubblicare. Il controllo finale avviene sul custom domain dopo il publish; staging e produzione sono origini distinte e vengono verificate separatamente.
