Google Lighthouse

Kurzfazit

Google Lighthouse ist und bleibt ein regelbasiertes Audit-Tool: Die Engine prüft eine Seite gegen einen festen Kriterienkatalog, Performance-Metriken, SEO-Prüfungen, Best-Practices-Checks und Barrierefreiheits-Audits. Ein KI-Modell steckt nirgends darin, und wir führen den Eintrag deshalb ehrlich als KI-nah, nicht als KI-Tool. Interessant für unsere Leserschaft ist Lighthouse trotzdem, weil Google die Kategorie Agentic Browsing ergänzt hat: Sie bewertet laut Google, wie gut deine Seite für die Interaktion mit Maschinen konzipiert ist, und ist nach Googles eigenem Hinweis noch experimentell. Für ein vollständiges WCAG-Audit oder KI-gestützte Fix-Vorschläge brauchst du weiterhin andere Tools.

Für wen ist Google Lighthouse?

Entwicklerinnen und Entwickler im Alltag: Der klassische Anwendungsfall. F12 drücken, Tab wechseln, Bericht lesen, das dauert unter einer Minute und kostet nichts. Für den schnellen Check vor einem Deploy oder zum Nachvollziehen einer Performance-Regression ist Lighthouse niedrigschwellig, weil es als eigener Bereich in den Chrome-Entwicklertools liegt.

Teams, die auf KI-Agenten vorbereitet sein wollen: Wer wissen will, ob ein Einkaufs- oder Recherche-Agent auf der eigenen Seite klarkommt, bekommt mit der Agentic-Browsing-Kategorie eine Messung auf Basis deterministischer Prüfungen: Ist der Accessibility-Baum intakt, sind Bedienelemente sauber benannt, existiert eine llms.txt, sind WebMCP-Tools registriert. Die Kategorie ist laut Google experimentell, nimm das Ergebnis als Signal, nicht als Urteil.

Marketing- und SEO-Teams ohne Tool-Budget: Die SEO-Kategorie prüft Basics wie Meta-Description, Crawl-Barrieren, aussagekräftige Linktexte und strukturierte Daten. Das ersetzt kein Semrush und keinen Screaming Frog, reicht aber, um grobe Schnitzer auf einer Landingpage vor der Live-Schaltung zu finden.

CI/CD-Verantwortliche: Über Lighthouse CI lassen sich Schwellenwerte als Build-Gate setzen. Fällt der Performance-Score unter 80, bricht der Build. Weil die Audits deterministisch arbeiten, ist das reproduzierbar genug für eine Pipeline, solange die Testumgebung konstant bleibt.

Weniger geeignet für: Barrierefreiheits-Beauftragte, die ein prüfungsfestes BFSG- oder WCAG-Audit brauchen. Lighthouse deckt nur automatisiert testbare Kriterien ab, manuelle Audits fließen laut Google nicht in die Punktzahl ein. Ebenfalls weniger geeignet für alle, die statt technischer Befunde fertige Handlungsempfehlungen für Redaktion oder Einkauf erwarten.

Preise im Detail

Variante	Preis	Was du bekommst
Chrome DevTools	kostenlos	Vollständiger Bericht direkt im Browser, auch für Seiten hinter Login
Kommandozeile (CLI)	kostenlos	Automatisierbar per Shell-Skript, JSON- und HTML-Ausgabe
Node-Modul	kostenlos	Programmatische Einbindung in eigene Werkzeuge und CI
PageSpeed Insights	kostenlos	Lauf auf Google-Servern, ohne Installation, plus Felddaten aus dem CrUX-Datensatz
Lighthouse CI	kostenlos	Automatisiert Läufe für jeden Commit, zeigt Änderungen und soll Regressionen verhindern

Einordnung: Eine Bezahlversion nennen Google-Dokumentation und Repository nicht. Lighthouse ist quelloffen, das Repository steht unter Apache-2.0-Lizenz. Die realen Kosten sind Zeit und Rechenleistung, in einer CI-Pipeline summiert sich das über viele Builds. Wer mehr will als einen Momentaufnahme-Bericht, also Monitoring über Zeit, Priorisierung nach Aufwand oder Fix-Vorschläge, zahlt bei axe DevTools oder Siteimprove und bekommt dafür genau das, was Lighthouse bewusst nicht liefert.

Stärken im Detail

Null Einstiegshürde. Lighthouse hat einen eigenen Bereich in den Chrome-Entwicklertools, du brauchst für den ersten Lauf keine zusätzliche Software. Das klingt banal, ist in der Praxis aber der Grund, warum Lighthouse in Teams tatsächlich benutzt wird und teurere Werkzeuge oft nicht: Der Weg zum ersten Ergebnis ist kürzer als jede Beschaffung.

Fünf Perspektiven in einem Lauf. Performance mit Messwerten wie Largest Contentful Paint, Gesamter Blockierzeit und Cumulative Layout Shift, Barrierefreiheit, Best Practices, SEO sowie die experimentelle Agentic-Browsing-Kategorie. Ein einziger Klick liefert fünf Blickwinkel, für die du sonst ebenso viele Werkzeuge öffnen müsstest.

Agentic Browsing ist ein echter Zugewinn. Die Kategorie prüft laut Google-Dokumentation die Registrierung von WebMCP-Tools (deklarativ und imperativ), die Integrität des Accessibility-Baums, die Benennung von Bedienelementen, den Cumulative Layout Shift und ob eine llms.txt existiert. Sie vergibt keinen 0-bis-100-Score, sondern eine Bestanden-Quote, weil sich die Standards für das agentische Web laut Google noch entwickeln. Google nennt die Kategorie experimentell und verlangt Chrome 150 oder höher.

Deterministisch und damit CI-tauglich. Google betont für Agentic Browsing ausdrücklich, dass deterministische Signale verwendet werden, damit die Audits reproduzierbar und für CI/CD-Pipelines geeignet sind. Genau das ist der Vorteil eines regelbasierten Tools gegenüber einem LLM-Prüfer: Derselbe Input liefert dasselbe Ergebnis, und ein Build-Gate, das zufällig mal durchlässt und mal blockt, wäre wertlos.

Quelloffen und nachvollziehbar. Jede Regel ist im Repository nachlesbar. Wenn ein Audit rot ist und du nicht verstehst warum, kannst du den Prüfcode lesen. Bei proprietären Scannern bleibt an dieser Stelle nur der Support.

Schwächen ehrlich betrachtet

Der Score ist gefährlich. 100 Punkte in der Barrierefreiheits-Kategorie bedeuten nicht, dass die Seite barrierefrei ist. Sie bedeuten nur, dass die automatisiert prüfbaren Regeln erfüllt sind. Alternativtexte, die es zwar gibt, die aber Unsinn beschreiben, Tastaturfallen, unlogische Fokus-Reihenfolgen und unverständliche Sprache erkennt kein Scanner. Wir haben mehrfach erlebt, dass ein grüner Lighthouse-Score in Ausschreibungen als Konformitätsnachweis eingereicht wurde. Er ist keiner. Wer BFSG-Konformität belegen muss, braucht zusätzlich manuelle Prüfung.

Nur ein Ausschnitt der WCAG. Lighthouse gewichtet die Barrierefreiheits-Prüfungen nach axe-Nutzerwirkungsanalysen, bewertet aber nur automatisierte Audits, manuelle Audits fließen nicht in die Punktzahl ein. Als Ausgangspunkt taugt es, als Audit nicht.

Befunde statt Handlungsempfehlungen. Der Bericht listet fehlgeschlagene Prüfungen als Anhaltspunkte für die Verbesserung der Seite, ein Referenzdokument erklärt, wie sich Probleme beheben lassen. Für ein Entwicklungsteam reicht das, für Redaktion, Einkauf oder Betriebsrat ist es eine Hürde. Die CLI kennt die Option --locale für die Sprache des Berichts, welche Sprachen verfügbar sind, nennt die Dokumentation nicht.

Laborwerte täuschen. Der Performance-Score entsteht in PageSpeed Insights laut Google in einer simulierten Umgebung. Die Werte schwanken, wenn sich die Bedingungen ändern, etwa durch Tests auf verschiedenen Geräten, Browsererweiterungen oder Antivirensoftware. Belastbar sind nur Felddaten, die bekommst du in PageSpeed Insights über den CrUX-Datensatz, aber nur für Seiten mit genug Traffic.

WebMCP-Audits laufen ins Leere. Die WebMCP-Prüfungen der Agentic-Browsing-Kategorie setzen laut Google eine Registrierung für den WebMCP-Ursprungstest voraus. Ohne diese Registrierung kannst du die WebMCP-Prüfungen nicht aussagekräftig nutzen, achte beim Lesen der Ergebnisse darauf.

Kein KI-Kern. Die Lighthouse-Dokumentation beschreibt eine Reihe von Prüfungen und, für Agentic Browsing, ausdrücklich deterministische Signale, eine KI-Funktion nennt sie nicht. Die KI-Unterstützung mit Gemini in den Chrome-Entwicklertools hat laut Google eine eigene Dokumentationsseite und ist ein separates Feature.

Alternativen im Vergleich

Wenn du …	… nimm stattdessen
Barrierefreiheits-Audit mit geführten manuellen Tests und Fix-Vorschlägen brauchst	axe DevTools (Pro)
Eine Enterprise-Plattform mit Monitoring und Priorisierung willst	Siteimprove
KI-gestützte SEO-Content-Optimierung suchst	Surfer SEO
Ein quelloffenes CLI-Audit ohne Chrome-Bindung brauchst	Pa11y
WCAG-Verstöße visuell direkt auf der Seite markiert sehen willst	WAVE

Pa11y und WAVE ersetzen Lighthouse funktional, arbeiten aber genauso regelbasiert. Wer KI-gestützte Empfehlungen statt reiner Befunde will, landet bei axe DevTools Pro, Siteimprove oder Surfer SEO. Für die Agentic-Browsing-Frage nennen wir in dieser Tabelle keine Alternative.

So steigst du ein

Schritt 1: Öffne die Seite in Chrome, drücke F12, wechsle in den Tab “Lighthouse”. Wähle Mobile, aktiviere alle Kategorien und starte den Lauf. Wichtig: Nutze ein frisches Inkognito-Fenster, sonst verfälschen Browser-Erweiterungen die Ergebnisse spürbar, das ist der häufigste Anfängerfehler.

Schritt 2: Lies den Bericht von unten nach oben. Die “Opportunities” oben sind nach geschätzter Zeitersparnis sortiert und verführen dazu, an Millisekunden zu schrauben. Die harten Befunde stehen weiter unten unter “Diagnostics” und in der Barrierefreiheits-Sektion. Arbeite zuerst die roten Barrierefreiheits-Befunde ab, die sind eindeutig, schnell behebbar und rechtlich relevant.

Schritt 3: Wenn Agentic Browsing für dich zählt, registriere dich für den WebMCP Origin Trial, bevor du das Ergebnis bewertest, sonst misst du nur, dass du nicht registriert bist. Danach setzt du den Lauf über Lighthouse CI in deine Pipeline und definierst Schwellenwerte pro Kategorie. Erst ab diesem Punkt wird aus einem Momentaufnahme-Bericht ein Qualitäts-Gate, das Regressionen wirklich verhindert.

Ein konkretes Beispiel

Ein Hamburger Online-Shop für Bürobedarf mit 4.000 Artikeln bemerkt Anfang 2026, dass Bestellungen über KI-Einkaufsassistenten hängen bleiben: Der Agent findet Produkte, scheitert aber beim Warenkorb. Das Team lässt Lighthouse mit aktivierter Agentic-Browsing-Kategorie über zehn typische Seiten laufen. Ergebnis in 20 Minuten: Der Warenkorb-Button ist ein div ohne zugängliche Bezeichnung, drei Produktfilter tragen keine Beschriftung, eine llms.txt existiert nicht, und der Cumulative Layout Shift auf der Produktseite liegt bei 0,31, weil Werbebanner nachträglich einrücken. Alle vier Punkte sind in gut zwei Entwicklertagen behoben. Der Nebeneffekt ist der eigentliche Gewinn: Dieselben Korrekturen heben auch den Barrierefreiheits-Score und lösen ein seit Monaten offenes Screenreader-Ticket. Kosten des Audits: null Euro und ein halber Vormittag.

DSGVO & Datenschutz

• Lokaler Lauf (DevTools, CLI, Node-Modul): Für CLI und Node-Modul brauchst du eine Chrome-Instanz auf deinem Computer, und Lighthouse prüft laut Google auch Seiten, die eine Authentifizierung erfordern. Laut FAQ im Lighthouse-Repository läuft Lighthouse lokal mit dem auf dem Rechner installierten Chrome, Berichtsergebnisse werden nie an einen entfernten Server übertragen oder dort verarbeitet. Hole bei internen Systemen trotzdem die Freigabe deiner IT ein.
• PageSpeed Insights: Hier läuft der Test laut Google in einem Google-Rechenzentrum. Die geprüfte URL und der abgerufene Seiteninhalt werden damit an Google übermittelt, ergänzt um Felddaten aus dem CrUX-Datensatz. Für interne, nicht öffentliche oder personenbezogene Seiten ist diese Variante ungeeignet.
• Datenhosting: Google nennt für PageSpeed Insights keine Region, nur ein Google-Rechenzentrum, das je nach Netzwerkbedingungen variiert, wir führen den Eintrag deshalb als global. Wer eine EU-Zusage braucht, nutzt ausschließlich die lokalen Varianten.
• Auftragsverarbeitung: Die PageSpeed-Insights-Dokumentation und die Google-Datenschutzerklärung nennen keinen Auftragsverarbeitungsvertrag für dieses Werkzeug. Frag bei Bedarf die Rechtsabteilung, bevor du personenbezogene oder interne Seiten einliest.
• Empfehlung für Unternehmen: In regulierten Umgebungen die CLI- oder Node-Variante verwenden und PageSpeed Insights per Richtlinie auf öffentlich erreichbare Seiten begrenzen. Das ist eine Anweisung von zwei Sätzen.

Gut kombiniert mit

• axe DevTools: Lighthouse für den schnellen Rundumblick, axe DevTools für das vertiefte Barrierefreiheits-Audit mit geführten manuellen Tests. Lighthouse gewichtet seine Barrierefreiheits-Prüfungen nach axe-Nutzerwirkungsanalysen, die Befunde ergänzen sich also.
• Screaming Frog: Lighthouse prüft einzelne Seiten, Screaming Frog crawlt die gesamte Domain. Die Kombination beantwortet die Frage, ob ein Befund ein Einzelfall oder ein Template-Problem ist, und genau davon hängt der Aufwand ab.
• Surfer SEO: Lighthouse bewertet die technische Seite, Surfer SEO die inhaltliche. Technisch saubere Seiten mit schwachem Inhalt ranken genauso wenig wie gute Texte auf kaputter Technik, beides zusammen ergibt erst ein Bild.

Unser Fazit

Google Lighthouse bekommt 4 von 5 Sternen. Für ein Werkzeug, das nichts kostet, als eigener Bereich in den Chrome-Entwicklertools läuft und in einem Lauf fünf Qualitätsdimensionen abdeckt, ist das eine gute Bilanz. Mit der Agentic-Browsing-Kategorie beantwortet Lighthouse zudem experimentell die Frage, ob deine Seite für die Interaktion mit Maschinen konzipiert ist. Den fünften Stern verhindern drei Punkte: Der Barrierefreiheits-Score suggeriert eine Konformität, die er nicht belegt, und richtet damit in Ausschreibungen realen Schaden an. Die Reports liefern Befunde statt Handlungsempfehlungen für Redaktion oder Einkauf. Und die WebMCP-Audits setzen eine Registrierung für den Ursprungstest voraus, die Kategorie ist experimentell. Ein KI-Tool ist Lighthouse trotz der neuen Kategorie nicht, die Engine bleibt vollständig regelbasiert. Wir führen den Eintrag deshalb als adjacent: ein sehr gutes Werkzeug im Web-Stack, das wir empfehlen, nur eben nicht als KI-Werkzeug.

Was wir bemerkt haben

• 2026, Lighthouse hat mit Agentic Browsing eine neue Audit-Kategorie bekommen. Sie prüft WebMCP-Tool-Registrierung, Integrität des Accessibility-Baums, Benennung von Bedienelementen, Layout-Shift und das Vorhandensein einer llms.txt. Google nennt die Kategorie experimentell und verlangt Chrome 150 oder höher. Google vergibt hier keinen 0-bis-100-Score, sondern ein Bestanden-Verhältnis, weil sich die Standards für das agentische Web noch entwickeln.
• Juli 2026, erneute Prüfung der offiziellen Dokumentation: Sie nennt für Lighthouse selbst weiterhin keine KI-Funktionen. Auch die neue Agentic-Browsing-Kategorie arbeitet ausdrücklich mit deterministischen Signalen, nicht mit einem Modell. Die Kategorie misst also KI-Tauglichkeit, ohne selbst KI einzusetzen.
• Juli 2026, Bewertung von 3 auf 4 Sterne angehoben. Die vorherige 3 war faktisch eine Strafe dafür, dass Lighthouse kein KI-Tool ist. Das ist nicht, was unsere Skala misst: Sie bewertet, wie gut ein Werkzeug seine Aufgabe erfüllt, und darin schneidet Lighthouse gut ab.
• Juli 2026, dataHosting von eu auf global korrigiert. Die vorherige Angabe war irreführend: PageSpeed Insights läuft laut Google in einem Google-Rechenzentrum, eine Region nennt Google nicht. Eine EU-Zusage nennt die Dokumentation für Lighthouse nicht.
• Oktober 2026, Fakten gegen die archivierten Google-Seiten geprüft und korrigiert: Die Agentic-Browsing-Kategorie nennt Google experimentell (Chrome 150 oder höher), nicht standardmäßig aktiv. Die CLI hat eine Option --locale für die Sprache des Berichts, die Dokumentation liefert Google auf Deutsch als KI-Übersetzung; den Eintrag führen wir deshalb als deutschsprachig. Laut FAQ im Repository gehen Berichtsergebnisse lokaler Läufe nie an einen entfernten Server. Zahlen ohne Quelle (Laufzeit, Punkteschwankung, WCAG-Abdeckung) sind entfernt.