Core Web Vitals nicht genügend Nutzungsdaten: Bedeutung und Lösung

Was bedeutet Core Web Vitals nicht genügend Nutzungsdaten?

Core Web Vitals nicht genügend Nutzungsdaten bedeutet, dass die Search Console für Ihre Seiten nicht genug echte Chrome Messwerte von Nutzern findet, um eine aussagekräftige Zusammenfassung zu erstellen. Ihre Website ist deshalb nicht defekt. Meist ist die Seite neu, der Traffic gering oder die Stichprobe der URL Gruppe zu klein.

Die Meldung in der Oberfläche ist eine ähnliche Warnung (englisch: Not enough usage data). Menüs und Texte ändern sich allerdings mit der Zeit, deshalb stützen wir uns nicht auf exakte Schaltflächennamen. Den aktuellen Wortlaut finden Sie in der Search Console Hilfe zum Core Web Vitals Bericht.

Dieser Artikel behandelt nur diese eine Situation. Die Definition der Kennzahlen lesen Sie in unserem Beitrag Core Web Vitals erklärt. Daher wiederholen wir sie hier nicht.

Kurz gesagt richtet sich der Text an alle, die den Bericht geöffnet haben, einen leeren Zustand sehen und wissen möchten, was nun zu tun ist. Zunächst erklären wir, was die Meldung bedeutet. Danach zeigen wir den Weg, den Sie gehen können. Unsere Antworten stützen sich auf die offizielle Dokumentation von Google, und wo diese keine Zahl nennt, erfinden wir auch keine.

Was prüfen Sie in den ersten 15 Minuten?

Panik ist nicht nötig, denn die Meldung weist meist auf fehlende Daten hin und nicht auf einen Fehler. Gehen Sie diese Schritte der Reihe nach durch:

1. Prüfen Sie zunächst, ob Sie die richtige Property gewählt haben. Eine Domain Property und eine URL Präfix Property können unterschiedliche Bereiche zeigen.
2. Öffnen Sie die Tabs für Mobilgeräte und Desktop getrennt. Ein Tab kann Daten zeigen, während der andere leer bleibt.
3. Schauen Sie in Analytics, ob die Website neu ist und wie viele Besuche in den letzten Monaten eingegangen sind.
4. Testen Sie die Startseite und eine wichtige Unterseite in PageSpeed Insights. Dann sehen Sie, ob der Bereich mit den Felddaten erscheint.
5. Stellen Sie sicher, dass die Seiten öffentlich sind, keinen Login verlangen und nicht mit noindex gesperrt sind.
6. Gehen Sie davon aus, dass Daten nicht so bald kommen, und planen Sie Labortests sowie eine eigene Messung echter Nutzer.

Diese sechs Schritte klären die Ursache in den meisten Fällen. Danach entscheiden Sie, welchen Weg Sie einschlagen.

Zudem empfehlen wir, jeden Schritt kurz zu notieren. Halten Sie zum Beispiel fest, welche Property, welchen Tab und welche Seite Sie geprüft haben. Wenn Sie den Bericht dann in einigen Wochen erneut öffnen, sehen Sie sofort, was sich geändert hat.

Arbeiten mehrere Personen an dem Thema, legen Sie für jeden Schritt eine verantwortliche Person fest. Somit arbeiten Entwickler, Redaktion und Geschäftsführung mit denselben Informationen.

Woher bekommt der Core Web Vitals Bericht seine Daten?

Der Bericht bezieht seine Daten aus dem Chrome User Experience Report, kurz CrUX. CrUX sammelt anonyme Leistungsmessungen von echten Chrome Nutzern, die bestimmte Browseroptionen aktiviert haben. Google nennt das also Felddaten.

Das heißt, Google besucht Ihre Website nicht mit einem Roboter und vergibt eine Note. Stattdessen sammelt Google Lade, Interaktions und Layout Erlebnisse, die echte Menschen auf Smartphone und Computer haben. Ohne Besucher gibt es also keine Daten.

Sie müssen sich nicht anmelden oder Code einbauen, um in CrUX aufzutauchen. Allerdings sagt die Dokumentation des Chrome UX Report klar, dass nicht jede Website und nicht jede Seite im Datensatz enthalten ist. Eine Seite muss öffentlich auffindbar sein, und es braucht genug Besucher für eine statistisch sinnvolle Stichprobe.

Die eigentliche Frage hinter der Meldung lautet deshalb: Haben genug echte Chrome Besucher diese Seiten aufgerufen? Den genauen Schwellenwert nennen wir hier nicht. Prüfen Sie den aktuellen Wert in der Dokumentation zum Chrome UX Report.

Ein weiterer Punkt ist allerdings wichtig. CrUX Daten bauen sich über die Zeit auf. Eine Änderung von heute zeigt sich morgen also nicht vollständig im Bericht. Lesen Sie die Ergebnisse daher als wöchentlichen Trend und nicht als Tageswert.

Wann tritt diese Meldung auf?

Die typischen Ursachen lassen sich in wenige Gruppen einteilen. Wenn Sie Ihre Gruppe kennen, wählen Sie den richtigen nächsten Schritt.

• Sie haben die Property erst kürzlich hinzugefügt, und es gab noch nicht genug Besuche.
• Sie haben die Website gerade veröffentlicht oder auf eine neue Domain umgezogen.
• Der Traffic ist wirklich gering, was bei B2B und lokalen Seiten häufig vorkommt.
• Die meisten Besucher nutzen einen anderen Browser als Chrome.
• Die Seiten liegen hinter einem Login und sind nicht öffentlich.
• Für den gewählten Gerätetyp, etwa Desktop, gibt es nur sehr wenige Besucher.

Diese Ursachen können außerdem gemeinsam auftreten. Eine neue lokale Firmenwebsite hat zum Beispiel wenig Traffic und überwiegend mobile Besucher. Der Desktop Tab bleibt dann lange leer.

Das ist normal. Zudem weist es allein weder auf eine Strafe noch auf einen technischen Fehler hin.

Am praktischsten finden Sie die Ursache, indem Sie in Analytics drei Dinge zusammen lesen: die Sitzungen der letzten Wochen, die Geräteverteilung und die Browserverteilung. Zusammen zeigen die drei Tabellen meist, zu welcher Gruppe Sie gehören. Danach wird Ihre Aufgabenliste deutlich kürzer.

Schadet Core Web Vitals nicht genügend Nutzungsdaten dem Ranking?

Nein. Die Meldung selbst senkt Ihr Ranking nicht. Sie beschreibt also eine Messlücke und keine Strafe. Fehlende Daten heißen zudem nicht, dass Ihre Seite schlecht ist.

Die Seitenerfahrung ist außerdem nur eines von vielen Signalen, die Google nutzt. Relevanz und Qualität des Inhalts sind oft deutlich entscheidender. Deshalb versprechen wir bei Tempo Arbeiten kein Ranking.

Andererseits beeinflusst die Nutzererfahrung die Conversion direkt. Eine Seite, die spät lädt oder springt, verliert Besucher. Fehlende Daten sind also kein Grund, die Leistung zu ignorieren.

Den größeren Zusammenhang zwischen Tempo und Suche erklärt unser Beitrag wie die Ladezeit SEO beeinflusst. Hier geht es nur darum, die Datenlücke richtig zu lesen.

Übertriebene Versprechen vermeiden wir bei diesem Thema. Tempo Arbeit kann zum Beispiel in manchen Fällen einen messbaren Unterschied machen, in anderen nicht. Wir empfehlen, das zu tun, was Nutzern hilft, ohne ein Ergebnis zu versprechen.

Die richtige Frage lautet daher nicht, ob Ihr Ranking fällt. Sie lautet, ob Ihr Besucher auf der Seite eine gute Erfahrung hat. Wenn Sie die erste Frage nicht beantworten können, beginnen Sie damit, die zweite zu messen.

Was unterscheidet eine URL Gruppe von der Ebene der Herkunft?

Die Search Console fasst Seiten mit ähnlicher Nutzererfahrung zu URL Gruppen zusammen. Fehlen für eine Gruppe genug Daten, lässt der Bericht sie weg. Dann kann die Search Console eine übergeordnete Origin Gruppe bilden, die alle URLs mit demselben Protokoll und Host umfasst.

PageSpeed Insights folgt einer ähnlichen Logik. Hat eine einzelne Seite keine Daten, fällt das Tool auf die Origin Ebene zurück. Hat auch die Origin zu wenig Daten, zeigt das Tool gar keine Felddaten, und die Dokumentation von Google sagt das ausdrücklich.

Konkret ist das praktische Ergebnis folgendes. Wenn Sie für eine Seite keine Daten sehen, heißt das nicht, dass die ganze Website keine hat. Ihre Startseite kann also Daten auf Origin Ebene zeigen, während ein neuer Blogbeitrag leer bleibt.

Ein Beispielszenario: Ihr Shop hat Hunderte Produktseiten, und jede erhält nur sehr wenige Besuche. Keine einzelne Seite erreicht den Schwellenwert, doch zusammen können sie auf Origin Ebene genug Stichproben liefern. Deshalb zeigt der Bericht manchmal nur die Origin Ebene.

Beachten Sie allerdings, dass die Origin Ebene ein Durchschnittsbild ist. Eine einzelne sehr langsame Seite kann in diesem Durchschnitt untergehen. Um die Problemseite zu finden, brauchen Sie also zusätzlich Labortests.

Warum fehlen in PageSpeed Insights die Felddaten?

PageSpeed Insights liefert zwei Arten von Daten. Die eine sind Felddaten von echten Chrome Nutzern, die andere sind Labordaten aus einem simulierten Seitenaufruf. Ist der Bereich mit den Felddaten leer, funktioniert der Laborbereich trotzdem.

Die Dokumentation zu PageSpeed Insights sagt, dass eine Seite genug Daten braucht, um in den CrUX Datensatz zu gelangen, bevor das Tool Nutzerdaten für sie zeigt. Ist die Seite ganz neu oder hat sie wenige echte Stichproben, erscheinen keine Felddaten.

Somit ergeben sich zwei Möglichkeiten. Entweder hat die Seite keine Daten und das Tool fällt auf die Origin Ebene zurück, oder auch die Origin hat keine, und der Felddatenbereich verschwindet ganz.

Sehen Sie diesen Bildschirm, halten Sie das Tool nicht für defekt. Ein erneutes Laden oder eine andere Adresse ändert das Ergebnis nicht. Nur mehr Besucher ändern es. Daher müssen Sie Ihre Messung auf anderem Weg aufbauen.

Achten Sie außerdem auf die Schreibweise der Adresse. Testen Sie eine URL mit Weiterleitung und die Zielseite ist eine andere, kann das Ergebnis von Ihrer Erwartung abweichen. Testen Sie nach Möglichkeit die endgültige Adresse nach der Weiterleitung.

Worin unterscheiden sich Labordaten und Felddaten?

Labordaten stammen aus einer kontrollierten Umgebung mit einem Gerät und einer festen Netzwerkbedingung. Felddaten spiegeln die Erfahrung echter Besucher auf vielen Geräten, in vielen Netzen und an vielen Orten wider. Die beiden können also unterschiedliche Ergebnisse liefern, und das ist normal.

Das web.dev von Google erklärt, dass Labordaten zur Fehlersuche nützlich sind und Felddaten die echte Erfahrung zeigen. Sie ersetzen einander nicht. Sie nutzen also beide gemeinsam.

Lighthouse gehört zur Laborseite. Details dazu finden Sie in unserem Beitrag Website Performance mit Lighthouse testen. Wir wiederholen sie hier nicht.

Dieser Unterschied erklärt auch, warum Sie bei fehlenden Felddaten nicht in Panik geraten sollten. Labortests helfen Ihnen, Probleme früh zu finden. Kommen Felddaten, bestätigen sie dann, wie stark diese Probleme echte Nutzer treffen.

Wie messen Sie die Leistung ohne Felddaten?

Ohne Felddaten haben Sie also drei Wege. Sie ergänzen sich, und keiner reicht allein aus.

• Labortest: Mit Lighthouse oder dem Laborbereich von PageSpeed Insights finden Sie problematische Elemente.
• Messung echter Nutzer (RUM, Real User Monitoring): Sie sammeln Leistungswerte Ihrer eigenen Besucher auf Ihrer eigenen Website.
• Manuelle Prüfung: Sie surfen selbst auf einem echten Smartphone und mit langsamer Verbindung durch Ihre Seite.

Ein Labortest ist stabil und wiederholbar, deshalb eignet er sich gut, um Änderungen zu vergleichen. Allerdings bildet er die Vielfalt echter Nutzer nicht ab. Ein guter Laborwert garantiert also kein gutes Ergebnis im Feld.

Wir sehen Laborergebnisse daher als ersten Check. Bei Entscheidungen bleibt der echte Nutzer der verlässlichste Beleg. Haben Sie ihn nicht, starten Sie Ihre eigene Messung.

Unterschätzen Sie die manuelle Prüfung nicht. Wenn Sie Ihre Seite auf einem echten Smartphone mit langsamer Verbindung öffnen und ein Formular ausfüllen, entdecken Sie Reibung, die ein Testtool nicht findet. Zum Beispiel merken Sie sofort, wenn eine Schaltfläche beim Laden springt.

Was ist die Messung echter Nutzer und wie starten Sie?

RUM bedeutet, dass Sie die Lade, Interaktions und Layout Werte Ihrer Besucher auf Ihrer eigenen Website erfassen. Das ähnelt dem, was Chrome in CrUX sammelt. Allerdings haben Sie es selbst in der Hand, und Sie sehen die Werte seitenweise, auch wenn das Volumen klein ist.

Konkret gibt es meist zwei Wege zum Start. Der erste ist die Web Vitals Bibliothek, die Google auf web.dev beschreibt, mit der Sie Messwerte an Ihr eigenes Analysetool senden. Der zweite ist ein fertiger Monitoring Dienst, der das für Sie erledigt.

Codedetails nennen wir in diesem Beitrag nicht. Ihr Entwickler kann der offiziellen Dokumentation folgen. Wichtig ist, dass Sie die Werte am 75. Perzentil zusammenfassen und Mobilgeräte und Desktop getrennt beobachten.

Allerdings braucht auch RUM Traffic. Haben Sie sehr wenige Besucher, schwanken die Werte stark. Beobachten Sie den Trend daher über mehrere Wochen und entscheiden Sie nicht anhand eines einzelnen Tages.

Denken Sie auch an den Datenschutz. Erfassen Sie bei der Messung keine personenbezogenen Daten; Leistungswerte tragen keine persönliche Identität. Prüfen Sie vor dem Einrichten eines Messdienstes, ob Ihre Cookie und Datenschutzhinweise dazu passen. Das ist keine Rechtsberatung, fragen Sie bei Bedarf eine Fachperson.

Welche Diagnosen erklären diese Meldung nicht?

Viele suchen bei dieser Meldung an der falschen Stelle. Die folgenden Probleme stehen nicht direkt mit fehlenden Daten in Verbindung.

• Sitemap Fehler: Ein Sitemap Problem betrifft die Entdeckung, nicht die Entstehung von Felddaten.
• Eine Sperre in der robots.txt: Das Crawling Problem betrachten Sie als eigenes Thema.
• Eine einzelne langsame Seite: Langsamkeit erzeugt schlechte Daten, nicht fehlende Daten.
• Ein Wechsel des Hostings: Er verursacht allein keinen Datenverlust, kann aber relevant sein, wenn der Traffic gefallen ist.

Allerdings kann Ihre Website auch ein echtes Indexierungs oder Zugriffsproblem haben. Um das zu unterscheiden, lesen Sie unsere Anleitung nicht indexierte Seiten in der Search Console finden.

Sehen Sie einen Sitemap Fehler, behandelt unser Beitrag zum Sitemap Fehler URL nicht zulässig diesen Fall als eigenes Thema. Wichtig ist, die beiden Probleme nicht zu verwechseln.

Kurz gesagt kostet es Zeit, eine Datenlücke als Symptom eines anderen Problems zu lesen. Verstehen Sie zuerst die Logik der Meldung. Haben Sie danach wirklich den Verdacht auf ein anderes Problem, schauen Sie es sich getrennt an.

Was sollte eine neue oder traffic arme Website tun?

Ist Ihre Website neu, brauchen Sie zuerst Geduld und dann eine Routine. In den ersten Tagen nach dem Hinzufügen einer Property ist ein leerer Bericht zu erwarten. Diesen Fall behandeln wir im Beitrag Search Console zeigt keine Daten.

Eine traffic arme Website braucht dagegen einen anderen Ansatz. Statt Seiten zu vermehren oder Besucher zu erfinden, konzentrieren Sie sich auf diese drei Dinge:

1. Halten Sie die Grundleistung per Labortest stabil. Komprimieren Sie Bilder und reduzieren Sie unnötige Skripte.
2. Investieren Sie in Inhalte und Kanäle, die echte Besucher bringen.
3. Warten Sie geduldig auf Daten der Origin Ebene und prüfen Sie nach einigen Wochen erneut.

Bildoptimierung und Skriptgewicht beeinflussen die Ladezeit tatsächlich. Details dazu finden Sie im Beitrag JavaScript und Ladezeit optimieren.

Bei einer traffic armen Website sind Inhaltsarbeit und Tempo Arbeit keine Rivalen. Beides gehört zusammen. Eine schnelle Seite ohne Besucher ist ebenso ineffizient wie eine Seite, die Besucher anzieht, aber langsam lädt.

Warum lesen Sie Mobilgeräte und Desktop getrennt?

Der Bericht der Search Console zeigt mobile und Desktop Daten getrennt. Der Grund: Netz, Prozessor und Bildschirm unterscheiden sich bei beiden Gerätetypen, und Google behandelt sie als zwei verschiedene Erfahrungen.

Nutzen die meisten Besucher mobile Geräte, bleibt der Desktop Tab womöglich lange leer. Das ist also kein Problem. Entscheidend ist, ob es Daten für den Gerätetyp gibt, den die Mehrheit Ihrer Besucher nutzt.

Schauen Sie in Analytics auf die Geräteverteilung. Kommt nicht einmal jeder zehnte Besucher vom Desktop, überrascht ein leerer Desktop Tab nicht. Bei solchen Websites stärken wir zunächst die mobile Erfahrung.

Bedenken Sie außerdem, dass dieselbe Seite mobil gut und am Desktop schlecht sein kann. Lesen Sie die beiden Tabs also getrennt, und setzen Sie nie einen anstelle des anderen.

Ihre Besucherverteilung entscheidet, welches Gerät Vorrang hat. Kommen Ihre Besucher während der Arbeitszeit vom Desktop, wie bei einer B2B Website, kann der Desktop Tab für Sie wichtiger sein.

Ist künstlicher Traffic zum Sammeln von Daten sinnvoll?

Nein. Bot Traffic, gekaufte Besucher oder wiederholte eigene Besuche gelten als Versuch, Systeme zu täuschen, und sie bringen ohnehin nichts. CrUX misst nur echte Chrome Nutzer, die seine Bedingungen erfüllen.

Künstlicher Traffic verfälscht außerdem Ihre Analysedaten und kann bei einem Werbekonto Probleme verursachen. Versuchen Sie nicht, einen Bericht mit regelwidrigen Methoden zu füllen.

Die legitimen Wege sind dagegen klar. Erstellen Sie zum Beispiel Inhalte, nutzen Sie Ihren E-Mail Verteiler und Ihre Social Kanäle, und schalten Sie bei Bedarf Werbung für echte Besucher. Falls Sie Anzeigen schalten, hilft Ihnen unser UTM Generator, Kampagnenlinks korrekt zu markieren.

Bis Daten ankommen, ist die sicherste Strategie also Labortest plus RUM.

Der ehrliche Weg ist langsamer, aber er trägt. Echtes Besucherwachstum bedeutet zudem echte Conversions, und der Bericht füllt sich als Nebeneffekt.

Wie lesen Sie den Bericht, sobald Daten da sind?

Zeigt der Bericht Daten, ordnet er Seiten in Status wie schlecht, verbesserungswürdig und gut ein. Die Schwellenwerte stehen in der Dokumentation von Google. Dort gelten zum Beispiel 2,5 Sekunden für LCP, 200 Millisekunden für INP und 0,1 für CLS als gute Grenzen.

Schwellenwerte können sich ändern. Prüfen Sie sie daher erneut in der Search Console Hilfe zum Core Web Vitals Bericht. Wir betrachten diese Werte nicht als festgeschrieben.

Öffnen Sie beim Lesen zuerst die problematischen URL Gruppen. Testen Sie dann eine Beispieladresse aus dieser Gruppe in PageSpeed Insights und lesen Sie die Hinweise aus dem Laborbereich.

Planen Sie nach einer Korrektur außerdem etwas Wartezeit ein. Felddaten bauen sich mit echten Besuchern über ein Zeitfenster auf, erwarten Sie also keine sofortigen Ergebnisse.

Beobachten Sie dieselbe Gruppe nach einer Verbesserung mehrere Wochen lang. Zeigt sich nicht sofort eine Besserung, haben Sie deshalb nichts falsch gemacht. Felddaten arbeiten mit einem Fenster, das zurückblickt.

Welches Tool zeigt was?

Verschiedene Tools beantworten verschiedene Fragen. Die folgende Tabelle fasst zusammen, was jedes Tool bei fehlenden Daten leistet.

Die Erkenntnis daraus: Auf einer Website ohne Felddaten arbeiten Labortest und RUM zusammen. Daher sollten Sie beides planen.

Welche Seiten testen Sie zuerst?

Da Ihnen Felddaten fehlen, müssen Sie nicht die ganze Website mit gleicher Sorgfalt testen. Wählen Sie zunächst die Seiten mit dem größten Geschäftswert, denn dort bewirkt knappe Zeit den größten Unterschied.

• Startseite: Die meisten Besucher steigen hier ein.
• Kategorieseiten für Leistungen oder Produkte: Die Conversion beginnt auf diesen Seiten.
• Blogbeiträge mit dem meisten organischen Traffic: Hier landen Suchbesucher zuerst.
• Kontakt oder Angebotsformular: Eine Verzögerung führt hier direkt zu Verlusten.
• Eine Beispielseite pro Template: Seiten mit demselben Template liefern ähnliche Ergebnisse.

Die Template Logik spart Zeit. Nutzen hundert Beiträge ein Template, gibt der Test von ein oder zwei Seiten meist eine gute Vorstellung.

Führen Sie den Test zudem für Mobilgeräte aus, da die meisten Besucher meist vom Smartphone kommen. Tragen Sie die Ergebnisse in eine Tabelle ein und vergleichen Sie nach jeder Änderung erneut.

Kann Core Web Vitals nicht genügend Nutzungsdaten dauerhaft bleiben?

Ja, bei manchen Websites kann die Meldung lange bleiben. Sehr spezielle Seiten, Seiten mit sehr wenigen Besuchern oder Seiten, die überwiegend Nutzer ohne Chrome bedienen, erreichen den Schwellenwert vielleicht nie.

Das ist daher kein Makel. Sie müssen nur die Gewohnheit ändern, allein anhand von Felddaten zu entscheiden. Auf einer solchen Website werden Labortest und Ihre eigene RUM Messung zur Hauptquelle.

Außerdem müssen Sie bei einer kleinen Website nicht warten, bis sich der Bericht füllt, um die Nutzererfahrung zu verbessern. Bildgrößen, Laden von Schriften, Skripte von Drittanbietern und das Seitenlayout sind ohnehin bekannte bewährte Praktiken.

Die Faustregel lautet: Gibt es keine Messung, ersetzen Sie Vermutungen durch ein belegbasiertes Vorgehen und führen Sie es regelmäßig aus.

Welche Fehler passieren am häufigsten?

Diese Fehler sehen wir bei Teams in dieser Situation am häufigsten.

• Die Meldung als Strafe verstehen und die Website hastig ändern.
• Einen Laborwert wie ein Feldergebnis darstellen.
• Die Daten einer Seite auf die ganze Website übertragen.
• Die Tabs für Mobilgeräte und Desktop verwechseln.
• Künstlichen Traffic senden, um Daten zu bekommen.
• Menünamen und Schwellenwerte aus dem Gedächtnis schreiben, statt die aktuelle Dokumentation zu prüfen.

Die meisten dieser Fehler entstehen nämlich aus Ungeduld, denn man will schnell Ergebnisse sehen. Der richtige Reflex ist, zuerst die Ursache zu finden und danach einen Messplan aufzubauen.

Ehrlich gesagt versprechen wir keinen Ranking Effekt durch Leistungsarbeit. Wir machen die Nutzererfahrung messbar und verbessern sie.

In welcher Reihenfolge gehen wir als Team vor?

Kommt eine Website mit dieser Situation zu uns, geht unser Team meist in dieser Reihenfolge vor. Das ist ein Beispielszenario und enthält keine Garantie.

1. Zunächst prüfen wir die Property und die Gerätetabs.
2. Dann lesen wir das Trafficvolumen und die Geräteverteilung in Analytics.
3. Danach messen wir die Startseite und einige kritische Templates per Labortest.
4. Anschließend entscheiden wir, ob wir eine Messung echter Nutzer einrichten.
5. Schließlich prüfen wir den Bericht in regelmäßigen Abständen erneut, bis sich Daten aufgebaut haben.

Diese Arbeit ist zudem meist Teil einer technischen SEO Betreuung. Möchten Sie den technischen Gesamtzustand Ihrer Website mit uns prüfen, schauen Sie sich unsere SEO Beratung an.

Für einen schnellen ersten Blick eignet sich unser SEO Check. Allerdings kann er Felddaten nicht ersetzen.

Was ist das Fazit, wenn Daten fehlen?

Kurz gesagt ist die Meldung eine Frage des Datenschwellenwerts und kein Fehler. Sie senkt Ihr Ranking nicht direkt. Sie ändert aber nichts daran, dass Sie die Leistung messen müssen.

Trennen Sie zuerst die Ursache: neue Website, wenig Traffic, ein Gerätetyp oder ein Zugriffsproblem. Schließen Sie die Lücke dann mit Labortest und Messung echter Nutzer. Sobald Daten da sind, lesen Sie den Bericht erneut.

Unter Ihren Quellen ist die offizielle Dokumentation von Google die verlässlichste. Menünamen und Schwellenwerte können sich ändern, schauen Sie deshalb immer auf die aktuelle Seite.