Per staging, noi mettiamo l’access control prima di robots.txt.
Usiamo autenticazione per il privato
Password, autenticazione o restrizioni di rete proteggono davvero l’ambiente. Disallow: / non è sicurezza.
Un preview pubblico può usare noindex
Se una URL deve essere raggiungibile per revisione ma non comparire nella ricerca, serviamo noindex lasciando il crawler libero di leggerlo.
Robots.txt resta un livello aggiuntivo
User-agent: *
Disallow: /
Può ridurre il crawling, ma non sostituisce autenticazione o noindex.
Separiamo staging e production
Verifichiamo entrambi gli host, rimuoviamo le sitemap di staging e impediamo che Disallow: / venga promosso in production.
Gate prima del release
Testiamo URL production con il tester e il file live con il checker.
Il controllo dipende dall’esposizione
Staging interno o revisione cliente richiedono autenticazione o restrizione di rete. Una preview pubblica che deve restare accessibile ma non apparire in ricerca può usare noindex restando crawlable. robots.txt è una seconda linea per il crawl, non una barriera di sicurezza.
Il rischio maggiore è portare in produzione un Disallow: / pensato per staging. Per questo la policy di produzione è esplicita e viene controllata come release gate.
Disattiviamo anche le preview vecchie
Dopo il lancio rimuoviamo l’accesso pubblico alle preview inutili o manteniamo l’autenticazione. Se uno staging pubblico è già indicizzato, aggiungere soltanto Disallow: / non è una procedura di rimozione. Valutiamo login, status HTTP appropriato oppure una fase crawlable con noindex.
Controlliamo le perdite di configurazione al release
Prima della promozione a production verifichiamo anche link interni, sitemap, canonical e variabili d’ambiente per individuare riferimenti allo staging. Dopo il deploy apriamo un campione di pagine pubbliche e confrontiamo le direttive di indicizzazione con robots.txt. Così intercettiamo non solo un Disallow: / dimenticato, ma anche hostname e riferimenti rimasti sull’ambiente sbagliato.
