«Discovered – currently not indexed» e «Crawled – currently not indexed» sono le due righe più comuni del report «Pagine indicizzate» di Search Console – e le più fraintese. Sembrano un guasto tecnico, ma in realtà sono una decisione di priorità e qualità che Google ha preso sulle tue pagine. Inviare con più forza non cambia nulla. Correggere la causa, sì.
Questa guida è un ciclo completo che puoi affidare interamente all'agente Hermes: estrarre l'elenco delle URLs, ispezionare ogni pagina, individuare la causa reale, approvare la coda di correzioni e inviare via Google Indexing API solo le pagine che meritano di essere indicizzate. Alla fine hai un pipeline settimanale ripetibile – non una sessione di clic una tantum.
Cosa ottieni
- Un inventario classificato: URLs bloccate in «discovered», URLs crawlate ma non indicizzate e URLs che non avresti mai dovuto inviare
- Un elenco approvato per Indexing API e un elenco di escluse con il motivo
- Un passo di verifica che mostra se i tuoi invii hanno funzionato davvero
Cosa ti serve: un agente Hermes installato e funzionante (hermes chat apre una sessione. Passi di installazione aggiornati: documentazione ufficiale su hermes-agent.nousresearch.com/docs), una proprietà di Search Console di cui sei proprietario e due set di credenziali Google (uno per leggere la GSC, uno per Indexing API). Primo setup circa 60–90 minuti, poi circa 15 minuti a settimana. «Fatto» significa: le tue URLs inviate mostrano un cambiamento di stato reale nell'API di ispezione entro due settimane – oppure hai prove solide del perché no.
Leggere bene i due stati
Google non è bloccato sul tuo sito. Ha preso una decisione – e lo stato ti dice quale.
Stato | Cosa significa davvero | Cause frequenti | Quando inviare |
|---|---|---|---|
Discovered – currently not indexed | Google conosce l'URL (via sitemap o link) ma non l'ha ancora crawlate | Priorità di crawling bassa, link interni deboli o assenti, pressione sul crawl budget nei siti grandi, sito nuovo, rendering JS lento o pesante, sitemap che cambiano spesso | Una volta, dopo aver migliorato i segnali di priorità (soprattutto i link interni) |
Crawled – currently not indexed | Google ha recuperato l'URL ma ha deciso di non indicizzarla | Contenuto duplicato o quasi duplicato, contenuto scarso, canonical verso un'altra URL, noindex al momento del crawl, soft 404, giudicata di basso valore | Solo se hai davvero cambiato qualcosa: contenuto, canonical o noindex |
Indexed | È nell'indice | — | Non inviare |
Excluded | Crawlata ed esclusa di proposito (noindex, canonical, scelta di duplicato, blocco) | — | Non inviare; verifica se l'esclusione è intenzionale |
In una frase: invia solo URLs che hai davvero modificato o che meritano una seconda occhiata. Indexing API è un canale di notifica, non un annullatore di ranking. Inviare una pagina scadente dieci volte restituisce dieci volte lo stesso verdetto.
Perché farlo fare a un agente
Il pulsante «Richiedi indicizzazione» della GSC non ha un'API pubblica – non esiste un modo ufficiale di premerlo con uno script. L'automazione più vicina è Google Indexing API, che accetta notifiche di URL direttamente. Un agente aggiunge valore per tre ragioni:
- Il ciclo è meccanico e lungo: inventario → ispezione → classificazione → correzione → invio → verifica. Ogni settimana.
- Richiede una traccia di audit: ti serve un file che mostri quali URLs sono state inviate, quando e perché.
- Richiede un cancello di approvazione: la parte che scrive su Google deve essere rivista da un umano. Hermes è costruito esattamente attorno a questa separazione – con skills, cartelle di progetto e regole di approvazione.
Cosa ti serve prima di iniziare
- Agente Hermes installato. Verifica con
hermes chatprima di continuare. - Una proprietà GSC di cui sei proprietario. Nel formato
sc-domain:example.com(non l'URL completa). - Accesso in lettura: un client OAuth di Google Cloud (client ID + segreto) per Search Console API. Gli script della skill GSC lo usano per sitemap, Search Analytics e ispezione delle URLs.
- Accesso in scrittura: un progetto Google Cloud con Indexing API attivata e una chiave JSON di service account. Aggiungi l'email del service account come proprietario in GSC → Impostazioni → Utenti e autorizzazioni. Se l'invio restituisce 403, è questo il passo mancante.
- Python 3 e
pip install google-auth google-api-python-client. - Una cartella di progetto. Ad esempio
/hermes-seo-projectconcontext/,data/,qa/e unapproval-rules.mdche imponga che il passo di invio richieda sempre la firma umana.
Passo 1: costruire l'inventario delle URLs
Copia le due skill GSC nella directory delle skill di Hermes (~/.hermes/skills): la skill di lettura (sitemap, Search Analytics, ispezione URLs) e la skill di indicizzazione (script di invio). Se l'harness cataloga le skill, puoi anche caricarli con skill_view.
Poi chiedi a Hermes in una sessione di chat, dalla cartella di progetto:
Elenca tutte le sitemap di sc-domain:example.com, estrai ogni URL con il suo lastmod e scrivile in data/url-inventory.csv. Segna qualsiasi sitemap il cui fetch fallisce.
Hermes esegue i comandi sitemap via lo strumento terminale e scrive il CSV. Un buon output: un CSV deduplicato con URL, lastmod e sitemap di origine. Controllo qualità: verifica cinque righe a caso e confronta il totale con il report sitemap della GSC. Se l'elenco è vuoto o l'autenticazione fallisce, ripeti il flusso di autenticazione GSC; lo script di lettura ha bisogno di un token OAuth fresco.
Passo 2: ispezionare e classificare
L'agente ispeziona poi l'inventario a lotti via URL Inspection API e ottiene lo stato di copertura attuale di ogni pagina. Chiedigli la fase successiva:
Ispeziona ogni URL di data/url-inventory.csv. Dividile in tre file: data/to-submit.txt (non indicizzate e meritevoli di invio), data/skip.txt (con un motivo per URL) e data/needs-fix.txt (non indicizzate e bloccate su qualcosa che possiamo cambiare).
L'API di ispezione ha limiti di frequenza per proprietà (controlla la quota attuale in Google Cloud Console; diverse migliaia al giorno, ma non infinite). Sui siti grandi, limita questo giro alle URLs con lastmod più recente – quelle che hai davvero modificato questo trimestre. Controllo qualità: campiona l'elenco delle escluse. Dovrebbe essere dominato da noindex, canonical che puntano altrove e duplicati – non da pagine che contano per te. Se un sito con migliaia di URLs produce un needs-fix vuoto, la fase di inventario probabilmente si è persa delle pagine. Allarga il range di ingresso.
Passo 3: fare triage prima di inviare
Il passo che tutti saltano. Mappa le URLs bloccate su una causa e una correzione, in quest'ordine:
Causa | Correzione | Inviare dopo la correzione? |
|---|---|---|
La pagina non ha alcun link interno | Aggiungere link contestuali da pagine indicizzate | Sì |
Sito o pagina completamente nuovo | Niente da correggere; inviare una volta e aspettare 1–2 settimane | Sì, una sola volta |
Bloccata da robots.txt | Rimuovere il blocco su quel percorso | Sì |
Crawlata ma duplicata o scarsa | Riscrivere, unire o eliminare | Solo dopo un vero cambiamento di contenuto |
canonical punta a un'altra URL | Correggere il canonical se sbagliato; se intenzionale, smettere di inviare questa URL | Solo dopo la correzione |
noindex al momento del crawl | Rimuovere il noindex e lasciare che Google ricrawli | Sì, dopo la rimozione |
Soft 404, paginazione/archivi senza valore | Correggere la pagina o eliminarla | No — esclusione permanente |
Chiedi a Hermes di preparare la coda di correzioni come tabella: URL, causa presunta, evidenza (risultato dell'ispezione o revisione del contenuto), azione suggerita, livello di rischio. Approva ogni riga nella chat. Il tuo approval-rules.md dovrebbe imporlo: l'agente prepara, tu approvi, e nulla sopra il rischio basso viene inviato senza firma.
Il cancello di approvazione separa la preparazione dell'agente dal passo di scrittura.
Le correzioni stesse sono normale lavoro SEO: riscrivere contenuti, ripulire i canonical, link interni. Questo pipeline copre la metà dell'invio. La metà della correzione è coperta dagli articoli di audit e aggiornamento della serie Hermes.
L'elenco di invio è l'intersezione di «correggibile» e «degno di indicizzazione».
Passo 4: inviare via Indexing API
Quando la coda è approvata, metti le URLs in data/approved-urls.txt e lascia che Hermes esegua la skill di indicizzazione:
python3 ~/.hermes/skills/gsc-indexing/scripts/index_submit.py check-auth
python3 ~/.hermes/skills/gsc-indexing/scripts/index_submit.py submit --urls-file data/approved-urls.txtIl tipo di notifica predefinito è URL_UPDATED, pensato per pagine nuove o modificate. Tre numeri da ricordare: la quota predefinita è 200 URLs al giorno, 600 richieste al minuto – e 403 significa che il service account non è proprietario della proprietà. Se l'elenco approvato supera le 200, distribuiscile su più giorni; Hermes può pianificare i lotti rimanenti.
Non inviare mai pagine già indicizzate né l'elenco delle escluse. Le notifiche sprecate bruciano solo quota e creano rumore.
Passo 5: verificare e aspettare
Lo status subito dopo l'invio ti dice solo se Google ha metadati della notifica – non se la pagina è indicizzata. La conferma vera arriva giorni dopo.
3–7 giorni dopo il lotto, chiedi a Hermes:
Re-ispeziona le URLs di data/approved-urls.txt e riporta i cambiamenti di stato rispetto all'ultima esecuzione.
Una progressione sana è discovered → crawled → indexed. Ecco come appare nel corso delle settimane: l'elenco delle non indicizzate si riduce e le tue correzioni reali (nuovi link interni, testi riscritti) compaiono nell'indice. Ricorda: i dati della GSC hanno giorni di ritardo e Google ricrawla secondo il proprio calendario. Un'URL che resta in «Crawled – currently not indexed» 10–14 giorni dopo correzioni reali è un segnale di qualità, non un problema di invio – spostala sul lavoro di contenuto.
Mantenere il ciclo in funzione
Trasforma il pipeline in una routine settimanale: URLs nuove o aggiornate dall'ultima esecuzione → ispezione → classificazione → triage → approvazione → invio → registro. Hermes può eseguire la parte di sola lettura (inventario, ispezione, classificazione) senza supervisione, su un calendario, e presentarti la coda ogni lunedì. Il passo di invio resta dietro il cancello di approvazione, con un registro continuo in qa/indexing-log.md: data di invio, URL, tipo di notifica, risultato. Sei mesi di registro sono l'unica misura onesta di se il pipeline funziona.
Limiti onesti
- Google documenta Indexing API per pagine con dati strutturati
JobPostingoBroadcastEvent. Usarla su pagine normali è pratica SEO diffusa, ma Google non garantisce indicizzazione né supporto per nessun tipo di pagina. - Il pulsante «Richiedi indicizzazione» non ha un'API pubblica. Indexing API è l'automazione più vicina, non lo stesso pulsante.
- Inviare non crea priorità. Se una pagina resta non indicizzata dopo correzione, invio e attesa, la risposta successiva è la qualità del contenuto – non un'altra notifica.
Domande frequenti
Indexing API funziona con pagine normali? Accetta qualsiasi URL che invii. La documentazione ufficiale di Google mira a pagine JobPosting e BroadcastEvent, quindi tratta gli invii di pagine normali come best-effort: utile, comune, ma mai garantito.
Perché resta in «Discovered – currently not indexed» dopo l'invio? Quello stato di solito significa priorità di crawling, non fallimento. Controlla i link interni verso la pagina, se robots.txt blocca il percorso e se la pagina dipende molto da JavaScript. Poi aspetta: sui siti nuovi, dalla scoperta al crawl possono passare 1–2 settimane.
Bastano 200 URLs al giorno? Per la maggior parte dei siti sì – comunque dovresti inviare solo URLs realmente modificate. Se ne hai di più con regolarità, dai priorità per valore di business e richiedi un aumento della quota in Google Cloud Console.
Indexing API accelera il ranking? No. Notifica solo a Google che un'URL è cambiata. Il ranking è un giudizio separato dei sistemi di Google, indipendente da quante notifiche invii.
In cosa differisce dal clic su «Richiedi indicizzazione» in Search Console? Stessa intenzione, meccanismo diverso. Il pulsante è pura UI senza API pubblica; Indexing API è il canale scriptabile. Nessuno dei due annulla il giudizio di Google su se una pagina debba stare nell'indice.
Autore: Julian Mercer, praticante di SEO tecnico in Auspia con 14 anni di esperienza. Scrive di crawlabilità, indicizzazione, schema e delle fondamenta tecniche che rendono un sito leggibile sia da Google che dai sistemi di IA.
