Squarespace gestisce gran parte di robots.txt. Noi usiamo i controlli supportati invece di presumere accesso libero al file raw.
Riconosciamo il comportamento di /search
Un Disallow su /search può essere un default normale della piattaforma.
Crawlers gestisce la visibilità generale
Per decisioni a livello sito usiamo Crawlers e verifichiamo l’output pubblicato.
noindex è più preciso per una pagina
Una singola URL pubblica usa il controllo noindex/indicizzazione; il privato rimane dietro password o access control.
La sitemap è automatica
Apriamo la sitemap generata e controlliamo gli URL canonical invece di trattarla come XML manuale.
Verifichiamo l’output reale
Controlliamo /robots.txt, /sitemap.xml, checker e tester.
Search crawler e AI crawler sono controlli separati
Squarespace oggi espone impostazioni distinte per crawler di ricerca e bot IA conosciuti. Per una singola pagina pubblica usiamo noindex; per la visibilità del sito usiamo Crawlers; per contenuti privati password o access control. Il blocco IA è una richiesta gestita dalla piattaforma, non una garanzia contro tutti i bot presenti o futuri.
Le esclusioni gestite non sono automaticamente errori
Path come /search e alcuni pattern di parametri possono essere esclusi intenzionalmente. Prima di “correggere” un alert lo confrontiamo con la documentazione Squarespace. Poiché robots.txt è generato, cerchiamo una regola inattesa nei setting Crawlers, nella visibilità pagina, nelle collection o in altri controlli supportati, non in un file server da sostituire.
Le collection richiedono una verifica dedicata
Una scelta di indicizzazione applicata a una collection può coinvolgere anche gli elementi associati. Prima di cambiare un controllo ampio elenchiamo quali pagine devono restare trovabili, poi controlliamo il sitemap automatico per verificare che gli URL pubblici siano coerenti con Crawlers e con i controlli pagina. Un URL inatteso va ricondotto al setting che lo genera, non nascosto con un’altra regola.
