Lighthouse-Accessibility-Daten nicht verfügbar

Was diese Prüfung macht

Meldet, dass der Audit keine Lighthouse-Accessibility-Daten von Googles PageSpeed-Insights-Schnittstelle (PSI) abrufen konnte. Ohne sie konnten der Lighthouse-Accessibility-Score und mehrere regelbasierte Audits (Farbkontrast, axe-Regelverstöße) nicht laufen — das Accessibility-Modul meldet daher ein Teilergebnis nur aus den statischen HTML-Prüfungen, die MetricSpot lokal ausführt.

Warum es wichtig ist

Das ist kein Problem mit deiner Seite — es ist ein Problem mit diesem Audit-Lauf. Fünf Ursachen sind üblich:

• Kein PSI-API-Key konfiguriert. Self-hosted-MetricSpot-Installationen brauchen GOOGLE_PSI_KEY; ohne Key drosselt der öffentliche PSI-Endpunkt aggressiv.
• PSI-Kontingent erschöpft. Die kostenlose Stufe erlaubt 25.000 Anfragen/Tag pro Key, 400/Minute. Eine Self-hosted-Instanz mit vielen Audits in kurzer Zeit stößt ans Burst-Limit.
• Deine Seite blockt Headless Chrome. Manche Sites nutzen Cloudflare Bot Fight Mode oder eine eigene WAF, die den PSI-Chrome-User-Agent erkennt und mit 403 antwortet.
• Die Seite liegt hinter einem Login. PSI ruft die URL anonym ab. Liegt der prüfbare Inhalt hinter Authentifizierung, sieht der öffentliche PSI-Render nur den Login-Bildschirm, nicht die echte Seite.
• Die Seite ist aus Googles Netzwerk nicht erreichbar. Geo-Blocking, IP-Allowlists, interne DNS — alles davon hindert PSI am Abruf.

Ein einzelner „Lighthouse nicht verfügbar”-Befund ist meist ein vorübergehender PSI-Aussetzer. Tritt er wiederholt auf, liegt eine der obigen Ursachen vor.

Wie du es behebst

Wenn du MetricSpot self-hosted betreibst:

# Key besorgen: https://developers.google.com/speed/docs/insights/v5/get-started
echo "GOOGLE_PSI_KEY=AIza…" >> .env
# Worker neu starten
dokku ps:restart metricspot

Ohne Key erlaubt PSI anonym etwa eine Anfrage pro Minute. Mit Key sind es 25.000/Tag.

Bei Managed MetricSpot (app.metricspot.com) — das Kontingent ist bereits konfiguriert. Ein „Lighthouse nicht verfügbar”-Befund bedeutet hier, dass PSI selbst an dieser URL gescheitert ist. Versuche:

1. Audit erneut starten. PSI liefert in etwa 1 % der Fälle vorübergehende 500er.
2. Eine öffentliche, nicht-authentifizierte URL prüfen. Bestätige, dass die Seite ohne Session-Cookie erreichbar ist.
3. WAF / Bot-Regeln prüfen. Wenn du Cloudflare nutzt, ergänze den PSI-User-Agent in deiner Allowlist. PSI meldet sich als Chrome-Lighthouse.
4. Im öffentlichen PSI-Tool reproduzieren — wenn das öffentliche Tool an deiner URL ebenfalls scheitert, ist das Problem reproduzierbar und nicht MetricSpot-spezifisch.

Für Seiten, die wirklich nicht per PSI prüfbar sind (Admin-Dashboards, Kundenbereiche), läuft der Rest des MetricSpot-Accessibility-Moduls weiterhin gegen das HTML, das wir abrufen können — Alt-Texte, Formular-Labels, lang-Attribut, aussagekräftiger Linktext, Heading-Hierarchie, Landmarks. Diese statischen Prüfungen machen ohnehin den Großteil der WCAG-Konformität aus. PSI liefert dir den dynamischen Lighthouse-Score obendrauf.

Häufig gestellte Fragen

Was ist der Unterschied zu „Lighthouse-Accessibility-Score”?

Lighthouse-Accessibility-Score feuert, wenn der Score unter dem Schwellenwert liegt. Dieser Befund feuert, wenn PSI gar keinen Score zurückgegeben hat. Sie schließen sich gegenseitig aus — du siehst entweder das eine oder das andere, nie beides.

Kann ich PSI deaktivieren und nur die statischen Prüfungen nutzen?

Ja — setze GOOGLE_PSI_KEY= leer, und MetricSpot überspringt PSI komplett. Du verlierst den Lighthouse-Score, die dynamischen axe-core-Prüfungen und die Lab-Daten der Core Web Vitals. Die meisten Nutzer lassen PSI aktiv.

Beeinflusst das meinen Gesamt-Audit-Score?

Die Gewichtung des Accessibility-Moduls berücksichtigt fehlende PSI-Daten — dein Gesamtscore wird aus den Prüfungen berechnet, die gelaufen sind, und nicht für die fehlenden bestraft. Wenn du die Ursache behebst (WAF-Allowlist, Login-Schranke), tragen die dynamischen Prüfungen beim nächsten Lauf wieder bei.