robots.txt spiegato: gestire correttamente i crawler dei motori di ricerca

Il file robots.txt fa parte degli strumenti fondamentali dell'ottimizzazione tecnica per i motori di ricerca. Con essa puoi indicare ai crawler dei motori di ricerca quali aree del tuo sito web possono essere scansionate e quali no.

Tuttavia, una configurazione errata può avere conseguenze notevoli. Nel peggiore dei casi, a Google viene impedito di indicizzare parti importanti o addirittura l'intero sito web.

È altrettanto importante capire cosa robots.txt non può: non è uno strumento affidabile per rimuovere pagine web dall'indice di Google.

In questo articolo spieghiamo come una robots.txt è strutturato, che User-agent, Vieta e Consenti significa come inserire una sitemap e quali errori dovresti assolutamente evitare.

Breve spiegazione: Muori robots.txt controlla principalmente quali URL i crawler dei motori di ricerca possono visitare. Controlla quindi Scansione. Se una pagina web debba essere indicizzata o meno è un'altra questione.

Che cos'è un file robots.txt? #

Muori robots.txt è un semplice file di testo che si trova nella directory radice di un host.

Nel caso di un sito web all'indirizzo:

https://example.com

si trova il file in:

https://example.com/robots.txt

I crawler dei motori di ricerca recuperano questo file e verificano quali regole di scansione si applicano a loro.

Dove deve trovarsi il file robots.txt? #

Il file deve trovarsi direttamente nella directory principale del rispettivo host.

Corretto:

https://example.com/robots.txt

Un file in:

https://example.com/verzeichnis/robots.txt

non è la robots.txt per l'intero sito web.

Il nome del file deve robots.txt lauten.

Il file robots.txt si applica sempre al rispettivo host #

Una importante particolarità tecnica è il campo di applicazione.

Il file in:

https://example.com/robots.txt

si applica agli URL sotto questo host e protocollo.

Non si applica automaticamente a:

https://shop.example.com

Se un sottodominio richiede regole di scansione proprie, ha conseguentemente bisogno di una propria robots.txt sotto il loro host.

Anche i diversi protocolli e le diverse porte vengono considerati tecnicamente separati.

Com'è strutturata una robots.txt? #

Un file semplice potrebbe apparire così, ad esempio:

User-agent: *
Disallow: /intern/

Sitemap: https://example.com/sitemap.xml

Gli elementi più importanti sono:

Istruzione	Significato
User-agent	Determina a quale crawler si applicano le seguenti regole
Vieta	Impedisce il crawling dei percorsi URL corrispondenti
Consenti	Consente la scansione dei percorsi URL corrispondenti all'interno delle rispettive categorie di regole
Mappa del sito	Fornisce l'indirizzo completo di una sitemap

Cosa significa User-agent? #

Con User-agent viene definito per quale crawler è destinato un gruppo di regole.

L'asterisco sta per tutti i crawler a cui si applica questo gruppo generale:

User-agent: *

Una regola può anche essere scritta in modo specifico per un determinato crawler.

Per esempio:

User-agent: Googlebot
Disallow: /beispiel/

Con ciò questo gruppo di regole si rivolge specificamente a Googlebot.

Cosa significa Disallow? #

Con Vieta puoi escludere un percorso URL per il rispettivo crawler dal crawling.

Esempio:

User-agent: *
Disallow: /intern/

In questo modo viene comunicato ai rispettivi crawler che gli URL sotto questo percorso non devono essere scansionati.

Per esempio:

https://example.com/intern/

https://example.com/intern/datei.html

https://example.com/intern/unterordner/

Cosa significa una direttiva Disallow vuota? #

Un vuoto VietaL'istruzione non blocca alcun percorso.

Esempio:

User-agent: *
Disallow:

Ciò non esclude nulla dal crawling per questo gruppo di regole.

Tuttavia, se il tuo sito web può essere completamente scansionato, una regola di questo tipo non è strettamente necessaria. In linea di principio, un sito web può anche fare a meno di limitazioni robots.txt-Le regole vengono scansionate.

Bloccare l'intero sito web per i crawler #

La seguente regola è particolarmente importante:

User-agent: *
Disallow: /

Istruisce i crawler interessati a non eseguire la scansione dell'intero sito web.

Attenzione: Questa configurazione non deve rimanere accidentalmente attiva su un sito web pubblicamente indicizzabile. Specialmente dopo il passaggio da un ambiente di sviluppo o di staging al sito web di produzione, dovresti robots.txt controllare.

Significa permettere. #

Con Consenti un determinato percorso all'interno di una struttura altrimenti bloccata può essere espressamente autorizzato per il crawling.

Un esempio semplificato:

User-agent: *
Disallow: /bereich/
Allow: /bereich/oeffentlich/

In questo modo l'area viene fondamentalmente bloccata, mentre è consentito effettuare il crawling del percorso specificamente autorizzato.

Allow e Disallow possono essere usati insieme #

I siti Web più complessi possono richiedere regole in cui viene esclusa un'area più ampia e viene nuovamente autorizzata una specifica risorsa o sottostruttura.

A ciò si dovrebbe prestare particolare attenzione, poiché piccole modifiche al pattern dell'URL possono avere un effetto diverso da quello previsto.

Consiglio pratico: Stai zitto robots.txt Il più semplice possibile. Dovresti usare regole complesse solo se c'è un motivo tecnico specifico.

I robots.txt non sono una funzione di sicurezza #

Un' Vieta-La regola non protegge i dati riservati.

Il file è accessibile pubblicamente e le sue regole possono essere consultate da chiunque.

Se, ad esempio, inserisci quanto segue:

User-agent: *
Disallow: /geheime-dokumente/

allora il sentiero non è protetto dai visitatori in questo modo.

Chi conosce l'URL può continuare ad accedervi direttamente, a meno che non vi sia una vera protezione degli accessi.

Importante: I contenuti riservati devono essere protetti con meccanismi di accesso adeguati. Un robots.txt non vi è alcuna protezione tramite password né alcun controllo degli accessi.

I file robots.txt e noindex non sono la stessa cosa #

Questa è la differenza più importante dell'intero articolo.

robots.txt	noindex
controlla il crawling	controlla l'indicizzazione
è disponibile come file di testo centrale	viene fornito, ad esempio, come istruzione meta robots o intestazione HTTP
può impedire il recupero di un URL	indica ai motori di ricerca di non indicizzare la pagina
nessun strumento affidabile per rimuovere una pagina web da Google	destinato all'esclusione di una pagina accessibile dall'indice

Perché un URL bloccato può comunque comparire su Google? #

Google può conoscere un URL anche in altri modi, ad esempio tramite i link di altri siti web.

Se l'URL tramite robots.txt è escluso dal crawling, Google non può recuperarne il contenuto effettivo normalmente.

L'URL potrebbe comunque essere noto a Google.

Ecco perché la seguente supposizione è errata:

Disallow = assolutamente escluso su Google

Un da robots.txt L'URL bloccato potrebbe in determinate circostanze continuare ad apparire come URL nei risultati di ricerca.

Perché noindex non funziona se a Google non è permesso di indicizzare la pagina? #

Supponendo che una pagina contenga:

<meta name="robots" content="noindex">

e allo stesso tempo blocca il robots.txt Google dal recupero di questa pagina.

Allora sorge un problema:

robots.txt
blocca il crawling
        ↓
Google non recupera la pagina
        ↓
Google non vede il tag noindex

Affinché Google possa noindexPer poter riconoscere il comando, il crawler deve avere il permesso di accedere alla pagina in questione.

Nota: Se una pagina pubblicamente accessibile deve essere esclusa dall'indice di Google, non devi contemporaneamente impedire a Google di noindexIstruzione da vedere.

Si può scrivere noindex nel file robots.txt? #

No. Google supporta noindex non come regola all'interno della robots.txt.

Dovresti quindi evitare di usare quanto segue:

User-agent: *
Noindex: /beispiel/

Se non si desidera che una pagina HTML venga indicizzata, è possibile utilizzare, ad esempio, un tag meta robots:

<meta name="robots" content="noindex">

Per altri tipi di risorse, a seconda del caso d'uso, è possibile utilizzare un intestazione HTTP corrispondente.

Quando è utile il file robots.txt? #

Un' robots.txt è particolarmente utile se desideri controllare il crawling di determinate aree di URL.

Ciò può essere rilevante, ad esempio, per i siti Web che possiedono un numero elevato di varianti di URL generate tecnicamente.

I casi possibili sono:

determinate aree tecniche
URL di ricerca o filtro non necessari
determinate strutture di URL generate automaticamente
accesso dei crawler a singole risorse
grandi volumi di URL di scansione irrilevanti

Se una limitazione sia sensata, tuttavia, deve essere valutato per il sistema specifico.

Non ogni URL tecnico deve essere bloccato #

Un lungo robots.txt non è automaticamente migliore di una corta.

Nel caso di siti web più piccoli e ben strutturati, spesso non vi è alcun motivo di bloccare preventivamente numerosi directory.

Ogni regola aggiuntiva aumenta piuttosto il rischio di escludere accidentalmente contenuti o risorse importanti.

Che ne è di WordPress? #

I siti Web WordPress possiedono spesso un sistema fornito automaticamente o dinamicamente robots.txt.

A seconda della configurazione e dei plugin utilizzati, il loro contenuto può variare.

Ecco perché non dovresti copiare ciecamente un file „robots.txt WordPress ottimizzato“ di qualcun altro da Internet.

Apri prima:

https://deine-domain.ch/robots.txt

e verifica quali regole il tuo sito web sta effettivamente inviando.

L'impostazione di WordPress per la visibilità ai motori di ricerca #

WordPress dispone nelle impostazioni di un'opzione per impedire ai motori di ricerca di indicizzare il sito web.

Questa impostazione è rilevante, ad esempio, durante una fase di sviluppo.

Per un sito web pubblicamente accessibile, dopo il go-live devi assolutamente verificare che una precedente configurazione di sviluppo non sia rimasta attiva per errore.

L'output tecnico che ne deriva può dipendere dalla versione di WordPress, dalla configurazione e dai plugin utilizzati. Perciò, ciò che conta davvero è sempre il sito web effettivamente pubblicato.

Gestire correttamente i siti di staging #

Un sito di sviluppo o di staging normalmente non dovrebbe apparire pubblicamente nei motori di ricerca.

Una pura robots.txt-Tuttavia, il blocco non costituisce una protezione completa contro questo.

Per gli ambienti di sviluppo non pubblici, una protezione di accesso reale è molto più affidabile.

Per esempio:

Sito di staging
↓
Autenticazione /
Protezione tramite password
↓
non accessibile al pubblico

In questo modo ti proteggi non solo dall'indicizzazione dei motori di ricerca, ma anche da accessi pubblici indesiderati.

Controllare robots.txt dopo un rilancio #

Dopo un rilancio del sito web appartiene la robots.txt alle file che dovresti assolutamente controllare.

Controlla in particolare:

Il sito web di produzione è scansionabile?

È attivo per errore il comando Disallow: /?

Ci sono aree importanti bloccate?

Le risorse CSS/JS importanti sono accessibili?

L'indirizzo della sitemap è corretto?

Le regole provengono ancora dall'ambiente di sviluppo?

Se contemporaneamente è stata modificata la struttura degli URL, dovresti inoltre controllare reindirizzamenti, sitemap e stato di indicizzazione.

Non bloccare inutilmente file CSS e JavaScript importanti #

Google esegue il rendering delle pagine web moderne e per farlo ha spesso bisogno di risorse CSS, JavaScript e di altro tipo.

Se risorse importanti tramite le robots.txt se viene bloccata, Google potrebbe non essere in grado di elaborare e visualizzare una pagina nello stesso modo in cui la vede un normale visitatore.

Ecco perché non dovresti bloccare in modo generalizzato le directory CSS e JavaScript solo perché questi file in sé non sono pensati come normali risultati di ricerca.

Google deve poter capire la pagina il più possibile come un visitatore #

Se il layout, la navigazione o i contenuti essenziali dipendono da JavaScript o CSS, il blocco di queste risorse può complicare l'elaborazione.

In caso di problemi, puoi utilizzare lo strumento di controllo URL della Google Search Console e analizzare in che modo Google elabora la pagina in questione.

Puoi trovare maggiori informazioni sulla verifica dell'URL all'indirizzo Google non indicizza il mio sito web: verifica le cause.

Specificare una Sitemap in robots.txt #

Muori robots.txt può fare riferimento a una sitemap XML.

Esempio:

User-agent: *
Disallow:

Sitemap: https://example.com/sitemap.xml

L'indirizzo della Sitemap deve essere specificato per intero.

Se il tuo sito web utilizza un indice delle sitemap, questo può essere specificato di conseguenza:

Mappa del sito: https://example.com/sitemap_index.xml

Spiegheremo come funzionano le sitemap XML e come inviarle a Google su Mappa del sito XML: cosa fa e come inviarla a Google.

La Sitemap e il file robots.txt hanno scopi contrastanti #

In modo semplice puoi ricordare la differenza così:

XML-Sitemap

"Ecco gli URL importanti
che dovresti conoscere."


robots.txt

"Non devi scansionare
queste aree di URL."

Ecco perché entrambe le configurazioni dovrebbero coincidere logicamente.

Non consigliare e bloccare un URL contemporaneamente #

Se un URL è presente come pagina importante e indicizzabile nella tua sitemap XML, non dovrebbe contemporaneamente essere robots.txt essere esclusi dal crawling.

Una tale configurazione genera segnali contraddittori:

Sitemap:
"Questo URL è rilevante."

robots.txt:
"Non recuperare questo URL."

Verifica quindi sempre entrambi i lati della configurazione in caso di problemi di indicizzazione.

Usare i commenti in robots.txt #

I commenti possono essere con un # essere avviate.

Esempio:

# Non eseguire il crawling dell'area tecnica
User-agent: *
Disallow: /intern/

Tutto dopo il # viene trattato come un commento in questa riga.

I commentari possono aiutare a documentare perché esiste una determinata regola nei file più complessi.

distinguere tra maiuscole e minuscole nei percorsi degli URL #

Nei percorsi degli URL in Consenti– e Vieta-Regeln ist die Groß- und Kleinschreibung relevant.

Ad esempio sono:

/Immagini/

/immagini/

non automaticamente lo stesso pattern di URL.

Scrivi quindi le regole in modo appropriato rispetto ai percorsi URL effettivamente utilizzati.

Caratteri jolly nel file robots.txt #

Google supporta, tra le altre cose, l'asterisco nelle regole dei percorsi * come segnaposto.

Un esempio:

User-agent: Googlebot
Disallow: /*.pdf

Questo consente di catturare i percorsi degli URL in base a un modello.

Dovresti usare tali regole con cautela, poiché possono interessare molte più URL rispetto a una semplice regola di directory.

Il simbolo del dollaro per la fine di un URL #

Google supporta anche $, per indicare la fine di un modello di URL.

Esempio:

User-agent: Googlebot
Disallow: /*.pdf$

Il modello prende di mira gli URL il cui percorso corrisponde a .pdf finisce.

Un URL con caratteri aggiuntivi o parametri secondo questo schema può quindi essere trattato in modo diverso.

Consiglio pratico: I caratteri jolly sono potenti, ma inclini agli errori. Per un normale sito web aziendale non dovresti usare pattern complessi, se regole semplici raggiungono lo stesso scopo.

Quale regola prevale in caso di sovrapposizioni? #

Se diversi Consenti– e VietaSe più regole corrispondono a un URL, Google valuta la regola specifica corrispondente in base alla lunghezza del percorso corrispondente.

Un esempio semplificato:

User-agent: *
Disallow: /ordner/
Allow: /ordner/oeffentlich/

Per un URL all'indirizzo:

https://example.com/ordner/oeffentlich/seite

è la più specifica Consenti-Regola determinante.

Proprio nel caso di insiemi di regole complessi, dovresti quindi considerare non solo l'ordine delle righe.

Crawl-delay e Google #

Manica robots.txtGli esempi su Internet contengono un'istruzione come:

Crawl-delay: 10

Google supporta ritardo di scansione nel robots.txt non.

Non dovresti quindi usare questa istruzione come metodo per controllare la velocità di scansione di Googlebot.

non riempire inutilmente il file robots.txt con regole estranee #

Su Internet si trovano numerosi file precompilati con lunghe liste di bot e regole.

Non dovresti accettare passivamente modelli del genere.

Una configurazione esterna può:

essere destinato a un altro CMS
contenere regole obsolete
bloccare risorse importanti
contenere regole per bot non necessarie
non corrispondere alla tua struttura degli URL
rendere più difficile la tracciabilità di errori futuri

Un file breve, comprensibile e documentato è spesso la soluzione migliore.

robots.txt e crawler di IA #

Anche altri sistemi automatizzati possono utilizzare i propri nomi di user-agent e rispettare il protocollo di esclusione dei robot.

Se e come un determinato servizio interpreti le regole di crawling dipende dal rispettivo fornitore e crawler.

Non dovresti quindi dare per scontato che una singola regola per Googlebot riguarda automaticamente tutti i crawler di motori di ricerca, intelligenza artificiale, analisi e di altro tipo.

Se desideri controllare in modo mirato un determinato crawler, dovresti verificarne la documentazione ufficiale aggiornata e la designazione dello user-agent.

verificare robots.txt pubblicamente nel browser #

Il primo controllo più semplice consiste nel richiamare direttamente il file:

https://deine-domain.ch/robots.txt

Verifica poi:

Il file viene visualizzato?

Il contenuto è quello previsto?

C'è Disallow: /?

Vengono bloccati percorsi importanti?

La Sitemap è corretta?

Ci sono vecchie regole?

Controllare robots.txt in Google Search Console #

Google Search Console fornisce informazioni su quelle rilevate da Google robots.txt pronto.

In questo modo puoi verificare, ad esempio, quale file Google ha riconosciuto per il tuo sito web e se ci sono problemi durante il recupero.

Per un URL specifico è inoltre importante il controllo degli URL, se desideri verificare se Google è in grado di eseguire il crawling della pagina.

Dopo una modifica non limitarsi a controllare il browser #

Se tu robots.txt-hai modificato la regola, non dovresti solo controllare se il nuovo file è visibile nel browser.

Verifica inoltre uno o più URL effettivamente interessati.

Per esempio:

Regola modificata
        ↓
Verificare robots.txt nel browser
        ↓
Identificare l'URL interessato
        ↓
Utilizzare il Controllo URL
        ↓
Controllare la scansionabilità

Google può memorizzare nella cache il file robots.txt #

Google richiama la robots.txt regolarmente e può memorizzarne temporaneamente il contenuto.

Pertanto, una modifica non deve necessariamente essere presa in considerazione da ogni scansione nello stesso secondo.

Quando hai risolto un blocco critico, dovresti controllare lo stato attuale e dare a Google il tempo di recuperare ed elaborare nuovamente la modifica.

Cosa succede se il file robots.txt non è raggiungibile? #

Il comportamento di un crawler dipende anche dallo stato HTTP che robots.txt fornisce.

Un'inesistenza permanente robots.txtIl documento non è la stessa cosa di un errore temporaneo del server durante il recupero.

Pertanto, non dovresti sperimentare intenzionalmente con gli stati di errore per controllare il crawling.

Per un sito web normale, la configurazione desiderata dovrebbe essere chiaramente e affidabilmente accessibile.

Spieghiamo le basi delle risposte HTTP su Codici di stato HTTP spiegati: 200, 301, 404, 403 e 500.

robots.txt e 404 #

Se non robots.txt esiste e il relativo recupero restituisce un normale stato di „non trovato“, Google lo tratta fondamentalmente come se non vi fossero limitazioni di scansione da parte di un file robots.txt.

Questo però non significa che tu debba creare intenzionalmente un file difettoso.

Una configurazione esistente e comprensibile è solitamente più semplice per la manutenzione e la diagnostica.

Verificare il file robots.txt di un nuovo sito web #

Prima del lancio di un nuovo sito web, dovresti controllare i seguenti punti:

robots.txt accessibile?
↓
nessun blocco totale accidentale?
↓
pagine importanti indicizzabili?
↓
risorse importanti indicizzabili?
↓
indirizzo della sitemap corretto?
↓
controllare noindex separatamente?
↓
Search Console configurata?
↓
testare gli URL importanti?

robots.txt dopo un cambio di dominio #

Durante un cambio di dominio dovresti robots.txt tenere conto sia in relazione al vecchio che al nuovo dominio.

Il nuovo sito Web non deve impedire accidentalmente a Google di effettuare la scansione.

Allo stesso tempo, i reindirizzamenti necessari dei vecchi URL devono essere raggiungibili da Google.

Pertanto, non bloccare indiscriminatamente il vecchio sito web se Google deve ancora poter eseguire il crawling dei suoi reindirizzamenti.

robots.txt e reindirizzamenti #

Se Google rimuove un vecchio URL a causa di un robots.txtUna regola di blocco del crawler può impedire a Google di recuperare normalmente un reindirizzamento configurato in quella posizione.

Durante una migrazione, Google dovrebbe quindi poter recuperare fondamentalmente i vecchi URL pertinenti per riconoscerne i reindirizzamenti verso le nuove destinazioni.

Ti spieghiamo come utilizzare correttamente i reindirizzamenti permanenti su Configurazione del reindirizzamento 301: reindirizzare gli URL in modo permanente.

considerare insieme robots.txt e codici di stato HTTP #

Per i problemi di SEO tecnica, dovresti distinguere diversi livelli:

robots.txt
→ Google può eseguire la scansione dell'URL?

HTTP-Status
→ Cosa risponde il server?

noindex
→ La pagina può essere indicizzata?

Canonical
→ Qual è l'URL della versione preferita?

Sitemap
→ Quale URL viene segnalato come rilevante?

Solo l'interazione di questi segnali mostra come un URL è configurato tecnicamente.

Esempio: la pagina pubblica deve essere indicizzata #

Supponendo che il seguente URL debba comparire su Google:

https://example.com/ratgeber

Una configurazione pulita potrebbe apparire, in forma semplificata, così:

robots.txt:
Scansione consentita

HTTP:
200 OK

Meta Robots:
nessun noindex

Canonical:
https://example.com/ratgeber/

Sitemap:
URL incluso

Link interni:
presenti

Ciò significa che a questi livelli non vi sono evidenti contraddizioni tecniche.

Esempio: la pagina non deve essere indicizzata #

Una pagina accessibile pubblicamente deve poter essere scansionata da Google, ma non deve comparire nei risultati di ricerca.

Allora il principio potrebbe essere:

robots.txt:
Indicizzazione consentita

Meta Robots:
noindex

Google può eseguire la scansione della pagina, che noindexRiconoscere l'istruzione ed elaborarla di conseguenza.

Esempio: area privata #

Un'area veramente riservata non dovrebbe semplicemente essere delimitata da:

Disallow: /privat/

„essere protetto.

Invece ha bisogno di una vera protezione dagli accessi non autorizzati.

Contenuto privato
        ↓
Accesso / Autenticazione
        ↓
non accessibile pubblicamente

La questione dell'indicizzazione sui motori di ricerca è quindi solo una parte del controllo di accesso effettivo.

Esempio: intero sito web bloccato accidentalmente #

Dopo un rilancio, il file mostra:

User-agent: *
Disallow: /

Ma il sito web deve essere scansionato pubblicamente da Google.

Allora questa regola è un errore di configurazione critico.

Dopo la correzione dovresti:

richiamare robots.txt
        ↓
controllare la regola
        ↓
verificare gli URL importanti con
Search Console
        ↓
controllare la sitemap
        ↓
monitorare l'andamento dell'indicizzazione

Esempio: l'URL è presente nella Sitemap e allo stesso tempo è bloccato #

Sitemap:

https://example.com/produkt/


robots.txt:

Disallow: /produkt/

Se la pagina di prodotto deve essere regolarmente indicizzata, questi segnali sono in contraddizione.

La soluzione non consiste nel chiedere a Google di indicizzare più spesso, ma nel correggere prima la configurazione tecnica.

Quando dovresti effettivamente modificare robots.txt? #

Modifica il file solo se hai un motivo concreto per farlo.

Per esempio:

area di crawling non necessaria identificata
struttura di URL generata tecnicamente
non deve essere indicizzata dai crawler
correggere la regola errata esistente
aggiungere l'indirizzo della sitemap
gestire un crawler specifico
configurare correttamente migrazione / relaunch

„Voglio migliorare il mio SEO“ da solo non è ancora un motivo per aggiungere Vieta-Integrare delle regole.

Verificare sempre gli impatti prima di apportare modifiche #

Una singola regola breve può riguardare migliaia di URL.

Da:

Disallow: /shop/filter/

e

Disallow: /shop/

possono verificarsi effetti completamente diversi.

Verifica quindi con precisione, prima di salvare, quali URL sono interessati da una regola.

Attenzione: Non fare esperimenti direttamente su un sito web di produzione con complesse robots.txt-Regole, se non puoi valutarne chiaramente gli effetti.

Errori comuni nel file robots.txt #

Disallow: / su sito live

usare robots.txt come noindex

bloccare contemporaneamente una pagina noindex

"proteggere" contenuti riservati solo
con robots.txt

bloccare file CSS importanti

bloccare file JavaScript importanti

inserire l'URL della Sitemap in modo errato

mantenere vecchie regole di staging

copiare template WordPress di terze parti
senza verificarli

usare wildcard complicate senza
alcuna necessità

ignorare maiuscole e minuscole

usare Crawl-delay per Google

bloccare il vecchio dominio durante una migrazione,
nonostante i reindirizzamenti debbano essere indicizzati

Checklist: verifica correttamente il file robots.txt #

https://deine-domain.ch/robots.txt
aprire
        ↓
file accessibile?
        ↓
host corretto?
        ↓
controllare le regole User-agent
        ↓
controllare le regole Disallow
        ↓
Disallow: / presente?
        ↓
controllare le regole Allow
        ↓
verificare i caratteri jolly (wildcard)
        ↓
pagine importanti scansionabili?
        ↓
risorse CSS/JS importanti scansionabili?
        ↓
indirizzo della Sitemap corretto?
        ↓
verificare noindex separatamente
        ↓
testare gli URL importanti
nella Search Console
        ↓
verificare nuovamente dopo le modifiche

Confronto tra robots.txt, noindex e sitemap #

Utensile	Compito principale	Scopo tipico
robots.txt	Controllare il crawling	Tenere i crawler lontani da determinate aree URL
noindex	Impedire l'indicizzazione	escludi la pagina accessibile dai risultati di ricerca
Mappa del sito XML	Condividi gli URL	Segnalare URL pertinenti ai motori di ricerca

Questi tre meccanismi non si sostituiscono a vicenda.

Un sito web tecnicamente pulito li utilizza in base al loro rispettivo compito.

Riepilogo #

Muori robots.txt è un file di testo accessibile pubblicamente nella directory principale di un host. Dice ai crawler dei motori di ricerca quali aree di URL possono scansionare e quali no.

Con User-agent individui il crawler in questione. Vieta esclude i percorsi appropriati dal crawling, mentre Consenti è possibile sbloccare percorsi più specifici. Inoltre, è possibile specificare l'indirizzo completo di una Sitemap XML.

La distinzione più importante è: I file robots.txt controllano il crawling e noindex controlla l'indicizzazione. Un da robots.txt Un URL bloccato può comunque essere noto a Google e apparire nei risultati di ricerca in determinate circostanze.

Un' robots.txt inoltre non è una funzione di sicurezza. I contenuti riservati richiedono una vera protezione degli accessi.

È necessaria particolare attenzione dopo un rilancio, in caso di modifiche del dominio e con i siti di staging. Una regola accidentale come Disallow: / può impedire a Google di effettuare il crawling dell'intero sito web di produzione.

Regole complesse, caratteri jolly e lunghe liste di crawler esterni dovrebbero essere usati solo se esiste un motivo tecnico specifico.

Un buon file robots.txt non è quindi il più esteso possibile. È tanto semplice quanto possibile e tanto specifico quanto necessario, e ogni blocco in esso contenuto ha uno scopo comprensibile.