Core Web Vitals-Bericht (Google Search Console)

TL;DR — Der Core Web Vitals-Bericht in der Google Search Console zeigt, wie Ihre Seiten für echte Besucher bei den drei Geschwindigkeits- und Stabilitätsmetriken von Google (LCP, INP, CLS) abschneiden. Es handelt sich um reale Daten von Chrome-Nutzern, gruppiert in Buckets ähnlicher Seiten und aufgeteilt in die Tabs „Mobile“ und „Desktop“. Es ist ein Website-weites Triage-Tool, kein Seiten-für-Seiten-Geschwindigkeitsprüfer – und wenn Sie eine kleine oder neue Website haben, werden möglicherweise gar keine Daten angezeigt.

Was der Core Web Vitals-Bericht ist

Sie finden ihn in der Google Search Console im Abschnitt Experience. Googles eigene Einzeiler-Beschreibung: Der Bericht “shows how your pages perform, based on real world usage data (sometimes called field data).” (Übersetzung) „zeigt, wie Ihre Seiten basierend auf realen Nutzungsdaten (manchmal auch Felddaten genannt) abschneiden.“

Das Wichtigste gleich vorweg: Dies ist ein Bericht, nicht die Metriken selbst. Core Web Vitals – LCP, INP und CLS – sind drei Messungen, wie sich Ihre Seite für einen realen Besucher anfühlt (wie schnell der Hauptinhalt lädt, wie schnell die Seite auf ein Tippen reagiert und wie stark die Dinge beim Laden springen). Diese Metriken werden anderswo auf dieser Website ausführlich definiert. Dieser Artikel handelt von dem Bericht – dem Tool in der Search Console, das Ihnen diese Zahlen anzeigt und sie organisiert.

Woher die Daten kommen

Der Bericht führt keinen Geschwindigkeitstest durch. Er bezieht Felddaten aus dem Chrome User Experience Report (CrUX) – anonymisierte Zeitmessungen von echten Chrome-Nutzern, die Ihre Seiten besucht haben. Das unterscheidet sich von einem Labortest wie PageSpeed Insights, der Ihre Seite einmal in einer kontrollierten Umgebung lädt. Felddaten zeigen, was wirklich mit echten Menschen passiert ist, gemittelt über die letzten 28 Tage.

Wie der Bericht organisiert ist

Drei Dinge sollten Sie darüber wissen, wie er Ihre URLs gruppiert:

• Mobile und Desktop sind separate Tabs. Eine Seite kann gleichzeitig auf Mobilgeräten „Gut“ und auf dem Desktop „Schlecht“ sein. Sie werden nie zusammengemischt.
• Drei Status-Buckets: Schlecht, Verbesserungswürdig und Gut. Der Status einer URL wird durch ihre schlechteste Metrik bestimmt – ein schlechter Wert zieht die gesamte Seite nach unten.
• URLs werden gruppiert, nicht einzeln bewertet. Google bündelt Seiten, die ähnlich sind (normalerweise dieselbe Seitenvorlage), sodass Sie oft sehen, dass ein Problem eine ganze Reihe von URLs gleichzeitig betrifft.

Das, was die meisten falsch verstehen

Dieser Bericht kann Ihnen nicht zuverlässig sagen, ob eine bestimmte Seite langsam ist. Google sagt es deutlich – er ist “not designed [to] find the status of a specific URL, but rather to see your site’s performance as a whole.” (Übersetzung) „ist nicht dafür konzipiert, den Status einer bestimmten URL zu finden, sondern die Leistung Ihrer Website als Ganzes zu sehen.“ Er dient dazu, Website-weite Probleme auf Vorlagenebene zu erkennen. Um eine einzelne Seite zu prüfen, verwenden Sie stattdessen PageSpeed Insights oder das URL Inspection-Tool.

Zwei weitere Dinge, die Sie früh wissen sollten:

• „Keine Daten verfügbar“ ist häufig und normalerweise kein Problem mit Ihren Seiten. Es bedeutet eines von zwei Dingen: Ihre Property ist brandneu in der Search Console, oder es gibt nicht genug Chrome-Traffic für das Gerät, das Sie ansehen (mobil oder Desktop), um die Berichtsschwelle von Google zu überschreiten.
• Es ist etwa einen Monat zurück. Da es sich um einen 28-Tage-Durchschnitt handelt, wird ein Fix, den Sie heute veröffentlichen, hier erst in Wochen vollständig sichtbar sein. Verwenden Sie PageSpeed Insights für schnelleres Feedback.

Möchten Sie die vollständige Mechanik – wie die URL-Gruppierung tatsächlich funktioniert, warum sie nicht mit PageSpeed Insights übereinstimmt, den Validierungs-Workflow und was mit FID passiert ist? Wechseln Sie zum Erweitert-Tab.

TL;DR — Der Core Web Vitals-Bericht zeigt CrUX-Felddaten (28-Tage-Rolling, 75. Perzentil) für Ihre indexierten URLs – er berechnet nichts Neues. Er gruppiert URLs nach Gerät (unabhängige Mobile-/Desktop-Tabs), Status (Schlecht / Verbesserungswürdig / Gut, die schlechteste Metrik gewinnt) und URL-Gruppe (Cluster ähnlich vorlagenbasierter Seiten mit gemeinsamem Status). Nur indexierte URLs erscheinen, und es wird eine Stichprobe angezeigt, nicht jede URL. Wenn eine URL-Gruppe zu klein ist, um privat berichtet zu werden, greift Google auf eine übergeordnete Origin-Gruppe zurück – und wenn selbst diese die Hürde nicht überschreitet, erhalten Sie „Keine Daten verfügbar.” Er stimmt nicht mit PageSpeed Insights überein (Gruppe vs. einzelne URL; GSC behält URL-Parameter bei, PSI entfernt sie). Er dient der seitenweiten Triage, nicht einzelnen URL-Nachfragen. FID wurde am 12. März 2024 entfernt, als INP zu einem Core Web Vital wurde – GSC hat es sofort entfernt, anders als die sechsmonatige Schonfrist von PSI/CrUX. Beheben Sie zuerst „Schlecht”, validieren Sie mit Tracking starten und erwarten Sie, dass die Felddaten nach etwa einem Monat aufholen.

Es ist ein Bericht, keine Neudefinition der Metriken

Der nützlichste Rahmen für diesen Artikel: Der Core Web Vitals-Bericht ist eine Ansicht in bereits vorhandene Daten, keine neue Messung. Google stellt klar, dass “the data for the Core Web Vitals report comes from the CrUX report. The CrUX report gathers anonymized metrics about performance times from actual users visiting your URL (called field data). The CrUX database gathers information about URLs whether or not the URL is part of a Search Console property.” (Übersetzung) „Die Daten für den Core-Web-Vitals-Bericht stammen aus dem CrUX-Bericht. Der CrUX-Bericht sammelt anonymisierte Metriken zu Leistungszeiten tatsächlicher Nutzer, die Ihre URL besuchen (sogenannte Felddaten). Die CrUX-Datenbank sammelt Informationen zu URLs, unabhängig davon, ob die URL Teil einer Search-Console-Property ist.“

Der Bericht enthält also keinerlei Labordaten – keine Lighthouse-Werte, keine synthetischen Tests. Er besteht zu 100 % aus Felddaten: echte Chrome-Nutzer, 28-Tage-Rolling-Fenster, bewertet am 75. Perzentil, nach Gerät aufgeteilt. Die Metrikdefinitionen, Schwellenwerte und das Gewicht des Ranking-Signals stehen im Core Web Vitals-Glossar und im Web Vitals-Thema – ich werde sie hier nicht neu ableiten. Hier geht es um das Tool.

Nur indexierte URLs, und nur eine Stichprobe

Drei Abgrenzungsregeln, die übersehen werden. Erstens, und am grundlegendsten: Eine URL-Gruppe erscheint nur, wenn sie eine Datenschwelle für sowohl LCP als auch CLS überschreitet – wenn eine Gruppe nicht genügend Berichtsdaten für beide hat, wird sie vollständig aus dem Bericht ausgelassen, nicht als bestanden markiert. Zweitens: “Nur indexierte URLs können in diesem Bericht erscheinen. Dieser Bericht ist keine umfassende Liste aller indexierten URLs. Er zeigt eine Stichprobe von Seiten, um Ihnen zu helfen, die Leistung Ihrer Website anhand der Core Web Vitals zu bewerten.” Betrachten Sie ihn also nicht als erschöpfendes Audit. Drittens, eine subtile Regel, die jeden verwirrt, der andere GSC-Berichte gewohnt ist: “Daten werden der tatsächlichen URL zugeordnet, nicht der kanonischen URL, wie in den meisten anderen Berichten.” Die meisten Search Console-Berichte rollen zur kanonischen URL auf; dieser nicht.

Mobile und Desktop sind unabhängige Datensätze

Der Bericht schlüsselt alles nach Gerät auf, und die beiden Tabs sind vollständig getrennt – niemals gemittelt. Eine URL-Gruppe kann gleichzeitig auf Mobilgeräten „Gut” und auf dem Desktop „Verbesserungswürdig” sein, da es sich um unterschiedliche CrUX-Datensätze handelt, die verschiedene Geräte, Netzwerke und CPU-Klassen widerspiegeln. Überprüfen Sie immer beide Tabs; eine „Gut”-Zusammenfassung auf einem kann einen „Schlecht”-Bereich auf dem anderen verbergen.

Status: Die schlechteste Metrik gewinnt

Jede URL-Gruppe landet in einem von drei Bereichen – Schlecht, Verbesserungswürdig oder Gut – und der Status der Gruppe entspricht dem ihrer am schlechtesten abschneidenden Metrik. Eine Gruppe mit gutem LCP und gutem INP, aber schlechtem CLS ist eine „Schlecht”-Gruppe. Diese „Schlechteste Metrik gewinnt”- Regel ist der Grund, warum ein einzelnes instabiles Layout-Element eine ansonsten schnelle Vorlage zunichtemachen kann.

Die zugrunde liegenden Schwellenwerte (LCP ≤ 2,5 s / INP ≤ 200ms / CLS ≤ 0,1 für „Gut“, jeweils beim 75. Perzentil) sind die Metrikdefinitionen, die im Core Web Vitals-Glossar behandelt werden – und es ist erwähnenswert: Nach meinem Forschungsstand führen die aktuellen Search Central-Dokumente immer noch diese ursprünglichen Zahlen auf. Falls Ihnen eine Behauptung begegnet ist, dass Google den „Gut“-LCP-Schwellenwert stillschweigend auf 2,0 Sekunden gesenkt hat oder dass ein Core Update Ende 2025 Core Web Vitals zu einem viel größeren Ranking-Faktor gemacht hat – ich konnte beides nicht anhand einer Google-eigenen Quelle verifizieren, und die Dokumente widersprechen dem. Behandeln Sie das als Gerücht.

URL-Gruppen – das Kernkonzept

Das ist das charakteristische Merkmal des Berichts und die größte Änderung im mentalen Modell für alle, die an die Einzel-URL-Gewohnheit von PageSpeed Insights gewöhnt sind. Google: “URLs in the report are grouped into pages that have a similar user experience. The LCP, INP, and CLS status applies to the entire group. Some outlier URLs might have better or worse values on some visits, but 75% of visits to all URLs in the group experienced the group status shown.” (Übersetzung) „URLs im Bericht werden zu Seiten gruppiert, die eine ähnliche Benutzererfahrung bieten. Der LCP-, INP- und CLS-Status gilt für die gesamte Gruppe. Einige Ausreißer-URLs können bei manchen Besuchen bessere oder schlechtere Werte aufweisen, aber 75 % der Besuche aller URLs in der Gruppe hatten den angezeigten Gruppenstatus.“

John Mueller beschrieb die Mechanik bereits 2021: „Das machen wir mit den Chrome User Experience Report-Daten, den Felddaten aus der realen Welt, im Wesentlichen, wo wir versuchen zu erkennen, wann es Seiten gibt, die ähnlich genug sind, dass wir sie gruppieren könnten.“ Und entscheidend ist, dass die Daten der Gruppe für eine URL einspringen können, die selbst keine Daten hat: „Wenn wir eine neue URL finden, die auch Teil dieser Gruppe ist, müssen wir keine Daten für diese neue URL haben. Wir können uns auf die Daten für die gesamte Gruppe verlassen.“

Das ist auch der Grund, warum der Bericht für das, was eigentlich nur ein Fehler ist, alarmierend aussehen kann. Mueller erneut: „Wir könnten im Wesentlichen eine Gruppe für eine Website haben. Aber diese könnte Tausende von URLs enthalten. Im Bericht in der Search Console würden wir das also wahrscheinlich so melden, dass Tausende von URLs dieses Problem haben.“ Ein Vorlagenfehler, Tausende URLs markiert.

Genau deshalb ist die Gruppierung nützlich und nicht nervig. Wie ich es im Ahrefs Core Web Vitals-Leitfaden formuliert habe: „Diese Gruppierung von Seiten ergibt viel Sinn. Das liegt daran, dass die meisten Änderungen zur Verbesserung der Core Web Vitals für eine bestimmte Seitenvorlage vorgenommen werden, die sich auf viele Seiten auswirkt.“ Und im PageSpeed Insights-Leitfaden: „Der Vorteil der GSC ist, dass sie ähnliche URLs in Gruppen einteilt. Für die gruppierten Seiten werden Sie wahrscheinlich in einem System oder einer Vorlage arbeiten.“ Korrigieren Sie die Vorlage einmal, und Sie korrigieren sie für die gesamte Gruppe. Oder, wie ich es in einem Interview mit Outside Communications formuliert habe: „Im Grunde gibt es hier Gruppen mit Problemen, die wahrscheinlich genau dasselbe Thema haben. Sie beheben es einmal, und Sie beheben dieses Problem für alle diese Seiten.“

Die Datenschutzschwelle und der Fallback auf Ursprungsgruppen

Die Gruppierung ist nicht nur eine Bequemlichkeit – sie ist eine Datenschutzanforderung. Google: „Um die Privatsphäre der Nutzer zu respektieren, muss eine URL-Gruppe eine Mindestmenge an Daten haben, um im Bericht angezeigt zu werden. Wenn eine URL-Gruppe nicht genügend Informationen hat, um im Bericht angezeigt zu werden, erstellt die Search Console eine übergeordnete Ursprungsgruppe, die genügend URLs und Daten enthalten sollte, um im Bericht angezeigt zu werden.“ Die Kaskade ist also: URL-Gruppe → Ursprungsgruppe → nichts. Wenn selbst der Ursprung die Hürde nicht überwinden kann, erhalten Sie „Keine Daten verfügbar.“ Das ist der mechanische Grund, warum Websites mit wenig Traffic breite, grobe Gruppierungen oder gar keine Daten sehen.

Warum eine „Schlechte“ Gruppe trotzdem schnelle Seiten enthalten kann

Da der Status für die gesamte Gruppe beim 75. Perzentil gilt, kann eine einzelne schnelle URL in eine langsame Gruppe geraten. In einer „Schlechten“ Gruppe zu sein, beweist nicht, dass diese URL langsam ist – es bedeutet, dass der Cluster insgesamt ein Problem hat. Gehen Sie nicht davon aus, dass jedes Mitglied schuldig ist; die Gruppe ist die Analyseeinheit.

Den Bericht lesen: Diagramm vs. Tabelle

Ein wirklich verwirrendes Detail, das die meisten Drittanbieter-Leitfäden überspringen. Das Übersichtsdiagramm und die Problemtabelle zählen unterschiedlich: “Das Diagramm zählt jede URL nur einmal, und zwar für das langsamste Problem, das diese URL betrifft. Die Tabelle hingegen zählt jedes Problem, das mit einer URL verknüpft ist.” Eine URL mit einem Problem der Stufe “Schlecht” und einem der Stufe “Verbesserungswürdig” erscheint also einmal (als “Schlecht”) im Diagramm, taucht aber in beiden Zeilen der Tabelle auf. Deshalb stimmen die Summen nicht überein – das ist beabsichtigt, kein Fehler. Wenn Sie auf ein Problem klicken, wie ich es beschreibe, “erhalten Sie eine Aufschlüsselung der betroffenen Seitengruppen”, mit Beispiel-URLs, sortiert nach Impressionen.

Korrekturen validieren: der Workflow “Start Tracking”

Der Bericht enthält eine integrierte Validierungsschleife, die leicht übersehen wird. Google: “When you think a particular issue is fixed, click Start Tracking on the issue details page in the Search Console Core Web Vitals report.” (Übersetzung) „Wenn Sie glauben, dass ein bestimmtes Problem behoben ist, klicken Sie auf der Problemdetailseite im Core Web Vitals-Bericht der Search Console auf Start Tracking.“ Das startet eine 28-tägige Überwachungssitzung für das Problem – Google beobachtet, wie sich die Felddaten der Gruppe über diesen Zeitraum ansammeln, anstatt sie sofort erneut zu prüfen. Drei Dinge, die Sie darüber wissen sollten, wie es aufgelöst wird: Jede einzelne betroffene URL, die während des Zeitraums weiterhin fehlschlägt, kann verhindern, dass das gesamte Problem als bestanden gilt; die Status, die Sie sehen, sind auf Problemebene “Nicht gestartet” / “Gestartet” / “Sieht gut aus” / “Bestanden” / “N/A” / “Fehlgeschlagen” und pro URL “Ausstehend” / “Bestanden” / “Fehlgeschlagen”; und das Klicken auf “Start Tracking” löst kein Reindexing oder anderes aktives Crawl-Verhalten aus – es ist rein ein Überwachungsflag für Daten, die Google bereits sammelt. Dies ist der richtige Weg, um zu bestätigen, dass eine Korrektur im Feld angekommen ist – nicht nur das aggregierte Diagramm anzuschauen und zu hoffen.

Core Web Vitals-Bericht vs. PageSpeed Insights

Diese beiden Tools schöpfen aus derselben CrUX-Quelle, präsentieren sie aber unterschiedlich, und sie werden für eine URL regelmäßig unterschiedliche Ergebnisse liefern. Zwei dokumentierte Gründe:

• Gruppe vs. Einzel-URL. Google: “Core Web Vitals kombiniert Daten und Status zu URL-Gruppen; PageSpeed Insights zeigt in der Regel Daten für einzelne URLs.” Eine einzelne URL kann ein Ausreißer in ihrer Gruppe sein, daher stimmen der Gruppenstatus und die PSI-Zahl für genau diese URL nicht überein.
• URL-Parameter. “Core Web Vitals-URLs enthalten URL-Parameter, wenn die Seite unterschieden wird; PageSpeed Insights entfernt alle Parameterdaten aus der URL und weist dann alle Ergebnisse der nackten URL zu.” Das allein erklärt viele Beschwerden darüber, “warum diese beiden Tools nicht übereinstimmen”.

Es gibt auch einen Unterschied in der Daten-Breite, den man im Blick behalten sollte, denn “Felddaten” und “Labordaten” werden oft ungenau verwendet. Der GSC-Bericht enthält nur CrUX-Felddaten, gruppiert – sonst nichts. PageSpeed Insights vermischt drei verschiedene Dinge: CrUX-Felddaten auf URL-Ebene, einen Fallback auf CrUX-Felddaten auf Ursprungsebene, wenn die URL selbst nicht genügend Daten hat, und einen Live-Lighthouse-Labortest. Wie ich in dem PSI-Leitfaden anmerke, “PageSpeed Insights zieht auch die Seitendaten sowie Ursprungsdaten und Labortestdaten heran, die von Lighthouse stammen.” Der GSC-Bericht hat keine dieser Laborebene – es sind Felddaten, Punkt.

Mein tatsächlicher Workflow und der praktische Tipp, den die meisten Konkurrenzartikel übersehen: Schnell in den Labordaten von PSI diagnostizieren und validieren, langsam aber real in GSC bestätigen. Aus dem PSI-Leitfaden: “Die CWV-Daten werden länger brauchen, um die Auswirkungen von Änderungen zu zeigen, da es sich um einen 28-Tage-Durchschnitt handelt. Verwenden Sie also PSI oder die PSI-Daten in Ahrefs, um zu prüfen, ob Ihre Änderungen die Labortest-Metriken verbessert haben.” Sie erhalten sofortiges Labor-Feedback, dass eine Änderung geholfen hat; dann warten Sie darauf, dass die Felddaten in GSC in den folgenden Wochen aufholen.

”Keine Daten verfügbar” und Websites mit geringem Traffic

Googles eigene Erklärung: „Wenn Sie einen Bildschirm mit der Meldung ‚Keine Daten verfügbar‘ sehen, bedeutet das entweder, dass Ihre Property neu in der Search Console ist oder dass nicht genügend Daten im CrUX-Bericht verfügbar sind, um aussagekräftige Informationen für den gewählten Gerätetyp (Desktop oder Mobil) zu liefern.“ CrUX hat eine Eignungsschwelle – eine URL oder Ursprung benötigt genügend Chrome-Traffic, bevor überhaupt Felddaten erscheinen.

Wie häufig ist das? Sehr häufig. In meiner Studie vom Januar 2022, die CrUX mit 43,66 Mio. eindeutigen Site-Audit-Seiten abglich, „fanden wir nur 5,21 Mio. (~11,9 %), die mindestens eine Core-Web-Vitals-Metrik aufwiesen, und 93 % davon (oder ~4,85 Mio. insgesamt) hatten alle drei Metriken.“ Diese Studie untersuchte den rohen CrUX-Datensatz (dieselbe Quelle, die auch der GSC-Bericht nutzt), nicht GSC selbst, und die Zahl stammt vom Januar 2022 – behandeln Sie die Zahl also als Größenordnung, nicht als aktuellen Prozentsatz. Der Punkt bleibt bestehen: Die meisten Seiten im Web erhalten einfach nicht genug Chrome-Traffic, um Felddaten zu erzeugen, was genau der Grund dafür ist, dass sich der Bericht auf die Gruppierung nach Ursprung stützt und warum so viele Websites nichts sehen. Wenn Sie zu diesen gehören, ist das keine saubere Gesundheitsbescheinigung – testen Sie einzelne URLs stattdessen in PageSpeed Insights oder Lighthouse.

FID ist weg – was sich im März 2024 geändert hat

Bringen Sie das genau richtig, denn veraltete Tutorials zeigen es immer noch falsch. Interaction to Next Paint (INP) ersetzte First Input Delay (FID) als Core Web Vital am 12. März 2024. Das Search-Console-spezifische Detail, das fast niemand behandelt: Laut der web.dev-Ankündigung des Chrome-Teams „wird FID aus der Google Search Console entfernt, sobald INP am 12. März ein Core Web Vital wird. Alle anderen Tools – wie PageSpeed Insights und CrUX – bieten eine sechsmonatige Abkündigungsfrist, um Entwicklern die Möglichkeit zu geben, ihren Code zu aktualisieren.“ GSC hat FID also sofort entfernt, ohne Gnadenfrist, während PSI und CrUX es sechs weitere Monate lang weiter anzeigten. Wenn Sie FID in einem Search-Console-Screenshot sehen, stammt er von vor März 2024.

Was ist aus dem Page Experience-Bericht geworden?

Ein echter, immer noch gesuchter Verwirrungspunkt. Google hat den eigenständigen Page Experience-Bericht – das alte Übersichts-Dashboard, das Core Web Vitals mit HTTPS und anderen UX-Signalen kombinierte – am 19. April 2023 aus der Search Console entfernt. Was überlebt hat: Der Core Web Vitals-Bericht und der HTTPS-Bericht existieren beide weiterhin als eigenständige Berichte. Nur die kombinierte Zusammenfassung ist verschwunden. Wenn Sie also nach einem „Page Experience“-Dashboard suchen und es nicht finden können, ist das der Grund – die beiden darunterliegenden Berichte sind weiterhin vorhanden. (Verwandte Berichte wie der Performance-Bericht und der Page Indexing-Bericht decken den Rest Ihrer Search-Console-Präsenz ab.)

Priorisieren und Beheben dessen, was der Bericht findet

Google unterteilt seine eigene Anleitung in nicht-technische und Entwickler-Tracks – ein netter Hinweis darauf, dass dieser Bericht von sehr unterschiedlichen Zielgruppen gelesen wird. Die Priorisierungsregel für alle: Beheben Sie zuerst „Schlecht“, dann „Verbesserungsbedürftig“. Für Entwickler sind die URLs innerhalb einer Gruppe nach Impressionen absteigend sortiert, sodass diejenigen oben den Gruppenstatus am stärksten beeinflussen.

Die häufigen Seiten-Level-Fixes, die Google nennt, sind unverblümt, aber real: “Reduce your page size: best practice is less than 500KB for a page and all its resources.” (Übersetzung) „Reduzieren Sie Ihre Seitengröße: Best Practice ist weniger als 500KB für eine Seite und alle ihre Ressourcen.“ Darüber hinaus gehört das eigentliche Wie zur Verbesserung von LCP, INP und CLS zu den einzelnen Metrik-Themen – ich werde es hier nicht duplizieren. Die Aufgabe des Berichts ist es, Ihnen zu sagen, welche Vorlagen Sie reparieren sollen, nicht sie für Sie zu reparieren.

Warum hat sich mein Status geändert, obwohl ich nichts angefasst habe?

Sehr häufig und normalerweise kein Fehler. Googles eigene Fehlerbehebung: “Wenn Sie keine Änderungen an Ihrer Website vorgenommen haben, aber eine große Änderung im Status für viele Seiten sehen, ist es möglich, dass Sie für viele Seiten einen Grenzstatus hatten und ein websiteweites Ereignis Ihre Seiten über die Kante gestoßen hat.” Verschiebungen im Traffic-Mix, eine Latenzänderung bei CDN oder Bild-Hosting, ein weit verbreitetes Browser-Update – all das kann eine Gruppe bereits grenzwertiger URLs gleichzeitig über eine Schwelle heben, da der Bericht ein 28-Tage-p75-Aggregat ist.

Und manchmal schwankt nur die Anzahl der förderfähigen URLs. Während einer Episode im Juli 2025, in der die Anzahl der URLs mit förderfähigen Daten sank (insbesondere bei Mobilgeräten), charakterisierte John Mueller diese Art von Bewegung als normale Stichprobengrößen-Variation, nicht als Problem – dass diese Berichte auf Stichproben dessen basieren, was Google über eine Website weiß, dass sich die Stichprobengrößen ändern und das nicht auf ein Problem hindeutet. Googles Barry Pollard, der am Core Web Vitals-Projekt arbeitet, erkannte den Rückgang an und sagte, dass ein Fix ausgerollt wird. Der Lernpunkt: Die Anzahl der förderfähigen URLs und die zugrunde liegende Metrikqualität sind zwei verschiedene Dinge – eine sich ändernde Stichprobe bedeutet nicht, dass Ihre Seiten langsamer geworden sind.

Beeinflusst der Bericht das Ranking?

Der Bericht spiegelt dieselben Felddaten wider, die Googles Ranking-Systeme berücksichtigen können, aber Vertreter haben Core Web Vitals durchweg als ein geringes, Tie-Breaker-Level-Signal neben der Inhaltsrelevanz dargestellt – die ausführlichere Diskussion zum Ranking-Gewicht finden Sie im Core Web Vitals-Glossar, daher halte ich es hier auf eine Zeile. Meine ehrliche Einschätzung: Ich glaube nicht, dass das Erreichen dieser Schwellenwerte heute viel bewegt, obwohl Google das Signal im Laufe der Zeit stärker gewichten könnte, so wie es es schließlich mit Mobile-Friendliness und HTTPS getan hat. Es gibt auch einen nicht-Ranking-Grund, sich darum zu kümmern, der übersehen wird: Schnellere Seiten erfassen mehr aufgezeichnete Daten (CrUX und Ihre eigenen Analysen), weil weniger Nutzer abspringen, bevor die Seite fertig geladen ist. Die Verbesserung dieser Metriken hilft hauptsächlich, weil sie ein Proxy für eine wirklich bessere Erfahrung ist.

Ein kurzer Hinweis zu Bing

Es gibt kein direktes Bing-Äquivalent – einen dedizierten, CrUX-artigen Core Web Vitals-Bericht mit URL-Gruppierung – in Bing Webmaster Tools. Bing zentriert seine Berichterstattung auf einen Performance Report (Klicks/Impressionen) und ein Site Scan technisches Audit, anstatt auf eine Felddaten-Core Web Vitals-Aufschlüsselung. Bing verweist in seinen Leitlinien auf Core Web Vitals-artige Metriken, hat aber keinen gruppierten Felddaten-Bericht veröffentlicht, der mit dem von Google vergleichbar ist. Bings Tooling ändert sich ziemlich oft, also überprüfen Sie die aktuellen Bing Webmaster Tools-Dokumente, wenn das für Sie wichtig ist.

Wo das einzuordnen ist

Dieser Bericht ist einer von mehreren in der Google Search Console. Der Performance Report deckt ab, wie Sie tatsächlich in der Suche abgeschnitten haben (Klicks, Impressionen, Position); der Page Indexing Report deckt die Abdeckungs-/Indexierungsseite ab. Die Metriken, die dieser Bericht aufzeigt – Core Web Vitals, CrUX und PageSpeed Insights als Begleiter für Labordaten – sind ihre eigenen tiefgehenden Betrachtungen im Web-Performance-Cluster.

KI-Zusammenfassung

Eine komprimierte Sicht auf die Advanced-Version:

• Es ist ein Bericht, nicht die Metriken. Der Core Web Vitals-Bericht (GSC → Erfahrung) zeigt CrUX-Felddaten (28-Tage-Rolling, 75. Perzentil) für Ihre indexierten URLs. Er berechnet nichts Neues und enthält keine Labordaten.
• Drei Gruppierungen: Gerät (unabhängige Mobile/Desktop-Tabs, nie gemittelt), Status (Schlecht / Verbesserungswürdig / Gut, die schlechteste Metrik gewinnt) und URL-Gruppe (Cluster ähnlich vorlagenbasierter Seiten mit gemeinsamem Status).
• URL-Gruppen sind die atomare Einheit — nicht einzelne URLs. Eine Vorlagenkorrektur kann Tausende markierte URLs bereinigen (Mueller). Eine „Schlecht“-Gruppe kann dennoch schnelle Seiten enthalten.
• Datenschutz-Kaskade: URL-Gruppe → Ursprungsgruppe → „Keine Daten verfügbar.“ Neue Seiten mit wenig Traffic sehen oft nichts; nur etwa 12 % der Seiten hatten in Patricks Studie von 2022 CrUX-Daten.
• Stimmt nicht mit PageSpeed Insights überein: Gruppen- vs. Einzel-URL-Daten, und GSC behält URL-Parameter bei, während PSI sie auf die nackte URL reduziert.
• Eignungs-Gate: Eine URL-Gruppe benötigt Schwellenwerte für sowohl LCP als auch CLS, bevor sie überhaupt erscheint — fehlt es an einem, wird sie ausgelassen, nicht als bestanden markiert. Nur indexierte URLs, und nur eine Stichprobe; Daten werden der tatsächlichen URL zugeordnet, nicht der kanonischen.
• Diagramm vs. Tabelle zählen unterschiedlich (Diagramm = jede URL einmal nach schlechtestem Problem; Tabelle = jedes Problem), daher stimmen die Summen nicht überein.
• FID am 12. März 2024 entfernt, als INP zu einer Core Web Vital wurde — GSC hat es sofort entfernt, im Gegensatz zur sechsmonatigen Schonfrist von PSI/CrUX.
• Page Experience-Bericht im April 2023 entfernt; Core Web Vitals- und HTTPS-Berichte bleiben bestehen.
• Workflow: Zuerst „Schlecht“ beheben, mit Start Tracking validieren — eine 28-Tage-Überwachungssitzung, bei der jede weiterhin fehlschlagende URL einen Bestehen verhindert und nichts neu indexiert wird — schnell in PSI diagnostizieren und etwa einen Monat warten, bis die Felddaten aufholen. Statusänderungen ohne Seitenänderungen sind normalerweise Grenzfälle, die über einen Schwellenwert kippen, oder Stichprobengrößen-Rauschen.

Offizielle Dokumentation

Primärquellen-Dokumentation von Google.

Google

• Core Web Vitals-Bericht — die kanonische Hilfeseite: Datenquelle (CrUX), Geräte-/Status-/URL-Gruppen-Organisation, „Keine Daten verfügbar“, den Ursprungsgruppen-Fallback, Diagramm-vs.-Tabelle-Zählung, PageSpeed Insights-Unterschiede und den Start-Tracking-Validierungsworkflow.
• Interaction to Next Paint wird am 12. März zu einer Core Web Vital — die Ankündigung des Chrome-Teams, einschließlich der Search-Console-spezifischen Zeile, dass FID sofort aus GSC entfernt wurde (im Gegensatz zur sechsmonatigen Schonfrist in PSI/CrUX).
• Einführung von INP in Core Web Vitals — die Ankündigung von Google Search Central vom Mai 2023 zum Übergang von FID zu INP.
• Core Web Vitals und Google-Suchergebnisse verstehen — die Übersicht von Search Central mit den aktuellen Schwellenwerten (zum Zeitpunkt der Recherche noch 2,5 s / 200ms / 0,1).

Zitate aus der Quelle

Aussagen von Google, die auf dem Record stehen. Jeder Link ist ein Deep Link, der direkt zur zitierten Passage auf der Quellseite springt.

Google — was der Bericht ist und woher die Daten stammen

• “The Core Web Vitals report shows how your pages perform, based on real world usage data (sometimes called field data).” (Übersetzung) „Der Bericht zu den Core Web Vitals zeigt, wie Ihre Seiten auf der Grundlage von Daten aus der realen Nutzung (manchmal auch Felddaten genannt) abschneiden.“ — Search Console-Hilfe. Zum Zitat springen
• “The data for the Core Web Vitals report comes from the CrUX report… The CrUX database gathers information about URLs whether or not the URL is part of a Search Console property.” (Übersetzung) „Die Daten für den Bericht zu den Core Web Vitals stammen aus dem CrUX-Bericht … Die CrUX-Datenbank sammelt Informationen über URLs, unabhängig davon, ob die URL Teil einer Search Console-Property ist.“ Zum Zitat springen
• “Only indexed URLs can appear in this report. This report isn’t a comprehensive list of all indexed URLs. It shows a sample of pages to help you assess your site’s performance based on Core Web Vitals.” (Übersetzung) „In diesem Bericht können nur indexierte URLs erscheinen. Dieser Bericht ist keine vollständige Liste aller indexierten URLs. Er zeigt eine Stichprobe von Seiten, die Ihnen helfen soll, die Leistung Ihrer Website anhand der Core Web Vitals zu bewerten.“ Zum Zitat springen
• “Data is assigned to the actual URL, not the canonical URL, as it is in most other reports.” (Übersetzung) „Die Daten werden der tatsächlichen URL zugeordnet, nicht der kanonischen URL, wie es in den meisten anderen Berichten der Fall ist.“ Zum Zitat springen

Google – URL-Gruppen und der Datenschutz-Fallback

• “URLs in the report are grouped into pages that have a similar user experience. The LCP, INP, and CLS status applies to the entire group. Some outlier URLs might have better or worse values on some visits, but 75% of visits to all URLs in the group experienced the group status shown.” (Übersetzung) „Die URLs im Bericht werden zu Seiten mit einer ähnlichen Benutzererfahrung gruppiert. Der Status für LCP, INP und CLS gilt für die gesamte Gruppe. Einige Ausreißer-URLs können bei manchen Besuchen bessere oder schlechtere Werte aufweisen, aber 75 % der Besuche aller URLs in der Gruppe hatten den angezeigten Gruppenstatus.“ Zum Zitat springen
• “In order to respect user privacy, a URL group must have a minimum amount of data to be shown in the report. If a URL group doesn’t have enough information to display in the report, Search Console creates a higher-level origin group that should contain enough URLs and data to show in the report.” (Übersetzung) „Um die Privatsphäre der Nutzer zu respektieren, muss eine URL-Gruppe über eine Mindestmenge an Daten verfügen, um im Bericht angezeigt zu werden. Wenn eine URL-Gruppe nicht genügend Informationen für die Anzeige im Bericht enthält, erstellt die Search Console eine übergeordnete Ursprungsgruppe, die genügend URLs und Daten enthalten sollte, um im Bericht angezeigt zu werden.“ Zum Zitat springen

Google – Bericht lesen und Korrekturen validieren

• “The chart counts each URL only once, for the slowest issue affecting that URL. The table, in contrast, counts every issue associated with a URL.” (Übersetzung) „Das Diagramm zählt jede URL nur einmal, und zwar für das langsamste Problem, das diese URL betrifft. Die Tabelle hingegen zählt jedes Problem, das mit einer URL verbunden ist.“ Zum Zitat springen
• “The report is not designed find the status of a specific URL, but rather to see your site’s performance as a whole, and troubleshoot issues affecting multiple pages on your site.” (Übersetzung) „Der Bericht ist nicht dazu gedacht, den Status einer bestimmten URL zu ermitteln, sondern die Leistung Ihrer Website als Ganzes zu betrachten und Probleme zu beheben, die mehrere Seiten Ihrer Website betreffen.“ Zum Zitat springen
• “When you think a particular issue is fixed, click Start Tracking on the issue details page in the Search Console Core Web Vitals report.” (Übersetzung) „Wenn Sie glauben, dass ein bestimmtes Problem behoben ist, klicken Sie auf der Detailseite des Problems im Core Web Vitals-Bericht der Search Console auf „Start Tracking“.“ Zum Zitat springen

Google – im Vergleich zu PageSpeed Insights und „Keine Daten verfügbar“

• “Core Web Vitals combines data and status into URL groups; PageSpeed Insights generally shows data for individual URLs.” (Übersetzung) „Core Web Vitals fasst Daten und Status in URL-Gruppen zusammen; PageSpeed Insights zeigt in der Regel Daten für einzelne URLs an.“ Zum Zitat springen
• “Core Web Vitals URLs include URL parameters when distinguishing the page; PageSpeed Insights strips all parameter data from the URL, and then assigns all results to the bare URL.” (Übersetzung) „Core-Web-Vitals-URLs enthalten URL-Parameter, wenn die Seite unterschieden wird; PageSpeed Insights entfernt alle Parameterdaten aus der URL und weist dann alle Ergebnisse der nackten URL zu.“ Zum Zitat springen
• “If you see a ‘No data available’ screen, it means either that your property is new in Search Console, or that there is not enough data available in the CrUX report to provide meaningful information for the chosen device type (desktop or mobile).” (Übersetzung) „Wenn Sie einen Bildschirm mit ‚No data available‘ sehen, bedeutet das entweder, dass Ihre Property neu in der Search Console ist oder dass im CrUX-Bericht nicht genügend Daten verfügbar sind, um aussagekräftige Informationen für den gewählten Gerätetyp (Desktop oder Mobil) zu liefern.“ Zum Zitat springen

Google — FID → INP in der Search Console (Chrome-Team, web.dev)

• “FID will be removed from Google Search Console as soon as INP becomes a Core Web Vital on March 12. All other tools—such as PageSpeed Insights and CrUX—will offer a six-month deprecation period to give developers a chance to update their code.” (Übersetzung) „FID wird aus der Google Search Console entfernt, sobald INP am 12. März zu einer Core Web Vital wird. Alle anderen Tools – wie PageSpeed Insights und CrUX – bieten eine sechsmonatige Übergangsfrist, um Entwicklern die Möglichkeit zu geben, ihren Code zu aktualisieren.“ Zum Zitat springen

John Mueller, Google — warum der Bericht URLs gruppiert (2021)

• “We do that with the Chrome User Experience Report data, the field real-world data, essentially, where we try to recognize when there are pages that are similar enough that we could group them together.” (Übersetzung) „Das machen wir mit den Daten des Chrome User Experience Reports, den Felddaten aus der realen Welt, wo wir im Wesentlichen versuchen zu erkennen, wann Seiten ähnlich genug sind, dass wir sie zusammenfassen könnten.“
• “We might have one group, essentially, for a site. But that could contain thousands of URLs. So, in the report in Search Console, I think we would report that as thousands of URLs have this problem.” (Übersetzung) „Wir könnten im Wesentlichen eine Gruppe für eine Website haben. Aber diese könnte Tausende von URLs enthalten. Im Bericht in der Search Console würden wir das also, glaube ich, so melden, dass Tausende von URLs dieses Problem haben.“ Zur Berichterstattung

Welches Tool (oder welchen Weg) sollte ich wählen?

„Ich möchte die Core Web Vitals einer bestimmten Seite prüfen.“ → Nicht dieser Bericht. Verwenden Sie PageSpeed Insights (Feld- und Labordaten für diese URL) oder das URL Inspection-Tool. Der Core-Web-Vitals-Bericht ist „nicht dafür ausgelegt, den Status einer bestimmten URL zu ermitteln.“

„Der Bericht zeigt ‚No data available‘ an.“ → Ist die Property brandneu? Geben Sie CrUX ein paar Tage Zeit, um Daten zu sammeln. → Andernfalls liegt es mit ziemlicher Sicherheit an unzureichendem Traffic – selbst die Origin-Gruppe kann die Datenschutzschwelle nicht überschreiten. Testen Sie einzelne URLs stattdessen in PageSpeed Insights / Lighthouse. „No data“ ist kein Freibrief für einwandfreie Leistung.

„Eine Gruppe ist ‚Poor‘ – was behebe ich zuerst?“ → Beheben Sie alles, was als Poor gekennzeichnet ist, bevor Sie etwas beheben, das als Need improvement gekennzeichnet ist. → Innerhalb einer Gruppe sind die URLs nach Impressionen absteigend sortiert – die oben stehenden beeinflussen den Gruppenstatus am stärksten. → Der Status wird durch die schlechteste Metrik der Gruppe bestimmt – finden Sie heraus, welche von LCP / INP / CLS fehlschlägt, und beheben Sie diese.

„Mein GSC-Status und PageSpeed Insights widersprechen sich für dieselbe URL.“ → Das ist zu erwarten. GSC meldet die Gruppe; PSI meldet die einzelne URL (die ein Ausreißer sein kann). Und GSC behält URL-Parameter bei, während PSI sie auf die nackte URL reduziert. Keines ist falsch – sie messen unterschiedliche Dinge.

„Ich habe einen Fix ausgerollt – wie bestätige ich, dass er funktioniert hat?“ → Prüfen Sie sofort das Labor-Ergebnis in PageSpeed Insights für schnelles Feedback. → Klicken Sie in GSC auf Start Tracking für das Problem, um es im Feld zu validieren. → Dann warten Sie – das 28-Tage-Rolling-Fenster bedeutet, dass der Bericht etwa einen Monat braucht, um die Änderung vollständig widerzuspiegeln.

„Mein Status hat sich geändert, aber ich habe die Website nicht angefasst.“ → Meistens Grenzfälle-URLs, die durch eine externe Verschiebung (Traffic-Mix, CDN-/Bildlatenz, ein Browser-Update) eine Schwelle überschreiten – oder schlicht Stichprobengrößen-Schwankungen. Prüfen Sie, ob sich die Anzahl der berechtigten URLs oder die zugrunde liegende Metrikqualität ändert; das sind zwei verschiedene Dinge.

Core Web Vitals-Bericht lesen – eine Checkliste zur Plausibilitätsprüfung

Ein kurzer Durchlauf, bevor Sie Schlussfolgerungen ziehen oder einem Entwickler eine Aufgabenliste übergeben:

• Sie haben sowohl die Tabs „Mobile“ als auch „Desktop“ geprüft – sie sind unabhängig und können voneinander abweichen.
• Sie behandeln URL-Gruppen, nicht einzelne URLs, als Einheit – eine Korrektur behebt wahrscheinlich die gesamte Gruppe.
• Sie verstehen, dass eine „Schlecht“-Gruppe schnelle Seiten enthalten kann (Gruppenstatus ist p75 über das Cluster).
• Sie wissen, dass Diagramm und Tabelle nicht übereinstimmen (Diagramm zählt jede URL einmal nach schwerwiegendstem Problem; Tabelle zählt jedes Problem).
• Sie beheben „Schlecht“ vor „Verbesserungswürdig“ und priorisieren nach den URLs mit den meisten Impressionen.
• Sie haben identifiziert, welche Metrik (LCP / INP / CLS) den Status jeder Gruppe festlegt, bevor Sie Code anfassen.
• Für Einzel-URL-Prüfungen haben Sie zu PageSpeed Insights / URL Inspection gewechselt, nicht zu diesem Bericht.
• Sie erwarten nicht, dass GSC mit PageSpeed Insights übereinstimmt (Gruppe vs. URL; Parameter beibehalten vs. entfernt).
• Wenn Sie „Keine Daten verfügbar“ sehen, haben Sie Traffic/Berechtigung geprüft, statt anzunehmen, dass Ihre Seiten in Ordnung sind.
• Nach einer Korrektur haben Sie Tracking starten geklickt und geben den Felddaten ~einen Monat Zeit, um aufzuholen.
• Sie jagen keiner Statusänderung hinterher, die wirklich Grenzschwellen- oder Stichprobengrößen-Rauschen ist.

Die Denkmodelle

1. Es ist ein Bericht, kein Messgerät. Jede Zahl sind CrUX-Felddaten – echte Chrome-Nutzer, 28-Tage-Rolling-Fenster, 75. Perzentil. Der Bericht zeigt diese Daten an; er berechnet nichts Neues und hat keine Laborebene. Er beschreibt also immer die jüngste Vergangenheit, nie „jetzt gerade“.

2. Die URL-Gruppe ist das Atom. Hören Sie auf, in einzelnen URLs zu denken. Google gruppiert ähnlich vorlagenbasierte Seiten, weist der gesamten Gruppe einen Status zu und kann Tausende von URLs aufgrund eines einzigen Vorlagenfehlers kennzeichnen. Korrigieren Sie die Vorlage einmal, korrigieren Sie die Gruppe. Eine schnelle URL kann trotzdem in einer „Schlecht“-Gruppe liegen.

3. Die schlechteste Metrik gewinnt. Der Status einer Gruppe wird durch ihre schwächste Metrik von LCP / INP / CLS bestimmt. Bevor Sie etwas optimieren, finden Sie heraus, welche Metrik fehlschlägt – Sie beheben nicht „die Gruppe“, sondern die Metrik, die sie nach unten zieht.

4. Die Datenschutzkaskade erklärt die Lücken. URL-Gruppe → Ursprungsgruppe → „Keine Daten verfügbar.“ Nicht genug Traffic für eine private Berichterstattung bedeutet grobe Gruppierungen oder gar nichts. „Keine Daten“ bedeutet unzureichende CrUX-Daten, nicht eine saubere Website.

5. Zwei Tools, zwei Aufgaben – schnell diagnostizieren, langsam bestätigen. PageSpeed Insights = einzelne URL, Feld + Labor, sofortiges Feedback. Der GSC-Bericht = gruppiert, nur Feld, ~einen Monat verzögert. Diagnostizieren und validieren Sie eine Korrektur in den Labordaten von PSI; warten Sie auf die GSC-Felddaten, um sie in der realen Welt zu bestätigen.

Core Web Vitals-Bericht – Spickzettel

So ist er organisiert

GSC-Bericht vs. PageSpeed Insights

Schnelle Fakten

• Datenquelle: CrUX-Felddaten, 28-Tage-Rolling, p75, pro Gerät.
• Nur indexierte URLs; eine Stichprobe, nicht alle; zugeordnet zur tatsächlichen URL, nicht zur kanonischen.
• „Keine Daten verfügbar“ = neue Property oder unzureichender CrUX-Traffic (URL-Gruppe → Ursprungsgruppe → nichts).
• Diagramm zählt jede URL einmal (schwerwiegendstes Problem); Tabelle zählt jedes Problem — die Summen stimmen nicht überein.
• FID aus GSC entfernt am 12. März 2024 (sofort; PSI/CrUX behielten es 6 weitere Monate).
• Page Experience-Bericht entfernt am 19. April 2023; Core Web Vitals- und HTTPS-Berichte bleiben bestehen.
• Beheben Sie zuerst Poor, validieren Sie mit Start Tracking, rechnen Sie mit ~28 Tagen, bis der Bericht dies widerspiegelt.
• Faustregel für Seitengewicht (Google): unter 500KB für eine Seite und alle ihre Ressourcen.

Fehler im Core Web Vitals-Bericht

Jede URL in einer Poor-Gruppe als einzeln langsam behandeln. Der Status gehört zur Gruppe am 75. Perzentil, daher kann ein einzelnes Mitglied schneller oder langsamer sein. Diagnostizieren Sie repräsentative URLs und beheben Sie dann die gemeinsame Vorlage oder Komponente.

Nur Mobile oder nur Desktop prüfen. Die Datensätze sind getrennt und können sich unterscheiden. Prüfen Sie beide Tabs unabhängig voneinander, anstatt sie zu einer Geschichte zusammenzufassen.

„Keine Daten verfügbar“ als Bestehen bezeichnen. Es bedeutet normalerweise, dass der URL oder Ursprung nicht genügend berechtigten CrUX-Traffic für einen Bericht hat. Verwenden Sie Labortests und andere Felddatenquellen; behaupten Sie nicht, dass die Seite Good ist.

Erwarten, dass GSC mit PageSpeed Insights für eine URL übereinstimmt. GSC meldet Gruppen und behält URL-Parameter bei; PSI meldet in der Regel eine einzelne nackte URL. Verstehen Sie die Einheit und URL-Behandlung, bevor Sie eine Differenz als Fehler behandeln.

Die Metrik optimieren, die bereits Good ist. Die schwächste Metrik der Gruppe bestimmt ihren Status. Stellen Sie fest, ob LCP, INP oder CLS verantwortlich ist, bevor Sie einem Entwickler Arbeit übergeben.

Start Tracking unmittelbar nach einer reinen Labor-Fix-Behebung aufrufen. Verifizieren Sie zuerst, dass die Änderung auf allen betroffenen Vorlagen bereitgestellt ist. Starten Sie dann die Feldvalidierung einmal und lassen Sie das rollierende CrUX-Fenster echte Nutzerdaten sammeln.

Die Diagramm- und Tabellensummen als Abgleichprüfung verwenden. Das Diagramm zählt jede URL einmal nach ihrem schwerwiegendsten Problem; die Tabelle zählt jedes Problem, das einer URL zugeordnet ist. Unterschiedliche Summen sind zu erwarten.

Eine Core Web Vitals-Behebung validieren

Verwenden Sie drei Beweisebenen. Keine einzelne Ebene reicht für sich allein aus.

1. Bereitstellungsnachweis

• Reproduzieren Sie die langsame Interaktion, das instabile Element oder das spät ladende größte Element auf einer repräsentativen betroffenen URL.
• Bestätigen Sie, dass der geänderte Code in der Produktion vorhanden ist — nicht nur in einer Vorschau — und auf jeder Vorlage, die durch die URL-Gruppe repräsentiert wird.
• Führen Sie Lighthouse oder eine andere Labor-Trace vorher und nachher unter denselben Testbedingungen aus. Die gezielte Metrik sollte sich verbessern, ohne dass sich ein anderes Core Web Vital verschlechtert.

2. Berichts-Workflow-Nachweis

• Öffnen Sie die genaue Problemzeile und notieren Sie Gerät, Status, Metrik, URL-Gruppe und Beispiel-URLs.
• Überprüfen Sie Beispiele in PageSpeed Insights stichprobenartig und denken Sie daran, dass eine einzelne URL von ihrer GSC-Gruppe abweichen kann.
• Klicken Sie Start Tracking erst, nachdem der Produktions-Rollout abgeschlossen ist. Beobachten Sie den Validierungsstatus des Problems, anstatt es wiederholt neu zu starten.

3. Feldergebnis-Nachweis

• Warten Sie, bis das 28-Tage-Rolling-CrUX-Fenster die Besuche nach der Veröffentlichung aufnimmt.
• Bestätigen Sie, dass sich die betroffene Gruppe auf demselben Gerät und derselben Metrik verbessert, die ursprünglich fehlgeschlagen sind.
• Prüfen Sie sowohl Mobile als auch Desktop und unterscheiden Sie eine echte Metrikverbesserung von einer Änderung, welche URLs genügend Daten hatten, um berechtigt zu sein.
• Wenn GSC unverändert bleibt, vergleichen Sie die Beispiel-URLs der Gruppe mit URL- und Ursprungs- ebenen PSI-Daten, bevor Sie entscheiden, dass die Bereitstellung fehlgeschlagen ist.

Die Bestehensbedingung ist nicht „Lighthouse wurde einmal grün“. Sie lautet: Die Produktionsbehebung ist in der gesamten Gruppe vorhanden, kontrollierte Laborbelege verbessern sich und das relevante GSC-Feldproblem klärt sich, nachdem genügend echte Nutzerdaten eingetroffen sind.

Fortschritt messen, ohne einen Leistungswert zu erfinden

Verfolgen Sie diese getrennt nach Gerät, Metrik, URL-Gruppe und Veröffentlichungsdatum:

Verwenden Sie die von Google veröffentlichten „Gut“-Schwellenwerte – LCP bei oder unter 2,5 Sekunden, INP bei oder unter 200 Millisekunden und CLS bei oder unter 0,1, gemessen am 75. Perzentil – als Qualitätsmaßstab. Erfinden Sie keine universelle Frist oder ein prozentuales Verbesserungsziel. Der nützliche Trend ist weniger förderfähige URLs in fehlgeschlagenen Gruppen, geklärte Problemvalidierungen und stabile Gewinne über aufeinanderfolgende 28-Tage-Fenster, ohne eine Metrik gegen eine andere einzutauschen.

Ressourcen, die Ihre Zeit wert sind

Meine verwandten Artikel

• Was sind Core Web Vitals (CWVs) und wie verbessert man sie? – mein Leitfaden zu den Metriken selbst und wie der GSC-Bericht betroffene Seiten nach Vorlage gruppiert.
• Google PageSpeed Insights für SEOs und Entwickler – der Lab-Daten-Begleiter und mein Workflow “diagnose in PSI, monitor in GSC” (Übersetzung) „Diagnose in PSI, überwachen in GSC“ (der Tipp zur 28-Tage-Verzögerung befindet sich hier).
• Core Web Vitals Datenstudie mit CrUX und 5,2 Millionen Seiten – mein groß angelegter Blick darauf, wie wenige Seiten überhaupt CrUX-Daten haben (die ~12-%-Zahl), was die meisten „Keine Daten verfügbar“-Bildschirme erklärt.

Meine Vorträge / Interviews

• Googles Core Web Vitals für KMU: Ein Gespräch mit Patrick Stox (Outside Communications) – eine kurze, nicht-technische Erklärung, wofür der Bericht da ist: „Sie beheben es einmal, Sie beheben dieses Problem für alle diese Seiten.“

Offiziell

• Core Web Vitals-Bericht – Search Console-Hilfe – die kanonische Referenz für alles in diesem Artikel.
• INP wird am 12. März zu einer Core Web Vital – web.dev – das Detail, dass FID sofort aus GSC entfernt wurde.

Aus der Branche

• Google erläutert die Gruppierung von URLs für Core-Web-Vitals-Werte (Search Engine Journal) — das John-Mueller-Office-Hours-Transkript darüber, warum eine Gruppe Tausende von URLs kennzeichnen kann.
• Google Search Console: So verwenden Sie den Core-Web-Vitals-Bericht (DebugBear) — eine praktische Anleitung von der Einrichtung bis zur Behebung und eine gute Erklärung, warum schnelle Seiten in langsamen Gruppen landen können.
• Core Web Vitals in der Google Search Console: Beheben und optimieren (Quattr) — ein strukturierter Optimierungsworkflow (sortieren → priorisieren → testen → beheben → validieren).
• Google Search Console: Page-Experience-Bericht wird eingestellt (Search Engine Land) — Berichterstattung über die Entfernung des Page-Experience-Rollups im April 2023.
• Core-Web-Vitals-Bericht in der Google Search Console aktualisiert (Search Engine Land) — die Ergänzung der Fallback-Ebene für Ursprungsgruppen im März 2023.
• Google-Core-Web-Vitals-Update in der Search Console (Search Engine Roundtable) — der Rückgang der berechtigten URLs im Juli 2025, mit Mueller und Pollard zur Schwankung der Stichprobengröße.

Zahlen, die man zitieren sollte

• Nur etwa 12 % der 43,66 Mio. eindeutigen Seiten im Site-Audit-Beispiel von Januar 2022 hatten eine CrUX-Metrik. In meiner Studie heißt es: “We found only 5.21M (~11.9%) had at least one Core Web Vitals metric, and 93% of those (or ~4.85M total) had all three metrics.” (Übersetzung) „Wir fanden, dass nur 5,21 Mio. (~11,9 %) mindestens eine Core-Web-Vitals-Metrik hatten und 93 % davon (oder insgesamt etwa 4,85 Mio.) alle drei Metriken aufwiesen.“ Das ist der zugrunde liegende CrUX-Datensatz, auf den sich der Bericht stützt – der Maßstab dafür, warum so viele Websites “No data available.” (Übersetzung) „Keine Daten verfügbar.“ sehen.
• FID wurde am 12. März 2024 aus der GSC entfernt – sofort, ohne Übergangsfrist, während PSI und CrUX ein sechsmonatiges Abschaltungsfenster boten. Quelle
• Faustregel für die Seitengröße: unter 500KB für eine Seite und alle ihre Ressourcen, gemäß Googles eigener Anleitung im Abschnitt „Fix issues“ des Berichts. Quelle
• Page-Experience-Bericht am 19. April 2023 entfernt – die Core-Web-Vitals- und HTTPS-Berichte sind das, was von diesem alten Rollup übrig bleibt. Berichterstattung

Testen Sie sich: der Core-Web-Vitals-Bericht

Fünf kurze Fragen zur Funktionsweise des Core-Web-Vitals-Berichts in der Search Console. Wählen Sie für jede eine Antwort aus und prüfen Sie dann.

Änderungsprotokoll