Fehlerbehebung

Die folgenden Fälle ergeben sich direkt aus Fehlerzuständen, Fallbacks und Admin-Hinweisen des aktuellen Codes.

Sitemap liefert 404

Mögliche Ursache

FG Sitemap ist deaktiviert oder WordPress ist über blog_public nicht für Suchmaschinen freigegeben.

Eine weitere Möglichkeit ist, dass eine angeforderte Child-Sitemap nach sämtlichen Filtern keinen gültigen Eintrag enthält.

Lösung

1. Unter FUNCKGROUP → FG Sitemap → Einstellungen prüfen, ob FG Sitemap aktiv ist.
2. Unter Einstellungen → Lesen die WordPress-Indexierbarkeit prüfen.
3. Bei einer Child-Sitemap kontrollieren, ob der zugehörige Post Type bzw. die Taxonomie gültige indexierbare Inhalte enthält.

Prüfung

/fg-sitemap.xml sollte HTTP 200 und XML liefern, sobald mindestens ein gültiger Sitemap-Bereich vorhanden ist.

Child-Sitemap liefert nach einem Update 404

Mögliche Ursache

Die in WordPress gespeicherten Rewrite-Regeln stammen noch von einer älteren Plugin-Struktur.

Lösung

FG Sitemap besitzt eine Rewrite-Versionierung und aktualisiert geänderte Regeln automatisch einmalig. Zusätzlich erkennt der Code bekannte Sitemap-Pfade über REQUEST_URI.

Wenn der Webserver den Request nicht bis WordPress durchreicht, muss die WordPress-Rewrite-Konfiguration des Servers geprüft werden.

Prüfung

Eine im Sitemap-Index verlinkte Child-Sitemap direkt aufrufen und HTTP-Status sowie XML prüfen.

robots.txt enthält keinen Sitemap-Eintrag

Mögliche Ursache

Im WordPress-Home-Pfad liegt eine physische robots.txt. Diese wird vom WordPress-Filter robots_txt nicht verändert.

Lösung

Im Backend den robots.txt-Status prüfen. Bei einer statischen Datei den folgenden Eintrag manuell ergänzen:

Sitemap: https://example.com/fg-sitemap.xml

Prüfung

Die öffentliche robots.txt aufrufen und kontrollieren, ob die absolute FG-Sitemap-URL enthalten ist.

Sitemap-URLs sind falsch oder zeigen noch auf die alte Domain

Mögliche Ursache

home_url() oder site_url() sind nach Migration bzw. Domainwechsel noch nicht korrekt gesetzt.

Lösung

1. WordPress-Home- und Site-URL prüfen.
2. Unter FUNCKGROUP → FG Sitemap den Sitemap-Cache leeren.
3. Sitemap neu aufrufen.

Prüfung

Alle <loc>-Werte müssen absolute URLs der erwarteten WordPress-Home-Domain enthalten.

Ein Inhalt fehlt in der Sitemap

Mögliche Ursache

Der Inhalt kann durch eine der Indexierbarkeitsprüfungen ausgeschlossen sein, zum Beispiel:

• nicht veröffentlicht
• passwortgeschützt
• Yoast- oder Rank-Math-noindex
• Canonical zeigt auf eine andere URL
• inaktive oder veraltete FG-Multilang-Variante
• bekannte FG-Weiterleitungsquelle
• projektspezifischer Ausschlussfilter

Lösung

Die Metadaten und Integrationen des konkreten Inhalts prüfen. Bei eigenen Filtern deren Rückgabewert kontrollieren.

Prüfung

Nach einer relevanten Änderung wird der Sitemap-Cache automatisch geleert; anschließend die betreffende Child-Sitemap erneut aufrufen.

Eine Taxonomie erscheint nicht

Mögliche Ursache

Taxonomie-Sitemaps verwenden hide_empty = true. Ein Term ohne zugeordnete Inhalte wird nicht berücksichtigt.

Zusätzlich können Noindex-, Canonical-, FG-Multilang- oder URL-Ausschlussregeln greifen.

Lösung

Term-Zuordnung und SEO-Metadaten prüfen.

Prüfung

Nach einer Term- oder Zuordnungsänderung die Taxonomie-Child-Sitemap erneut laden.

Bilder fehlen in der Sitemap

Mögliche Ursache

• Bilder einbeziehen ist deaktiviert.
• Das Bild wird nicht als Beitragsbild, src, data-src, data-lazy-src oder unterstütztes ACF-Feld gefunden.
• Eine benutzerdefinierte Bildquelle wird nicht über fg_sitemap_wp_post_images ergänzt.

Lösung

Die Bildquelle prüfen und bei projektspezifischen Renderern den öffentlichen Bildfilter verwenden.

Prüfung

In der Post-Type-Child-Sitemap nach <image:image> und <image:loc> suchen.

IndexNow-Key-Datei liefert nicht den erwarteten Key

Mögliche Ursache

IndexNow ist deaktiviert, die gespeicherte Key-Zeichenfolge ist ungültig oder der Request erreicht WordPress nicht.

Lösung

1. IndexNow aktivieren.
2. Die im Backend angezeigte Key-Datei-URL verwenden.
3. Bei Server-404 die WordPress-Rewrite-Verarbeitung prüfen.

Prüfung

Die Key-Datei muss HTTP 200 und genau den im Backend gezeigten Key als Plaintext zurückgeben.

IndexNow meldet HTTP 403

Mögliche Ursache

Der IndexNow-Key konnte vom Endpoint nicht verifiziert werden.

Lösung

Die im Backend angezeigte Key-Datei öffentlich aufrufen und prüfen, ob sie den erwarteten Key liefert.

Prüfung

Den manuellen Startseiten-Test erneut ausführen. Ein erfolgreicher Request liefert HTTP 200 oder 202.

IndexNow meldet HTTP 429 oder einen 5xx-Fehler

Mögliche Ursache

Der Endpoint begrenzt Requests oder hat einen temporären Serverfehler.

Lösung

Keine manuelle Queue-Manipulation ist erforderlich. Der Code plant bei HTTP 429, HTTP 5xx und Netzwerkfehlern automatisch einen weiteren Versuch nach 15 Minuten.

Prüfung

Später den IndexNow-Status und die Queue-Länge im Backend kontrollieren.

Änderungen erscheinen trotz Cache nicht sofort

Mögliche Ursache

Die konkrete Änderung löst keinen der vom Plugin beobachteten Invalidierungs-Hooks aus oder ein externer Cache liegt vor WordPress.

Lösung

Den Sitemap-Cache manuell über die Übersicht leeren. Bei unveränderter Ausgabe zusätzlich vorgeschaltete Server-/Proxy-Caches prüfen.

Prüfung

Die Sitemap nach dem Leeren erneut abrufen und den betroffenen Eintrag vergleichen.