Far scansionare un sito appena nato: chi arriva davvero, e in che ordine

Alcuni link in questa pagina sono link di affiliazione: se ti registri tramite questi link, il sito riceve una commissione senza costi aggiuntivi per te. Prezzi e consigli non cambiano.

Abbiamo messo online un sito statico il 15 ottobre, non abbiamo pubblicato nulla per quattro giorni, poi tre articoli in una sera. Il log degli accessi registrava tutto il tempo. Quindici giorni dopo contiene 9.987 richieste, e l’ordine con cui internet si è accorto di noi non è quello che si pianifica.

Nessuna teoria qui sotto. Ogni numero viene da quel log.

Il primo visitatore è stato un crawler di IA, dopo 65 minuti

La prima pagina è andata online alle 13:14 UTC. Quello che è successo poi, in ordine di prima comparsa:

Niente puntava ancora al sito. Nessuna segnalazione era stata fatta da nessuna parte. I crawler di Anthropic e OpenAI hanno trovato un hostname nuovo su un piccolo VPS entro un’ora e hanno iniziato a percorrerlo.

Il punto pratico è questo: se oggi pubblichi testi tecnici, i tuoi primi lettori sono pipeline di retrieval, e arrivano prima che un motore di ricerca sappia che esisti. Decidi la politica del robots.txt prima di pubblicare, non dopo averlo notato.

Guarda cosa ha fatto ClaudeBot nelle sue prime due richieste, a un secondo di distanza: /robots.txt, poi /. In quindici giorni ha chiesto quel file 78 volte, una per sessione di scansione. GPTBot lo ha chiesto zero volte nello stesso periodo, scaricando 391 URL. Gli stessi due secondi di lavoro, comportamento opposto. Ci torneremo in un pezzo a parte, perché è esattamente ciò che decide quale metodo di blocco vale la pena mettere in campo.

Google ci ha ignorati del tutto finché non è stato fatto un passaggio

Zero richieste di Googlebot nei primi quattro giorni. Non rallentato, non lento: assente. Il sito era raggiungibile, aveva una sitemap, aveva il robots.txt ed era linkato da un dominio consolidato che gestiamo anche noi.

Ha cambiato tutto la verifica del dominio in Search Console con l’invio della sitemap. Dal log di quella sera:

• 19:35 - dominio verificato con un record DNS TXT.
• 19:41:31 - prima richiesta di Googlebot nella storia del sito: /robots.txt e /sitemap.xml nello stesso secondo.
• 19:42 - 19:46 - Googlebot percorre a turno ogni sitemap di lingua.

Sei minuti. Si può discutere se Search Console sia formalmente necessaria - non lo è - ma la differenza fra quattro giorni di silenzio e sei minuti è difficile da ignorare quando parti da zero.

Scegli una proprietà di dominio invece di una per prefisso URL se puoi aggiungere un record DNS: un TXT sull’apex copre ogni sottodominio che creerai e sopravvive a un passaggio http/https o www che altrimenti spaccherebbe i dati su due proprietà.

Poi, tre ore e venti dopo Googlebot, è comparso GoogleOther, che da allora ha scaricato quasi quanto Googlebot stesso: 520 richieste contro 541. È un crawler separato sulla stessa infrastruttura, per prodotti diversi dalla ricerca. Se un giorno decidi di limitare Google, sappi che sono due nomi, non uno.

Bing è arrivato via IndexNow, in pochi giorni e senza alcun account

IndexNow è un patto semplice: ospiti un file chiave, poi invii in POST l’elenco degli URL cambiati, e i motori partecipanti (Bing, Yandex, Seznam, Naver) lo sanno subito invece di aspettare una scansione.

Tutto il protocollo è una richiesta:

curl -X POST https://api.indexnow.org/indexnow \
  -H "Content-Type: application/json; charset=utf-8" \
  -d '{
    "host": "example.com",
    "key": "YOUR-KEY",
    "keyLocation": "https://example.com/YOUR-KEY.txt",
    "urlList": ["https://example.com/new-post/"]
  }'

La chiave è un file nella radice del dominio il cui nome è la chiave e il cui contenuto è la stessa stringa. Questa è tutta la verifica: se riesci a metterci quel file, l’host è tuo.

Un 200 significa accettato, non indicizzato. Ma bingbot è arrivato da solo il giorno dopo la nostra prima segnalazione, senza account, senza console, senza passaggi di verifica - tre giorni prima di Googlebot. Per un sito nuovo è un vantaggio concreto, e costa una riga nella pipeline di deploy.

La trappola del file indice

Questa è la parte che ci ha quasi ingannati, ed è il paragrafo più utile del pezzo.

Hugo multilingua genera su /sitemap.xml un indice di sitemap - un elenco di altre sitemap, una per lingua - e non un elenco di pagine. Abbiamo inviato quello, e Search Console ha risposto:

Status: Success. Discovered pages: 0.

Entrambe le metà sono vere e sembrano contraddirsi. L’indice è stato scaricato e analizzato correttamente, quindi lo stato è un successo; l’indice stesso non contiene URL di pagine, quindi il contatore resta a zero finché i figli non vengono scaricati a parte. Un’occhiata a “Success” e te ne vai convinto di aver finito.

Abbiamo inviato anche la sitemap figlia della lingua principale:

Status: Success. Discovered pages: 23.

Quindi: se la tua sitemap è un indice, invia anche i figli per lingua, e prendi il numero di pagine trovate, non la parola nello stato, come prova che ha funzionato. Lo stesso vale per qualsiasi generatore che produce un indice: le grandi installazioni WordPress con Yoast lo fanno, come tutto ciò che impagina le sitemap oltre i 50.000 URL.

Giorno 12: la coda lunga arriva tutta insieme

Per undici giorni il log conteneva otto o nove crawler distinti. Poi, fra il 26 e il 29 ottobre, in quattro giorni ne sono comparsi quattordici nuovi:

ElevenlabsCrawler (448 richieste), meta-externalagent (322), MJ12bot (319), AwarioBot (308), SofyaBot (232), SemrushBot (213), Amazonbot (96), PerplexityBot (63), DataForSeoBot (62), YandexBot (49), Applebot (30), archive.org_bot (26), Baiduspider (14), DuckDuckBot (8).

Lo schema è abbastanza netto da poterlo pianificare. I crawler dei backlink, quelli di monitoraggio del marchio e la seconda fila dei crawler di IA non scoprono i siti da soli: leggono gli indici degli altri. Appena Google e Bing ti hanno, sei in un flusso che rivende la scoperta, e il resto segue entro un paio di settimane, che tu lo voglia o no.

Quanto costa, misurato: dei 153,4 MB serviti in quindici giorni, 88,8 MB sono andati a user agent che si dichiarano crawler. È il 58% di tutti i byte, contro circa 4.000 richieste di tipo browser. Su un sito statico servito da un VPS minuscolo nessuno se ne accorge. Su qualsiasi cosa che renderizzi a ogni richiesta è il tuo piano di capacità.

L’ordine che funziona davvero

Per un sito nuovo, in questo ordine, con il motivo di ogni passo:

1. Fatti linkare da qualcosa che viene già scansionato. Un link nel footer da un dominio esistente vale più di qualsiasi modulo di segnalazione. La scoperta passa ancora soprattutto dai link.
2. Servi una sitemap e tieni onesto il robots.txt. Indica la sitemap dal robots.txt; controlla che nessuno dei due sia un residuo di una configurazione di staging che vieta tutto.
3. Invia IndexNow a ogni pubblicazione, dalla pipeline. Costa poco, è immediato, non serve account. Copre Bing e compagnia; per Google non fa nulla, perché Google non partecipa.
4. Verifica il dominio in Search Console e invia la sitemap - figli compresi. È il passaggio che ha trasformato quattro giorni di niente in sei minuti.
5. Poi aspetta. Essere scansionati non è essere indicizzati, ed essere indicizzati non è posizionarsi. I primi due sono infrastruttura e richiedono minuti; il terzo è contenuto e richiede mesi.

Cosa faremmo diversamente

Inviare la sitemap a Search Console il primo giorno, prima che esistano contenuti. La verifica è un record DNS e richiede cinque minuti; farla presto significa che il crawler conosce già il sito quando compare il primo articolo, invece di far partire il cronometro dopo. Abbiamo passato quattro giorni a pubblicare in un vuoto evitabile.

Il ping IndexNow invece l’abbiamo sistemato: ora è un passo del workflow di deploy, nello stesso punto dello smoke test dopo il deploy, così una pubblicazione che arriva al server arriva anche ai motori. Farlo a mano significa dimenticarselo esattamente una volta, sull’articolo che contava.

Cosa questo log non può dire

È un sito, una nicchia, una finestra di quindici giorni, su un hostname senza storia. Il crawl budget di un dominio consolidato si comporta in altro modo. Con un campione di uno non possiamo nemmeno separare “arrivato per Search Console” da “arrivato perché era il quarto giorno”: i sei minuti sono un indizio, non un esperimento controllato. E contare i download del robots.txt misura i download, non l’obbedienza: un crawler che legge il file e lo ignora, in questi dati, è identico a uno educato.