PageSpeed Insights nicht verfügbar

Was diese Prüfung macht

Markiert Audits, bei denen die PageSpeed Insights-API einen Fehler oder ein leeres Payload zurückgegeben hat statt eines Lighthouse-Laufs. Das ist eine informative Prüfung, kein Pass/Fail.

Wenn PSI nicht verfügbar ist, hat jede nachgelagerte Performance-Metrik — Lighthouse-Score, LCP, INP, CLS, Server-Antwortzeit — keine Datenbasis und wird übersprungen.

Warum es zählt

Performance ist die Hälfte eines Audits, die direkt auf User Experience und Core-Web-Vitals-Rankings abbildet. Wenn PSI deine Seite nicht laden kann, geht das Audit für das gesamte Performance-Modul dunkel. Schlimmer: Die Ursache trifft meist auch Googles eigenen Crawler — derselbe Fehler, der PSI blockierte, schadet wahrscheinlich auch Indexierung, KI-Crawlern und echten Nutzer:innen.

Behandle diese Warnung als Anfang einer Checkliste, nicht als einmaligen API-Aussetzer.

So behebst du es

Geh die Diagnose-Checkliste der Reihe nach durch. Der erste Treffer ist meist die Ursache.

1. Manuell reproduzieren.

Öffne pagespeed.web.dev, füge die exakte URL ein, die MetricSpot geprüft hat, und lass es laufen. Drei Ausgänge:

• PSI funktioniert im Browser. Vermutlich ein transientes Timeout oder Rate Limit. Wiederhole das MetricSpot-Audit in 30 Minuten.
• PSI zeigt denselben Fehler. Googles eigene Infrastruktur kann die Seite ebenfalls nicht laden. Weiter auf der Checkliste.
• PSI liefert eine andere URL (nach Redirects). Dein Canonical leitet in einer Schleife oder zu einer 404 weiter. Siehe Ursache #2.

2. robots.txt auf Blockaden prüfen.

curl -sI https://yourdomain.com/robots.txt
curl -s https://yourdomain.com/robots.txt | grep -i -E "user-agent|disallow"

PSI identifiziert sich als Chrome-Lighthouse. Wenn deine robots.txt es blockiert (oder * vom geprüften Pfad blockiert), schlägt PSI still fehl. Siehe die robots.txt-Prüfung für die sichere Konfiguration.

3. Auf Redirect-Loops oder -Ketten prüfen.

curl -sIL https://yourdomain.com/page | grep -E "^HTTP|^location:"

PSI folgt höchstens wenigen Redirects, bevor es aufgibt. Typische Übeltäter: HTTP→HTTPS→www→non-www-Ketten, Locale-Redirects, die endlos pingpongen, Marketing-Page-Redirects zu /landing/$utm_source. Fix mit den Prüfungen Weiterleitungsketten und HTTP auf HTTPS weiterleiten.

4. Auf Auth-Walls und IP-Geo-Blocks prüfen.

PSI läuft aus Googles Rechenzentren. Wenn deine Seite Login verlangt, hinter einem Cloudflare-Bot-Challenge sitzt, auf ein Land beschränkt ist oder deine WAF Google-IPs rate-limited, bekommt PSI 401/403/429 und schlägt fehl.

curl -sI -H "User-Agent: Chrome-Lighthouse" https://yourdomain.com/page

Ein 200 hier bedeutet, der PSI-User-Agent kommt durch. Ein 403 oder ein cf-mitigated: challenge-Header ist dein Übeltäter.

5. Response-Status und Timeout prüfen.

curl -sI -o /dev/null -w "%{http_code} %{time_total}s\n" https://yourdomain.com/page

PSI wertet alles Non-2xx als Fehler. Server-Timeouts über ~30 Sekunden scheitern ebenfalls. Wenn die Seite langsam zum ersten Byte ist, fix die Server-Antwortzeit vor dem Retry.

6. Wann wiederholen vs. ermitteln.

Einmal nach 30 Minuten wiederholen, wenn:

• PSI im Browser für dieselbe URL funktioniert.
• curl -I mit dem Lighthouse-User-Agent 200 zurückgibt.
• Keine kürzlichen Änderungen an robots.txt, WAF-Regeln oder DNS.

Sofort ermitteln, wenn:

• PSI für dieselbe URL auch im Browser fehlschlägt.
• curl -I für Chrome-Lighthouse 4xx/5xx zurückgibt.
• Der Fehler über mehrere Audits hinweg besteht.

Häufig gestellte Fragen

Warum scheitert PSI sporadisch auf Seiten, die normalerweise funktionieren?

Die öffentliche PSI-API hat ein Rate Limit pro IP (rund 25.000 Queries pro Tag mit API-Key, deutlich weniger unauthentifiziert). Burst-Audit-Traffic — deiner plus andere Tools mit derselben Egress-IP — kann das Kontingent kurzzeitig erschöpfen. Einzelne Retries 15–30 Minuten später gelingen fast immer.

Schadet PSI-Unverfügbarkeit meinen Rankings?

Die Unverfügbarkeit selbst nicht. Aber die Ursachen — robots.txt-Blockaden, Redirect-Loops, Auth-Walls, Geo-Blocks, langsame TTFB — meist schon, weil Googlebot gegen dieselbe Wand läuft. Behandle die Warnung als “Google kann diese Seite möglicherweise auch nicht rendern” und prüf zuerst Server-Antwortzeit, HTTPS und robots.txt-Befunde.

Bekomme ich Performance-Daten ohne PSI?

Für eine einzelne Seite lass Lighthouse direkt in Chrome DevTools laufen — das umgeht die API komplett. Für laufendes Monitoring liefert der Chrome User Experience Report (CrUX) reale Felddaten via BigQuery und CrUX-API, auch wenn PSIs Lab-Läufe scheitern. MetricSpot nutzt heute nur PSI, also überspringt das Audit diese Metriken weiterhin; die Daten existieren, nur nicht in diesem Report.