Wie man Core Web Vitals in der Google Search Console liest und die Webseiten-Geschwindigkeit verbessert

Die Google Search Console (GSC) ist ein kostenloses Tool, mit dem Google Ihnen zeigt, wie Ihre Webseite in der Suche wahrgenommen wird. Dazu gehört auch ein Blick auf die Geschwindigkeit, also die Core Web Vitals-Metriken. Und genau hier verirren sich Laien am häufigsten.

Dieser Artikel ist für Menschen, die für die Geschwindigkeit einer Webseite verantwortlich sind, aber in der Search Console den Überblick verlieren. Für Entwickler, Marketer, Projektmanager und Webseitenbetreiber, die Daten zu Core Web Vitals lesen und wissen müssen, was sie damit anfangen sollen.

Warum schreiben wir das gerade jetzt? Bei PageSpeed.ONE haben wir erfolgreich Dutzende von großen und kleinen Webseiten unserer Kunden optimiert. Die Search Console ist bei uns das zweitwichtigste Tool, gleich nach unserem eigenen Geschwindigkeitsmonitoring. Wir nehmen sie ernst, weil wir in der Praxis regelmäßig den Zusammenhang zwischen Core Web Vitals und den Ergebnissen im SEO, den Klickpreisen in PPC und den Konversionen sehen.

Was ist die Google Search Console und warum ist sie wichtig#

Die Google Search Console ist eine Sammlung von Berichten darüber, wie Ihre Webseite in der Google-Suche abschneidet. Sie können sehen, für welche Suchanfragen Sie angezeigt werden, welche Seiten Google indexiert hat, welche technischen Probleme es mit der Webseite gibt und wie die Benutzererfahrung einschließlich der Geschwindigkeit bewertet wird.

Für Webmaster ist sie aus einem einfachen Grund entscheidend: Es sind Daten direkt von Google und keine Schätzungen Dritter. Wenn Google sagt, dass ein Teil Ihrer Seiten aus Sicht der Core Web Vitals „schlecht“ ist, ist das dasselbe Signal, das sich in der Bewertung in der Suche widerspiegelt.

Und warum insbesondere für die Geschwindigkeit? Geschwindigkeit ist eines der Bewertungssignale. Sie hat Einfluss auf SEO und auf den Klickpreis in PPC, weil eine langsame Zielseite den Quality Score in Google Ads verschlechtert. Wir sehen den Einfluss der Core Web Vitals auf das Geschäft regelmäßig, zum Beispiel bei dem Onlineshop Denatura, wo wir die Geschwindigkeitsoptimierung mit einer kontinuierlichen Analyse in der Search Console verbunden haben und allmählich Verbesserungen der Positionen in der Suche sahen.

Die Search Console zeigt schnell, wo Sie aus Sicht von Google problematische URLs oder Seitengruppen haben.

Wie Google die Geschwindigkeit misst#

Bevor wir uns den Berichten zuwenden, ist es wichtig zu verstehen, wie Google überhaupt die Geschwindigkeit misst. Ohne dieses Verständnis verlieren Sie sich in den Zahlen.

Grundlagen: Metriken, CrUX und Bewertung nach der schlechtesten Metrik#

Die Geschwindigkeit wird durch drei Metriken der Core Web Vitals beschrieben: Ladegeschwindigkeit (LCP), Reaktionsgeschwindigkeit auf Interaktionen (INP) und visuelle Stabilität (CLS). Jede hat ihre Grenzen für „gut“, „verbesserungsbedürftig“ und „schlecht“. Wir analysieren sie ausführlich in separaten Artikeln zu LCP, INP und CLS.

Wichtig ist, woher die Zahlen stammen. Es handelt sich nicht um einmalige Tests, sondern um Daten von echten Chrome-Nutzern aus dem Chrome UX Report (CrUX). Google sammelt die Geschwindigkeit so, wie sie die tatsächlichen Besucher in den letzten 28 Tagen erlebt haben, und zwar getrennt für Mobil- und Desktopgeräte.

Achten Sie auf eine Regel, die selbst Fortgeschrittene verwirrt: Eine Gruppe von Seiten wird nach der schlechtesten Metrik bewertet. Wenn eine Gruppe einen schlechten CLS hat, aber einen hervorragenden INP, gilt die gesamte Gruppe als „schlecht“. Ein Problem reicht aus, und die ganze Gruppe fällt ins Rote.

Drei Ebenen der Geschwindigkeitsmessung#

Geschwindigkeit wird nicht nur auf einer Ebene gemessen. Es lohnt sich, drei zu unterscheiden, da jede eine andere Frage beantwortet und ein anderes Tool hat:

• Domänenebene sagt, wie die gesamte Webseite abschneidet. Diese Daten finden Sie im PageSpeed.ONE-Monitoring und anderen Tools, die mit CrUX arbeiten.
• Ebene der Seitengruppen zeigt, welche Seitentypen die Webseite herunterziehen. Dies ist die Domäne des Core Web Vitals-Berichts in der Search Console.
• Einzelne Seiten bearbeiten Sie, wenn Sie eine URL feinabstimmen müssen. Dafür gibt es den Webgeschwindigkeitstest (Insights) oder die CrUX API.

Drei Ebenen der Messung der Webgeschwindigkeit. Die Search Console deckt hauptsächlich die mittlere Ebene ab, also die Seitengruppen.

Über jede Ebene und darüber, wo die Daten zu finden sind, schreiben wir weiter unten ausführlicher.

Prinzipien: Wem welche Daten zugeordnet werden#

Google ordnet die Geschwindigkeit nicht allen Seiten gleich zu. Es funktioniert in Schritten:

• Wenn eine bestimmte Seite genügend eigenen Verkehr hat, wird sie nach ihren eigenen Core Web Vitals bewertet.
• Wenn die Seite keine eigenen Daten hat, ordnet Google sie einer Gruppe ähnlicher Seiten zu (das sehen Sie in der Search Console) oder verwendet die Bewertung der gesamten Domäne. Der Domänenwert deckt dabei die meisten URLs auf der Webseite ab und ist daher so entscheidend.
• Beachten Sie, dass nicht einmal die Domäne CrUX-Daten haben muss. Bei neuen oder wenig besuchten Webseiten hat Google einfach nicht genug Messungen.

Auf diese Prinzipien folgen weitere CrUX-Regeln, die hier nur am Rande erwähnt werden, aber es ist gut, sie zu kennen: Daten laufen in einem kumulativen 28-Tage-Fenster, sodass Änderungen zeitverzögert auftreten, und bei Single-Page-Applications (SPA) werden einige Metriken anders gemessen. Details finden Sie im Artikel über den Chrome UX Report.

Geschwindigkeitsberichte in der Google Search Console#

Jetzt zum Wesentlichen: Wo man Berichte findet und wie man sie liest, um keine falschen Schlüsse zu ziehen.

Core Web Vitals Bericht#

Den Bericht finden Sie im linken Menü der Search Console im Bereich Seitenerfahrung (Experience), Punkt Core Web Vitals. Es öffnet sich eine Übersicht unterteilt in mobil und desktop. Behandeln Sie immer beide Teile separat, da sich die mobile und die Desktop-Erfahrung normalerweise unterscheiden.

Wenn Sie auf Mobil oder Desktop klicken, gelangen Sie zu den einzelnen Seitengruppen mit einer Problembeschreibung (z. B. „LCP länger als 2,5 s“). Hier ist der größte Hinweis, was zu optimieren ist. Google bietet Ihnen für jede Gruppe auch Beispiele für konkrete URLs.

Vorsicht vor dem irreführenden Core Web Vitals Diagramm#

Das Diagramm im Core Web Vitals Bericht verleitet zu Missverständnissen. Laien denken, es zeige den Wert der Metrik an. Es zeigt jedoch die Anzahl der Seiten im grünen, orangenen und roten Bereich.

Das hat praktische Konsequenzen. Ein Verschieben von Seiten von Orange nach Grün kann beispielsweise eine Verbesserung des LCP von 2,51 s auf 2,49 s bedeuten, bei der nur die Bereichsgrenze überschritten wurde, aber die tatsächliche Geschwindigkeit sich kaum verändert hat. Und umgekehrt muss ein großer Sprung im Diagramm keinen großen Sprung in der wahrgenommenen Geschwindigkeit bedeuten.

Der Bericht in der Search Console zeigt, wie viele URLs in den Bereich „Verbesserung erforderlich“ fallen, nicht den Durchschnittswert der Metrik für die Domäne.

Wie liest man ihn also richtig? Beobachten Sie den Anteil der orangen und roten Seiten. Wenn mehr als 10 % der URLs orange oder rot sind, sollten Sie das unbedingt angehen, um keine Punkte bei Google zu verlieren.

Backend-Antwortbericht#

Der zweite wichtige Bericht ist versteckt und ebenfalls etwas irreführend. Sie finden ihn unter Einstellungen (Settings) im Abschnitt Crawl-Statistiken (Crawl stats), wo Google die durchschnittliche Server-Antwortzeit meldet. Es ist im Wesentlichen TTFB, also die Zeit, bis der Server zu antworten beginnt. Auch wenn der Bericht versteckt ist, ist er aus zwei Gründen sehr wichtig.

Erstens hat die Server-Antwortzeit einen direkten Einfluss auf die Core Web Vitals-Metriken. Ein langsames Backend verzögert das Laden und wirkt sich vor allem auf LCP aus. Zweitens beeinflusst es das sogenannte Crawl-Budget, also wie viele Seiten und wie oft Google bereit ist, zu crawlen. Je langsamer der Server, desto weniger schafft Google. Der Begriff und die Empfehlungen werden in der Google-Dokumentation zum Crawl-Budget beschrieben.

Wie interpretiert man die Antwortzeit?

• Wenn sie langfristig über 0,8 s liegt, sollten Sie das unbedingt mit der Infrastruktur, den Entwicklern oder Experten besprechen.
• Wenn Schwankungen zu schlechteren Zahlen mit dem Traffic korrelieren, verstärken Sie die Infrastruktur, der Server kommt bei Spitzenzeiten nicht hinterher.
• Wenn Schwankungen nicht mit dem Traffic zusammenhängen, könnten Roboter dahinterstecken. Immer häufiger sind es AI-Bots, auf die wir Strategien für AI-Bots haben.

Wie misst man die Geschwindigkeit mit der Google Search Console#

Die Search Console ist ein großartiges Puzzlestück, aber allein reicht sie nicht aus. Lassen Sie uns durchgehen, was Sie daraus gewinnen können und womit Sie sie ergänzen sollten.

Sie brauchen Domänendaten#

Den Domänenblick, also wie es um die Geschwindigkeit der gesamten Webseite im Laufe der Zeit steht, kann die Search Console nicht richtig. Das müssen Sie andernorts haben, im Monitoring. Hier sind drei Dinge entscheidend: Alarme, Langzeitmessung mit Datenhistorie und Debug-Informationen für Entwickler.

In PageSpeed.ONE dient dazu der Domänenbericht mit vollständigen Daten aus CrUX. Sie sehen die Entwicklung nach Tagen und Monaten und Debug-Daten, wie die Aufschlüsselung von LCP in einzelne Teile. Dazu eine kostenlose Testversion, Wächter, die Sie selbst auf Verschlechterungen hinweist, und weitere Funktionen. Das ist genau der Teil, den die Search Console nicht abdeckt, und deshalb kommt man bei ernsthafter Arbeit an der Geschwindigkeit ohne separates Monitoring nicht aus.

Für einmalige Statusabfragen reicht dann der Webgeschwindigkeitstest PageSpeed.ONE oder PageSpeed Insights von Google. Sie eignen sich für eine schnelle Überprüfung, nicht für die Verfolgung der Entwicklung im Laufe der Zeit.

Einzelne URLs#

Konkrete URLs empfehlen wir nur bei wirklich wichtigen Seiten zu behandeln, typischerweise der Homepage, oder bei Webseiten, bei denen Sie bereits Domänen- und Gruppendaten (siehe unten) in Ordnung haben. Es macht keinen Sinn, eine Seite zu optimieren, solange ganze Gruppen kaputt sind.

Sie brauchen Seitengruppen#

Seitengruppen sind die Domäne der Search Console, anderswo bekommen Sie sie nicht so schön zusammen. Arbeiten Sie mit den beiden Berichten, die wir oben beschrieben haben: dem Core Web Vitals Bericht und dem Backend-Antwortbericht. Der erste sagt Ihnen, welche Seitentypen problematisch sind, der zweite deckt einen langsamen Server auf.

Haben Sie das Problem gelöst und es spukt immer noch in der Google Search Console herum?#

Die Search Console hat oft Verzögerungen und ist nicht perfekt genau, sodass sich die Korrektur nicht sofort zeigt. Keine Panik. Nach der Behebung der Probleme können Sie im Core Web Vitals Bericht auf die Schaltfläche Start Tracking (Verfolgung starten) klicken. Ein 28-tägiges Überwachungsfenster wird gestartet, das automatisch überprüft, ob die Korrektur gegriffen hat. Die Zustände der URLs werden dabei als Pending (ausstehend), Passed (bestanden) oder Failed (nicht bestanden) angezeigt.

Was bedeutet „No data available“#

Manchmal stoßen Sie im Bericht auf die Meldung „No data available“ (keine Daten verfügbar). Das bedeutet eines von zwei Dingen: Entweder ist die Property in der Search Console neu und Google hat noch nichts zu zeigen, oder die Webseite hat wenig Traffic und einen Mangel an Daten in CrUX. In beiden Fällen ergänzen Sie den Domänenblick mit synthetischem Messen im Monitoring.

Praktische Checklisten#

Zum Abschluss zwei Listen, an denen Sie sich in der Praxis orientieren können.

Was regelmäßig zu tun ist#

• Überwachen Sie die Domain-Überwachung. Der Domänenblick auf die Geschwindigkeit gibt Ihnen den schnellsten Überblick über den Zustand der gesamten Webseite. Optimalerweise von einem Tool, das sich selbst meldet.
• Überwachen Sie die Seitengruppen in der Search Console. Hier sehen Sie, welche Seitentypen das Rating nach unten ziehen und wo mit den Korrekturen begonnen werden muss.
• Suchen Sie nach Auswirkungen auf SEO und PPC. Verbessern oder verschlechtern Sie die Geschwindigkeit und korrelieren Sie diese mit den Daten aus dem Leistungsbericht (Performance) in der Search Console. Sie sehen, ob es sich auf Positionen und Klicks auswirkt.
• Wählen Sie die richtige Frequenz. Eine kleine Webseite reicht es einmal im Monat zu überprüfen, eine große Webseite ruhig jede Woche bis jeden Tag. Der ideale Zustand ist, wenn sich die Tools selbst melden: Das PageSpeed.ONE Monitoring tut das, in die Search Console müssen Sie manuell schauen.

Was zu tun ist, wenn eine Gruppe in den Core Web Vitals orange oder rot ist#

• Nehmen Sie es als Priorität. Das sind URLs, die eine niedrigere Bewertung erhalten. Finden Sie konkrete Seitenbeispiele in der Gruppe, die Search Console bietet sie Ihnen an.
• Messen Sie diese URLs im Monitoring. Überwachen Sie sie, damit Sie den Verlauf sehen, nicht nur eine Momentaufnahme.
• Schauen Sie sich die Debug-Daten an. Kombinieren Sie synthetisches Messen und CrUX-Debug-Daten, damit Sie genau wissen, was die Metrik verschlechtert.
• Testen Sie die Seite im Browser. Wie das geht, beschreibt der Artikel über Web Vitals im Browser.
• Greifen Sie auf unsere Anleitungen zurück. Schauen Sie je nach problematischer Metrik auf die Optimierung von LCP, INP oder CLS. Für einen schnellen Start: Bei LCP kümmern Sie sich um die Größe und das Format der Bilder und die Server-Antwort, bei INP um unnötigen JavaScript und Drittanbieter-Code, bei CLS geben Sie immer Bildmaße an und reservieren Platz für später ladende Elemente.
• Kommen Sie nicht weiter? Rufen Sie die Experten. Mit der Optimierung und der Datenauswertung helfen wir im Rahmen unserer Dienstleistungen.
• Nach der Korrektur Start Tracking durchführen. Starten Sie die Verfolgung in den Core Web Vitals Berichten und lassen Sie Google die Korrektur überprüfen.