Scegli il controllo che corrisponde all'esito desiderato
Il crawling è il recupero automatizzato di un URL. L'indicizzazione è la decisione di un motore di ricerca di memorizzare e mostrare informazioni su quell'URL. Il controllo accessi determina chi può ottenere il contenuto. Robots.txt riguarda il crawling e i crawler conformi scelgono se seguirlo. L'IETF Robots Exclusion Protocol afferma che non è autorizzazione.
Usa una regola Disallow per gestire l'accesso dei crawler a un percorso pubblico a basso valore, come una route di ricerca interna controllata. Usa noindex per contenuto pubblico che non dovrebbe apparire nei risultati supportati. Usa veri controlli di accesso per anteprime, aree con login, esportazioni o dati sensibili. Per informazioni di clienti, dipendenti, pagamenti o regolate, ottieni revisione qualificata di sicurezza e piattaforma; robots.txt non è mai un controllo compensativo.
Robots.txt può chiedere ai crawler conformi di evitare un percorso pubblico definito; non garantisce la rimozione dai risultati.
Usa noindex in HTML o un header X-Robots-Tag, e lascia la risposta crawlable in modo che l'istruzione possa essere letta.
Richiedi autenticazione o un controllo appropriato a livello di applicazione o server, poi rimuovi l'URL dai percorsi di scoperta pubblica.
Usa la sintassi e l'ambito di base con precisione
Pubblica un robots.txt in testo semplice UTF-8 in /robots.txt per ogni schema, host e porta che richiede regole. Un file a https://www.example.com/robots.txt non governa automaticamente https://example.com, un sottodominio o un'origine HTTP. Verifica le origini servite dagli URL canonici, redirect, CDN e applicazione prima di presumere che una regola si applichi.
Un gruppo inizia con User-agent e poi usa Allow o Disallow sui path. User-agent: * è il gruppo generale. Il matching è case-sensitive e parte dall'inizio del path. La regola più specifica vince; un Allow ugualmente specifico dovrebbe prevalere su Disallow. Disallow: non blocca nulla, mentre Disallow: / blocca l'intera origine. Lo standard definisce # per i commenti, * per il wildcard e $ per la fine di un pattern.
Se non esiste un bisogno documentato di gestione del crawl, non aggiungere esclusioni; non creare blocchi speculativi.
Preferisci un prefisso stabile e stretto come /search/ a un wildcard generico o a una regola di filename non spiegata.
Registra lo scopo della regola, il proprietario e il riferimento alla modifica, ma non trattare i commenti come sostituto della revisione.
Blocca solo pattern supportati da evidenza sugli URL
Prima di scrivere una regola, inventaria le pagine importanti, i percorsi di crawl indesiderati, le varianti di query, la ricerca on-site, le route di anteprima, le risorse e gli URL delle sitemap. Per ogni URL di esempio registra il risultato atteso e la regola corrispondente. Confronta l'elenco con gli URL canonici e la navigazione live in modo che un blocco non nasconda una route utile.
Mantieni disponibili le risorse critiche per il browser a meno che non sia stato testato il contrario. Google avverte che bloccare CSS, JavaScript, immagini o altre risorse può rendere una pagina più difficile da analizzare. Robots.txt non risolve la selezione del contenuto duplicato, l'autorizzazione o la qualità della pagina; usa canonicalizzazione, redirect, controlli di accesso o lavoro sul contenuto dove appropriato.
Usa campioni reali di URL e evidenza del server o del crawl, non una lista generica copiata da un altro sito.
Tieni per ogni esempio l'URL campione, il risultato previsto, la regola abbinata e il proprietario responsabile nel record di rilascio.
Mantieni coerenti sitemap, noindex e decisioni sulla privacy
Una sitemap dice ai motori di ricerca quali URL e file consideri importanti; può aiutare la scoperta ma non garantisce crawling o indicizzazione. Forti link interni sono comunque importanti. Puoi aggiungere un URL Sitemap completamente qualificato in robots.txt, ma non inserire URL privati, redirectati, bloccati da robots o intenzionalmente noindex. Riconcilia l'output della sitemap con le regole robots al rilascio.
Noindex non è una direttiva di robots.txt per Google. Google la supporta in un meta tag HTML o nell'header di risposta HTTP X-Robots-Tag, e deve poter effettuare il crawl della risposta per vederla. Se una pagina pubblica deve uscire dai risultati Google, rimuovi qualsiasi blocco robots che nasconde il noindex. Se il contenuto è non pubblico, non pubblicizzare il suo percorso in robots.txt; applica il controllo di accesso. I confini sui dati sensibili richiedono revisione qualificata.
Usa un URL completo, per esempio Sitemap: https://www.example.com/sitemap.xml; non sovrascrive un blocco di crawling.
Usa un meta noindex per l'HTML o un header X-Robots-Tag: noindex nella risposta HTTP quando adatto, poi testa la risposta live.
Restringi prima l'accesso quando il contenuto è sensibile, poi usa il processo di rimozione del motore di ricerca se appropriato.
Testalo e rilascialo come un file di configurazione critico
Valida il testo approvato in locale, poi testa esempi consentiti e bloccati per il gruppo di crawler previsto. Dopo il deployment, recupera il /robots.txt pubblico in privato o tramite richiesta HTTP diretta per confermare contenuto, origine e stato della risposta. Google offre un report robots.txt in Search Console per file accessibili e una libreria parser open-source per test locali.
I crawler possono memorizzare nella cache i file robots, quindi non promettere cambiamenti immediati di discovery o indicizzazione. Errori di server o di rete portano i crawler ad assumere disallow completo, mentre un 4xx può permettere l'accesso. Tieni il file sotto controllo di versione, richiedi revisione extra per modifiche che coinvolgono l'intero sito o wildcard, e conserva la versione precedente. I preflight e la pianificazione di rollback di SIU aiutano a intercettare un rilascio sbagliato prima che diventi un problema più esteso di disponibilità o discoverability.
Richiedi un secondo revisore per migrazioni di origine, blocchi sull'intero sito, wildcard e cambi che interessano route di login, checkout o supporto.
Ripristina la versione precedente quando un URL campione importante viene appena bloccato, una risorsa necessaria è inaccessibile o l'endpoint non è disponibile.
Un singolo test crawler non prova che ogni client automatizzato interpreti ogni regola allo stesso modo.