Checklist per la Gestione del Crawl Budget

Il crawl budget è il limite pratico di quanto crawling un motore di ricerca è disposto e in grado di fare su un sito nel tempo. Gestirlo significa ridurre le richieste che non possono migliorare la scoperta o l’indicizzazione, quindi rendere le URL importanti più facili da trovare e meno costose da recuperare.

Checklist: gestione del crawl budget. Timebox: 1–2 giorni lavorativi per la diagnosi, poi 1–3 sprint di engineering per le correzioni approvate. Proprietario: responsabile tecnico SEO. Contributori: ingegnere della piattaforma, proprietario CDN o infrastruttura, ingegnere analytics e responsabile merchandising o contenuti per qualsiasi spazio URL interessato. Autorità di rilascio: responsabile tecnico SEO e ingegnere proprietario congiuntamente.

Sii chiaro sull’ambito: un sito sano con 2.000 o 8.000 pagine canonical non ha quasi mai bisogno di un progetto sul crawl budget. Ha un problema di prioritarizzazione, linking, qualità o indicizzabilità. Avvia questa checklist quando un sito grande o in rapida evoluzione presenta evidenze di spreco di crawling, scoperta ritardata, crawling ripetuto di URL di scarso valore o sovraccarico del server — non perché un report di crawling contenga un numero elevato.

Perché questa fase, e perché qui

Sebbene questa sia una checklist autonoma piuttosto che una fase numerata, essa consuma l’audit tecnico di base : regole canonical, risultati dei codici di stato, comportamento di rendering, architettura del sito, inventario delle sitemap e copertura dell’indice. Necessita anche di un inventario dei contenuti approvato, perché lo “spreco” non può essere definito finché l’azienda non ha detto quali URL dovrebbero essere trovati, aggiornati e indicizzati.

Eseguita dopo che il team è in grado di distinguere le pagine canonical di valore da filtri, duplicati, inventario scaduto, ricerca interna e route amministrative. Eseguirla prima incoraggia blocchi indiscriminati. Eseguirla dopo un grande rollout programmatico, una migrazione o un rilascio di navigazione a faccette è troppo tardi: i crawler potrebbero già essere intrappolati in uno spazio URL effettivamente illimitato.

Se saltata su un sito davvero grande, le URL prioritarie nuove e modificate possono attendere dietro infinite combinazioni di parametri, pagine di errore, catene di reindirizzamento e duplicati. Se eseguita su un sito sano e piccolo, consuma tempo di engineering senza affrontare il vero vincolo. L’argomento di dipendenza è semplice: la classificazione viene prima del controllo, e l’evidenza viene prima delle regole.

Input e output

Gli output sono il contratto con l’engineering e il successivo ciclo di misurazione. “Migliorare l’efficienza del crawl” non è un deliverable.

La checklist

Registra PASS, FAIL o N/A e allega evidenze per ogni elemento. Ogni elemento è completo solo quando la sua condizione “Fatto quando” può essere osservata.

1. Dimostra che il crawl budget è il vincolo

Cosa: decidi se questo lavoro merita un progetto. Perché: il crawl budget viene spesso incolpato quando una pagina è in realtà di bassa qualità, orfana, non canonical, bloccata o intenzionalmente esclusa. Come: confronta il numero di URL canonical, la creazione giornaliera di URL, la salute del server, le date dell’ultimo crawl, il ritardo di scoperta, le ragioni di copertura e la quota di richieste bot verificate spese al di fuori dell’inventario canonical. Segmenta per directory e template; una media a livello di sito nasconde una singola sezione fuori controllo. Strumento: pipeline di log, crawler, report di copertura dei motori di ricerca, esportazioni sitemap e calendario rilasci. Fatto quando: una diagnosi firmata nomina almeno un vincolo misurato o chiude la checklist come “non materiale”, con le evidenze e un’azione successiva più appropriata.

2. Costruisci un dataset affidabile di richieste bot

Cosa: crea una tabella normalizzata delle richieste per la finestra di analisi. Perché: le stringhe user-agent possono essere falsificate, gli analytics campionati omettono i bot e i log CDN possono differire dai log di origine. L’analisi dei file di log significa esaminare i record di accesso al server per vedere cosa hanno effettivamente richiesto i crawler. Come: combina dati CDN e di origine dove necessario, normalizza l’host e la codifica URL, rimuovi gli asset statici a meno che il rendering non sia in esame, verifica i principali bot di ricerca con il metodo di verifica pubblicato dal fornitore e conserva stato, byte, tempo di risposta ed esito della cache. Strumento: log CDN o web server, verifica DNS, SQL o un analizzatore di log. Fatto quando: l’intervallo di date e la conservazione sono documentati, i bot noti sono separati dagli agenti non verificati, i totali corrispondono ai record grezzi e la stessa query può riprodurre ogni grafico nella diagnosi.

3. Misura dove le richieste vengono sprecate

Cosa: classifica ogni richiesta del crawler in: canonical utile, duplicato, reindirizzamento, errore, bloccato, parametro, facet, ricerca interna, soft-404, asset o sconosciuto. Un soft 404 è una pagina che restituisce 200 OK ma si comporta come un risultato mancante o vuoto. Perché: il volume totale di crawl non può mostrare se i crawler stanno aggiornando l’inventario o girando in loop attraverso stati inutili. Come: unisci le richieste all’inventario di crawl e canonical, raggruppa per percorso normalizzato e firma dei parametri, poi classifica i pattern per conteggio richieste e costo server. Riconcilia questi pattern con le ragioni di copertura come scoperto ma non indicizzato, crawllato ma non indicizzato, duplicato, bloccato e soft 404; la copertura spiega il risultato riportato da un motore di ricerca, mentre i log provano le richieste. Ispeziona il gruppo sconosciuto manualmente piuttosto che forzarlo in un’etichetta conveniente. Strumento: log verificati, esportazione copertura, crawler del sito, esportazione canonical e profiler delle risposte. Fatto quando: almeno il 95% delle richieste bot in ambito ha una classificazione revisionata, il resto sconosciuto è elencato e i principali pattern di spreco hanno URL di esempio, risultati di copertura e proprietari.

4. Contieni facet e parametri alla fonte

Cosa: governa i parametri di filtro, ordinamento, paginazione, tracciamento, sessione e ricerca. La navigazione a faccette consente agli utenti di combinare filtri come marca, colore e dimensione; combinazioni non controllate possono creare uno spazio di crawl effettivamente infinito. Perché: bloccare un crawler dopo che i template hanno generato milioni di link cura il sintomo lasciando esposti scoperta, comportamento utente, analytics e altri bot. Come: assegna a ogni parametro una funzione e una policy: pagina di destinazione indicizzabile, duplicato canonical, pagina noindex, reindirizzamento, stato scollegato o pattern bloccato. Utilizza un ordinamento stabile dei parametri, previeni combinazioni vuote e contraddittorie e rimuovi i parametri di tracciamento o sessione dai link interni. Non canonicalizzare una pagina verso un target con contenuti materialmente diversi solo per sopprimerla. Strumento: registro parametri, sorgente template, crawler con report di pattern URL, log e test URL automatizzati. Fatto quando: ogni parametro osservato ha una policy approvata, i template crawlabili emettono solo combinazioni consentite, le combinazioni vietate hanno copertura di test e il volume di log per i pattern target diminuisce al checkpoint concordato.

5. Elimina spazi infiniti e trappole di crawl

Cosa: chiudi le route che possono generare date, calendari, paginazione, ID, varianti di maiuscole/minuscole, segmenti di percorso o filtri ricorsivi illimitati. Perché: un crawler può continuare a scoprire URL sintatticamente nuove anche quando ogni pagina contiene lo stesso risultato vuoto o duplicato. Come: imposta limiti finiti, restituisci 404 o 410 per stati impossibili, collega solo a intervalli validi, normalizza le regole di maiuscole/minuscole e trailing slash, reindirizza i duplicati esatti una volta sola e smetti di generare link alla pagina successiva oltre il set di risultati finale. Testa valori malformati ed estremi, non solo il percorso felice. Strumento: generatore di URL sintetiche, crawler, log, test del router e test delle regole edge. Fatto quando: ogni generatore ha un massimo documentato, gli stati fuori intervallo restituiscono la risposta prevista, nessuna route testata crea una nuova sequenza illimitata e i pattern di richiesta interessati diminuiscono senza bloccare pagine di valore.

6. Correggi soft 404, errori e sprechi di reindirizzamento

Cosa: fai sì che i codici di risposta descrivano il risultato effettivo. Perché: una pagina vuota con 200 chiede ai crawler di analizzare e valutare contenuti che avrebbero dovuto essere dichiarati mancanti; risposte 5xx ripetute consumano capacità e possono far apparire un host inaffidabile; le catene impiegano diverse richieste per raggiungere una destinazione. Come: restituisci 404 per URL mancanti, 410 per risorse rimosse intenzionalmente quando appropriato, 200 solo per pagine sostanziali e un singolo reindirizzamento verso la destinazione canonical finale per URL spostate. Ripara i link interni che puntano a reindirizzamenti o errori. Strumento: log, crawler, suite di test HTTP, monitoraggio e inventario route. Fatto quando: i risultati vuoti campionati non restituiscono più 200, le route prioritarie non hanno catene di reindirizzamento, i link interni risolvono direttamente e la soglia del tasso di errore nelle regole decisionali viene superata per due finestre di misurazione consecutive.

7. Rendi coerenti i controlli canonical e di indicizzazione

Cosa: allinea risposta, URL canonical , meta robots, header HTTP robots, link interni e appartenenza alla sitemap. Perché: segnali contraddittori causano visite ripetute: una URL può essere inviata in una sitemap, canonicalizzata altrove, collegata in tutta la navigazione e bloccata dalla direttiva che ne spiega lo stato. Come: crea una matrice di regole per ogni classe di URL e testa la risposta di produzione renderizzata. Usa robots.txt per gestire l’accesso dei crawler, non come meccanismo di rimozione affidabile; una URL bloccata non può rivelare una direttiva noindex a livello di pagina a un crawler che non la recupera mai. Strumento: crawler, HTML grezzo e renderizzato, ispettore header, tester robots e ispezione URL. Fatto quando: il 100% dei campioni prioritari e tutti i casi di test dei template corrispondono a una regola coerente, senza URL canonical indicizzabile bloccata e senza pattern escluso promosso attraverso sitemap o navigazione primaria.

8. Pulisci le sitemap XML trasformandole in un feed prioritario

Cosa: pubblica solo URL canonical, indicizzabili e con risposta 200 e date di modifica veritiere in ogni sitemap XML . Perché: una sitemap è un segnale di scoperta, non un archivio di ogni URL che il CMS ha prodotto. Reindirizzamenti, duplicati, errori e timestamp lastmod invariati diluiscono quel segnale e oscurano i confronti di copertura. Come: riconcilia le URL della sitemap con l’inventario canonical, suddividi i file in unità diagnostiche stabili come tipo di contenuto o directory, rimuovi le URL escluse e aggiorna lastmod solo per modifiche sostanziali alle pagine. Invia le sitemap modificate e registra download, avvisi ed errori. Strumento: parser sitemap, esportazione CMS, log e report sitemap dei motori di ricerca. Fatto quando: ogni URL inviata restituisce 200, è auto-canonical e indicizzabile, le esclusioni sono zero, lastmod supera un controllo campionario di modifica dei contenuti e i conteggi inviati corrispondono all’inventario approvato.

9. Usa i link interni per avvicinare le pagine prioritarie

Cosa: ripara le pagine orfane e riduci la distanza in clic verso le URL di alto valore attraverso link interni utili. La profondità di crawl è il numero di passaggi di link di cui un crawler ha bisogno per raggiungere una pagina da una pagina di partenza scelta. Perché: bloccare gli sprechi non dice a un crawler cosa visitare dopo; lo fanno i link HTML stabili da pagine forti e visitate di frequente. Come: calcola profondità e link entranti dalla homepage e dagli hub pertinenti, aggiungi link contestuali o di navigazione dove gli utenti ne beneficiano, sostituisci i link verso URL reindirizzate e assicurati che la paginazione esponga l’inventario più profondo. Non appiattire tutto in un footer. Strumento: crawler del grafo dei link, template, log e prestazioni di ricerca per directory. Fatto quando: ogni URL prioritaria ha almeno un link entrante crawlabile, nessuna orfana prioritaria rimane, i template prioritari concordati sono entro tre passaggi di link da un hub pertinente e i log confermano che i nuovi campioni linkati vengono scoperti o rivisitati.

10. Proteggi la capacità del server e i percorsi di rendering

Cosa: mantieni le richieste dei crawler veloci e di successo senza servire ai bot di ricerca una pagina materialmente diversa. Perché: la domanda di crawl non può compensare un host che va in timeout, limita indiscriminatamente i crawler legittimi o richiede rendering costoso per contenuti e link di base. Come: confronta tempi di risposta ed errori per bot, route, stato cache e template; memorizza in cache le risposte sicure; rimuovi i percorsi di query costosi; preserva HTML essenziale e link nella risposta iniziale; e testa le regole di firewall e CDN con bot verificati. Strumento: monitoraggio delle prestazioni dell’applicazione, analytics CDN, log, test di uptime e ispezione delle pagine renderizzate. Fatto quando: l’host soddisfa le soglie di risposta ed errore concordate sotto carico previsto, i crawler verificati non vengono accidentalmente bloccati e i contenuti prioritari più i link sono presenti senza interazione dell’utente.

11. Implementa per pattern e verifica il compromesso

Cosa: rilascia il più piccolo insieme di regole coerente, poi confronta prima e dopo. Perché: un cambiamento globale di robots, canonical, routing o navigazione può rimuovere preziose pagine di coda lunga più velocemente di quanto rimuova sprechi. Come: inizia con un pattern URL o directory misurabile, preserva un controllo ove pratico, annota il rilascio e confronta richieste bot, errori, latenza di ricrawl delle priorità, copertura, impressioni e carico del server dopo un ciclo di crawl completo. Tieni le istruzioni di rollback accanto alla regola. Strumento: log di deployment, log del server, report di copertura, report AmICited e monitoraggio. Fatto quando: la misura di spreco target migliora, la scoperta e l’indicizzazione prioritaria non regrediscono oltre la tolleranza dichiarata, il proprietario firma il risultato e la decisione di rollout o rollback successiva è registrata.

Strumenti in AmICited

AmICited fornisce evidenze dai motori di ricerca e sulle prestazioni attorno alla diagnosi. I log grezzi del server rimangono la fonte di verità per il comportamento a livello di richiesta tra i bot.

1. Apri Bing Crawl al report live di Bing Crawl per rivedere l’attività di crawl di Bing e i problemi URL segnalati. Cattura l’intervallo, il tipo di problema, le URL di esempio e l’ora di esportazione; non generalizzare il comportamento di Bing a tutti i crawler.

2. Utilizza Sitemap e Indicizzazione al report sitemap per confrontare i conteggi inviati, l’ultimo download, gli avvisi e gli errori, inviare una sitemap pulita o richiedere l’indicizzazione per un batch limitato di URL prioritarie modificate. Una richiesta accelera la riconsiderazione; non rende indicizzabile una pagina bloccata o di bassa qualità.

3. Controlla esempi rappresentativi di successi, pattern di spreco e pagine riparate in Ispezione URL al report di ispezione URL . Registra il canonical dichiarato e selezionato, il verdetto di copertura, l’ultimo crawl e l’ora di ispezione. La sua vista di copertura è un campione in crescita, non un report completo del crawl budget.

4. Apri Directory Google Search al report delle directory per confrontare clic e impressioni per sezione prima di limitare una directory o modificarne i link. Una sezione a basso traffico potrebbe comunque essere strategicamente necessaria; utilizza questo report per dimensionare l’impatto sulla ricerca, non per dichiarare spreco di crawl da solo.

Regole decisionali: come si presenta un problema in numeri

Queste sono soglie operative per questa checklist, non limiti universali dei motori di ricerca. Sostituiscile solo con una baseline documentata del sito e una tolleranza al rischio approvata.

Non aprire un progetto sul crawl budget solo perché il sito supera una riga relativa al conteggio URL. Al contrario, non ignorare un sito di 20.000 pagine la cui trappola del calendario genera milioni di URL distinte. L’evidenza di scoperta limitata o spreco è il fattore decisivo.

Deliverable

Consegna un pacchetto versionato, non una diapositiva che dice “crawl ottimizzato”:

• crawl-budget-summary.md: ambito, decisione, metodo di verifica bot, finestra di analisi, risultati, trattamenti approvati, rischi, ordine di rilascio e trigger di rollback.
• crawl-pattern-register.csv: pattern normalizzato, URL di esempio, scopo, conteggio richieste, quota, risposta, stato canonical, stato sitemap, link entranti, valore aziendale, trattamento, proprietario e stato.
• priority-url-sample.csv: almeno 20 URL con campi baseline e checkpoint per scoperta, ultimo crawl, verdetto di indicizzazione, profondità, link entranti, risposta e canonical selezionato.
• sitemap-reconciliation.csv: URL inviata, stato inventario, risposta, canonical, indicizzabilità, validazione lastmod, azione ed evidenza.
• monitoring-spec.md: query, dashboard, soglie, proprietari, cadenza, route di alert, date di checkpoint e conservazione.

Il responsabile tecnico SEO possiede il pacchetto; l’engineering firma le modifiche a route e infrastruttura; il responsabile dei contenuti o merchandising firma qualsiasi decisione che rimuova un percorso utente individuabile o una pagina di destinazione indicizzabile.

Cosa va storto

Il team ottimizza un sito minuscolo. Gli ingegneri passano uno sprint a bloccare parametri mentre pagine importanti rimangono sottili o orfane. Chiudi la checklist come non materiale e reindirizza il lavoro a contenuti, linking o indicizzabilità.

Robots.txt diventa uno strumento di cancellazione. Le URL bloccate possono rimanere note e i crawler non possono recuperare le loro direttive a livello di pagina. Definisci prima il ciclo di vita previsto, rimuovi la generazione interna e utilizza il comportamento di risposta, reindirizzamento, canonical o noindex che corrisponde.

Ogni facet viene trattato come duplicato. Una combinazione marca-e-categoria con domanda reale può essere una pagina di destinazione utile; un ordinamento di solito no. Decidi a livello di pattern usando la domanda e la distintività dei contenuti.

Ci si aspetta che un tag canonical blocchi il crawling. I canonical esprimono una versione preferita, ma i duplicati potrebbero comunque essere recuperati per valutare la relazione. Rimuovi link e generazione dispendiosi piuttosto che affidarti a un singolo suggerimento.

Le sitemap diventano dump di database. URL reindirizzate, scadute, bloccate e non canonical oscurano l’inventario che il team desidera effettivamente venga crawllato. Riconcilia l’appartenenza alla sitemap come gate di rilascio.

L’analytics viene scambiato per log. L’analytics lato client raramente registra le richieste dei bot di ricerca. Senza log di accesso verificati, il team non può misurare l’allocazione delle richieste o il costo delle risposte.

Il rollout blocca pagine che generano entrate. Una regola ampia su parametri o percorso cattura categorie valide, pagine localizzate, paginazione o destinazioni di campagne. Testa esempi positivi e negativi, implementa un pattern alla volta e mantieni un rollback rapido.

Successo significa meno richieste. Il volume di crawl può diminuire perché pagine di valore sono scomparse dalla scoperta. Un cambiamento di successo riduce gli sprechi mentre la scoperta prioritaria, l’indicizzazione e la domanda di ricerca rimangono in salute.

Fase successiva

Alimenta il registro dei pattern, la riconciliazione delle sitemap, il campione prioritario e le soglie di monitoraggio nell’aggiornamento e iterazione continui . Questa fase necessita di percorsi di scoperta stabili e segnali di cambiamento affidabili; altrimenti una pagina aggiornata può essere pubblicata correttamente ma attendere invisibile dietro trappole di crawl o link interni deboli.

Riapri questa checklist dopo una migrazione, un cambiamento di piattaforma o routing, un rilascio di navigazione a faccette, una grande espansione dell’inventario, un incidente di errore prolungato o una violazione della soglia concordata. Non rieseguire l’intero esercizio su base calendariale quando la baseline di monitoraggio rimane pulita.

FAQ

Le FAQ seguenti coprono ambito, regole robots, parametri, sitemap e cadenza di revisione. Il principio guida è coerente: classifica prima lo spazio URL, usa l’evidenza delle richieste come secondo passo e modifica i controlli dei crawler solo quando l’esito previsto per l’utente e l’indicizzazione è esplicito.