Google Indexing API für Magento 2 - Installation und Konfiguration

1. Wichtige Informationen vor der Implementierung

Das Modul integriert Magento 2 mit der Google Indexing API und ermöglicht das Hinzufügen von URLs zu einer zentralen Meldungswarteschlange. Die Warteschlange wird durch den Magento-Cron verarbeitet, und jede Meldung wird validiert, dedupliziert, mit Limits versehen und protokolliert.

Gemäß der Google-Dokumentation ist die Indexing API offiziell in erster Linie für Seiten mit strukturierten Daten vorgesehen:

• JobPosting,
• BroadcastEvent, eingebettet in VideoObject.

Die Nutzung der API für Produkte, Kategorien, CMS-Seiten oder Blogbeiträge garantiert weder die Indexierung noch die Platzierung in den Suchergebnissen. Das Modul sollte als technisches Werkzeug zur Übermittlung von URLs betrachtet werden und nicht als Ersatz für XML-Sitemap, korrekte Canonicals, robots, hreflang, interne Verlinkung und die allgemeine SEO-Qualität.

Offizielle Google-Materialien:

• https://developers.google.com/search/apis/indexing-api/v3/quickstart
• https://developers.google.com/search/apis/indexing-api/v3/prereqs
• https://developers.google.com/search/apis/indexing-api/v3/using-api
• https://developers.google.com/search/apis/indexing-api/v3/quota-pricing

2. Anforderungen

Stellen Sie vor der Installation sicher, dass die Umgebung die folgenden Anforderungen erfüllt:

• Magento 2.4.x,
• PHP 8.1 oder neuer,
• Composer,
• funktionsfähiger Magento-Cron,
• Möglichkeit zur Installation des Pakets google/apiclient,
• Adminzugang zu Magento,
• Google Cloud-Projekt mit aktivierter Indexing API,
• in Google Search Console verifizierte Property für die Shop-Domain,
• Google-Servicekonto als Inhaber in Google Search Console hinzugefügt.

Das Modul erfordert das Paket:

google/apiclient:^2.16

Das Paket ist in der composer.json des Moduls deklariert, daher sollte Composer es automatisch installieren.

3. Installation des Moduls

3.1. Installation über Composer aus einem VCS-Repository

Wenn das Modul aus einem privaten oder öffentlichen Git-Repository installiert wird, fügen Sie das Repository dem Magento-Projekt hinzu:

composer config repositories.kowal.google.indexing.api vcs https://github.com/kowalco/google-indexing-api

Wenn das Repository privat ist, konfigurieren Sie ein GitHub-Token:

composer config --global --auth github-oauth.github.com 

Installieren Sie das Paket:

composer require kowal/module-google-indexing-api

Aktivieren Sie das Modul:

bin/magento module:enable Kowal_GoogleIndexingApi

Führen Sie das Datenbank-Schema-Upgrade aus:

bin/magento setup:upgrade

Leeren Sie den Cache:

bin/magento cache:flush

Im Produktionsmodus führen Sie zusätzlich aus:

bin/magento setup:di:compilebin/magento setup:static-content:deploybin/magento cache:flush

3.2. Lokale Installation in app/code

Wenn das Modul ohne Composer als lokaler Code installiert wird, platzieren Sie es im Verzeichnis:

app/code/Kowal/GoogleIndexingApi

Installieren Sie anschließend die Abhängigkeit Google API Client im Magento-Projekt nach:

composer require google/apiclient:^2.16

Aktivieren Sie das Modul und führen Sie die Standard-Magento-Befehle aus:

bin/magento module:enable Kowal_GoogleIndexingApibin/magento setup:upgradebin/magento cache:flush

Für Produktion:

bin/magento setup:di:compilebin/magento setup:static-content:deploybin/magento cache:flush

3.3. Installationsprüfung

Prüfen Sie, ob das Modul aktiv ist:

bin/magento module:status Kowal_GoogleIndexingApi

Nach erfolgreicher Installation sollten im Adminpanel verfügbar sein:

• Stores > Configuration > Kowal > Google Indexing API,
• das Admin-Menü Google Indexing API > Indexing Queue,
• Google Indexing API > Import URLs,
• Google Indexing API > API Logs,
• Google Indexing API > Setup Assistant.

In der Datenbank sollten folgende Tabellen erstellt werden:

• kowal_google_indexing_queue,
• kowal_google_indexing_api_log.

4. Vorbereitung von Google Cloud und Search Console

4.1. Erstellen eines Google Cloud-Projekts

1. Öffnen Sie die Google Cloud Console.
2. Erstellen Sie ein neues Projekt oder wählen Sie ein bestehendes Projekt, das für den Shop verwendet wird.
3. Aktivieren Sie die API:

Indexing API

Ohne aktivierte API kann das Modul keine Meldungen korrekt versenden.

4.2. Erstellen eines Servicekontos

1. Gehen Sie in Google Cloud zu IAM & Admin > Service Accounts.
2. Erstellen Sie ein neues Servicekonto.
3. Generieren Sie einen Schlüssel im JSON-Format.
4. Laden Sie die JSON-Datei herunter und bewahren Sie sie sicher auf.

Das Modul verlangt, dass das JSON mindestens die Felder enthält:

• type,
• project_id,
• private_key,
• client_email.

Das Feld type muss den Wert haben:

service_account

4.3. Servicekonto als Inhaber in Search Console hinzufügen

1. Öffnen Sie Google Search Console.
2. Wählen Sie die Property aus, die der Shop-Domain entspricht.
3. Stellen Sie sicher, dass die Property verifiziert ist.
4. Fügen Sie die Adresse client_email aus der JSON-Datei als Inhaber der Property hinzu.

Beispiel einer Servicekonto-Adresse:

my-service-account@project-name.iam.gserviceaccount.com

Wenn das Servicekonto nicht Inhaber der Search-Console-Property ist, kann Google Berechtigungsfehler zurückgeben, zum Beispiel fehlende Bestätigung des URL-Eigentums.

5. Konfiguration des Moduls in Magento

Die Konfiguration befindet sich unter:

Stores > Configuration > Kowal > Google Indexing API

Die Konfiguration unterstützt Magento-Scopes:

• Default Config,
• Website,
• Store View.

Dadurch können bei Bedarf separate Einstellungen für verschiedene Shops oder Store Views verwendet werden.

6. Abschnitt General

Enable

Standardmäßig:

No

Aktiviert oder deaktiviert die Funktion des Moduls.

Wenn das Feld den Wert No hat, verarbeitet der Cron die Warteschlange nicht. Adressen können in der Datenbank vorhanden sein, aber der Warteschlangen-Prozessor sendet sie nicht an Google.

Empfehlung:

• Setzen Sie bei der ersten Konfiguration No oder lassen Sie Dry Run = Yes,
• setzen Sie nach erfolgreichen Tests Yes.

Dry Run

Standardmäßig:

Yes

Testmodus. Wenn Dry Run aktiviert ist, verarbeitet das Modul Warteschlangen-Datensätze, speichert Status und Logs, sendet aber keine echte Meldung an Google.

Das ist der sicherste Modus für den ersten Start, Konfigurationstests und die Prüfung, ob URLs wie erwartet in die Warteschlange gelangen.

Empfehlung:

• Führen Sie die ersten Tests immer mit Dry Run = Yes durch,
• deaktivieren Sie Dry Run erst nach Prüfung von credentials, allowed hosts, Warteschlange und Logs.

7. Abschnitt Google Access Credentials

Credentials Source

Standardmäßig:

Encrypted configuration value

Bestimmt, woher das Modul das JSON des Google-Servicekontos bezieht.

Verfügbare Optionen:

Empfehlung:

• für einfache Implementierungen kann der verschlüsselte Wert in der Konfiguration verwendet werden,
• für Umgebungen mit Dateizugriffskontrolle kann der Upload einer JSON-Datei bequemer sein.

Service Account JSON

Sichtbar, wenn Credentials Source = Encrypted configuration value.

In dieses Feld muss der vollständige Inhalt der JSON-Datei des Google-Servicekontos eingefügt werden.

Das Modul validiert das JSON vor dem Speichern. Geprüft werden:

• Korrektheit des JSON-Formats,
• Vorhandensein der Felder type, project_id, private_key, client_email,
• der Wert type = service_account.

Der Wert wird als verschlüsselte Magento-Konfiguration gespeichert.

Service Account JSON File

Sichtbar, wenn Credentials Source = Uploaded JSON file.

Ermöglicht das Hochladen der JSON-Datei des Google-Servicekontos.

Das Modul:

• akzeptiert nur Dateien mit der Erweiterung .json,
• validiert den Dateiinhalt,
• prüft die erforderlichen Felder type, project_id, private_key, client_email,
• speichert die Datei außerhalb des öffentlichen Verzeichnisses in var/google-indexing,
• versucht, die Dateiberechtigungen auf 0600 zu setzen, sofern der Dateitreiber dies erlaubt.

Die Datei wird mit einem vom Konfigurations-Scope abhängigen Namen gespeichert, zum Beispiel für den globalen Scope:

var/google-indexing/service-account-default-0.json

Google Cloud Project ID

Textfeld für die Kennung des Google Cloud-Projekts.

In der aktuellen Implementierung des Moduls basiert die Hauptautorisierung auf den Daten aus dem JSON des Servicekontos. Das Feld Google Cloud Project ID dient einer informativen und ordnenden Funktion in der Konfiguration, besonders wenn der Shop mehrere Umgebungen oder mehrere Google Cloud-Projekte nutzt.

Empfehlung:

• tragen Sie den Wert project_id aus der JSON-Datei ein,
• verwenden Sie separate Google Cloud-Projekte für Produktions- und Testumgebungen, falls diese Trennung im Projekt vorgesehen ist.

8. Abschnitt Queue and Limits

Daily Publish Limit

Standardmäßig:

200

Bestimmt die maximale Anzahl an Publish-Meldungen, die das Modul pro Tag ausführen darf.

Der Limiter zählt Requests des Typs:

• publish,
• publish_dry_run.

Wenn das Limit ausgeschöpft ist, ruft der Warteschlangen-Prozessor bis zum nächsten Tagesfenster keine weiteren Datensätze zum Versand ab.

Empfehlung:

• belassen Sie 200, wenn das Projekt das standardmäßige Onboarding-Limit von Google nutzt,
• erhöhen Sie den Wert nur dann, wenn für das Google Cloud-Projekt ein höheres Limit genehmigt wurde,
• die Einstellung 0 blockiert den Versand, da die Anzahl verfügbarer Slots dann 0 beträgt.

Requests Per Minute Limit

Standardmäßig:

60

Bestimmt die maximale Anzahl an Publish-Requests pro Minute.

Das Modul vergleicht diesen Wert mit der Anzahl der in den Logs gespeicherten Requests aus der letzten Minute. Wenn das Minutenlimit ausgeschöpft ist, verarbeitet der Cron in diesem Lauf keine weiteren Datensätze.

Empfehlung:

• für eine typische Implementierung den Standardwert beibehalten,
• den Wert reduzieren, wenn Sie die API konservativer belasten möchten,
• 0 nur setzen, wenn Sie den Versand vorübergehend stoppen möchten.

Cron Batch Size

Standardmäßig:

20

Bestimmt die maximale Anzahl an Warteschlangen-Datensätzen, die in einem Cron-Lauf verarbeitet werden.

Die tatsächliche Zahl der verarbeiteten Datensätze wird zusätzlich begrenzt durch:

• Daily Publish Limit,
• Requests Per Minute Limit,
• die Anzahl versandbereiter Datensätze,
• Status und Datum von scheduled_at.

Empfehlung:

• 20 ist ein sicherer Startwert,
• bei großen Warteschlangen kann der Wert erhöht werden, jedoch nur unter Berücksichtigung der Google-Limits.

Default Indexing Lag minutes

Standardmäßig:

15

Bestimmt die Standardverzögerung zwischen dem Hinzufügen einer URL zur Warteschlange und dem Zeitpunkt, ab dem sie gesendet werden darf.

Die Verzögerung hilft dabei:

• Duplikate zu reduzieren,
• den Versand nach jeder kleinen Änderung zu vermeiden,
• dem Administrator Zeit zur Korrektur von Inhalten zu geben,
• das API-Limit besser zu verwalten.

In der aktuellen Implementierung wird diese Einstellung verwendet, wenn die Meldung keine eigene Verzögerung hat.

Manual Form Indexing Lag minutes

Standardmäßig:

15

Bestimmt die Verzögerung für URLs, die über das Formular hinzugefügt wurden:

Google Indexing API > Import URLs

Wenn der Administrator eine URL-Liste manuell einfügt, wird jede gültige Adresse mit dieser Verzögerung eingeplant.

Empfehlung:

• setzen Sie 0, wenn der manuelle Import sofort in die Warteschlange gelangen soll,
• belassen Sie 15, wenn Sie einen Puffer für Deduplizierung und Meldungskontrolle beibehalten möchten.

Mass Action Indexing Lag minutes

Standardmäßig:

15

Bestimmt die Verzögerung für URLs, die hinzugefügt wurden über:

• Massenaktionen für Produkte,
• Massenaktionen für CMS-Seiten,
• Buttons zur Meldung der Indexierung auf den Bearbeitungsseiten von Produkt, Kategorie und CMS-Seite.

Empfehlung:

• für Massenoperationen den Wert 15 oder höher beibehalten,
• für kleine Shops und manuelle Admin-Arbeit kann ein niedrigerer Wert erwogen werden.

Max Attempts

Standardmäßig:

5

Bestimmt die maximale Anzahl an Versandversuchen für einen Warteschlangen-Datensatz.

Wenn Google einen temporären Fehler zurückgibt, setzt das Modul den Status retry, sofern die Anzahl der Versuche kleiner ist als Max Attempts. Nach Überschreiten des Limits erhält der Datensatz den Status failed_permanent.

Als temporär behandelte Fehler:

• 408,
• 409,
• 412,
• 429,
• 500,
• 502,
• 503,
• 504.

Retry Delay minutes

Standardmäßig:

15

Grundverzögerung vor dem nächsten Versandversuch nach einem temporären Fehler.

Der Cron verwendet eine ansteigende Verzögerung. Der Multiplikator hängt von der Anzahl der Versuche ab und ist auf maximal 24 begrenzt. Dadurch werden weitere Versuche nicht zu aggressiv ausgeführt.

Beispiel für den Wert 15:

Allowed Source Types

Standardmäßig:

manual,product,category,cms_page,amasty_blog_post

Liste zulässiger Quelltypen, durch Kommas getrennt.

Unterstützte Werte:

Wenn der Quelltyp nicht in der Liste enthalten ist, überspringt der Scheduler die Meldung und markiert sie als skipped.

Empfehlung:

• behalten Sie die Standardwerte bei, wenn der Shop alle üblichen Quellen nutzt,
• entfernen Sie Quellen, die Sie nicht für die Warteschlange zulassen möchten.

Allowed URL Hosts

Standardmäßig:

leer

Liste zulässiger URL-Hosts, durch Kommas getrennt.

Beispiel:

example.com,www.example.com

Wenn die Liste ausgefüllt ist, akzeptiert das Modul nur Adressen, die zu den angegebenen Hosts gehören. Wenn eine URL einen anderen Host hat, gibt die Validierung den Fehler zurück:

host_not_allowed

Empfehlung:

• füllen Sie diese Liste in der Produktion immer aus,
• fügen Sie alle vom Shop genutzten Hosts hinzu, zum Beispiel die Hauptdomain, die www-Version, Store-View-Domains und Sprachdomains,
• fügen Sie keine Testdomains in die Produktionskonfiguration ein.

Require HTTPS URLs

Standardmäßig:

Yes

Erzwingt, dass gemeldete URLs das Schema https verwenden.

Wenn das Feld aktiviert ist, wird eine Adresse mit http mit folgendem Fehler abgelehnt:

https_required

Empfehlung:

• für produktive Shops Yes beibehalten,
• No nur in Ausnahmefällen in Testumgebungen verwenden.

9. Abschnitt Auto-Indexing

Enable Auto-Indexing

Standardmäßig:

No

Das Feld ist für automatische Integrationen beim Speichern oder Löschen von Entitäten sowie für zusätzliche URL-Provider vorbereitet.

Im aktuellen Umfang des Moduls stehen manuelle und administrative Mechanismen zum Hinzufügen von URLs zur Warteschlange zur Verfügung, darunter URL-Import, Mass Actions und Buttons auf Bearbeitungsformularen.

Empfehlung:

• belassen Sie No, wenn Auto-Indexing im Projekt nicht implementiert wurde,
• aktivieren Sie es erst dann, wenn das Projekt die Verarbeitung automatischer Entitätsereignisse enthält, die diese Konfiguration nutzt.

10. Abschnitt Logs

API Log Retention Days

Standardmäßig:

90

Bestimmt die Anzahl der Tage, für die API-Logs aufbewahrt werden.

Der Cron zum Bereinigen der Logs läuft täglich um:

03:15

Er entfernt Einträge, die älter sind als die in diesem Feld angegebene Anzahl an Tagen.

Empfehlung:

• 90 Tage sind ein sinnvoller diagnostischer Wert,
• bei einer großen Anzahl von Requests kann die Retention reduziert werden,
• bei SEO-Audits kann die Retention erhöht werden, wobei die Größe der Log-Tabelle zu berücksichtigen ist.

11. Installations- und Konfigurationsassistent

Der Assistent befindet sich unter:

Google Indexing API > Setup Assistant

Sein Ziel ist die schnelle Prüfung, ob die Konfiguration auf Magento- und Google-Seite für den ersten Test bereit ist.

11.1. Abschnitt Current Status

Der Assistent zeigt den aktuellen Status der wichtigsten Elemente an:

Wenn Credentials den Status Missing or invalid hat, sollten Sie zur Konfiguration zurückkehren und das JSON oder die credentials-Datei korrigieren.

Wenn Allowed Hosts den Status Not configured anzeigt, begrenzt das Modul keine Hosts. Technisch kann das funktionieren, für produktive Umgebungen wird jedoch empfohlen, die Shop-Hosts explizit einzutragen.

11.2. Abschnitt Setup Steps

Der Assistent zeigt eine Liste der Schritte an, die vor dem ersten echten Request erforderlich sind:

1. Erstellen oder Auswählen eines Google Cloud-Projekts.
2. Aktivieren der Indexing API und Erstellen eines JSON-Schlüssels für das Servicekonto.
3. Einfügen des JSON oder Hochladen der JSON-Datei in die Magento-Konfiguration.
4. Hinzufügen der Service Account Email als Inhaber in Google Search Console.
5. Ausführen von Tests und anschließend Import einer URL bei aktiviertem Dry Run.

Der Assistent enthält Links zu:

• Google Cloud für die Indexing API,
• der Modulkonfiguration in Magento,
• Google Search Console.

11.3. Test Google Credentials

Der Button:

Test Google Credentials

prüft, ob Magento die Daten des Servicekontos verwenden kann, um ein OAuth-Token für den Scope zu erhalten:

https://www.googleapis.com/auth/indexing

Ein positives Ergebnis bedeutet, dass:

• das JSON korrekt ist,
• der private Schlüssel verwendet werden kann,
• Google ein OAuth-Token ausgestellt hat.

Ein negatives Ergebnis kann bedeuten:

• ungültiges JSON,
• fehlerhafter oder beschädigter private_key,
• fehlendes Pflichtfeld im JSON,
• Problem bei der Kommunikation mit Google,
• Verwendung eines Schlüssels, der kein Servicekonto-Schlüssel ist.

Dieser Test bestätigt noch nicht, dass das Servicekonto Eigentümerzugriff auf die Domain in Search Console hat. Dafür ist ein URL-metadata-Test oder eine echte Meldung einer Test-URL erforderlich.

11.4. Test URL Metadata

Das Formular:

Test URL Metadata

ermöglicht die Eingabe einer öffentlichen URL von einem erlaubten Host und führt einen metadata-Request an die Google Indexing API aus.

Vor dem Versand des Requests führt das Modul folgende Schritte aus:

• Normalisierung der URL,
• Prüfung, ob die URL absolut ist,
• Prüfung des Schemas http oder https,
• bei aktiviertem Require HTTPS URLs wird https verlangt,
• Prüfung von Allowed URL Hosts, sofern diese konfiguriert wurden.

Mögliche Ergebnisse:

Der Metadata-Test erstellt keine neue Publish-Meldung. Er dient zur Diagnose der Verbindung und des URL-Status.

12. Erste Inbetriebnahme Schritt für Schritt

Empfohlene Reihenfolge für die erste Inbetriebnahme:

1. Installieren Sie das Modul und führen Sie setup:upgrade aus.
2. Gehen Sie in Magento zu Stores > Configuration > Kowal > Google Indexing API.
3. Setzen Sie Enable = Yes.
4. Lassen Sie Dry Run = Yes.
5. Wählen Sie die Quelle der credentials.
6. Fügen Sie das JSON des Servicekontos ein oder laden Sie die JSON-Datei hoch.
7. Füllen Sie Google Cloud Project ID mit dem Wert project_id aus dem JSON.
8. Füllen Sie Allowed URL Hosts aus, zum Beispiel example.com,www.example.com.
9. Belassen Sie die Standardlimits, sofern Google keine höheren Limits genehmigt hat.
10. Speichern Sie die Konfiguration und leeren Sie den Cache.
11. Gehen Sie zu Google Indexing API > Setup Assistant.
12. Prüfen Sie, ob der Assistent die credentials als bereit anzeigt.
13. Klicken Sie auf Test Google Credentials.
14. Fügen Sie die Service Account Email als Inhaber in Google Search Console hinzu, falls dies noch nicht erfolgt ist.
15. Führen Sie Test URL Metadata für eine öffentliche URL eines erlaubten Hosts aus.
16. Gehen Sie zu Google Indexing API > Import URLs.
17. Fügen Sie eine Test-URL mit der Aktion URL_UPDATED hinzu.
18. Starten Sie den Magento-Cron:

bin/magento cron:run

19. Prüfen Sie Google Indexing API > Indexing Queue.
20. Prüfen Sie Google Indexing API > API Logs.
21. Wenn alles korrekt funktioniert, deaktivieren Sie Dry Run.
22. Fügen Sie erneut eine Test-URL hinzu und prüfen Sie die echte Google-Antwort.

13. URL-Import aus dem Adminpanel

Der manuelle Import befindet sich unter:

Google Indexing API > Import URLs

Das Formular enthält folgende Felder:

Verfügbare Aktionen:

Nach dem Absenden des Formulars zeigt das Modul eine Zusammenfassung an:

• hinzugefügt,
• aktualisiert,
• dedupliziert,
• ungültig,
• übersprungen.

Die ersten 10 Validierungsmeldungen werden als Notice im Adminpanel angezeigt.

14. Indexierungswarteschlange

Die Warteschlange befindet sich unter:

Google Indexing API > Indexing Queue

Jeder Warteschlangen-Datensatz enthält unter anderem:

• URL,
• URL-Hash,
• Store ID,
• Website ID,
• Quelltyp,
• ID der Quellentität,
• Herkunft des Requests,
• die Aktion URL_UPDATED oder URL_DELETED,
• Status,
• Priorität,
• Anzahl der Versuche,
• maximale Anzahl der Versuche,
• geplantes Versanddatum,
• Verarbeitungsdatum,
• letzter Fehlercode,
• letzter Fehlergrund,
• letzte Fehlermeldung,
• Google-Antwort,
• die Information created_by.

Warteschlangenstatus

Aktionen für Warteschlangen-Datensätze

Hinweis: Transmit Now führt einen echten Request aus, wenn Dry Run = No gilt. Bei Dry Run = Yes wird ein Dry-Run-Log ohne echten Versand an Google gespeichert.

15. Cron

Das Modul fügt zwei Cron-Aufgaben in der Gruppe default hinzu.

Verarbeitung der Warteschlange

kowal_google_indexing_process_queue

Zeitplan:

*/5 * * * *

Die Aufgabe startet den Warteschlangen-Prozessor alle 5 Minuten.

Der Prozessor:

1. Prüft, ob das Modul aktiviert ist.
2. Gibt alte Sperren von processing-Datensätzen frei, die älter als 30 Minuten sind.
3. Verschiebt scheduled-Datensätze nach pending, wenn scheduled_at <= now.
4. Prüft verfügbare Slots in den Tages- und Minutenlimits.
5. Ruft pending- und retry-Datensätze ab.
6. Sortiert sie nach Priorität und geplantem Versanddatum.
7. Sendet einen Request an Google oder führt einen Dry Run aus.
8. Speichert Antwort, Status und API-Log.

Log-Bereinigung

kowal_google_indexing_cleanup_logs

Zeitplan:

15 3 * * *

Die Aufgabe entfernt API-Logs, die älter sind als die im Feld angegebene Anzahl an Tagen:

API Log Retention Days

16. API-Logs

Die Logs sind verfügbar unter:

Google Indexing API > API Logs

Das Log umfasst:

• ID des Warteschlangen-Datensatzes,
• Store ID,
• Request-Typ,
• Endpoint-URL,
• Payload,
• HTTP-Status,
• Response-Body,
• Dauer des Requests,
• Erstellungsdatum des Logs.

Request-Typen:

17. Mass Actions und Admin-Buttons

Das Modul fügt Mechanismen zum Melden von URLs aus dem Adminpanel hinzu.

Produkte

Im Produkt-Grid steht eine Massenaktion zur Verfügung, die Produkt-URLs zur Warteschlange hinzufügt.

Das Modul überspringt Produkte, die:

• deaktiviert sind,
• nicht einzeln sichtbar sind.

Die URLs werden auf Basis von URL Rewrites für aktive Store Views generiert.

CMS-Seiten

Im CMS-Seiten-Grid steht eine Massenaktion zur Verfügung, die Seiten-URLs zur Warteschlange hinzufügt.

Das Modul überspringt inaktive Seiten.

Wenn eine CMS-Seite allen Store Views zugewiesen ist, löst das Modul die URLs für alle Store Views auf.

Produkt, Kategorie und CMS-Seite - Buttons im Bearbeitungsformular

Das Modul fügt Buttons zur Meldung der Indexierung auf den Bearbeitungsseiten hinzu von:

• Produkt,
• Kategorie,
• CMS-Seite.

Der Button löst die Entitäts-URLs für Store Views auf und fügt sie als URL_UPDATED zur Warteschlange hinzu.

18. Empfohlene Startkonfiguration

Für die erste produktive Implementierung:

19. Typische Probleme und Diagnose

Credentials test failed

Prüfen Sie:

• ob das JSON korrekt ist,
• ob das JSON von einem Servicekonto stammt,
• ob es private_key und client_email enthält,
• ob das Feld type den Wert service_account hat,
• ob die JSON-Datei beim Einfügen nicht beschädigt wurde.

Google gibt einen Berechtigungsfehler zurück

Prüfen Sie:

• ob die Domain in Search Console verifiziert ist,
• ob client_email des Servicekontos als Inhaber hinzugefügt wurde,
• ob die getestete URL zu derselben Search-Console-Property gehört,
• ob Sie das richtige Google Cloud-Projekt und das richtige JSON verwenden.

Die URL wird vor dem Versand abgelehnt

Prüfen Sie die Validierungsmeldung:

Die Warteschlange wird nicht verarbeitet

Prüfen Sie:

• ob Enable = Yes gilt,
• ob der Magento-Cron funktioniert,
• ob die Datensätze den Status pending oder retry haben,
• ob scheduled_at nicht in der Zukunft liegt,
• ob Tages- oder Minutenlimits nicht ausgeschöpft sind,
• ob Daily Publish Limit und Requests Per Minute Limit nicht auf 0 gesetzt sind.

Datensätze wechseln in retry

Prüfen Sie:

• den HTTP-Status im Warteschlangen-Datensatz,
• das API-Log,
• die Google-Antwort,
• ob nicht das Limit 429 auftritt,
• ob keine temporären 5xx-Fehler vorliegen,
• ob Max Attempts und Retry Delay wie erwartet gesetzt sind.

20. Optionale Integration mit Amasty Blog

Die Integration mit Amasty Blog ist als separates Modul vorgesehen:

Kowal_GoogleIndexingApiAmastyBlog

Paket:

kowal/module-google-indexing-api-amasty-blog

Dieses Modul ist für die Funktion der Hauptintegration nicht erforderlich. Es sollte nur in Projekten installiert werden, die amasty/blog verwenden und eine Massenaktion für Blogbeiträge benötigen.