Core Web Vitals: nicht genügend Daten in der Search Console

Was „Nicht genügend Nutzungsdaten“ bedeutet

Der Core-Web-Vitals-Bericht in der Search Console zeigt, wie echte Chrome-Nutzer deine Seiten erlebt haben. Jedes Mal, wenn jemand mit den passenden Chrome-Einstellungen eine deiner Seiten aufruft, gehen LCP, INP und CLS dieses Besuchs an Google. Die Werte landen in einem öffentlichen Datensatz namens Chrome User Experience Report, kurz CrUX. Die Search Console greift auf diesen Datensatz zu und zeigt dir das Ergebnis. Anders als viele glauben, ruft die Search Console deine Website also nicht selbst auf. Sie sammelt nur echte Nutzerdaten.

Gibt es für deine Seiten zu wenige solcher Besuche, gibt es nichts anzuzeigen. Dann siehst du „Nicht genügend Nutzungsdaten in den letzten 90 Tagen für diesen Gerätetyp“ – für Mobilgeräte oder Desktop, manchmal für beides.

Manche deuten das als schlechtes Zeichen. Fehlende Daten sagen aber nichts darüber aus, wie schnell oder langsam deine Website ist. Google hat einfach nicht genug Besucher gesehen, um überhaupt etwas dazu zu sagen.

Warum CrUX keine Daten für deine Website hat

Der Hauptgrund ist Traffic. CrUX erfasst eine Seite oder einen Origin (Protokoll plus Domain, also https://www.example.com) nur, wenn sie „ausreichend beliebt“ ist. Was das genau bedeutet, sagt Google nicht. Auf der Methodik-Seite steht nur, dass der Schwellenwert hoch genug liegt, um sich bei der Verteilung sicher zu sein.

Und für diesen Schwellenwert zählt von vornherein nur ein kleiner Teil deiner Besucher. CrUX erfasst nur Chrome-Nutzer, die Nutzungsstatistiken aktiviert haben, ihren Browserverlauf synchronisieren und keine Sync-Passphrase verwenden. Das betrifft Chrome auf dem Desktop und Chrome unter Android. Chrome auf dem iPhone zählt nicht mit (darunter läuft WebKit, genau wie bei Safari). Safari selbst, Firefox, Edge und der Browser in der Instagram-App zählen ebenfalls nicht. Hat deine Website viel iPhone-Traffic, landen die meisten Besucher nie im Datensatz. Mobilgeräte und Desktop werden außerdem getrennt gezählt. Du kannst also Daten für Desktop haben und keine für Mobilgeräte – oder umgekehrt. Der Gerätetyp mit dem geringeren Chrome-Traffic geht zuerst leer aus.

Außerdem muss die Seite selbst die Voraussetzungen erfüllen. Alles, was nach Weiterleitungen keinen 200-Statuscode liefert, wird übersprungen. Seiten mit einem noindex-Meta-Tag oder dem Header X-Robots-Tag: noindex ignoriert Google ebenfalls. Die Search Console legt noch eine eigene Regel obendrauf: Nur URLs, die tatsächlich indexiert sind, tauchen im Bericht auf.

Und wenn du die Property gerade erst in der Search Console eingerichtet hast, siehst du dort ohnehin erst einmal nichts. Das erledigt sich von selbst, sobald Google die Daten verarbeitet hat.

Seiten ohne Daten übernehmen den Wert des Origins

Die Search Console schlüsselt Daten auch nicht nach einzelnen Seiten auf. Sie fasst ähnliche URLs zusammen. Hat eine Gruppe nicht genügend eigene Daten, nutzt die Search Console den Origin als Fallback – also alle URLs mit demselben Protokoll, Host und Port. Eine Seite, die CrUX noch nie gesehen hat, kann in deinem Bericht also trotzdem als „Gut“ oder „Schlecht“ auftauchen, weil sie sich den Wert vom Rest deiner Website leiht.

In der Praxis bekommen Startseite und Blog den meisten Traffic. Sie bestimmen diesen Origin-Wert. Deine Produktseiten oder dein Checkout können viel langsamer sein, und du würdest es in der Search Console nie sehen. Genau deshalb nehme ich den website-weiten CrUX-Wert nie als Zielwert. Er ist nach Traffic gewichtet. Deine meistbesuchten Seiten entscheiden also über den Wert – und das sind nicht zwingend die Seiten, auf die es dir ankommt.

Lighthouse hilft hier nicht weiter

Überall liest du den Rat, PageSpeed Insights oder Lighthouse laufen zu lassen, bis CrUX-Daten vorliegen. Ich verstehe, warum das empfohlen wird. Aber es bringt dir nicht, was du brauchst. Ein Lighthouse-Test lädt deine Seite genau einmal auf einem simulierten Smartphone – mit gedrosselter Verbindung und leerem Cache. Um Probleme auf der Seite selbst zu finden, ist das in Ordnung. Es sagt aber nichts darüber aus, was deine Besucher erleben.

Der INP braucht zum Beispiel echte Menschen, die auf echten Geräten klicken und tippen. Lighthouse klickt auf gar nichts. Beim CLS hört Lighthouse auf zu messen, sobald die Seite geladen ist. Eine spät nachladende Anzeige, die den Inhalt nach unten schiebt, oder ein Element, das beim Scrollen springt, landet nie im Bericht. Und der LCP hängt vom Gerät ab, von der Verbindung und davon, wie weit der Besucher von deinem CDN entfernt ist. Ein einzelner Testlauf deckt davon genau einen Fall ab.

Warten funktioniert nur, wenn dein Traffic wächst. CrUX betrachtet die Besuche der letzten 28 Tage (die Verzögerung ist übrigens viel kürzer, als viele denken, siehe warum die Verzögerung von 28 Tagen ein Mythos ist). Wenn du diesen Monat nicht genug qualifizierte Chrome-Besuche hattest, hast du sie nächsten Monat wahrscheinlich auch nicht.

Messe deine eigenen Besucher mit RUM

Die Alternative: Miss selbst. Real User Monitoring, RUM, führt ein kleines Skript im Browser jedes Besuchers aus, misst die Core Web Vitals dieses Besuchs und sendet die Werte an dich statt an Google. Dieselbe Art von field data wie bei CrUX – nur gibt es keinen Schwellenwert und du bist nicht auf Chrome-Nutzer beschränkt.

Eine Seite mit 50 Besuchen im Monat liefert Daten. Deine iPhone-Besucher genauso: Safari misst seit Safari 26.2 (Dezember 2025) LCP und INP. Sie tauchen also in RUM auf, während CrUX sie weiterhin außen vor lässt. Du siehst auch, welches Element einen schlechten Wert verursacht hat: das Bild, das den LCP bestimmt hat, oder der Button, der nur träge reagiert hat. Nach einem Deploy siehst du den Effekt innerhalb von Minuten – statt irgendwo im Durchschnitt von 28 Tagen.

Core/Dash ist das RUM-Tool, das ich dafür gebaut habe. Ein Script-Tag oder das WordPress-Plugin genügt, und ab dem ersten Seitenaufruf laufen Daten ein. Es setzt keine Cookies und erfasst keine personenbezogenen Daten. Du brauchst also kein Consent-Banner. Bei kleineren Websites zählt das: Ein RUM-Skript hinter einem Consent-Banner misst nur Nutzer, die zustimmen. Dann hast du wieder nur einen Bruchteil deiner Besucher. Die Tarife starten bei 16 $ pro Monat bei jährlicher Abrechnung. Für die Testphase von 14 Tagen brauchst du keine Kreditkarte.

Lass es weiterlaufen, sobald CrUX deine Website erfasst. Die Search Console zeigt nur URL-Gruppen. Sie verrät dir nie, welche Seite oder welches Element eine Gruppe langsam gemacht hat.

Prüfe, was CrUX aktuell über deine Website hat

Bevor du etwas änderst, prüfe, ob CrUX deinen Origin überhaupt führt. Das CrUX-History-Tool auf corewebvitals.io zeigt den CrUX-Verlauf für jede Website. Ist der Bereich Mobil dort leer, bleibt er es auch in der Search Console.

Siehe auch: Core/Dash installieren, die Browser-Dimension für die Besucher, die CrUX außen vor lässt, und die Gerätetyp-Dimension zur Trennung von Mobil und Desktop.

Quellen: Search-Console-Hilfe: Core-Web-Vitals-Bericht, CrUX-Methodik, Safari 26.2 bringt LCP und INP.