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.
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 di indicizzazione, 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. L'invio tramite sitemap.xml e il classico ping non aiutano: Google e Bing non si precipitano più su di essi da tempo. L'unico modo per richiedere un'indicizzazione prioritaria in tempo reale è tramite le API ufficiali di invio diretto.
Google Indexing API: come funziona
Google espone un endpoint REST ufficiale 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, e basta. Il modulo firma un JWT RS256 con la chiave privata del Service Account, 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. La quota predefinita è di 200 URL al giorno per Service Account, sufficiente per la grande maggioranza dei negozi. Google può concedere una quota maggiore su richiesta motivata. Da notare: Google ha ufficialmente limitato l'uso di questa API alle pagine che contengono dati strutturati JobPosting o BroadcastEvent. L'API accetta comunque altri tipi e risponde 200, ma Google può ignorare l'indicizzazione reale: il modulo invia comunque per completezza, e la dashboard riflette la risposta dell'API, non la decisione finale di indicizzazione.
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). 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.
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: se il prodotto è attivo, l'URL viene accodato come URL_UPDATED, altrimenti come URL_DELETED. actionProductDelete viene chiamato all'eliminazione definitiva: URL_DELETED accodato. Per le pagine CMS: actionObjectCmsAddAfter (creazione), actionObjectCmsUpdateAfter (aggiornamento), actionObjectCmsDeleteAfter (eliminazione). Per le categorie: actionCategoryAdd, actionCategoryUpdate, actionCategoryDelete: 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.
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.
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. Vedi a colpo d'occhio se l'indicizzazione funziona e dove c'è un problema.
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.
Casi d'uso tipici
Negozio in crescita con 50 nuovi prodotti a settimana: il modulo accoda ogni creazione, il CRON invia a Google e IndexNow entro 10 minuti: i tuoi nuovi prodotti sono in SERP in poche ore invece di giorni. Negozio multilingua con catalogo di 5000 prodotti: ad ogni modifica di scheda, gli URL canonici di tutte le lingue vengono accodati e inviati: benefici del guadagno SEO 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.
Limiti noti e buone pratiche
IndexNow non gestisce URL_DELETED: il protocollo considera un 404 o 410 sull'URL come il modo corretto di segnalare una eliminazione. Il modulo ignora quindi i job IndexNow in URL_DELETED (Google li invia correttamente, supportando questo tipo di azione). La quota Google è limitata a 200 URL al giorno per Service Account per impostazione predefinita: per un negozio che modifica di più, devi richiedere un aumento a Google, o creare un secondo Service Account con la propria quota. Il modulo non invia varianti o combinazioni di prodotti: l'URL canonico del prodotto principale basta per Google, che 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.