Stamattina volevo fare una cosa semplice: pubblicare un articolo, dire a Google «ehi, esiste», e non dover ogni volta entrare a mano in Search Console per chiedere l’indicizzazione. Sembra banale. Poi apri Google Cloud, trovi tre API diverse, service account, OAuth, endpoint, token, schermate di consenso, errori 400, 403, 411… e capisci perché molti installano un plugin e sperano che faccia magia.
Il punto è questo: inviare una pagina a Google, inviare una sitemap e usare una API di indicizzazione istantanea non sono la stessa cosa. Sembrano tre modi diversi per ottenere lo stesso risultato, ma in realtà hanno scopi, limiti e rischi diversi.
Prima distinzione: indicizzazione non significa scansione
Quando pubblichi un articolo, Google deve prima scoprirlo, poi scansionarlo, poi decidere se indicizzarlo. Sono tre passaggi separati.
- Scoperta: Google viene a sapere che l’URL esiste.
- Scansione: Googlebot apre la pagina e legge contenuto, canonical, robots, link, immagini.
- Indicizzazione: Google decide se inserirla davvero nei risultati.
Tu puoi aiutare molto nei primi due passaggi. Non puoi però obbligare Google a indicizzare una pagina. Se il contenuto è debole, duplicato, bloccato da robots/noindex, lento, poco collegato o ritenuto non utile, Google può anche conoscerlo e non indicizzarlo.
Metodo 1: invio manuale da Search Console
È il metodo che molti conoscono: vai in Search Console, usi Controllo URL, incolli l’indirizzo dell’articolo e clicchi Richiedi indicizzazione.
È il modo più diretto per dire a Google: «controlla proprio questa pagina». Non vuol dire che la pagina entrerà subito in SERP, ma per articoli nuovi o modifiche importanti resta il gesto più chiaro.
Qui è importante capirsi: quando premi quel pulsante non stai “mettendo la pagina su Google” come se stessi caricando un file su un server. Stai chiedendo a Google di inserirla in una coda di controllo. Google farà un test live, guarderà se la pagina risponde, se è raggiungibile, se è bloccata da noindex, se il canonical è coerente, se il contenuto è leggibile e se ci sono segnali sufficienti per considerarla.
Se tutto è a posto, la richiesta viene accettata. Ma anche in quel caso non hai una garanzia di indicizzazione immediata. Hai solo fatto la cosa più esplicita possibile: hai preso un URL e lo hai portato davanti a Google.
Come si fa, in pratica
- Apri Google Search Console.
- Seleziona la proprietà del sito, per esempio danielechiuri.it.
- In alto, nella barra Controllo URL, incolla l’indirizzo completo dell’articolo.
- Attendi il controllo.
- Se la pagina non è indicizzata o è appena stata modificata, clicca Richiedi indicizzazione.
Se Search Console risponde “URL sconosciuto a Google”, non è per forza un errore. Vuol dire che Google non aveva ancora scoperto quella pagina. Se invece la richiesta viene rifiutata, allora bisogna leggere il test live: potrebbe esserci un 404, un redirect sbagliato, un blocco robots, un canonical errato o un problema temporaneo di accesso.
È esattamente quello che è successo nel nostro caso: avevamo provato a inviare un URL sbagliato, che rispondeva 404. Search Console ha rifiutato la richiesta, giustamente. Corretto lo slug, l’articolo vero rispondeva 200, aveva index, follow, canonical corretto ed era presente nella sitemap.
Quando ha senso usarlo
- articoli nuovi e importanti;
- pagine aggiornate in modo sostanziale;
- correzioni SEO su pagine che prima avevano problemi;
- URL che Google ancora non conosce.
Il limite è evidente: è manuale. Se pubblichi una volta ogni tanto va benissimo. Se pubblichi spesso, o se ogni articolo nasce da script e deploy, diventa un passaggio facile da dimenticare. Per questo ha senso affiancargli un’automazione.
Metodo 2: invio della sitemap tramite Search Console API
Qui non dici a Google «leggi questo singolo URL». Gli dici: rileggi la sitemap. Nel mio caso:
https://www.danielechiuri.it/wp-sitemap.xml
WordPress aggiorna automaticamente la sitemap quando pubblichi nuovi articoli. In teoria Google la conosce già e prima o poi tornerà a leggerla. Il punto è proprio quel prima o poi: non sai quando lo farà. Può passare poco tempo, può passare di più, dipende dal sito, dalla frequenza di aggiornamento, dalla fiducia, dai link interni e da mille segnali che non controlli direttamente.
Quando invii di nuovo la sitemap tramite Search Console API non stai creando una sitemap nuova. Stai dicendo a Google: «questa sitemap è stata aggiornata, torna a guardarla». È una sollecitazione ufficiale, non una forzatura.
Se mando la sitemap a Search Console, Google riceve una notifica e può programmare una nuova scansione. La differenza rispetto all’invio manuale è che qui non punto un singolo articolo: punto l’elenco aggiornato delle URL che il sito dichiara come valide.
Questa è la strada pulita per un blog normale: non promette indicizzazione immediata, ma è coerente con le API ufficiali di Google.
L’endpoint Search Console per la sitemap
PUT https://www.googleapis.com/webmasters/v3/sites/{siteUrl}/sitemaps/{feedpath}
Serve l’autorizzazione OAuth con scope:
https://www.googleapis.com/auth/webmasters
Nel nostro caso abbiamo creato uno script PowerShell locale che invia la sitemap:
powershell -NoProfile -ExecutionPolicy Bypass -File C:danielechiurideploysubmit-sitemap-search-console.ps1
Al primo avvio lo script apre Google, chiede autorizzazione, salva un token locale e poi può essere rilanciato ogni volta che pubblichiamo o modifichiamo contenuti indicizzabili.
Metodo 3: Google Indexing API
Qui nasce la confusione. L’endpoint che spesso si vede nei plugin “instant indexing” è questo:
POST https://indexing.googleapis.com/v3/urlNotifications:publish
Il body è molto semplice:
{
"url": "https://www.example.com/articolo/",
"type": "URL_UPDATED"
}
Sembra perfetto: invio il singolo URL, Google risponde 200, problema risolto. Ma c’è un dettaglio enorme: nella documentazione ufficiale Google dice che la Indexing API è pensata per pagine con dati strutturati JobPosting oppure BroadcastEvent dentro un VideoObject.
Tradotto: offerte di lavoro e live streaming. Non articoli normali di un blog.
Molti plugin la usano lo stesso. Tecnicamente una chiamata può anche partire. Ma se stai lavorando su un sito editoriale, consulenziale o professionale, bisogna sapere che non è l’uso previsto da Google. Per questo, per danielechiuri.it, ho preferito automatizzare la sitemap con Search Console API e tenere l’invio manuale per gli articoli davvero importanti.
Nota pratica: usare un sistema di “instant indexing” e poi inviare subito a mano la stessa pagina è ridondante. Stai chiedendo due volte a Google di guardare lo stesso URL. L’invio manuale ha senso se vuoi fare un controllo live, verificare che non ci siano 404, noindex o canonical sbagliati, oppure se l’automazione non è partita. Ma come routine normale, se l’automazione funziona, non serve duplicare la richiesta.
La differenza pratica
| Metodo | Cosa fa | Quando usarlo |
|---|---|---|
| Controllo URL manuale | Chiede a Google di controllare una pagina specifica | Articoli importanti, pagine appena pubblicate |
| Search Console API sitemap | Notifica a Google la sitemap aggiornata | Dopo ogni pubblicazione o modifica SEO |
| Indexing API | Invia un URL singolo a `urlNotifications:publish` | Ufficialmente JobPosting e BroadcastEvent |
Come abbiamo configurato lo script
Il primo tentativo era usare un service account, cioè un’identità tecnica Google con una chiave JSON. Ma Google Cloud bloccava la creazione delle chiavi con una policy di sicurezza: iam.disableServiceAccountKeyCreation.
A quel punto abbiamo scelto OAuth desktop:
- Abilitata la Google Search Console API nel progetto Google Cloud.
- Creata una schermata consenso OAuth esterna in modalità test.
- Aggiunto l’account Google come utente di test.
- Creato un ID client OAuth di tipo app desktop.
- Scaricato il JSON del client OAuth.
- Salvato il JSON in una cartella locale non versionata.
- Creato uno script che apre Google, riceve il consenso e salva un refresh token.
Il file JSON non deve finire nel tema, non deve andare in produzione e non deve essere committato. È una credenziale locale.
Comando finale
Dopo un nuovo articolo o una modifica importante:
powershell -NoProfile -ExecutionPolicy Bypass -File C:danielechiurideploysubmit-sitemap-search-console.ps1
Risposta corretta:
OK sitemap inviata a Google Search Console (204)
Quel 204 significa: richiesta accettata, nessun contenuto da restituire. È normale.
Quindi cosa conviene fare davvero?
Per un blog come questo, la routine sensata è:
- Pubblico l’articolo.
- Controllo che la pagina risponda 200, sia indicizzabile e sia nella sitemap.
- Lancio lo script Search Console per inviare la sitemap aggiornata.
- Per gli articoli più importanti, faccio anche Controllo URL manuale e Richiedi indicizzazione.
Non è “instant indexing” nel senso magico del termine. È un flusso pulito: Google riceve segnali corretti, il sito resta dentro le linee guida, e io non devo ogni volta ricordarmi a mano tutti i passaggi.
Conclusione
La differenza tra API e invio manuale è questa: l’invio manuale punta una pagina precisa, la Search Console API lavora bene sulla sitemap, la Indexing API sembra la scorciatoia ma non nasce per gli articoli di un blog.
Automatizzare è utile. Automatizzare male, invece, crea l’illusione di aver “forzato Google”. Google non si forza: si aiuta. Con pagine tecnicamente pulite, sitemap aggiornata, contenuti utili e segnali coerenti.
Se vuoi configurare anche tu un flusso pulito per notificare Google dopo nuove pubblicazioni, scrivimi: spesso basta poco per togliere confusione tra API, sitemap, plugin e promesse di indicizzazione istantanea.
