Alles, was Sie wissen sollten bevor Sie installieren.
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.
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 Indexierungsverzö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 Übermittlung über sitemap.xml und das klassische Ping helfen nicht: Google und Bing stürzen sich schon lange nicht mehr darauf. Der einzige Weg, in Echtzeit prioritäre Indexierung anzufordern, sind die offiziellen direkten Übermittlungs-APIs.
Google Indexing API: wie es funktioniert
Google stellt einen offiziellen 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, fügen ihn als Eigentümer Ihrer Search-Console-Property hinzu, und das war's. Das Modul signiert ein JWT RS256 mit dem privaten Schlüssel des Service Account, 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. Die Standardquote beträgt 200 URLs pro Tag pro Service Account, was die große Mehrheit der Shops abdeckt. Google kann auf begründeten Antrag eine höhere Quote gewähren. Beachten Sie: Google hat die Nutzung dieser API offiziell auf Seiten beschränkt, die JobPosting- oder BroadcastEvent-strukturierte Daten enthalten. Die API akzeptiert dennoch andere Typen und antwortet mit 200, aber Google kann die tatsächliche Indexierung ignorieren: Das Modul übermittelt trotzdem zur Vollständigkeit, und das Dashboard spiegelt die API-Antwort wider, nicht die endgültige Indexierungsentscheidung.
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. 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.
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: Wenn das Produkt aktiv ist, wird die URL als URL_UPDATED eingereiht, sonst als URL_DELETED. actionProductDelete wird beim endgültigen Löschen aufgerufen: URL_DELETED eingereiht. Für CMS-Seiten: actionObjectCmsAddAfter (Erstellung), actionObjectCmsUpdateAfter (Aktualisierung), actionObjectCmsDeleteAfter (Löschung). Für Kategorien: actionCategoryAdd, actionCategoryUpdate, actionCategoryDelete: der Kategorie-Root (ID 1 und 2) wird aus Sicherheitsgründen ignoriert. 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.
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.
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. Sie sehen auf einen Blick, ob die Indexierung läuft und wo es klemmt.
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.
Typische Anwendungsfälle
Wachsender Shop mit 50 neuen Produkten pro Woche: Das Modul reiht jede Erstellung ein, der CRON übermittelt innerhalb von 10 Minuten an Google und IndexNow: Ihre neuen Produkte sind innerhalb von Stunden statt Tagen in SERP. Mehrsprachiger Shop mit Katalog von 5000 Produkten: Bei jeder Listing-Änderung werden die kanonischen URLs aller Sprachen eingereiht und übermittelt: Sie profitieren gleichzeitig vom SEO-Gewinn auf allen Ihren Märkten. 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 Massen-Wiedervermögnung nach Lösung eines Konfigurations- oder Quotenproblems.
Bekannte Einschränkungen und Best Practices
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 daher IndexNow-Jobs in URL_DELETED (Google übermittelt sie ordnungsgemäß, da es diesen Aktionstyp unterstützt). Die Google-Quote ist standardmäßig auf 200 URLs pro Tag pro Service Account begrenzt: Für einen Shop, der mehr ändert, müssen Sie entweder eine Erhöhung bei Google beantragen oder einen zweiten Service Account mit eigener Quote erstellen. Das Modul übermittelt keine Produktvarianten oder -kombinationen: Die kanonische URL des Hauptprodukts reicht für Google, das 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.