Google Search Console: robots.txt nicht erreichbar trotz 200 OK

Die Google Search Console meldete bei einer WordPress-Seite wiederholt „robots.txt nicht erreichbar“ und „Sitemap konnte nicht gelesen werden“. Gleichzeitig lieferten Browser und curl für Startseite, robots.txt und Sitemap jeweils 200 OK.

Google Search Console meldet einen allgemeinen HTTP-Fehler beim Lesen der WordPress-Sitemap — Ausgangslage: Die Sitemap war im Browser erreichbar, wurde von Google aber zeitweise als nicht lesbar gemeldet.

Das Setup

Die Website läuft auf WordPress in der Synology Web Station. Davor liegen Router, UniFi-Gateway, Portweiterleitungen und die Synology-Firewall. Die öffentliche Adresse wird über DynDNS aktualisiert. Die Hauptdomain leitet dauerhaft auf die kanonische www-Adresse weiter.

1. HTTP-Antworten unabhängig vom Browser prüfen

Der erste Schritt ist immer die Frage: Liefert der Webserver wirklich eine saubere Antwort – auch ohne Browsercache und ohne eingeloggte WordPress-Sitzung?

curl.exe -I https://www.example.de/
curl.exe -I https://www.example.de/robots.txt
curl.exe -I https://www.example.de/wp-sitemap.xml
curl.exe -A "Googlebot" -I https://www.example.de/beispielartikel/

Erwartet werden 200 OK, ein passender Content-Type und keine Wartungsseite. Für eine statische robots.txt ist Content-Type: text/plain ideal.

2. Inhalt auf noindex, Wartungsmodus und Canonical prüfen

$html = curl.exe -A "Googlebot" -s https://www.example.de/beispielartikel/
$html | Select-String -Pattern 'noindex|maintenance|canonical'

Die Ausgabe sollte keinen noindex-Hinweis und keine Wartungsseite enthalten. Bei der kanonischen URL darf kein Widerspruch entstehen.

3. DNS getrennt nach A, AAAA und CNAME prüfen

Resolve-DnsName www.example.de -Type A -Server 8.8.8.8
Resolve-DnsName www.example.de -Type AAAA -Server 8.8.8.8
Resolve-DnsName www.example.de -Type CNAME -Server 8.8.8.8

Ein besonders tückischer Fehler ist ein funktionierender IPv4-Eintrag bei gleichzeitig falschem IPv6-Ziel. Google kann IPv6 verwenden und dadurch auf einem völlig anderen Webserver landen. In diesem Fall wurde die www-Adresse schließlich per CNAME auf eine reine IPv4-DynDNS-Subdomain gelegt.

4. Die statische robots.txt im Webroot

WordPress kann eine virtuelle robots.txt erzeugen. Für eine eindeutige Fehleranalyse lag hier zusätzlich eine statische Datei direkt im WordPress-Webroot:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://www.example.de/wp-sitemap.xml

Die Datei muss im selben Verzeichnis wie wp-config.php und index.php liegen.

5. Entscheidend: Kommt der Google-Test überhaupt am NAS an?

Mit einem gezielten SYN-Mitschnitt lässt sich prüfen, ob während des Live-Tests überhaupt neue HTTPS-Verbindungen am Webserver eintreffen. Dieser Befehl war in unserem Fall der wichtigste Nachweis:

tcpdump -ni any -tttt -nn 'dst host 9.3.4.250 and tcp dst port 443 and (tcp[tcpflags] & tcp-syn != 0)'

Wichtig: 9.3.4.250 ist die NAS-Adresse aus diesem Beispiel und muss an das eigene System angepasst werden. Der Filter zeigt nur neue TCP-SYN-Verbindungen zum HTTPS-Port und bleibt dadurch deutlich übersichtlicher als ein unbeschränkter Mitschnitt auf Port 443.

Interpretation

Pakete sichtbar: DNS, Router und Portweiterleitung führen grundsätzlich bis zum NAS.
Keine Pakete: Der Fehler liegt vor dem NAS – typischerweise DNS, IPv6, Provider, Router, Geo-Blocking oder Portweiterleitung.
SYN sichtbar, aber kein erfolgreicher Abruf: NAS-Firewall, Web Station, Zertifikat oder Virtual Host prüfen.

Google Search Console meldet robots.txt nicht erreichbar — Der Live-Test zeigte zeitweise weiterhin „robots.txt nicht erreichbar“, obwohl externe Prüfungen 200 OK lieferten.

6. Firewalls und Region Blocking

Eine Website kann für den eigenen Browser funktionieren und Suchmaschinen trotzdem blockieren. Kritisch sind insbesondere Länderfreigaben. Googlebot kommt nicht zuverlässig nur aus einem einzigen Land. Für eine öffentliche Website müssen TCP 80 und 443 aus allen Quellen erreichbar sein. Verwaltungsdienste bleiben weiterhin auf das interne Netz begrenzt.

7. Erst nach stabiler Erreichbarkeit erneut testen

Nach DNS-Änderungen, Neustarts und Firewall-Anpassungen sollte nicht im Minutentakt alles erneut verändert werden. Zuerst lokal und extern prüfen, anschließend den Live-Test in der Search Console ausführen und den Paketmitschnitt parallel beobachten.

Google Search Console bestätigt, dass die URL auf Google ist — Endstand: Die URL ist erreichbar, indexierbar und wieder im Google-Index.

Abschlusscheckliste

Die Hauptdomain leitet genau einmal per 301 auf die kanonische Adresse.
A-, AAAA- und CNAME-Einträge führen zum richtigen Anschluss.
/robots.txt liefert 200 OK und text/plain.
/wp-sitemap.xml liefert 200 OK und XML.
Googlebot erhält keine Wartungsseite und kein noindex.
TCP 80/443 sind für öffentliche Besucher freigegeben.
Der tcpdump zeigt den eingehenden Live-Test am NAS.
Die Sitemap wird in der Search Console fehlerfrei verarbeitet.