Tutto quello che vorresti sapere prima di installare.
Uno sguardo dettagliato su come funziona DataFirefly Indexing API — Invio automatico Google Indexing API e IndexNow (Bing, Yandex, Naver) per PrestaShop 8 e 9, perché l'abbiamo progettato così, e il ragionamento dietro le funzionalità qui sopra.
§ 01
Il problema: Googlebot e Bingbot impiegano tempo per fare crawling
È il punto cieco SEO di ogni negozio in crescita. Pubblichi un nuovo prodotto lunedì mattina e Google non lo indicizza fino a giovedì sera. Correggi un refuso in una scheda e Bing mostra ancora la vecchia versione due settimane dopo. Durante quel ritardo, perdi traffico organico, perdi conversioni, e i tuoi utenti vedono informazioni obsolete nei risultati di ricerca. Per un negozio che pubblica o modifica 20 prodotti a settimana, sono centinaia di URL perpetuamente in ritardo. La sitemap XML resta indispensabile: è il canale di scoperta ufficiale e deve restare pulita e aggiornata. Ma non conferisce alcuna priorità, e il classico ping della sitemap non serve più da quando Google ha rimosso il suo endpoint di ping a giugno 2023. Per segnalare una modifica in minuti anziché in giorni, serve l'invio diretto.
§ 02
Google Indexing API: cosa fa e cosa non fa
Google espone un endpoint REST all'URL indexing.googleapis.com che accetta notifiche di aggiornamento o eliminazione di URL. L'autenticazione è tramite un Service Account Google Cloud: crei un Service Account, scarichi la sua chiave in formato JSON, lo aggiungi come proprietario della tua proprietà Search Console. Il modulo firma un JWT RS256 con la chiave privata, scambia quel JWT contro un token di accesso OAuth2 su oauth2.googleapis.com, mantiene quel token in cache per 55 minuti, e lo usa per autenticare ogni invio. Il punto da conoscere prima di acquistare: la documentazione Google limita ufficialmente questa API alle pagine che contengono dati strutturati JobPosting, oppure BroadcastEvent integrato in un VideoObject. Una scheda prodotto o una pagina categoria non rientra in nessuno dei due casi. L'API accetta comunque l'invio e risponde 200, ma quel 200 significa solo che la notifica è stata ricevuta: su crawling e indicizzazione decide unicamente Google. La quota predefinita è di 200 URL al giorno per Service Account, e l'aumento di quota è riservato ai siti che usano effettivamente JobPosting o BroadcastEvent, quindi un negozio non deve contarci. Il modulo invia, registra il codice di ritorno, e la dashboard riflette la risposta dell'API, non la decisione di indicizzazione. Se cerchi un guadagno di indicizzazione misurabile su un catalogo prodotti, è IndexNow a fornirlo.
§ 03
IndexNow: Bing, Yandex, Naver, Seznam in una sola chiamata
IndexNow è un protocollo aperto promosso da Microsoft Bing e Yandex nel 2021, al quale si sono uniti Naver (il motore dominante in Corea del Sud) e Seznam (il motore storico in Repubblica Ceca). A differenza dell'API Google, IndexNow non impone alcuna restrizione sul tipo di pagina: schede prodotto, categorie e pagine CMS rientrano nel suo perimetro normale. Il principio: generi una chiave alfanumerica, la pubblichi alla radice del tuo dominio (file chiave.txt), e chiami l'endpoint api.indexnow.org con una lista di URL da indicizzare. La chiamata è gratuita, illimitata, e propagata automaticamente a tutti i motori partecipanti. Nessuna quota, nessun Service Account, nessun OAuth: solo una chiave e una chiamata HTTP. Il modulo genera la chiave automaticamente all'installazione, offre due metodi per servirla alla radice (riscrittura .htaccess con snippet generato, o file fisico), e raggruppa gli URL fino a 100 per chiamata per risparmiare richieste.
§ 04
Gli hook PrestaShop ascoltati
Il modulo si aggancia agli hook ufficiali del ciclo di vita degli oggetti PrestaShop. Per i prodotti: actionProductSave viene chiamato alla creazione e ad ogni modifica, e se il prodotto è attivo l'URL viene accodato come URL_UPDATED, altrimenti come URL_DELETED. actionProductDelete viene chiamato all'eliminazione definitiva, con URL_DELETED accodato. Per le pagine CMS: actionObjectCmsAddAfter (creazione), actionObjectCmsUpdateAfter (aggiornamento), actionObjectCmsDeleteAfter (eliminazione). Per le categorie: actionCategoryAdd, actionCategoryUpdate, actionCategoryDelete, con la radice di categoria (ID 1 e 2) ignorata per sicurezza. Ogni hook costruisce l'URL canonico tramite l'oggetto Link ufficiale di PrestaShop, il che garantisce il rispetto delle preferenze SEO friendly URL, dei prefissi di lingua e delle regole multilingua.
§ 05
La coda: perché e come
Inviare in modo sincrono ad ogni hook sarebbe doppiamente sbagliato: la latenza rallenterebbe l'amministrazione (una chiamata a Google può richiedere da 2 a 5 secondi), e un fallimento API renderebbe impossibile salvare il prodotto. Il modulo accoda quindi ogni invio in una tabella di coda persistente (df_indexapi_queue) e un CRON elabora il lotto ogni pochi minuti. La deduplica è cruciale: se modifichi un prodotto tre volte in un'ora, il modulo riconosce che esiste già un job per quella tupla (negozio, tipo, ID, provider, azione) e aggiorna semplicemente il suo URL e la sua data, non ne crea tre. Il blocco logico pending a processing evita la doppia elaborazione se due CRON paralleli prendono dalla coda contemporaneamente. E ogni fallimento incrementa un contatore di tentativi, attivando un ritentativo automatico al CRON successivo fino a un massimo configurabile (predefinito 5). Oltre, il job passa allo stato errore e rimane visibile nella schermata Coda con il messaggio esatto dell'API.
§ 06
Il registro e la dashboard
Ogni invio produce una voce nella tabella df_indexapi_log: provider Google o IndexNow, tipo e ID dell'oggetto, URL esatto inviato, azione URL_UPDATED o URL_DELETED, codice HTTP restituito, indicatore accettato o rifiutato, messaggio completo di risposta e data. La schermata Registro espone questi dati in un HelperList standard PrestaShop con filtri nativi (provider, codice HTTP, accettato), ordinamento ed esportazione CSV. La Dashboard aggrega tutto: cinque card per i contatori di stato della coda, due card di diagnostica provider (Service Account Google configurato o no, chiave e host IndexNow configurati o no), una tabella di tasso di accettazione a 30 giorni per provider con colorazione semantica (verde sopra 90, arancione tra 60 e 90, rosso sotto), e un grafico Chart.js degli invii giornalieri che sovrappone totale inviato e totale accettato. Va letta come un indicatore della salute tecnica delle chiamate API, non come una prova di indicizzazione.
§ 07
Sicurezza del CRON e file chiave
Il controller CRON è esposto su un URL frontend standard PrestaShop, ma protetto da un token casuale di 32 caratteri generato all'installazione e rigenerabile con un clic dalla configurazione. Senza il token corretto, il controller risponde 403. Sono supportate tre azioni: process elabora un lotto della coda (da chiamare ogni 5 a 15 minuti dal tuo CRON di hosting), purge elimina job e log elaborati oltre la ritenzione configurata (da chiamare una volta al giorno), e key serve il contenuto del file chiave IndexNow come text/plain per la riscrittura .htaccess (protetto dalla conoscenza preventiva della chiave nel parametro k). Lo snippet .htaccess esatto da incollare alla radice di PrestaShop è generato automaticamente nella pagina Configurazione con la chiave attuale.
§ 08
Casi d'uso tipici
Negozio in crescita con 50 nuovi prodotti a settimana: il modulo accoda ogni creazione, il CRON invia entro 10 minuti, e Bing, Yandex, Naver e Seznam prendono generalmente in carico i nuovi URL nelle ore successive. Sul lato Google, l'invio accelera la scoperta senza garanzia di risultato. Negozio multilingua con catalogo di 5000 prodotti: ad ogni modifica di scheda, gli URL canonici di tutte le lingue vengono accodati e inviati, su tutti i tuoi mercati contemporaneamente. Negozio B2B con catalogo tecnico aggiornato frequentemente (prezzi, scorte, schede tecniche): la deduplica evita di saturare le API in raffiche di modifiche, un solo job per prodotto anche se lo modifichi venti volte in un giorno. Recupero SEO dopo migrazione: un pulsante Rilancia tutti i job nella schermata Coda permette di reinviare in blocco dopo aver risolto un problema di configurazione o di quota.
§ 09
Limiti noti e buone pratiche
Google riserva ufficialmente l'Indexing API alle pagine JobPosting e BroadcastEvent, il che rende IndexNow il canale principale del modulo per un catalogo prodotti. Attiva IndexNow per primo e considera Google un extra registrato. IndexNow non gestisce URL_DELETED: il protocollo considera un 404 o 410 sull'URL come il modo corretto di segnalare una eliminazione, quindi il modulo ignora questi job (Google, invece, supporta questo tipo di azione). La quota Google è limitata a 200 URL al giorno per Service Account, e poiché l'aumento di quota è condizionato alla presenza di markup JobPosting o BroadcastEvent, un negozio deve considerare questo tetto come definitivo: restringi il filtro Google alle novità, oppure crea un secondo Service Account con la propria quota. Il modulo non invia varianti o combinazioni di prodotti, dato che l'URL canonico del prodotto principale basta e Google consolida naturalmente le varianti. E la radice di categoria (ID 1 e 2) viene ignorata per evitare di inviare URL non pertinenti.
Ancora non ci sono recensioni.