Google Indexing API: guida

TL;DR — La Google Indexing API permette ai proprietari dei siti di dire a Google tramite codice «questa pagina è cambiata, esegui di nuovo il crawling», invece di fare clic sui pulsanti. Ma c’è il punto che la maggior parte delle guide omette: Google la supporta ufficialmente solo per le pagine di offerte di lavoro e le pagine di livestream. Non è una scorciatoia per indicizzare più velocemente articoli del blog o pagine di prodotto: Google lo ha detto più volte.

Che cos’è la Indexing API

Quando pubblichi o modifichi una pagina, normalmente aspetti che Google torni a eseguire il crawling secondo il proprio programma. La Indexing API permette invece di inviare una notifica a Google: «ehi, questo URL è nuovo/aggiornato» oppure «questo URL non esiste più, rimuovilo». Lo fai con il codice (un piccolo programma che chiama i server di Google), non facendo clic in una dashboard.

Sembra potente, e lo è — per le cose esatte per cui è stata costruita.

L’unica cosa da capire

Google supporta ufficialmente la Indexing API solo per due tipi di pagine:

1. Offerte di lavoro — pagine con dati strutturati JobPosting (annunci di lavoro che scadono e devono essere rimossi rapidamente).
2. Livestream — pagine con dati strutturati BroadcastEvent (eventi video dal vivo che contano solo durante la trasmissione).

Tutto qui. Sono entrambi contenuti sensibili al tempo che diventano rapidamente obsoleti: per questo Google ha costruito una corsia preferenziale per loro.

Se non hai annunci di lavoro o livestream, la Indexing API non è lo strumento adatto a te, indipendentemente da ciò che ti dice un plugin o un SaaS che promette «indicizzazione in poche ore».

Il mito da ignorare

Il mito più grande online è: «Usa la Indexing API per indicizzare rapidamente qualsiasi pagina». Non funziona così e Google ha definito ripetutamente abuso il suo utilizzo per le pagine normali. Le persone lo fanno comunque perché gli strumenti lo vendono come una scorciatoia per la crescita, ma Google può (e dice che lo farà) revocare il tuo accesso se ne abusi.

C’è anche una seconda trappola: quando invii un URL e ricevi una risposta «success», significa solo che Google ha ricevuto la richiesta. Non significa che la pagina sia stata indicizzata. Molti strumenti confondono i due concetti; la documentazione di Google è chiara.

Che cosa fare invece per indicizzare più velocemente

Per le pagine normali (blog, prodotti, articoli), le cose che aiutano davvero sono noiose ma reali:

• Invia una sitemap XML in Google Search Console.
• Collega le nuove pagine da altre pagine del sito.
• Fai in modo che la pagina meriti davvero di essere indicizzata (qualità, non riempitivo scarno).
• Per un caso isolato, usa «Richiedi indicizzazione» nello strumento Controllo URL di Search Console, con moderazione.

Vuoi la versione tecnica — configurazione, metodi API effettivi, quote e citazioni esatte di Google? Passa alla scheda Advanced.

TL;DR — La Indexing API è una REST API (v3) autenticata tramite Google Cloud che accetta notifiche URL_UPDATED e URL_DELETED. Google la supporta ufficialmente solo per pagine JobPosting e BroadcastEvent inserito in VideoObject (livestream), non per i contenuti generici. Un 200 dell’endpoint di stato conferma la ricezione, non l’indicizzazione. La posizione di Google si è irrigidita nel tempo: 2022 («non ha senso») → settembre 2024 (avviso antispam aggiunto alla documentazione) → maggio 2025 (Mueller: «gli spammer abusano della Indexing API… usatela correttamente o non usatela»). L’abuso, compresi più account per gonfiare la quota, può far revocare l’accesso. Per le pagine generiche le leve sono sitemap, link interni, qualità e l’occasionale «Richiedi indicizzazione» in GSC — e ricorda che Google non supporta IndexNow.

Che cos’è davvero la Indexing API

La Indexing API è un canale programmatico di push: una REST API (v3), autenticata tramite un service account Google Cloud, che chiami per dire a Google che un URL è stato aggiunto/aggiornato (URL_UPDATED) o deve essere rimosso (URL_DELETED). Affianca sitemap e Search Console come metodo per far scoprire e aggiornare gli URL a Google, ma per tipo di contenuto è la più ristretta del gruppo.

Nel mio deck How Search Works elenco la Indexing API come fonte di scoperta degli URL con l’etichetta «casi d’uso limitati»: in due parole, è tutta la storia. È reale, funziona e può essere usata solo per una piccola parte del web.

Per che cosa Google la supporta ufficialmente

Questo è il fatto fondamentale, quindi lo esprimo come fa Google. La Indexing API «can only be used to crawl pages with either JobPosting or BroadcastEvent embedded in a VideoObject.» Tutto qui: due tipi di dati strutturati: Glossa italiana: può essere usata per eseguire il crawling solo di pagine con JobPosting o BroadcastEvent incorporato in un VideoObject.

• JobPosting — pagine di annunci di lavoro. Scadono e gli annunci obsoleti offrono un’esperienza negativa, quindi è importante aggiungerli/rimuoverli tempestivamente.
• BroadcastEvent in un VideoObject — pagine di eventi livestream. Sono rilevanti solo durante la trasmissione e subito intorno a essa.

Perché solo questi due? Entrambi sono intrinsecamente sensibili al tempo e di breve durata. La motivazione di Google è che la notifica rapida delle modifiche conta molto di più per loro che per le pagine evergreen, che il crawling normale gestisce bene.

Come funziona

Prerequisiti

La configurazione non è banale: non è una funzionalità da un solo clic:

• Un progetto Google Cloud con la Indexing API abilitata. Come dice Google, «need to tell Google about your client and activate access to the API.» Glossa italiana: devi informare Google del tuo client e attivare l’accesso all’API.
• Un service account con un file di chiave JSON, conservato in modo sicuro.
• La verifica in Search Console del sito, poi l’aggiunta del service account come proprietario delegato del sito.
• OAuth: «Every call to the Indexing API must be authenticated with an OAuth token that you get in exchange for your private key,» usando lo scope https://www.googleapis.com/auth/indexing. Glossa italiana: ogni chiamata alla Indexing API deve essere autenticata con un token OAuth ottenuto in cambio della chiave privata.

I due metodi (più un controllo di stato)

• URL_UPDATED — «To notify Google of a new URL to crawl or that content at a previously-submitted URL has been updated.» Invia in POST l’URL con "type": "URL_UPDATED". Una chiamata riuscita restituisce HTTP 200: secondo la formulazione di Google questo «means that Google may try to recrawl this URL soon,» non che lo farà o che il crawling produrrà un’indicizzazione. Glossa italiana: serve a notificare a Google un nuovo URL da sottoporre a crawling o che il contenuto di un URL già inviato è stato aggiornato; un 200 significa solo che Google potrebbe provare a eseguire presto un nuovo crawling.
• URL_DELETED — prima di richiedere la rimozione, Google richiede che «the URL must return a 404 or 410 status code or the page must contain» un meta tag noindex: è un o l’uno o l’altro, non «elimina la pagina e aggiungi anche noindex». Quando il requisito è soddisfatto, invia in POST l’URL con "type": "URL_DELETED" affinché Google lo rimuova. Glossa italiana: l’URL deve restituire 404/410 oppure la pagina deve contenere noindex.
• Stato (GET) — restituisce metadati (latest_update, latest_remove, notify_time). La precisazione critica, alla lettera: la richiesta GET «only returns whether you successfully submitted a request.» Non dice se Google abbia effettivamente indicizzato o rimosso qualcosa. Glossa italiana: restituisce solo se hai inviato correttamente una richiesta.
• Batching — per ridurre le connessioni HTTP, puoi «combine up to 100 calls to the Indexing API into a single HTTP request.» La quota si conta comunque per URL: 10 richieste in un batch consumano 10 richieste di quota. Glossa italiana: puoi combinare fino a 100 chiamate in una singola richiesta HTTP.

Quote

La quota predefinita di Google ha tre dimensioni separate, non un solo numero:

• 200 richieste di pubblicazione al giorno per progetto — comprende insieme chiamate URL_UPDATED e URL_DELETED. È il numero citato dalla maggior parte delle guide.
• 180 richieste getMetadata (stato) al minuto per progetto.
• 380 richieste al minuto per progetto su tutti gli endpoint combinati.

Tutte e tre sono descritte come «initial default quota for testing»: superarle «requires additional approval for usage and resource provisioning» tramite un modulo di richiesta, e Google osserva che «the quota may increase or decrease based on the document quality.» Glossa italiana: sono quote iniziali predefinite per i test; superarle richiede un’approvazione aggiuntiva per l’uso e la fornitura delle risorse; la quota può aumentare o diminuire in base alla qualità della documentazione. Il comune «trucco» di creare più service account o progetti per gonfiare la quota giornaliera è esattamente ciò che Google vieta (vedi sotto).

Si può usare per le pagine normali? Che cosa dice davvero Google

La risposta breve è: no, non in modo supportato — e Google è stato sorprendentemente coerente e sempre più esplicito su questo punto.

La documentazione contiene un avviso antispam. Intorno a settembre 2024 Google ha aggiunto al quickstart una formulazione esplicita: «All submissions through the Indexing API undergo rigorous spam detection,» e «any attempts to abuse the Indexing API, including the use of multiple accounts or other means to exceed usage quotas, may result in access being revoked.» Glossa italiana: tutte le richieste tramite la Indexing API sono sottoposte a una rigorosa rilevazione dello spam; i tentativi di abusarne, compreso l’uso di più account o altri mezzi per superare le quote, possono portare alla revoca dell’accesso.

I rappresentanti lo dicono da anni. Nel maggio 2022 John Mueller lo ha spiegato con l’analogia dei veicoli da costruzione: l’API «is meant for very specific kinds of content,» e usarla altrove «doesn’t really make sense.» Nel maggio 2025 il tono era più netto: Mueller ha detto «We see a lot of spammers misuse the Indexing API like this, so I’d recommend just sticking to the documented & supported use-cases,» e «I’d just use it properly, or not use it. If we wanted to suggest that people could use it regardless, we’d document it as such.» Glossa italiana: è pensata per tipi di contenuto molto specifici e usarla per altro non ha davvero senso; attenetevi ai casi d’uso documentati e supportati, oppure non usatela.

Quell’arco — 2022 «non ha senso» → 2024 avviso antispam nella documentazione → 2025 «gli spammer abusano… usatela correttamente o non usatela» — è un andamento pluriennale, non un caso isolato. Anche la copertura ha osservato che l’API viene di fatto sommersa da blogger e SEO che trattano i siti normali come se fossero idonei.

Il rischio reale, espresso con precisione. Mueller non arriva a promettere una penalità algoritmica. L’inquadramento onesto è: non è supportata ed è contraria alle linee guida, i contenuti inviati in modo improprio potrebbero non restare indicizzati e il tuo accesso può essere revocato. Non presentarla come un’azione manuale garantita, ma non fingere nemmeno che sia gratuita.

Il mito dell’endpoint di stato

Questo punto merita una riga a sé perché molti strumenti sbagliano: una richiesta inviata con successo è una conferma di ricezione, non una promessa di indicizzazione. La richiesta GET «only returns whether you successfully submitted a request.» Se una dashboard mostra un badge verde «indicizzato» a partire da un 200, sta deducendo qualcosa che l’API non ha mai detto. Glossa italiana: restituisce solo se hai inviato correttamente una richiesta.

Indexing API vs Richiesta di indicizzazione vs IndexNow

Tre cose vengono continuamente confuse. Sono meccanismi diversi:

• Indexing API (Google): programmatica, ma limitata nei contenuti a JobPosting/BroadcastEvent. È la più ristretta delle tre.
• Richiedi indicizzazione (Controllo URL di GSC): funziona per qualsiasi pagina che possiedi, ma è manuale, un URL alla volta e pensata per un uso occasionale; è una richiesta, non una garanzia.
• IndexNow: il protocollo aperto di push tra motori (Bing, Yandex, Yep, Seznam, Naver) — e Google non lo usa. È l’equivalente cross-engine della Indexing API e quello che sostengo davvero: ho contribuito a pubblicare l’integrazione IndexNow in Ahrefs Site Audit. Ma non raggiunge Google.

(Analisi completa nella scheda Frameworks.)

Che cosa fare invece per le pagine generiche

Se non pubblichi annunci di lavoro o livestream, la Indexing API non è il tuo strumento e Google lo ha detto ripetutamente. Le vere leve Google sono quelle poco glamour:

• Sitemap — per copertura e scoperta.
• Link interni — le pagine orfane fanno fatica; le pagine collegate vengono trovate.
• Qualità dei contenuti — Google decide che cosa merita di essere indicizzato; le pagine scarne restano bloccate in «Scoperta: attualmente non indicizzata», indipendentemente da quanto tu le spinga.
• «Richiedi indicizzazione» di GSC — per casi isolati reali, con moderazione.

Per il push tra motori (Bing e altri, non Google), IndexNow è lo strumento giusto. E se ti interessa perché le pagine non vengono indicizzate in primo luogo, è una questione di frequenza di crawling e qualità, non di API.

Riepilogo AI

Una sintesi della versione Advanced:

• Che cos’è: una REST API (v3) autenticata tramite Google Cloud per inviare a Google notifiche URL_UPDATED / URL_DELETED.
• L’unico fatto importante: supportata ufficialmente solo per pagine JobPosting e BroadcastEvent (livestream), non per contenuti generici. Entrambi sono progettati per contenuti sensibili al tempo.
• Il mito numero uno: «indicizza rapidamente qualsiasi pagina». Non è così: Google definisce abuso l’uso più ampio. Un invio riuscito conferma solo che Google ha ricevuto la richiesta, non che qualcosa sia stato indicizzato.
• La posizione di Google si è irrigidita: 2022 «non ha senso» → settembre 2024 avviso antispam nella documentazione → maggio 2025 Mueller «gli spammer abusano… usatela correttamente o non usatela».
• Rischio: non supportata e contraria alle linee guida; più account per superare la quota di circa 200 al giorno possono far revocare l’accesso. Non necessariamente una penalità manuale, ma i contenuti potrebbero non restare indicizzati.
• Non è la stessa cosa di IndexNow (cross-engine, Bing/Yandex ecc.; Google non lo usa) né di Richiedi indicizzazione di GSC (qualsiasi pagina, manuale, occasionale).
• Per le pagine normali: sitemap + link interni + qualità + Richiedi indicizzazione GSC occasionale.

Documentazione ufficiale

Documentazione primaria di Google.

Google — Indexing API

• Indexing API Quickstart — panoramica, limitazione a JobPosting/BroadcastEvent e avviso sulla rilevazione dello spam.
• Come usare la Indexing API — metodi URL_UPDATED / URL_DELETED e precisazione sull’endpoint di stato.
• Prerequisiti — progetto Cloud, service account, scope OAuth e proprietà delegata in Search Console.
• Quote e prezzi — quota predefinita (200) e approvazione necessaria per aumentarla.

Google — contesto per le pagine generiche

• Chiedere a Google di eseguire di nuovo il crawling dei tuoi URL — sitemap e percorso «Richiedi indicizzazione» di Search Console per i contenuti normali.
• Guida approfondita a come funziona Google Search — dove si collocano la scoperta degli URL e la pipeline crawl → index → serve.

Citazioni dalla fonte

Dichiarazioni ufficiali di Google. Ogni link è un deep link che porta al passaggio citato nella pagina fonte.

Documentazione Google — la limitazione

• “The Indexing API can only be used to crawl pages with either JobPosting or BroadcastEvent embedded in a VideoObject.” Glossa italiana: la Indexing API può essere usata per eseguire il crawling solo di pagine con JobPosting o BroadcastEvent incorporato in un VideoObject. — Google Search Central, Indexing API Quickstart. Vai alla citazione
• “The Indexing API allows site owners to directly notify Google when their job posting or livestreaming video pages are added or removed.” Glossa italiana: consente ai proprietari dei siti di notificare direttamente a Google quando le pagine di annunci di lavoro o video livestream vengono aggiunte o rimosse. Vai alla citazione

Documentazione Google — l’avviso antispam (aggiunto alla documentazione intorno a settembre 2024)

• “All submissions through the Indexing API undergo rigorous spam detection.” Glossa italiana: tutti gli invii tramite la Indexing API sono sottoposti a una rigorosa rilevazione dello spam. Vai alla citazione
• “Any attempts to abuse the Indexing API, including the use of multiple accounts or other means to exceed usage quotas, may result in access being revoked.” Glossa italiana: i tentativi di abusare della Indexing API, compreso l’uso di più account o altri mezzi per superare le quote, possono portare alla revoca dell’accesso. Vai alla citazione

Documentazione Google — la precisazione sull’endpoint di stato (sfata-miti)

• “The GET request doesn’t tell you when Google indexes or removes a URL; it only returns whether you successfully submitted a request.” Glossa italiana: la richiesta GET non dice quando Google indicizza o rimuove un URL; restituisce solo se hai inviato correttamente una richiesta. — Google Search Central, How to Use the Indexing API. Vai alla citazione

Documentazione Google — quota

• “The default value is set to 200.” (richieste di pubblicazione/giorno) Glossa italiana: il valore predefinito è impostato su 200. — Google Search Central, quota e prezzi. Vai alla citazione
• “The default value is set to 180.” (richieste di stato getMetadata/minuto) e “The default value is set to 380.” (tutti gli endpoint/minuto): le due dimensioni di quota che la maggior parte delle guide omette. Glossa italiana: il valore predefinito è impostato rispettivamente su 180 e 380. Vai a 180 · Vai a 380
• “The quota may increase or decrease based on the document quality.” Glossa italiana: la quota può aumentare o diminuire in base alla qualità della documentazione. — Google Search Central, quota e prezzi. Vai alla citazione

Documentazione Google — batching e rimozione

• “…you can combine up to 100 calls to the Indexing API into a single HTTP request.” Glossa italiana: puoi combinare fino a 100 chiamate alla Indexing API in una singola richiesta HTTP. — Google Search Central, How to Use the Indexing API. Vai alla citazione
• “…the URL must return a 404 or 410 status code or the page must contain” un meta tag noindex: prima di richiedere la rimozione. Glossa italiana: l’URL deve restituire 404/410 oppure la pagina deve contenere un meta tag noindex. — Google Search Central, How to Use the Indexing API. Vai alla citazione
• “An HTTP 200 response means that Google may try to recrawl this URL soon.” Glossa italiana: una risposta HTTP 200 significa che Google potrebbe provare presto a eseguire un nuovo crawling di questo URL. — Google Search Central, How to Use the Indexing API (su URL_UPDATED). Vai alla citazione

John Mueller, Google Search Advocate — Bluesky, circa maggio 2025

• “We see a lot of spammers misuse the Indexing API like this, so I’d recommend just sticking to the documented & supported use-cases.” Glossa italiana: vediamo molti spammer abusare della Indexing API in questo modo, quindi consiglio di attenersi ai casi d’uso documentati e supportati.
• “I’d just use it properly, or not use it. If we wanted to suggest that people could use it regardless, we’d document it as such.” Glossa italiana: la userei correttamente oppure non la userei; se volessimo suggerire di usarla comunque, lo documenteremmo. Leggi la copertura

John Mueller, Google — SEO office hours, maggio 2022 (l’inquadramento dei «veicoli da costruzione»)

• “The indexing API is meant for very specific kinds of content. And using it for other kinds of content doesn’t really make sense.” Glossa italiana: la Indexing API è pensata per tipi di contenuto molto specifici e usarla per altri tipi non ha davvero senso.
• “It’s not that it’s illegal or that it will cause problems if you put construction vehicles on your medical website. But it doesn’t really make sense.” Glossa italiana: non è illegale né necessariamente problematico mettere veicoli da costruzione sul sito medico, ma non ha davvero senso. Leggi la copertura

Indexing API — scheda rapida

Casi d’uso supportati (questo è l’elenco completo)

I due metodi

Batching: combina fino a 100 chiamate in una richiesta HTTP; la quota viene comunque conteggiata per URL, non per batch.

Fatti rapidi

• La quota predefinita ha tre parti: 200 richieste di pubblicazione/giorno, 180 richieste di stato (getMetadata)/minuto, 380 richieste/minuto su tutti gli endpoint. Per superarla serve l’approvazione di Google e può cambiare in base alla qualità della documentazione.
• 200 ≠ indicizzato. Una risposta positiva conferma solo che l’invio è stato ricevuto.
• Più account per superare la quota = accesso revocato (secondo la documentazione).
• Autenticazione: progetto Google Cloud + service account + OAuth, scope https://www.googleapis.com/auth/indexing, service account aggiunto come proprietario delegato GSC.
• Non è IndexNow (cross-engine, non Google). Non sostituisce sitemap o Richiedi indicizzazione di GSC.

Una chiamata di pubblicazione minima (solo per contenuti supportati)

Questa è la forma di una singola notifica URL_UPDATED. Usala solo per pagine con dati strutturati JobPosting o BroadcastEvent: sono i casi per cui l’API è autorizzata. Per brevità il passaggio di autenticazione (scambiare la chiave del service account con un token OAuth) è omesso; nella pratica useresti una libreria client delle API Google per ottenere il token.

La richiesta

POST https://indexing.googleapis.com/v3/urlNotifications:publish
Authorization: Bearer <OAUTH_TOKEN>
Content-Type: application/json

{
  "url": "https://example.com/jobs/senior-seo-analyst",
  "type": "URL_UPDATED"
}

Per segnalare una rimozione (dopo che la pagina è scomparsa o ha ricevuto noindex):

{
  "url": "https://example.com/jobs/senior-seo-analyst",
  "type": "URL_DELETED"
}

Controllo dello stato — la risposta informa solo che la richiesta è stata ricevuta, non che qualcosa sia stato indicizzato:

GET https://indexing.googleapis.com/v3/urlNotifications/metadata?url=https%3A%2F%2Fexample.com%2Fjobs%2Fsenior-seo-analyst
Authorization: Bearer <OAUTH_TOKEN>

Qui 200 significa «abbiamo ricevuto il tuo invio»: non è una conferma che Google abbia indicizzato (o rimosso) l’URL.

Batching di più URL: puoi combinare fino a 100 chiamate individuali in una singola richiesta HTTP multipart a https://indexing.googleapis.com/batch invece di inviare 100 richieste separate; la quota viene però conteggiata per URL, quindi un batch di 100 chiamate consuma 100 richieste dell’assegnazione giornaliera. Le librerie client delle API Google (Java, Python, JavaScript, PHP, .NET) gestiscono la formattazione del batch; scriverla a mano raramente vale la pena.

Indexing API vs Richiedi indicizzazione vs IndexNow

Il framework decisionale è questo: capisci che cosa hai e a quale motore tieni, poi scegli il canale.

Come scegliere

1. Hai annunci di lavoro o livestream e vuoi automatizzare? → Indexing API.
2. Vuoi inviare pagine generiche a Bing/Yandex/Yep? → IndexNow.
3. Vuoi che Google esegua una volta un nuovo crawling di una pagina normale? → «Richiedi indicizzazione» di GSC.
4. Vuoi indicizzare pagine generiche su Google su larga scala? → Non esiste un pulsante per il push. Sitemap + link interni + qualità. (E pazienza: vedi la frequenza di crawling.)

Il modello mentale: la Indexing API sembra la più potente delle tre perché è un’API, ma per tipo di contenuto è la più ristretta. Potenza e ambito non sono la stessa cosa.

Strumenti

• Google Cloud Console — crea il progetto, abilita la Indexing API e genera la chiave JSON del service account con cui ti autenticherai.
• Google Search Console — Controllo URL — per le pagine normali è il vero strumento: controlla come un URL è stato sottoposto a crawling, renderizzato e indicizzato e usa «Richiedi indicizzazione» per casi isolati occasionali.
• Google Search Console — Sitemap e copertura — invia sitemap e verifica che cosa è indicizzato, «Scoperta: attualmente non indicizzata» o escluso.
• Librerie client delle API Google — il modo più pulito per gestire lo scambio del token OAuth per le chiamate alla Indexing API, invece di scrivere a mano la firma JWT.
• Integrazione IndexNow (Ahrefs Site Audit ecc.) — per il canale di push cross-engine (Bing e altri, non Google). È lo strumento giusto quando vuoi il comportamento di push programmatico che le persone vorrebbero dalla Indexing API per le pagine generiche.

Risorse che vale la pena leggere

I miei articoli correlati

• What Is Googlebot & How Does It Work? — dove si colloca la Indexing API tra le fonti di scoperta degli URL di Google (link, sitemap, RSS, GSC e API).
• How to Fix «Discovered – currently not indexed» — il vero articolo sul «perché le mie pagine non vengono indicizzate»: la soluzione è qualità e link interni, non un’API di push.
• The Beginner’s Guide to Technical SEO — dove crawling e indicizzazione si inseriscono nel quadro più ampio.

I miei interventi

• How Search Works (SlideShare) — il mio percorso su scoperta, crawling, rendering, indicizzazione e ranking; la slide sulla scoperta degli URL etichetta la Indexing API «casi d’uso limitati». (Vale il mio disclaimer abituale: «questa è la mia interpretazione dei sistemi… non sarà completa o accurata al 100%.»)

Su IndexNow (il fratello cross-engine — Google non lo usa)

• Integrazione IndexNow in Ahrefs Site Audit — il canale di push che sostengo davvero, per Bing/Yandex/Yep e non per Google.
• Come inviare pagine a IndexNow in Site Audit.

Di altri autori

• Google Adds Spam Warning To Indexing API Documentation (Search Engine Journal, settembre 2024) — documenta quando è stato inserito il linguaggio sulla rilevazione dello spam.
• Google Again Says Stop Using Indexing API For Unsupported Content (Search Engine Roundtable, maggio 2025) — Barry Schwartz tratta l’avvertimento di Mueller su Bluesky contro l’abuso dell’API.
• Misuse of Indexing API Could Lead to SEO Issues (StanVentures, maggio 2025) — riproduce alla lettera le citazioni di Mueller su Bluesky e spiega il rischio di revoca dell’accesso.
• Google Answers Whether Using the Indexing API for a Normal Website Is Good or Bad (iLoveSEO, maggio 2022) — trascrizione dell’inquadramento dei «veicoli da costruzione» nelle office hours di Mueller.
• Google Says Its Indexing API Is Inundated by Bloggers (Optimixed) — tratta come l’uso fuori ambito da parte di blogger e SEO abbia sovraccaricato l’API.
• r/TechSEO — la community per il debugging di crawling e indicizzazione.

Problemi comuni

Problemi in cui le persone si imbattono davvero con la Indexing API, nell’ordine sintomo → causa → soluzione.

«Ho ricevuto una risposta 200 ma la pagina non è ancora indicizzata»

• Sintomo: la chiamata URL_UPDATED (o il GET di stato) restituisce successo, ma la pagina non compare mai nella ricerca oppure Search Console continua a dire «Scoperta: attualmente non indicizzata».
• Causa: un 200 conferma solo che Google ha ricevuto la notifica. Secondo la documentazione di Google, l’endpoint di stato «only returns whether you successfully submitted a request»: non dice se qualcosa sia stato sottoposto a crawling, indicizzato o rimosso.
• Soluzione: smetti di trattare la risposta dell’API come una conferma di indicizzazione. Controlla lo stato reale nell’applicazione Controllo URL di Search Console o nel report Copertura. Se la pagina non è ancora indicizzata dopo un’attesa ragionevole, il problema è di scoperta/qualità (vedi «Che cosa fare invece» nella scheda Advanced), non della chiamata API.

«Il mio accesso alla Indexing API è stato revocato»

• Sintomo: le chiamate che prima funzionavano iniziano a fallire oppure Google Cloud/Search Console mostra che l’accesso del service account è stato ritirato.
• Causa: Google afferma chiaramente che «any attempts to abuse the Indexing API, including the use of multiple accounts or other means to exceed usage quotas, may result in access being revoked.» Il motivo più comune è inviare pagine non JobPosting/non BroadcastEvent oppure creare service account aggiuntivi per aggirare la quota predefinita di circa 200 al giorno.
• Soluzione: verifica che cosa hai inviato: se è contenuto generico (articoli del blog, pagine di prodotto, qualunque cosa senza dati strutturati JobPosting o BroadcastEvent), fermati. L’API non è documentata come supportata per questo e Mueller ha detto direttamente: «I’d just use it properly, or not use it.» Non esiste una procedura di ricorso documentata oltre a restare nei casi d’uso supportati in futuro.

«Gli invii per le pagine normali non sembrano fare nulla»

• Sintomo: invii URL_UPDATED per un normale articolo o una pagina di prodotto e non cambia nulla: crawling o indicizzazione non diventano più rapidi.
• Causa: il tipo di contenuto non è uno dei due supportati da Google. La Indexing API «can only be used to crawl pages with either JobPosting or BroadcastEvent embedded in a VideoObject.» Gli invii fuori da questo ambito non sono un segnale documentato o supportato.
• Soluzione: non è un bug da correggere: è lo strumento sbagliato. Per le pagine generiche usa una sitemap, link interni e, per casi isolati, «Richiedi indicizzazione» in Controllo URL di Search Console.

«Sto raggiungendo il limite di quota»

• Sintomo: gli invii iniziano a fallire o vengono limitati: intorno a 200 al giorno oppure in raffiche più brevi anche sotto 200 al giorno.
• Causa: Google applica davvero tre quote predefinite separate: 200 richieste di pubblicazione (URL_UPDATED/URL_DELETED) al giorno, 180 richieste di stato (getMetadata) al minuto e 380 richieste al minuto su tutti gli endpoint combinati. Una raffica di controlli di stato può limitarti sui limiti al minuto molto prima di raggiungere i 200 giornalieri. Superare una di queste quote «requires additional approval for usage and resource provisioning» e Google osserva che la quota concessa «may increase or decrease based on the document quality.»
• Soluzione: se stai davvero pubblicando/aggiornando così tante pagine JobPosting o BroadcastEvent al giorno, richiedi un aumento della quota tramite Google Cloud; non creare service account o progetti aggiuntivi per aggirarla, perché è esplicitamente indicato come abuso che porta alla revoca dell’accesso.

Checklist

Prima di toccare la Indexing API

• Conferma che le pagine da inviare contengano davvero dati strutturati JobPosting oppure BroadcastEvent incorporato in un VideoObject: sono gli unici due tipi di contenuto supportati da Google.
• Se nessuno dei due si applica, fermati qui. Usa invece sitemap, link interni, qualità dei contenuti e «Richiedi indicizzazione» GSC occasionale, non l’API.
• Decidi se il volume di invii rientra realisticamente nella quota predefinita di circa 200 al giorno o se dovrai richiedere un aumento.

Configurazione

• Crea (o scegli) un progetto Google Cloud e abilita la Indexing API.
• Crea un service account e scarica il suo file di chiave JSON; conservalo in modo sicuro (non inserirlo mai in un repository pubblico).
• Verifica il sito in Search Console se non lo hai già fatto.
• Aggiungi l’email del service account come proprietario delegato del sito in Search Console.
• Conferma di poter scambiare la chiave del service account con un token OAuth usando lo scope https://www.googleapis.com/auth/indexing (in genere tramite una libreria client Google invece di scrivere a mano la firma JWT).

Invio di una notifica

• Scegli il metodo corretto: URL_UPDATED per una pagina supportata nuova o modificata, URL_DELETED dopo che la pagina è scomparsa o ha ricevuto noindex.
• Invia in POST l’URL con il campo type corretto a https://indexing.googleapis.com/v3/urlNotifications:publish.
• Tratta una risposta 200 solo come conferma di ricezione, non come prova che la pagina sia stata indicizzata o rimossa.
• Controlla poi Search Console (Controllo URL o Copertura) se devi confermare lo stato reale dell’indicizzazione.

Restare nelle linee guida

• Invia tramite questa API solo pagine JobPosting/BroadcastEvent: nient’altro.
• Non creare più service account o progetti solo per superare la quota; richiedi invece un aumento legittimo.
• Se non sei sicuro che una pagina sia idonea, trattala come «non idonea» e usa sitemap/link interni/Richiedi indicizzazione.

Quiz

Cinque domande per verificare che cosa hai davvero capito della Indexing API.

Cronologia modifiche