Alles, was Sie vor der Installation wissen wollen.
Ein detaillierter Blick darauf, wie DataFirefly Indexing API — Automatische Übermittlung Google Indexing API und IndexNow (Bing, Yandex, Naver) für PrestaShop 8 und 9 funktioniert, warum wir es so gebaut haben und der Gedanke hinter den Funktionen oben.
§ 01
Das Problem: Googlebot und Bingbot brauchen Zeit zum Crawlen
Es ist der SEO-Blindfleck jedes wachsenden Shops. Sie veröffentlichen am Montagmorgen ein neues Produkt und Google indiziert es erst am Donnerstagabend. Sie korrigieren einen Tippfehler in einem Listing und Bing zeigt zwei Wochen später immer noch die alte Version. Während dieser Verzögerung verlieren Sie organischen Traffic, Sie verlieren Conversions und Ihre Nutzer sehen veraltete Informationen in den Suchergebnissen. Für einen Shop, der 20 Produkte pro Woche veröffentlicht oder ändert, sind das Hunderte von URLs, die ständig hinter der Indexierung zurückliegen. Die XML-Sitemap bleibt unverzichtbar: Sie ist der offizielle Entdeckungskanal und muss sauber und aktuell bleiben. Sie verleiht jedoch keine Priorität, und das klassische Sitemap-Ping ist nutzlos, seit Google seinen Ping-Endpunkt im Juni 2023 entfernt hat. Um eine Änderung in Minuten statt in Tagen zu signalisieren, brauchen Sie die direkte Übermittlung.
§ 02
Google Indexing API: was sie leistet und was nicht
Google stellt einen REST-Endpunkt unter indexing.googleapis.com bereit, der URL-Update- oder Löschbenachrichtigungen akzeptiert. Die Authentifizierung erfolgt über einen Google-Cloud-Service-Account: Sie erstellen einen Service Account, laden seinen JSON-Schlüssel herunter und fügen ihn als Eigentümer Ihrer Search-Console-Property hinzu. Das Modul signiert ein JWT RS256 mit dem privaten Schlüssel, tauscht dieses JWT gegen ein OAuth2-Zugriffstoken bei oauth2.googleapis.com aus, speichert dieses Token 55 Minuten lang im Cache und verwendet es zur Authentifizierung jeder Übermittlung. Der Punkt, den Sie vor dem Kauf kennen sollten: Die Google-Dokumentation beschränkt diese API offiziell auf Seiten mit JobPosting-strukturierten Daten oder BroadcastEvent innerhalb eines VideoObject. Eine Produktseite oder eine Kategorieseite fällt in keinen der beiden Fälle. Die API akzeptiert die Übermittlung dennoch und antwortet mit 200, aber diese 200 bedeutet nur, dass die Benachrichtigung eingegangen ist: Über Crawling und Indexierung entscheidet allein Google. Die Standardquote beträgt 200 URLs pro Tag pro Service Account, und Quotenerhöhungen sind Websites vorbehalten, die JobPosting oder BroadcastEvent tatsächlich verwenden, ein Shop sollte also nicht damit rechnen. Das Modul übermittelt, protokolliert den Rückgabecode, und das Dashboard spiegelt die API-Antwort wider, nicht die Indexierungsentscheidung. Wenn Sie einen messbaren Indexierungsgewinn für einen Produktkatalog suchen, liefert ihn IndexNow.
§ 03
IndexNow: Bing, Yandex, Naver, Seznam in einem einzigen Aufruf
IndexNow ist ein offenes Protokoll, das 2021 von Microsoft Bing und Yandex vorangetrieben wurde, dem sich seitdem Naver (die dominierende Suchmaschine in Südkorea) und Seznam (die historische Suchmaschine in Tschechien) angeschlossen haben. Anders als die Google-API kennt IndexNow keine Beschränkung des Seitentyps: Produktseiten, Kategorien und CMS-Seiten liegen in seinem normalen Anwendungsbereich. Das Prinzip: Sie generieren einen alphanumerischen Schlüssel, veröffentlichen ihn am Root Ihrer Domain (schluessel.txt-Datei) und rufen den Endpunkt api.indexnow.org mit einer Liste zu indizierender URLs auf. Der Aufruf ist kostenlos, unbegrenzt und wird automatisch an alle teilnehmenden Suchmaschinen weiterverbreitet. Keine Quote, kein Service Account, kein OAuth: nur ein Schlüssel und ein HTTP-Aufruf. Das Modul generiert den Schlüssel automatisch bei der Installation, bietet zwei Methoden, ihn am Root bereitzustellen (.htaccess-Umschreibung mit generiertem Snippet oder physische Datei), und bündelt URLs bis zu 100 pro Aufruf, um Anfragen zu sparen.
§ 04
Die abgehörten PrestaShop-Hooks
Das Modul greift auf die offiziellen Lifecycle-Hooks der PrestaShop-Objekte zu. Für Produkte: actionProductSave wird beim Erstellen und bei jeder Änderung aufgerufen, und wenn das Produkt aktiv ist, wird die URL als URL_UPDATED eingereiht, sonst als URL_DELETED. actionProductDelete wird beim endgültigen Löschen aufgerufen, mit URL_DELETED eingereiht. Für CMS-Seiten: actionObjectCmsAddAfter (Erstellung), actionObjectCmsUpdateAfter (Aktualisierung), actionObjectCmsDeleteAfter (Löschung). Für Kategorien: actionCategoryAdd, actionCategoryUpdate, actionCategoryDelete, wobei der Kategorie-Root (ID 1 und 2) aus Sicherheitsgründen ignoriert wird. Jeder Hook erstellt die kanonische URL über das offizielle PrestaShop-Link-Objekt, was die Einhaltung der SEO-friendly-URL-Einstellungen, der Sprachpräfixe und der Mehrsprachenregeln garantiert.
§ 05
Die Warteschlange: warum und wie
Eine synchrone Übermittlung bei jedem Hook wäre doppelt schlecht: Die Latenz würde die Verwaltung verlangsamen (ein Aufruf an Google kann 2 bis 5 Sekunden dauern), und ein API-Fehler würde das Speichern von Produkten unmöglich machen. Das Modul reiht daher jede Übermittlung in eine persistente Warteschlangentabelle (df_indexapi_queue) ein, und ein CRON verarbeitet den Stapel alle paar Minuten. Die Deduplizierung ist entscheidend: Wenn Sie ein Produkt dreimal in einer Stunde ändern, erkennt das Modul, dass bereits ein Job für dieses Tupel (Shop, Typ, ID, Anbieter, Aktion) existiert, und aktualisiert einfach seine URL und sein Datum, es erstellt keine drei. Die logische Sperre pending zu processing vermeidet doppelte Verarbeitung, falls zwei parallele CRONs gleichzeitig aus der Warteschlange ziehen. Und jeder Fehler erhöht einen Wiederholungszähler, löst eine automatische Wiederholung im nächsten CRON bis zu einem konfigurierbaren Maximum (Standard 5) aus. Darüber hinaus wechselt der Job in den Fehlerzustand und bleibt im Warteschlangenbildschirm mit der genauen API-Nachricht sichtbar.
§ 06
Das Protokoll und das Dashboard
Jede Übermittlung erzeugt einen Eintrag in der Tabelle df_indexapi_log: Anbieter Google oder IndexNow, Objekttyp und ID, exakt übermittelte URL, Aktion URL_UPDATED oder URL_DELETED, zurückgegebener HTTP-Code, Akzeptiert- oder Abgelehnt-Indikator, vollständige Antwortnachricht und Datum. Der Log-Bildschirm zeigt diese Daten in einem Standard-PrestaShop-HelperList mit nativen Filtern (Anbieter, HTTP-Code, akzeptiert), Sortierung und CSV-Export. Das Dashboard aggregiert alles: fünf Karten für die Warteschlangen-Statuszähler, zwei Anbieterdiagnose-Karten (Google Service Account konfiguriert oder nicht, IndexNow-Schlüssel und Host konfiguriert oder nicht), eine 30-Tage-Akzeptanzraten-Tabelle pro Anbieter mit semantischer Färbung (Grün über 90, Orange zwischen 60 und 90, Rot darunter) und ein Chart.js-Diagramm täglicher Übermittlungen, das insgesamt übermittelte und insgesamt akzeptierte überlagert. Lesen Sie es als Indikator für die technische Gesundheit der API-Aufrufe, nicht als Nachweis der Indexierung.
§ 07
Sicherheit des CRON und der Schlüsseldatei
Der CRON-Controller wird auf einer Standard-PrestaShop-Frontend-URL exponiert, aber durch ein 32-Zeichen-Zufalls-Token geschützt, das bei der Installation generiert und mit einem Klick aus der Konfiguration erneuerbar ist. Ohne das richtige Token antwortet der Controller mit 403. Drei Aktionen werden unterstützt: process verarbeitet einen Warteschlangen-Stapel (alle 5 bis 15 Minuten durch Ihren Host-CRON aufzurufen), purge löscht Jobs und Logs, die über die konfigurierte Aufbewahrung hinaus verarbeitet wurden (einmal täglich aufzurufen), und key stellt den Inhalt der IndexNow-Schlüsseldatei als text/plain für die .htaccess-Umschreibung bereit (geschützt durch Vorabkenntnis des Schlüssels im k-Parameter). Das genaue .htaccess-Snippet zum Einfügen am PrestaShop-Root wird automatisch auf der Konfigurationsseite mit dem aktuellen Schlüssel generiert.
§ 08
Typische Anwendungsfälle
Wachsender Shop mit 50 neuen Produkten pro Woche: Das Modul reiht jede Erstellung ein, der CRON übermittelt innerhalb von 10 Minuten, und Bing, Yandex, Naver und Seznam berücksichtigen die neuen URLs in der Regel innerhalb weniger Stunden. Auf Google-Seite beschleunigt die Übermittlung die Entdeckung ohne Erfolgsgarantie. Mehrsprachiger Shop mit Katalog von 5000 Produkten: Bei jeder Listing-Änderung werden die kanonischen URLs aller Sprachen eingereiht und übermittelt, auf allen Ihren Märkten gleichzeitig. B2B-Shop mit häufig aktualisiertem technischen Katalog (Preise, Bestände, technische Datenblätter): Die Deduplizierung vermeidet das Spammen der APIs bei Änderungs-Ausbrüchen, ein einziger Job pro Produkt, selbst wenn Sie es zwanzigmal an einem Tag ändern. SEO-Wiederherstellung nach Migration: Ein Alle Jobs wiederholen-Button im Warteschlangenbildschirm ermöglicht eine erneute Massenübermittlung nach Lösung eines Konfigurations- oder Quotenproblems.
§ 09
Bekannte Einschränkungen und Best Practices
Google beschränkt die Indexing API offiziell auf JobPosting- und BroadcastEvent-Seiten, wodurch IndexNow bei einem Produktkatalog der Hauptkanal des Moduls ist. Aktivieren Sie IndexNow zuerst und behandeln Sie Google als protokollierte Zugabe. IndexNow handhabt URL_DELETED nicht: Das Protokoll betrachtet einen 404 oder 410 auf der URL als korrekten Weg, eine Löschung zu signalisieren, das Modul ignoriert diese Jobs also (Google unterstützt diesen Aktionstyp sehr wohl). Die Google-Quote ist auf 200 URLs pro Tag pro Service Account begrenzt, und da Quotenerhöhungen an vorhandenes JobPosting- oder BroadcastEvent-Markup geknüpft sind, sollte ein Shop diese Grenze als endgültig betrachten: Beschränken Sie den Google-Filter auf Neuheiten, oder erstellen Sie einen zweiten Service Account mit eigener Quote. Das Modul übermittelt keine Produktvarianten oder -kombinationen, da die kanonische URL des Hauptprodukts ausreicht und Google Varianten natürlich konsolidiert. Und der Kategorie-Root (ID 1 und 2) wird ignoriert, um die Übermittlung nicht relevanter URLs zu vermeiden.
Es gibt noch keine Rezensionen.