Aggiornato a marzo 2026 — Verificato rispetto alla documentazione più recente sul crawl budget di Google, incrociato con l’analisi approfondita di Gary Illyes del 2024, e testato su dati reali dei log di server provenienti da siti dei clienti di SEOJuice.
TL;DR: Se il tuo sito ha meno di 10.000 pagine, il crawl budget quasi certamente non è il problema. Smettila di ottimizzarlo. Ma se gestisci un e-commerce con 500K pagine prodotto, un sito di annunci con URL potenzialmente infiniti o qualunque piattaforma con navigazione a filtri (faceted navigation) — il crawl budget sta silenziosamente distruggendo la tua indicizzazione. Questa guida spiega come diagnosticare se hai davvero un problema di crawl budget e come risolverlo se ce l’hai. La risposta, di solito, è fin troppo banale: server più veloci, URL più puliti, robots.txt migliore.
Il tuo crawl budget reale è il più piccolo tra questi due valori. Se Google vuole davvero eseguire il crawling di 50.000 delle tue pagine oggi (domanda alta), ma il tuo server riesce a gestire solo 5.000 richieste di fetch senza degradare (rate limit bassa), ottieni 5.000. Se il tuo server può gestire 100.000 fetch ma a Google interessano solo 2.000 delle tue pagine (domanda bassa), ottieni 2.000.
Questa è la parte che la maggior parte delle guide sbaglia. Trattano il crawl budget come una “pool” fissa che devi “risparmiare” bloccando le pagine “non importanti”. In realtà è dinamico, cambia di giorno in giorno e, per la maggior parte dei siti, non è affatto il collo di bottiglia.
Devo dirlo chiaramente perché ho visto agenzie vendere ottimizzazioni del crawl budget a siti con 200 pagine.
Se il tuo sito ha meno di circa 10.000 URL univoci, l’ottimizzazione del crawl budget è quasi certamente tempo sprecato.
Gary Illyes lo ha detto lui stesso, più volte, tra cui a Google I/O e su Twitter. La sua formulazione esatta: “Se il tuo sito ha poche migliaia di URL, nella maggior parte dei casi verrà sottoposto a crawling in modo efficiente”. Martin Splitt, Developer Advocate di Google, ha ripreso lo stesso concetto in un episodio di JavaScript SEO office hours, quando ha detto che il crawl budget diventa una preoccupazione reale “solo quando arrivi alle decine di migliaia di pagine o più”.
Google esegue il crawling di miliardi di pagine al giorno. Il tuo blog WordPress da 500 pagine è un errore di arrotondamento. Google lo scansionerà tutto entro pochi giorni da qualsiasi modifica, senza che tu faccia nulla di speciale.
Dove il crawl budget conta davvero:
Se nessuno di questi casi ti descrive, salta alla sezione FAQ in fondo e vai avanti con la tua vita. Dico sul serio. Usa il tuo tempo per qualità dei contenuti e linking interno. Penso ancora che sia qualcosa che il 90% delle persone che fa “ottimizzazione del crawl budget” dovrebbe sentire: molto probabilmente il tuo problema è altrove.
2. Verifica il tuo gap di indicizzazione. Confronta il numero di pagine presenti nella tua sitemap con il numero di pagine indicizzate nel report “Pages” di GSC. Se hai 100.000 URL nella sitemap ma solo 40.000 indicizzati, allora qualcosa sta consumando il tuo crawl budget prima ancora di arrivare alle pagine che contano.
3. Guarda i log del server. Questa è la diagnosi reale. GSC ti fornisce dati aggregati. I log del server ti danno la verità — ogni singola richiesta che Googlebot ha fatto, quando, su quale URL e che risposta ha ricevuto. Se vedi Googlebot spendere il 60% del crawling su pagine archive paginate o su URL filtrati, allora il problema è chiarissimo, nero su bianco.
Sarò onesto su una limitazione: non sono sicuro al 100% che il report delle crawl stats di GSC sia sempre accurato. Abbiamo visto discrepanze tra ciò che GSC dichiara e ciò che mostrano i log del server dei clienti. A volte discrepanze importanti — gap del 30-40%. Non so se sia un problema di campionamento lato Google, un effetto di caching o qualcos’altro. Per questo, quando la posta in gioco è alta, raccomando sempre di verificare con i log del server.
| Segnale di diagnosi | Salute | Attenzione | Critico |
|---|---|---|---|
| Nuova pagina indicizzata entro | 1-3 giorni | 1-2 settimane | 4+ settimane o mai |
| Richieste di crawl GSC/giorno rispetto al totale pagine | > 50% delle pagine crawlate a settimana | 10-50% a settimana | < 10% a settimana |
| Tempo di risposta medio del server | 200ms | 200-500ms | > 500ms |
| % di crawl su URL non indicizzabili | < 10% | 10-30% | > 30% |
| Catene di redirect durante il crawl | Nessuna | < 5% delle richieste | > 5% hit chain |
| Tasso di errori 5xx durante il crawl | 0% | 1% | > 1% |
Nota: queste soglie sono linee guida basate sull’esperienza, ricavate da pattern emersi nei dati dei clienti di SEOJuice, non da numeri ufficiali pubblicati da Google. I risultati possono variare in base alla dimensione del sito, al settore e all’architettura del server.
Se la maggior parte dei tuoi segnali è nella colonna “Salute”, non hai un problema di crawl budget. Vai a ottimizzare qualcos’altro.
Questa è la variabile del crawl budget con il maggiore impatto e con la minor attenzione. Tutti vogliono parlare di robots.txt e sitemap. Nessuno vuole parlare del motivo per cui il tuo server impiega 1,2 secondi a rispondere a una semplice richiesta HTML.
Googlebot è educato. Monitora in tempo reale il tempo di risposta del tuo server. Se il server inizia a rallentare, Googlebot riduce la velocità di crawling per evitare di sovraccaricarti. È il rate limit del crawl in azione. Un server che risponde in 100ms verrà crawlatizzato in modo molto più aggressivo rispetto a uno che risponde in 800ms.
"Se il sito è davvero veloce, Googlebot sarà in grado di usare più connessioni e fare crawling più velocemente. Se il sito rallenta o risponde con errori del server, rallenterà e farà meno crawling."
— Gary Illyes, Senior Search Analyst, Google (Google Developers Blog)
È una citazione diretta dal post ufficiale sul crawl budget. Per Google, “davvero veloce” significa TTFB (time to first byte) sotto i 200ms. Non il tempo di caricamento della pagina — il TTFB. Il tempo che impiega il server a iniziare l’invio della risposta HTML.
Quick win per il tempo di risposta del server:
Su uno dei siti di un cliente di SEOJuice (un e-commerce di mobili, circa 80K pagine prodotto), abbiamo visto il suo crawl rate in GSC scendere da 15.000 richieste/giorno a 3.000 in due settimane. Nessuna modifica a contenuti o struttura. La causa? Il provider di hosting lo ha migrato su un nuovo cluster e il TTFB è passato da 180ms a 900ms. Dopo aver sistemato l’hosting, il crawl rate è tornato a crescere entro quattro giorni. Nessun cambiamento a robots.txt. Nessun aggiornamento di sitemap. Solo server più veloci.
I parametri URL sono la fonte singola più comune di spreco nel crawling. E il problema è subdolo perché spesso non te ne accorgi.
Immagina un sito e-commerce con filtri. Un utente naviga le scarpe e seleziona: taglia 10, colore nero, brand Nike, ordinati per prezzo, pagina 2. Questo è un URL come:
/shoes?size=10&color=black&brand=nike&sort=price&page=2Ora moltiplicalo per ogni combinazione possibile. 8 taglie, 12 colori, 40 brand, 4 opzioni di ordinamento, 50 pagine di risultati. È 8 × 12 × 40 × 4 × 50 = 768.000 URL. Partendo da una singola pagina di categoria. E il contenuto su molte di queste pagine si sovrappone in modo significativo — scarpe Nike nere taglia 10 ordinate per prezzo sono, per lo più, gli stessi prodotti delle scarpe Nike nere taglia 10 ordinate per “più recenti”.
Googlebot non lo sa. Vede 768.000 URL univoci e inizia a crawlarli. Le tue pagine prodotto reali — quelle che dovrebbero posizionarsi — restano in coda dietro centinaia di migliaia di varianti filtrate che nessuno cercherà mai.
Questo è ciò che la gente intende con “la navigazione a faccette crea trappole per il crawl”. Non è che Google si blocchi in un loop infinito (anche se può succedere con alcune configurazioni di paginazione). È che Google destina il suo crawl budget limitato a URL che non apportano alcun valore univoco.
Voglio essere preciso su una cosa: lo strumento per i parametri URL in Google Search Console è stato dismesso e rimosso nel 2022. Prima Google ti permetteva di indicargli quali parametri ignorare. Quell’opzione non c’è più. Ora hai tre strumenti per gestire la cosa:
Ognuno ha compromessi. Più sotto tratterò robots.txt e i canonical in sezioni dedicate.
Il tuo robots.txt è il primo file che Googlebot controlla prima di eseguire il crawling del sito. È anche il file più frainteso in SEO. Le persone o lo lasciano vuoto (perdono un’occasione) oppure vanno troppo oltre (bloccando cose che non dovrebbero).
Il principio chiave è questo: blocca ciò che spreca crawl budget, non ciò che è “non importante”. C’è una differenza. Una pagina “non importante” potrebbe comunque dover essere indicizzata. Una pagina che spreca crawl budget è una pagina che non offre alcun valore univoco per la ricerca ed esiste in migliaia di varianti generate dai parametri.
# Block faceted navigation parameters
User-agent: *
Disallow: /*?sort=
Disallow: /*?color=
Disallow: /*?size=
Disallow: /*&sort=
Disallow: /*&color=
Disallow: /*&size=
# Block internal search results
Disallow: /search?
Disallow: /search/
# Block session-based URLs
Disallow: /*?sessionid=
Disallow: /*?ref=
# Block admin, cart, and account pages
Disallow: /admin/
Disallow: /cart/
Disallow: /my-account/
Disallow: /checkout/
# Block print and PDF versions
Disallow: /*?print=
Disallow: /*?format=pdf
# DO NOT block CSS, JS, or images
# Googlebot needs these to render your pages
Allow: /*.css
Allow: /*.js
Allow: /*.jpg
Allow: /*.png
Allow: /*.webp
Sitemap: https://example.com/sitemap.xmlErrori critici che ho visto:
/products/ perché vuole bloccare /products?filter= e finisce per deindicizzare l’intero catalogo.Questo ultimo punto vale la pena ripeterlo perché fa inciampare anche SEOs esperti. Robots.txt blocca il crawling. Non blocca l’indicizzazione. Se vuoi impedire l’indicizzazione, usa <meta name="robots" content="noindex"> o un header HTTP X-Robots-Tag. Però ricorda: perché Google veda un tag noindex, deve prima eseguire il crawling della pagina. Quindi, se blocchi il crawling con robots.txt E aggiungi noindex, Google non vedrà mai il tag noindex. È un paradosso che confonde la gente da anni.
Una sitemap non garantisce l’indicizzazione. Non garantisce neanche il crawling. Quello che fa è dare a Google un indizio su quali URL esistono, quando sono stati modificati l’ultima volta e (discutibilmente) quanto siano importanti rispetto agli altri.
Le persone sbagliano quasi sempre includendo troppo, non troppo poco.
Cosa includere nella tua sitemap:
<lastmod> — non la data corrente, non la stessa data su ogni pagina, ma la reale data dell’ultima modificaCosa escludere dalla tua sitemap:
Ho visto sitemap con 500.000 URL in cui solo 80.000 erano davvero indicizzabili. Gli altri 420.000 erano redirect, pagine noindexed, varianti con parametri e URL rotti. Quella sitemap non aiuta Google — lo porta in una caccia al tesoro in cui l’84% della mappa è sbagliata.
Martin Splitt ha definito <lastmod> “uno dei tag più abusati nelle sitemap” perché molte piattaforme CMS lo impostano sulla data corrente in ogni pagina. Se ogni pagina dice “sono stato appena modificato”, Google impara a ignorare completamente il segnale. Se il tuo CMS non traccia le reali date di modifica, sistemalo prima di preoccuparsi di qualsiasi altra cosa legata alle sitemap.
Dedico una sezione separata alla navigazione a faccette perché è l’intersezione tra crawl budget, contenuti duplicati e architettura tecnica — e se la gestisci male può far crollare il SEO di un sito in modo silenzioso nell’arco di mesi.
Il problema: la navigazione a faccette (filtri su e-commerce, annunci, job board) genera combinazioni di URL in modo esponenziale. Abbiamo visto la matematica sopra. Ma la soluzione non è semplice come “blocca tutto con robots.txt”, perché alcune pagine filtrate hanno un valore reale di ricerca.
Pensaci: “scarpe da corsa taglia 10 Nike” è una query di ricerca reale che una persona digita davvero su Google. Una pagina a faccette che combacia con quella query potrebbe posizionarsi. Bloccare tutti gli URL filtrati significa perdere quell’opportunità.
Il framework che consiglio (e che implementiamo per i clienti di SEOJuice quando hanno questo problema):
| Tipo di faccetta | Esempio | Valore di ricerca | Approccio consigliato |
|---|---|---|---|
| Categoria + Brand | /shoes/nike/ | Alto — le persone cercano brand + categoria | Indicizza, includi in sitemap, usa URL pulito |
| Categoria + 1 filtro | /shoes?color=black | Medio — dipende dal volume di ricerca | Verifica il volume di ricerca. Indicizza se >100 ricerche mensili, altrimenti canonical alla categoria padre |
| Categoria + 2+ filtri | /shoes?color=black&size=10 | Basso — troppo specifico per la maggior parte delle ricerche | Canonical al filtro singolo più rilevante o alla categoria padre |
| Varianti di ordinamento | /shoes?sort=price-asc | Nessuno — nessuno cerca “scarpe ordinate per prezzo” | Blocca con robots.txt o noindex |
| Paginazione su pagine profonde | /shoes?page=47 | Nessuno oltre pagina 2-3 | Noindex dopo pagina 3-5, mantenere crawlable |
| Parametri di sessione/tracciamento | /shoes?utm_source=email | Nessuno | Blocca con robots.txt, rimuovi a livello server |
L’implementazione dei tag canonici per pagine multi-filtro è simile a questa:
<!-- On /shoes?color=black&size=10&sort=price -->
<link rel="canonical" href="https://example.com/shoes?color=black" />
<!-- On /shoes?sort=price -->
<link rel="canonical" href="https://example.com/shoes" />
<!-- On /shoes (the clean category page) -->
<link rel="canonical" href="https://example.com/shoes" />Un errore che ho fatto e che non ho ancora risolto completamente: cosa fare con le pagine a faccette che si sono accumulate backlink. Un cliente aveva migliaia di link esterni che puntavano a URL filtrati. Mappare tutto con canonical verso la pagina padre dovrebbe “portare” l’equity verso l’alto — sulla carta sembra perfetto.
In pratica, dopo aver implementato i canonical, abbiamo visto un calo del 15% nei ranking della pagina padre. Non so ancora perché. La mia migliore ipotesi è che la consolidazione improvvisa di migliaia di segnali abbia confuso la valutazione di Google, ma è solo speculazione. Abbiamo rollbackato i canonical sulle pagine filtrate che avevano più link e abbiamo lasciato quelle pagine indicizzabili. È un compromesso con cui non mi sento a mio agio.
Versione breve: rel="next" e rel="prev" sono stati deprecati. Google ha confermato nel 2019 che non usava quel segnale da anni. Quindi cosa fai invece?
Tre opzioni, in ordine di preferenza:
Opzione 1: Load-more o infinite scroll con pushState. È l’approccio più pulito per i nuovi siti. Gli utenti vedono un solo URL. Google fa crawling dell’intero contenuto. Niente URL di paginazione da sprecare crawl budget. Ma richiede JavaScript, che introduce anche altri costi di crawl budget (ne parlo sotto).
Opzione 2: Paginazione tradizionale con noindex dalla pagina 2 in poi. Mantieni gli URL paginati crawlable (così Google può scoprire i prodotti/articoli linkati da lì), ma mettili noindex, così Google non prova a indicizzare pagine template identiche. Il canonical su ogni pagina paginata dovrebbe essere self-referencing — non canonicalizzare tutte le pagine alla pagina 1, perché il contenuto è diverso.
Opzione 3: Pagina “view-all”. Se il contenuto paginato totale è inferiore a ~200 elementi, valuta una singola pagina view-all che canonicalizzi la serie paginata. Storicamente, Google preferisce le pagine view-all. Il lato negativo: i tempi di caricamento. Se la tua pagina view-all impiega 8 secondi a caricarsi, peggiora più di quanto aiuta.
<!-- Page 2 of blog archive -->
<meta name="robots" content="noindex, follow">
<link rel="canonical" href="https://example.com/blog/page/2" />
<!-- Important: use "noindex, follow" — not "noindex, nofollow"
You want Google to follow the links on paginated pages
to discover the actual content pages -->Nota la direttiva follow. È cruciale. Non vuoi che la pagina paginata sia in indice, ma vuoi assolutamente che Google segua i link su quella pagina per trovare le pagine di contenuto reali. Usare nofollow qui isolerebbe tutti gli articoli o i prodotti che sono linkati solo dalla pagina 2+ dell’archivio.
Questa sezione riguarda chiunque gestisca un sito molto basato su JavaScript (React, Vue, Angular, Next.js senza un SSR adeguato). Se il tuo sito è HTML tradizionale renderizzato lato server, vai avanti.
Google esegue il crawling in due ondate. Prima ondata: scarica e processa l’HTML grezzo. Seconda ondata: rende la pagina con un browser Chromium headless per eseguire JavaScript e vedere il contenuto finale. La seconda ondata avviene più tardi — a volte ore dopo, a volte giorni.
Martin Splitt l’ha spiegato in modo approfondito nei suoi JavaScript SEO office hours. Il punto chiave: il rendering è costoso per Google. Richiede più risorse rispetto a un semplice fetch di HTML. Google deve avviare un’istanza di Chromium, eseguire il tuo JavaScript, attendere che le chiamate API si risolvano e poi processare il DOM renderizzato. Questo significa che le pagine dipendenti da JavaScript vengono crawlate in modo meno efficiente rispetto alle pagine renderizzate lato server.
Impatto sul crawl budget:
La soluzione: server-side rendering (SSR) o static generation (SSG). Next.js, Nuxt, SvelteKit lo supportano. Se non puoi fare un SSR completo, usa dynamic rendering: servi HTML pre-renderizzato a Googlebot e l’esperienza completa in JS agli utenti. Google, tecnicamente, scoraggia questa pratica, ma a inizio 2026 funziona comunque nella pratica. Abbiamo affrontato le sfide specifiche delle SPA nel nostro guida alle best practice SEO per le SPA.
Su cosa guardare nei log:
Strumenti: Screaming Frog Log Analyzer è il tool dedicato più popolare. Puoi anche parsare i log con strumenti da riga di comando (grep per l’user agent di Googlebot, poi pipe con awk). Per monitoraggio continuativo, la funzione di crawler analytics di SEOJuice elabora i log del server in automatico e segnala i problemi di crawl budget.
Esempio reale dai nostri dati: un cliente aveva un sito WordPress con circa 25.000 post pubblicati. Buoni contenuti, traffico decente. Ma nei log del server si vedeva Googlebot spendere il 40% del crawl budget su endpoint API /wp-json/ e URL /feed/. Non sono pagine che cerca davvero nessuno. Aggiungendo due righe a robots.txt, quel 40% è stato liberato per le pagine contenuto reali. Entro tre settimane, il crawl rate sulle pagine articoli è aumentato del 60% e hanno visto 12 nuove pagine indicizzate, rimaste mesi nella purgatoria “Discovered — currently not indexed”.
# WordPress-specific crawl budget savings
User-agent: *
Disallow: /wp-json/
Disallow: /feed/
Disallow: /comments/feed/
Disallow: /author/*/feed/
Disallow: /category/*/feed/
Disallow: /tag/*/feed/
Disallow: /?replytocom=
Disallow: /trackback/I link interni sono il segnale più forte che puoi controllare per dire a Google quali pagine contano. Non i meta tag. Non i valori di priorità della sitemap (che Google ignora comunque). I link interni.
Ogni link è un voto. Una pagina linkata dalla home, dalla navigazione e da altre 50 pagine verrà crawlata più spesso di una pagina linkata da una singola pagina archive “sepolta” a tre click di distanza. È una distribuzione base di PageRank ed è così che Googlebot decide dove spendere il proprio crawl budget.
Implicazione pratica: se le pagine non vengono indicizzate e sono a 3+ click dalla home, aggiungere link interni da pagine ben collegate aumenta la loro frequenza di crawling. L’abbiamo visto in modo consistente: le pagine che passano da 0-1 link interni a 5+ ricevono la prima visita di Googlebot entro 48 ore, anche su siti grandi dove di solito le nuove pagine aspettano settimane.
Ecco perché abbiamo inserito il linking interno automatico in SEOJuice. Gestire manualmente i link interni su 10.000+ pagine è impossibile. Ma il beneficio sulla priorità di crawl rende questa attività una delle tecniche tecniche SEO con miglior ritorno sull’investimento.
Un’architettura “flat” (ogni pagina raggiungibile in 3 click o meno) è migliore per il crawl budget rispetto a gerarchie profonde. Però “flat” non significa “linka tutto con tutto”. Significa linking strategico — cluster tematici, hub page, link contestuali — che crea percorsi di crawl chiari verso le pagine più importanti.
Voglio essere specifico su cosa facciamo davvero, invece di usare un linguaggio marketing vago.
SEOJuice traccia il comportamento di crawl tramite tre input: statistiche di crawl in GSC (tramite la Search Console API), i nostri dati di crawling (facciamo crawling dei siti dei clienti per costruire il grafo dei link interni) e, opzionalmente, l’integrazione dei log di server.
Quello che mettiamo in evidenza:
Al momento non facciamo un’analisi completa dei file di log direttamente nel prodotto (parsare formati arbitrari di server log su larga scala è una sfida ingegneristica che non sono riuscito a risolvere come mi soddisfa). Ma i dati di GSC più il nostro crawler danno a molti siti abbastanza informazioni per identificare e risolvere i problemi di crawl budget senza toccare un file di log.
Se hai letto fino a qui e hai stabilito che hai davvero un problema di crawl budget, ecco cosa sistemare, in ordine di impatto:
I passaggi 1-3 risolvono il problema per la maggior parte dei siti che davvero hanno bisogno di ottimizzazione del crawl budget. I passaggi 4-9 sono per il resto — siti con architetture complesse dove le basi non bastano.
No. Il crawl budget determina se le tue pagine vengono crawlate e indicizzate, non come si comportano una volta indicizzate. Ma una pagina che non viene mai crawlatizzata non verrà mai indicizzata e una pagina non indicizzata non può posizionarsi. Quindi il crawl budget è un prerequisito, non un fattore di ranking. Ottimizzarlo non migliora i ranking delle pagine che sono già indicizzate — aiuta le pagine che non vengono indicizzate affatto.
Quasi mai. Le impostazioni di crawl rate in GSC ti permettono di ridurre il crawl rate di Googlebot, non di aumentarlo. L’unico motivo per usarle è se Googlebot sta davvero travolgendo il tuo server. Se il tuo server regge quel traffico, lascialo stare. Ho visto persone ridurlo pensando che “costringesse” Google a concentrarsi sulle pagine importanti. Non funziona così: Google fa semplicemente meno crawl di tutto.
Pagine popolari e aggiornate spesso: più volte al giorno. Pagine statiche non cambiate per mesi: ogni poche settimane. In media è circa ogni 1-2 settimane per pagina, ma varia moltissimo. I siti di news vengono crawlatizzati entro pochi minuti. Una pagina “Chi siamo” raramente aggiornata potrebbe passare un mese tra una visita e l’altra. Il tag <lastmod> può suggerire se una pagina è cambiata, ma solo se lo usi in modo accurato — Google lo ignora se è sempre impostato alla data di oggi.
Puoi aumentare il limite di crawl rate (server più veloce) e ridurre lo spreco di crawl (così più budget va alle pagine importanti). Ma non puoi chiedere direttamente a Google di crawlarne di più. La domanda di crawl la decide Google in base al valore percepito dei contenuti. Il miglior approccio indiretto: pubblicare con frequenza, costruire backlink, fare contenuti davvero utili. I siti ad alto valore vengono crawlatizzati in modo più aggressivo, automaticamente.
Sì. Google continua a crawlarle per capire il tag noindex. 100.000 pagine noindexed significano 100.000 “hits” di crawl budget (anche se meno frequentemente rispetto alle pagine indicizzate). Se davvero quelle pagine non devono mai essere indicizzate, robots.txt è più efficiente lato crawl — ma robots.txt blocca la possibilità di far vedere a Google qualsiasi cosa nella pagina, inclusi i link. Usa noindex+follow quando vuoi che Google scopra i link ma non indicizzi. Usa robots.txt quando non vuoi che la pagina venga crawlatizzata affatto.
Questo articolo fa parte della nostra serie di SEO tecnica. Se stai lavorando su problemi di crawl budget, queste guide correlate ti aiuteranno:
Se stai gestendo un sito grande e vuoi monitoraggio automatizzato del crawl budget, SEOJuice traccia lo spreco di crawl, la velocità di indicizzazione e il tempo di risposta del server su tutte le tue pagine. Non sostituirà l’analisi dei log per architetture complesse, ma mette in evidenza la maggior parte dei problemi di crawl budget che contano — in continuo, non solo quando qualcuno si ricorda di fare un audit. Inizia una prova gratuita e scopri dove sta andando il tuo crawl budget in pochi minuti.
no credit card required