Alles wat u wilt weten voordat u installeert.
Een gedetailleerde blik op hoe DataFirefly Indexing API: Automatische Indiening bij Google Indexing API en IndexNow (Bing, Yandex, Naver) voor PrestaShop 8 en 9 werkt, waarom we het zo gebouwd hebben en de gedachte achter de bovenstaande functies.
Het probleem: Googlebot en Bingbot komen traag langs
Dit is de blinde vlek in de vindbaarheid van elke groeiende webshop. U publiceert maandagochtend een nieuw product, en Google indexeert het pas donderdagavond. U corrigeert een typefout op een pagina, en Bing toont twee weken lang nog de oude versie. Al die tijd loopt u organisch verkeer mis, verliest u conversies, en zien uw bezoekers verouderde informatie in de zoekresultaten. Voor een winkel die per week 20 producten publiceert of aanpast, betekent dat op elk moment honderden URL's met achterstand. De XML-sitemap blijft onmisbaar: dat is het officiële ontdekkingskanaal en die moet schoon en actueel zijn. Maar hij geeft geen prioriteit, en de klassieke sitemap-ping heeft geen nut meer sinds Google dat endpoint in juni 2023 heeft afgeschaft. Om een wijziging binnen minuten in plaats van dagen te melden, is directe indiening nodig.
Google Indexing API: wat hij wel en niet doet
Google biedt een REST-endpoint op indexing.googleapis.com dat meldingen over gewijzigde of verwijderde URL's aanneemt. De authenticatie verloopt via een Google Cloud-serviceaccount: u maakt een Service Account aan, downloadt de sleutel in JSON-formaat en voegt het account als eigenaar toe aan uw Search Console-property. De module ondertekent een JWT met RS256 met de privésleutel, wisselt die JWT op oauth2.googleapis.com in voor een OAuth2-toegangstoken, houdt dat token 55 minuten in cache en gebruikt het om elke indiening te authenticeren. Wat u moet weten voordat u koopt: de documentatie van Google beperkt deze API officiële tot pagina's met gestructureerde JobPosting-gegevens, of BroadcastEvent binnen een VideoObject. Een productpagina of een categoriepagina valt in geen van beide gevallen. De API neemt de indiening toch aan en antwoordt met 200, maar die 200 betekent alleen dat de melding is ontvangen: Google beslist zelf over crawlen en indexeren. Het standaardquotum is 200 URL's per dag per serviceaccount, en een verhoging is voorbehouden aan sites die JobPosting of BroadcastEvent werkelijk gebruiken, dus een webshop moet daar niet op rekenen. De module dient in, logt de antwoordcode, en het dashboard toont het antwoord van de API, niet de indexeringsbeslissing. Zoekt u meetbare winst in indexering voor een productcatalogus, dan levert IndexNow die.
IndexNow: Bing, Yandex, Naver en Seznam in één aanroep
IndexNow is een open protocol dat Microsoft Bing en Yandex in 2021 hebben opgezet, en waar Naver (de grootste zoekmachine in Zuid-Korea) en Seznam (de klassieke zoekmachine in Tsjechië) zich sindsdien bij hebben aangesloten. Anders dan de Google-API legt IndexNow geen enkele beperking op aan het paginatype: productpagina's, categorieën en CMS-pagina's vallen er gewoon onder. Het principe: u maakt een alfanumerieke sleutel aan, publiceert die in de root van uw domein (een bestand sleutel.txt) en roept het endpoint api.indexnow.org aan met een lijst URL's. Die aanroep is gratis, onbeperkt en wordt automatisch doorgegeven aan alle deelnemende zoekmachines. Geen quotum, geen Service Account, geen OAuth: alleen een sleutel en een HTTP-aanroep. De module maakt de sleutel bij de installatie automatisch aan, biedt twee manieren om die in de root te serveren (een herschrijfregel in htaccess met een gegenereerd fragment, of een fysiek bestand), en bundelt de URL's tot 100 per aanroep om verzoeken te besparen.
De PrestaShop-hooks waarnaar geluisterd wordt
De module haakt in op de officiële hooks van de levenscyclus van PrestaShop-objecten. Voor producten: actionProductSave wordt aangeroepen bij het aanmaken en bij elke wijziging, en is het product actief dan komt de URL als URL_UPDATED in de wachtrij, anders als URL_DELETED. actionProductDelete wordt aangeroepen bij het definitief verwijderen, met URL_DELETED. Voor CMS-pagina's: actionObjectCmsAddAfter (aanmaken), actionObjectCmsUpdateAfter (wijzigen) en actionObjectCmsDeleteAfter (verwijderen). Voor categorieën: actionCategoryAdd, actionCategoryUpdate en actionCategoryDelete, waarbij de hoofdcategorieën (ID 1 en 2) uit voorzorg worden overgeslagen. Elke hook bouwt de canonieke URL op via het officiële Link-object van PrestaShop, wat de instellingen voor SEO-vriendelijke URL's, de taalvoorvoegsels en de meertalige regels respecteert.
De wachtrij: waarom en hoe
Bij elke hook meteen synchroon indienen zou op twee manieren verkeerd uitpakken: de vertraging zou de backoffice traag maken (een aanroep naar Google kan 2 tot 5 seconden duren), en een API-fout zou het opslaan van het product blokkeren. De module zet elke indiening daarom in een blijvende wachtrijtabel (df_indexapi_queue), en een CRON werkt het pakket om de paar minuten af. De ontdubbeling is daarbij wezenlijk: wijzigt u een product drie keer in een uur, dan ziet de module dat er al een job bestaat voor die combinatie (winkel, type, ID, provider, actie) en werkt hij simpelweg de URL en de datum bij, in plaats van er drie aan te maken. De logische vergrendeling van pending naar processing voorkomt dubbele verwerking wanneer twee CRON-taken tegelijk uit de wachtrij putten. En elke mislukking verhoogt de pogingenteller, wat bij de volgende CRON een nieuwe poging in gang zet tot een instelbaar maximum (standaard 5). Daarna krijgt de job de status fout en blijft hij zichtbaar in het scherm Wachtrij, met het exacte bericht dat de API teruggaf.
Het logboek en het dashboard
Elke indiening levert een regel op in de tabel df_indexapi_log: de provider (Google of IndexNow), het objecttype en het ID, de exact ingediende URL, de actie URL_UPDATED of URL_DELETED, de teruggegeven HTTP-code, een aanduiding geaccepteerd of geweigerd, het volledige antwoordbericht en de datum. Het scherm Logboek toont die gegevens in een gewone PrestaShop-HelperList met native filters (provider, HTTP-code, geaccepteerd), sortering en CSV-export. Het dashboard brengt alles samen: vijf kaarten met de tellers per status van de wachtrij, twee diagnosekaarten per provider (Google Service Account wel of niet ingesteld, IndexNow-sleutel en host wel of niet ingesteld), een tabel met het acceptatiepercentage over 30 dagen per provider met kleurcodering (groen boven 90, oranje tussen 60 en 90, rood daaronder), en een Chart.js-grafiek van de dagelijkse indieningen waarin het totaal ingediend en het totaal geaccepteerd over elkaar liggen. Lees dat als een teken van de technische gezondheid van de API-aanroepen, niet als bewijs van indexering.
De beveiliging van de CRON en het sleutelbestand
De CRON-controller staat in de storefront op een gewone PrestaShop-URL, maar is beveiligd met een willekeurig token van 32 tekens dat bij de installatie wordt aangemaakt en dat u met één klik opnieuw kunt genereren. Zonder het juiste token antwoordt de controller met 403. Er zijn drie acties: process werkt een pakket uit de wachtrij af (aan te roepen om de 5 tot 15 minuten door de cron van uw hosting), purge verwijdert verwerkte jobs en logs die ouder zijn dan de ingestelde bewaartermijn (één keer per dag), en key serveert de inhoud van het IndexNow-sleutelbestand als text/plain voor de herschrijfregel in htaccess (beveiligd doordat men de sleutel in de parameter k al moet kennen). Het exacte htaccess-fragment om in de root van PrestaShop te plakken wordt automatisch gegenereerd in het configuratiescherm, met de actuele sleutel.
Typische gebruikssituaties
Een groeiende winkel met 50 nieuwe producten per week: de module zet elke aanmaak in de wachtrij, de CRON dient binnen 10 minuten in, en Bing, Yandex, Naver en Seznam nemen de nieuwe URL's doorgaans binnen enkele uren mee. Bij Google versnelt de indiening de ontdekking, zonder garantie op een resultaat. Een meertalige winkel met een catalogus van 5.000 producten: bij elke wijziging van een pagina komen de canonieke URL's van alle talen in de wachtrij en worden ze ingediend, op al uw markten tegelijk. Een B2B-winkel met een technische catalogus die vaak wordt bijgewerkt (prijzen, voorraad, technische fiches): de ontdubbeling voorkomt dat u de API's overspoelt bij reeksen wijzigingen, met één job per product ook als u het twintig keer op een dag aanpast. Herstel van de vindbaarheid na een migratie: met een knop om alle jobs opnieuw te starten in het scherm Wachtrij dient u alles in bulk opnieuw in nadat u een configuratie- of quotumprobleem hebt opgelost.
Bekende beperkingen en goede gewoonten
Google beperkt de Indexing API officiële tot pagina's met JobPosting en BroadcastEvent, waardoor IndexNow voor een productcatalogus het hoofdkanaal van de module is. Zet IndexNow dus als eerste aan en beschouw Google als een gelogde bonus. IndexNow kent de actie URL_DELETED niet: het protocol gaat ervan uit dat een 404 of 410 op de URL de juiste manier is om een verwijdering te melden, dus slaat de module die jobs over (Google ondersteunt dat type actie wel). Het Google-quotum ligt vast op 200 URL's per dag per Service Account, en omdat een verhoging afhangt van JobPosting- of BroadcastEvent-markup moet een webshop dat plafond als definitief beschouwen: beperk het Google-filter tot nieuwe items, of maak een tweede Service Account aan met een eigen quotum. De module dient geen productvarianten of combinaties in, omdat de canonieke URL van het hoofdproduct volstaat en Google varianten vanzelf samenvoegt. En de hoofdcategorieën (ID 1 en 2) worden overgeslagen, om te voorkomen dat er irrelevante URL's worden ingediend.
Er zijn nog geen beoordelingen.