Da ist sie, die Mail von der Google Search Console: „Core Web Vitals: Bewertung nicht bestanden.“ Und du sitzt davor und denkst: Moment mal, meine Website lädt doch schnell? PageSpeed zeigt sogar Grün! Was will Google eigentlich von mir?
Willkommen bei einer der am meisten missverstandenen Meldungen der ganzen Search Console. Die gute Nachricht vorweg: „Nicht bestanden“ ist keine Abstrafung, kein Ranking-Todesurteil und oft nicht mal ein akutes Problem. Aber sie ist auch keine Meldung, die man einfach wegklickt, denn sie verrät dir etwas, das kein Speed-Test der Welt dir zeigt: wie sich deine Website für ECHTE Besucher anfühlt.
In diesem Artikel entschlüsseln wir die Meldung komplett: was da genau gemessen wird, warum deine PageSpeed-Punkte etwas völlig anderes sagen können, wie schlimm das Ganze fürs Ranking wirklich ist, und warum die Bewertung nach deinem Fix wochenlang rot bleibt, obwohl längst alles behoben ist.
Das Wichtigste in Kürze:
- Die Bewertung basiert auf Felddaten echter Chrome-Nutzer (CrUX), nicht auf Labortests. Deshalb kann PageSpeed grün zeigen und die Search Console trotzdem rot.
- Gemessen werden drei Metriken: LCP (Laden, gut bis 2,5 s), INP (Reaktion, gut bis 200 ms) und CLS (Layout-Stabilität, gut bis 0,1), jeweils am 75. Perzentil.
- Core Web Vitals sind ein Rankingfaktor, aber nur einer von vielen. Relevanter Content rankt laut Google auch mit schwacher Bewertung.
- Die Daten laufen über ein rollierendes 28-Tage-Fenster. Nach einem Fix dauert es deshalb bis zu vier Wochen, bis die Bewertung umspringt. Das ist normal!
- Wenig Traffic = keine Daten: Kleine Websites tauchen im Bericht oft gar nicht auf, und das ist kein Fehler.
Was die Meldung wirklich bewertet: echte Besucher, keine Tests
Der wichtigste Satz dieses Artikels zuerst: Die Core-Web-Vitals-Bewertung in der Search Console basiert komplett auf dem CrUX-Report, dem Chrome User Experience Report. Das sind Messwerte von echten Chrome-Nutzern, die deine Website in den letzten 28 Tagen tatsächlich besucht haben, mit ihren echten Handys, in ihrem echten Funkloch, auf ihrem echten fünf Jahre alten Android-Gerät.
Kein simulierter Test, kein Labor, sondern Realität.
Und diese Realität wird streng ausgewertet: Google schaut auf das 75. Perzentil, also darauf, welche Erfahrung mindestens drei Viertel deiner Besucher haben. Deine Website muss demnach auch für die langsameren Geräte und Verbindungen gut funktionieren, nicht nur für dein Glasfaser-MacBook.
Gemessen wird dabei getrennt nach mobil und Desktop, und die Search Console fasst ähnliche Seiten zu URL-Gruppen zusammen, statt jede Seite einzeln zu bewerten.
Die drei Metriken und ihre Grenzwerte
Bewertet werden genau drei Dinge, und für jedes gibt es klare Schwellen:
| Metrik | Was sie misst | Gut | Schlecht |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Wann das größte Element sichtbar ist, gefühlt: „die Seite ist da“ | bis 2,5 s | über 4,0 s |
| INP (Interaction to Next Paint) | Wie schnell die Seite auf Klicks und Eingaben reagiert | bis 200 ms | über 500 ms |
| CLS (Cumulative Layout Shift) | Wie stark sich das Layout beim Laden verschiebt (Layout-Shifts) | bis 0,1 | über 0,25 |
Dazwischen liegt jeweils die Zone „Optimierung erforderlich“, Googles Ampelsystem eben. Sobald eine URL-Gruppe bei einer der drei Metriken nicht im grünen Bereich landet, gilt sie als nicht bestanden. Eine Metrik reicht also! Deshalb lohnt sich in der Search Console immer der Blick, WELCHE Metrik eigentlich meckert, bevor du irgendwas optimierst.
Falls dir INP neu vorkommt: Die Metrik hat den früheren FID (First Input Delay) im März 2024 offiziell abgelöst.
Und sie ist deutlich strenger, weil sie nicht nur die erste Eingabe misst, sondern die Reaktionsfähigkeit über den ganzen Besuch.
Gerade Websites mit viel JavaScript, üppigen Page Buildern und vielen Plugins sind seitdem öfter aus dem grünen Bereich gerutscht, ohne dass sich an der Website selbst etwas geändert hätte.
Warum PageSpeed grün zeigt und die Search Console trotzdem rot
Jetzt zur Verwirrung Nummer eins. Du testest deine Website mit PageSpeed Insights oder Lighthouse, alles leuchtet freundlich, und trotzdem steht in der Search Console „nicht bestanden“. Wie passt das zusammen?
Ganz einfach: Das sind zwei verschiedene Messungen. Lighthouse liefert dir Labordaten, erhoben in einer simulierten Umgebung mit festen Netzwerkbedingungen — die Search Console schaut dagegen auf die Felddaten deiner echten Besucher. Der Unterschied auf einen Blick:
| Lighthouse / PageSpeed (Labor) | CrUX-Felddaten der Search Console (Feld) |
|---|---|
| Ein einzelner, simulierter Testlauf | Echte Besucher, gesammelt über 28 Tage |
| Feste Netzwerkbedingungen, immer gleich | Die tatsächlichen Geräte und Verbindungen deiner Nutzer |
| Zum Debuggen und Nachbessern gedacht | Zeigt die wahre Nutzererfahrung |
Google sagt das übrigens selbst ganz offen: Labordaten sind zum Debuggen da, Felddaten zeigen die wahre Nutzererfahrung — und die Werte können voneinander abweichen.
Ein Beispiel aus der Praxis: Deine Kundschaft ist mobil unterwegs, viele mit älteren Geräten. Das Labor simuliert ein Durchschnittsgerät und sagt „passt“. Deine echten Besucher am 75. Perzentil erleben aber 3 Sekunden LCP, und genau die zählen.
Umgekehrt geht es übrigens auch: mieser Laborwert, aber zufriedene echte Nutzer, weil deine Besucher überwiegend am schnellen Desktop sitzen.
Merke: Der PageSpeed-Punktwert ist ein Werkzeug, die Felddaten sind das Urteil. Den Unterschied zwischen Ladezeit, Laborwerten und gefühlter Geschwindigkeit hab ich im großen Guide zur PageSpeed-Optimierung ausführlich auseinandergenommen.
Wie schlimm ist „nicht bestanden“ fürs Ranking wirklich?
Zeit für eine ehrliche Einordnung, denn hier wird draußen viel Panik verkauft. Ja, Core Web Vitals sind ein Rankingfaktor, Google bestätigt das ausdrücklich: Sie werden von den Ranking-Systemen verwendet. Aber dieselbe Google-Dokumentation sagt auch: Die Suche zeigt immer den relevantesten Inhalt, selbst wenn die Page Experience schwach ist.
Übersetzt heißt das: Eine rote Bewertung kostet dich keinen Platz eins, wenn dein Inhalt der beste ist. Sie ist das Zünglein an der Waage, wenn Inhalte vergleichbar gut sind, und genau in umkämpften Suchergebnissen ist das Zünglein eben doch relevant.
Dazu kommt der Effekt, der in keiner Ranking-Debatte auftaucht, aber jeden Umsatz betrifft: Eine Website, die am 75. Perzentil träge lädt und auf Klicks verzögert reagiert, verliert Besucher und Conversions, bevor irgendein Algorithmus überhaupt mitreden muss.
Optimier also für deine Besucher, das Ranking-Argument gibt es gratis dazu.
Der Fix ist drin und nichts passiert? Das 28-Tage-Fenster
Und damit zum Teil, an dem die meisten verzweifeln. Du hast optimiert, die Laborwerte sind top, du klickst in der Search Console auf „Fehlerbehebung überprüfen“, und dann: wochenlang nichts. Die Bewertung bleibt stur auf „nicht bestanden“. Ist die Validierung kaputt?
Nein, sie funktioniert genau wie vorgesehen, nur anders, als man intuitiv erwartet. Die Felddaten laufen über ein rollierendes 28-Tage-Fenster. Deine Verbesserung von heute muss sich also erst über vier Wochen in die Statistik „einwaschen“, während die langsamen Messwerte von vorgestern noch drinstecken.
Und die Validierung in der Search Console beschleunigt daran gar nichts: Google sagt klipp und klar, dass der Klick keine Neuindexierung auslöst, sondern lediglich eine vierwöchige Beobachtung der CrUX-Daten startet.
Als behoben gilt das Problem erst, wenn es im gesamten 28-Tage-Fenster auf keiner URL der Gruppe mehr auftritt.
So gehst du die Behebung an
Die Reparatur selbst beginnt immer mit derselben Frage: Welche Metrik fällt durch, und auf welcher Geräteklasse? Danach richtet sich alles Weitere.
Ganz grob sieht die Zuordnung so aus:
- Ein schlechter LCP führt fast immer zu Bildern (Stichwort Bildoptimierung und WebP), Serverantwortzeit, Caching-Plugin und gegebenenfalls CDN.
- Ein schlechter INP zeigt auf JavaScript-Ballast, also übervolle Plugin-Sammlungen, Drittanbieter- und Tracking-Skripte und schwere Page-Builder-Setups.
- Ein schlechter CLS entsteht durch nachrutschende Elemente, klassisch: Bilder ohne feste Größen, eingeblendete Banner, nachladende Werbung oder Schriften und zu aggressives Lazy Loading im sichtbaren Bereich.
Die konkreten Handgriffe für jede dieser Baustellen sprengen diesen Artikel, dafür gibt es den erwähnten PageSpeed-Guide mit allen Details. Und wenn du es nicht selbst machen willst: Genau diese Diagnose (welche Metrik, welche Ursache, welche Maßnahme mit welchem Effekt) ist der Kern unserer Performance-Optimierung, mit Messung vorher und nachher, damit du den Effekt schwarz auf weiß siehst statt nur im Bauchgefühl.
Sonderfall: Bei mir zeigt der Bericht gar nichts an
Noch ein häufiger Verwirrungsfall zum Schluss: Dein Core-Web-Vitals-Bericht ist leer oder zeigt nur einen Bruchteil deiner Seiten.
Keine Sorge, deine Website ist nicht kaputt, sie hat nur zu wenig Traffic für belastbare Daten.
In den CrUX-Report fließen nur Chrome-Nutzer mit aktivierter Statistik-Übermittlung ein, und URL-Gruppen ohne ausreichende Datenmenge lässt Google schlicht weg. Eine exakte Mindestbesucherzahl nennt Google nicht, aber kleine und junge Websites fallen regelmäßig darunter.
Für dich heißt das: kein Grund zur Panik, aber auch kein Freifahrtschein.
Miss in dem Fall mit Labortools und gesundem Menschenverstand, und behalte den Bericht im Auge, wenn dein Traffic wächst.
Solche Search-Console-Signale regelmäßig zu deuten (was ist dringend, was ist Rauschen?) ist übrigens genau die Sorte Arbeit, die wir in der laufenden SEO-Betreuung übernehmen, damit dich Meldungen wie diese gar nicht erst kalt erwischen.
Fazit
„Core Web Vitals: Bewertung nicht bestanden“ heißt übersetzt: Mindestens ein Viertel deiner echten Besucher hatte in den letzten 28 Tagen bei mindestens einer der drei Metriken kein gutes Erlebnis. Nicht mehr, nicht weniger. Kein Ranking-Beben, aber ein ernstzunehmender Hinweis aus der Realität deiner Nutzer, und deutlich aussagekräftiger als jeder Labor-Punktwert.
Der Umgang damit in drei Sätzen: Finde raus, welche Metrik auf welchem Gerätetyp durchfällt. Behebe die Ursache, nicht den Punktwert. Und dann gib den Felddaten ihre vier Wochen, denn schneller kann die Bewertung systembedingt gar nicht umspringen. Wer das weiß, liest die Meldung nie wieder mit Schweißperlen!
Häufige Fragen zur Core-Web-Vitals-Bewertung
Was bedeutet „Core Web Vitals Bewertung: nicht bestanden“?
Mindestens eine der drei Metriken (LCP, INP oder CLS) lag bei deinen echten Besuchern der letzten 28 Tage am 75. Perzentil nicht im grünen Bereich. Die Bewertung stammt aus Felddaten des Chrome User Experience Reports, nicht aus Labortests. Sie ist ein Qualitätshinweis, keine Abstrafung.
Warum besteht meine Seite nicht, obwohl PageSpeed gute Werte zeigt?
Weil PageSpeed-Punkte Labordaten aus einer simulierten Umgebung sind, die Search-Console-Bewertung aber auf Messwerten echter Besucher basiert. Wenn deine realen Nutzer langsamere Geräte oder Verbindungen haben als die Simulation, fallen die Felddaten schlechter aus. Es zählen die Felddaten.
Wie lange dauert es nach einem Fix, bis die Bewertung grün wird?
Rechne mit bis zu vier Wochen. Die Felddaten laufen über ein rollierendes 28-Tage-Fenster, und die Validierung in der Search Console startet nur eine vierwöchige Beobachtung, ohne etwas zu beschleunigen. Als behoben gilt das Problem erst, wenn es im gesamten Fenster nicht mehr auftritt.
Sind Core Web Vitals ein Rankingfaktor?
Ja, Google bestätigt, dass die Ranking-Systeme sie verwenden, aber als eines von vielen Signalen. Relevanter Content rankt auch mit schwacher Bewertung. In umkämpften Suchergebnissen mit ähnlich guten Inhalten können sie allerdings den Unterschied machen, und unabhängig vom Ranking kosten schlechte Werte messbar Besucher und Conversions.
Mein Core-Web-Vitals-Bericht ist leer. Ist das ein Problem?
Nein, das heißt nur, dass deine Website zu wenig Traffic für statistisch belastbare Felddaten hat. Google lässt URL-Gruppen ohne ausreichende Datenmenge einfach weg und nennt keine exakte Mindestbesucherzahl. Miss in dem Fall mit PageSpeed Insights oder GTmetrix im Labor-Modus und behalte den Bericht im Blick, wenn dein Traffic wächst.
