Guide robots.txt

Robots.txt e sottodomini: come verifichiamo lo scope

Il nostro metodo per protocollo, host, porta, www, staging e ownership del deployment prima di cambiare le regole robots.txt.

Di Robots.txt Tools Editorial TeamUltima verifica 2026-09-131 min di lettura

Metodo editoriale: questa guida documenta il flusso di verifica usato dal Robots.txt Tools Editorial Team. La prima persona descrive il metodo operativo e non rivendica lavori per clienti o casi personali.

Robots.txt e sottodomini: come verifichiamo lo scope

Quando una regola sembra corretta ma non funziona, noi controlliamo lo scope prima della sintassi. Robots.txt vale per una specifica origin composta da protocollo, host e porta.

Separiamo ogni origin

https://example.com/robots.txt
https://shop.example.com/robots.txt
http://example.com/robots.txt
https://example.com:8443/robots.txt

Non esiste ereditarietà automatica tra queste origini.

Creiamo un inventario degli host

Production, www, shop, docs, preview e staging vengono controllati separatamente. Questo spesso evidenzia file vecchi, 404 o piattaforme diverse.

Identifichiamo chi pubblica la risposta

Framework, CMS, CDN o reverse proxy possono possedere /robots.txt. Modifichiamo il livello che serve davvero il file pubblico.

Testiamo l’URL sull’host corretto

Una URL dello shop viene verificata contro la policy dello shop. Il tester mostra la regola vincente e il checker conferma il file live.

Lo staging richiede sicurezza reale

Per contenuti privati usiamo autenticazione o access control. Disallow: / non è sicurezza. Per preview pubblici valutiamo anche noindex.

Guide correlate