Website-Audit und Lighthouse-Reporting: das Dashboard, mit dem Agenturen technische Arbeit zeigen

Jedes Gespräch über Vitals endet bei derselben Frage: Welche Seite? Dieser Report beantwortet sie, indem er zwei Messungen nebeneinander hält. Der Feldwert ist das, was Besucher tatsächlich erlebt haben – Largest Contentful Paint, Interaction to Next Paint und Cumulative Layout Shift im 75. Perzentil, im Vergleich zu Googles eigenen Schwellenwerten für gut und schlecht. Das Labor-Audit ist das, was Lighthouse auf jeder aufgeführten URL unter kontrollierten Bedingungen gemessen hat, auf Abruf, am Tag der Korrektur. Das eine sagt, ob die Website besteht; das andere sagt, welches Template schuld ist.

Die Tabelle der geprüften Seiten ist der Ort, an dem diese Paarung sichtbar wird. Jede geprüfte URL trägt ihre eigenen vier Scores neben ihrem eigenen Labor-LCP und -CLS, und ein Ring zählt, wie viele Seiten klar bestehen, wie viele Verbesserung brauchen und wie viele durchfallen. Aus „die Seite fühlt sich langsam an“ wird so ein Arbeitsauftrag, der das Template, den Traffic dahinter und die schuldige Kennzahl benennt. Trends auf Property-Ebene und die Geräteaufteilung, die Google veröffentlicht, gehören in den Search Console Report; diese Seite ist der Prüfstand darunter.

Der Tab „Chancen“ listet, was das Audit gefunden hat und was die Behebung wert ist – Millisekunden bei renderblockierenden Ressourcen und der Server-Antwortzeit; Kibibyte bei der Bildauslieferung, ungenutztem JavaScript, nicht minimiertem CSS und Cache-Laufzeiten. Jede Zeile trägt ihren Bereich und einen Schweregrad, der sich aus der Größe der Einsparung ableitet, sodass eine Entwicklerschätzung und eine Agenturpriorität aus derselben Liste argumentiert werden statt aus zwei verschiedenen Exporten.

Die Diagnosen stehen daneben als Erklärung und nicht als Aufgabenliste: DOM-Größe, Arbeit im Haupt-Thread, JavaScript-Ausführungszeit, Zahl der Anfragen, übertragenes Gewicht und die Labor-Zeiten dahinter, etwa First Contentful Paint, Largest Contentful Paint, Speed Index und Total Blocking Time. Jede kommt mit ihrem Zielwert und einem schlichten Satz dazu, warum das zählt – meist der Unterschied zwischen einem Report, den ein Kunde an seine Entwicklung weiterleitet, und einem, der mit Rückfragen zurückkommt.

Automatisierte Prüfungen zur Barrierefreiheit sind so gruppiert, wie die Behebung tatsächlich geschnitten wird: nach Auswirkung. Kritische Befunde wie unbeschriftete Formularfelder und Bilder ohne Alternativtext stehen getrennt von schwerwiegenden wie Kontrastfehlern und Links ohne Namen, und die wiederum getrennt von mittleren wie Größe der Tap-Ziele, Überschriftenreihenfolge und Fokusreihenfolge. Jede Zeile trägt die Zahl der betroffenen Elemente, sodass ein Angebot aus Zahlen entsteht und nicht aus dem vagen Versprechen, die Barrierefreiheit zu verbessern.

Der Report ist bewusst ehrlich darüber, was ein automatisierter Durchgang abdeckt. Diese Prüfungen finden einen Bruchteil der Hürden, die eine manuelle Prüfung findet, und die Oberfläche sagt das – was eine Agentur davor schützt, dass ein Kunde einen sauberen Lauf als Konformitätsnachweis liest. Richtig eingesetzt ist es der günstigste erste Durchgang, den es gibt: Er räumt die mechanischen Fehler ab, hinterlässt einen dokumentierten Nachweis, was wann behoben wurde, und lässt einer manuellen Prüfung eine deutlich kleinere Fläche.

Zehn Prüfungen aus Crawl und Markup laufen als Liste mit bestanden oder nicht bestanden, jeweils mit einem Satz dazu, was der Crawl gefunden hat: Titel-Elemente, Meta-Beschreibungen, crawlbare Links, Canonical-Angaben, hreflang-Auszeichnungen, eine gültige robots-Datei, Alt-Attribute an Bildern, lesbare Schriftgrößen, Abstände zwischen Tap-Zielen und die Gültigkeit strukturierter Daten. Über der Tabelle steht eine Gesamtzahl, sodass als Erstes sichtbar ist, wie viele der zehn sauber sind und wie viele offene Arbeit bedeuten.

Das ist das On-Page-Audit und nicht der Bericht zur Indexierung – was ein Crawler auf der Seite lesen kann, nicht das, was Google behalten hat. Die beiden beantworten verschiedene Fragen und gehören an verschiedene Orte; deshalb liegen Abdeckung, Suchanfragen und Impressionen im Search Console Report, und diese Seite bleibt beim Markup. Beides zusammen zu lesen ist das übliche Muster: erst beheben, was das Audit hier meldet, dann über die folgenden Wochen beobachten, wie Indexierung und Position darauf reagieren.

Jedes Audit ist über den Kundenwechsel im Workspace auf einen Kunden begrenzt und trägt Ihr Agentur-Branding, sodass dieselbe Struktur die Januar-Runde und die Juni-Runde trägt. Scores, Vitals, Chancen, Diagnosen, Barrierefreiheit und technische Checks behalten ihre Plätze über Mandate hinweg, und der Vergleich von Monat zu Monat wird damit zum zweimaligen Lesen desselben Abschnitts statt zum Abgleich zweier unterschiedlich gebauter Dokumente. Der Workspace liefert die Oberfläche; die Datenquelle zu verbinden bleibt ein eigener Schritt.

Diese Wiederholung ist es, die technische Arbeit zu etwas macht, das ein Kunde verlängert. Ein Entwickler sieht eine sortierte Liste mit geschätzten Einsparungen; ein Kundenbetreuer sieht vier Scores, eine Gesamtzahl und die Seiten dahinter – und beide schauen auf denselben Report. Teams verbringen die Zeit damit, zu entscheiden, was als Nächstes behoben wird, statt ein Präsentationslayout neu zu bauen, und das Audit hört auf, das Deliverable zu sein, auf dessen Erstellung sich niemand freut.