Core Web Vitals News: Was sich geändert hat und was Sie zuerst beheben sollten
Von Toy Wen Da, Mitgründer · Aktualisiert · 12 Min. Lesezeit
Übersetzt aus dem englischen Original. Auf Englisch lesen
Wenn Sie nach Core-Web-Vitals-News suchen, steckt meist eine Markierung in der Search Console oder eine Metrikänderung dahinter, von der Sie gehört haben. Die kurze Antwort: Interaction to Next Paint (INP) hat First Input Delay (FID) am 12. März 2024 als offizielle Core Web Vital abgelöst. Öffnen Sie den Core-Web-Vitals-Bericht in der Search Console, um zu sehen, welche URLs markiert sind.
Bevor Sie Code anfassen, lassen Sie die Seite durch den kostenlosen Website Speed Test laufen. Er liefert Lighthouse-Werte und zeigt, welche Core-Web-Vitals-Metrik die Seite ausbremst. So wissen Sie, ob Sie ein Ladeproblem, ein Interaktionsproblem oder ein Layoutproblem jagen, bevor Sie auch nur eine Codezeile öffnen.
Was sich bei den Core Web Vitals zuletzt tatsächlich geändert hat
Neuigkeiten zu den Core Web Vitals kommen in zwei Varianten: als Austausch einer Metrik oder als Leak, der bestätigt, wie stark sich Google im Hintergrund auf echtes Nutzerverhalten stützt. Beides geschah 2024, und beides prägt bis heute, wie Teams Korrekturen priorisieren sollten.
Der Wechsel von FID zu INP
Bis zum 12. März 2024 maß Google die Reaktionsfähigkeit einer Seite mit First Input Delay, kurz FID. FID betrachtete nur die allererste Interaktion eines Besuchers auf einer Seite: einen Klick, einen Tipp, einen Tastendruck. Eine Seite konnte FID problemlos bestehen und sich danach trotzdem jedes Mal träge anfühlen.
Interaction to Next Paint schließt diese Lücke. INP beobachtet jeden Klick, Tipp und Tastendruck während des gesamten Besuchs und meldet dann die langsamste Interaktion, die kein seltener Ausreißer war. Das ist wichtig, denn Chrome-Nutzungsdaten zeigen: Rund 90 % der Zeit, die ein Besucher auf einer Seite verbringt, fallen nach dem Ende des Ladevorgangs an, nicht währenddessen. FID erfasste also nur einen kleinen Ausschnitt der Erfahrung. INP misst den Teil, den Nutzer tatsächlich spüren.
Ein guter INP-Wert liegt bei 200 Millisekunden oder weniger. Alles zwischen 200 und 500 Millisekunden gilt als „Needs improvement“. Über 500 Millisekunden stuft die Search Console den Wert als „Poor“ ein.
Der Leak der Content Warehouse API
Im März 2024 wurde eine Reihe interner Google-API-Dokumentation öffentlich bekannt, und Branchenbeobachter haben sie bis weit in 2025 hinein auseinandergenommen. Die Regeln der Core Web Vitals hat sie nicht neu geschrieben. Sie hat aber bestätigt, was viele SEOs bereits vermuteten: Die öffentlichen Metriken sind ein Stellvertreter für ein deutlich größeres, klickbasiertes Ranking-System.
Die geleakte Dokumentation verweist Berichten zufolge auf Module, die mit Chrome-Nutzungsdaten zusammenhängen, sowie auf ein System namens NavBoost. Es sortiert Ergebnisse anhand von rund 13 Monaten fortlaufendem Klickverhalten neu. Der Zusammenhang mit den Core Web Vitals ist einfache Ursache und Wirkung: Eine langsame oder instabile Seite erzeugt mehr „schlechte Klicks“, also Besuche, bei denen jemand ein Ergebnis anklickt, frustriert ist und sofort zu den Suchergebnissen zurückspringt. Wenn Sie Ihre Core Web Vitals verbessern, erfüllen Sie nicht nur eine Punktetabelle. Sie nehmen Besuchern auch einen Grund, überhaupt zu Google zurückzuspringen.
Die längere Zeitleiste
Die Core Web Vitals sind nicht 2020 aus dem Nichts aufgetaucht. Google arbeitet seit über einem Jahrzehnt darauf hin:
| Jahr | Änderung | Warum es heute wichtig ist |
|---|---|---|
| 2011 | Das Panda-Update nimmt minderwertige Inhalte ins Visier | Hat gezeigt, dass die für Nutzer sichtbare Qualität das Ranking beeinflusst, nicht nur Keywords |
| 2014 | HTTPS wird zum Ranking-Signal | Erstmals wurde ein technischer, inhaltsunabhängiger Faktor als Signal bestätigt |
| 2018 | Mobile Page Speed Update | Die Seitengeschwindigkeit auf Mobilgeräten bekommt ein eigenes, ausdrückliches Signal |
| 2020 | Core Web Vitals offiziell angekündigt (Page-Experience-Update) | LCP, FID und CLS werden zum messbaren Trio |
| 2024 | FID wird durch INP ersetzt (12. März) | Die Reaktionsfähigkeit wird über den gesamten Besuch gemessen, nicht nur beim ersten Klick |
Core Web Vitals in der Google Search Console prüfen: Schritt für Schritt
Die Search Console ist weiterhin die kostenlose, maßgebliche Stelle, um zu sehen, wie Googles eigene Felddaten Ihre Seiten bewerten. So rufen Sie den Bericht auf und lesen ihn richtig.
Den Bericht öffnen
- Melden Sie sich bei der Google Search Console an und wählen Sie Ihre Property aus.
- Klicken Sie in der linken Seitenleiste unter Nutzerfreundlichkeit (Experience) auf Core Web Vitals.
- Sie sehen zwei Übersichtsdiagramme: Mobil (Mobile) und Desktop. Klicken Sie bei einem von beiden auf Bericht öffnen (Open report).
- Jeder Bericht zeigt URL-Gruppen, nach Status sortiert: Mangelhaft (Poor), Verbesserungswürdig (Need improvement) und Gut (Good).
Die URL-Gruppen lesen
Die Search Console berichtet standardmäßig nicht über einzelne URLs, sondern fasst ähnliche Seiten zusammen, meist nach Template. Das ist Absicht. Wenn alle Ihre Produktseiten dasselbe Layout nutzen, haben sie sehr wahrscheinlich auch dasselbe Core-Web-Vitals-Problem.
Wenn Sie eine „Poor“-Gruppe öffnen, sehen Sie:
- Welche konkrete Metrik durchfällt (LCP, INP oder CLS)
- Eine Auswahl betroffener URLs
- Die Anzahl der URLs in dieser Gruppe
Hier wird eine Seite, bei der die Core-Web-Vitals-Bewertung weiterhin „Failed“ lautet, in der Regel diagnostiziert: nach Template, nicht durch Raten an einer einzelnen Seite.
Nach einer Korrektur
Sobald Sie eine Korrektur ausgespielt haben, gehen Sie zurück in den Bericht und klicken bei der betroffenen URL-Gruppe auf Validate fix. Google crawlt in den folgenden Tagen eine Stichprobe dieser URLs erneut und aktualisiert den Status, sobald genügend Daten echter Nutzer vorliegen. Das kann zwei bis vier Wochen dauern, denn die Felddaten der Core Web Vitals brauchen eine echte Stichprobe von Besuchen, nicht nur einen einmaligen Crawl.
Die drei Metriken und ihre Schwellenwerte
| Metrik | Was sie misst | Gut | Needs improvement | Poor |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Zeit, bis das größte sichtbare Element gerendert ist | 2,5 Sekunden oder weniger | 2,5–4 Sekunden | Über 4 Sekunden |
| INP (Interaction to Next Paint) | Verzögerung zwischen einer Nutzeraktion und der nächsten sichtbaren Reaktion | 200 ms oder weniger | 200–500 ms | Über 500 ms |
| CLS (Cumulative Layout Shift) | Wie stark sich sichtbare Inhalte unerwartet verschieben | 0,1 oder weniger | 0,1–0,25 | Über 0,25 |
Google beurteilt laut der Core-Web-Vitals-Dokumentation von web.dev alle drei Werte am 75. Perzentil der Seitenaufrufe. Das heißt: Mindestens drei von vier echten Besuchen müssen „Gut“ erreichen, damit die Seite insgesamt besteht.
Wann die Google Search Console reicht und wann nicht
Das ist der ehrliche Teil, den die meisten Ratgeber auslassen. Der Core-Web-Vitals-Bericht der Search Console ist kostenlos, nutzt echte Besucherdaten und reicht für viele Websites tatsächlich aus. Er hat aber echte Grenzen.
Wo die Search Console genügt
- Sie betreuen eine Website mit wenigen Templates. Die Ansicht nach URL-Gruppen zeigt Ihnen genau, welches Template defekt ist.
- Sie prüfen einen einmaligen Einbruch. Wenn eine einzelne Seite nach einem Inhalts-Update plötzlich „Poor“ anzeigt, finden die Felddaten der Search Console zusammen mit dem kostenlosen Website Speed Test meist die Ursache.
- Sie brauchen nur Felddaten, keine Ursachenanalyse. Die Search Console sagt Ihnen, was echten Nutzern passiert. Sie sagt nicht, welches Skript oder Bild es verursacht hat.
Wo Sie mehr als die Search Console brauchen
- Eine Seite hat zu wenig Traffic für Felddaten. Google braucht ein Mindestvolumen an echten Besuchen, bevor es einen Wert meldet. Seiten mit wenig Traffic zeigen „no data“, auch wenn sie tatsächlich langsam sind.
- Sie müssen die eigentliche Ursache aufspüren. Die Search Console nennt Ihnen die Metrik und das Template. Sie zeigt nicht, welches Drittanbieter-Skript den Main Thread blockiert. Dafür brauchen Sie Chrome DevTools oder ein Labortool wie Lighthouse.
- Das Problem kehrt mit jedem Release zurück. Wenn jeder Deploy erneut eine Layoutverschiebung einführt, brauchen Sie Monitoring in Ihrer Build-Pipeline und keine monatliche Kontrolle eines GSC-Berichts.
- Sie nutzen eine Plattform mit Ursachen auf Plugin-Ebene. Bei Shopify ist zum Beispiel oft eine Drittanbieter-App die eigentliche Quelle eines schlechten INP-Werts. Um das zu beheben, müssen Sie wissen, welche Shopify-Apps die Core Web Vitals tatsächlich verbessern, statt nur mehr Tracking-Ballast hinzuzufügen.
Kurz gesagt: Die Search Console sagt Ihnen, dass etwas nicht stimmt und ungefähr wo. Warum, bis hinunter zum einzelnen Skript oder Stylesheet, sagt sie selten.
Häufige Ursachen und Lösungen je Metrik
| Metrik | Typische Ursache | Das prüfen Sie zuerst | Wer es in der Regel behebt |
|---|---|---|---|
| LCP | Hero-Bild oder Haupttextblock lädt spät | Ist das LCP-Element im rohen HTML auffindbar? | Frontend-Entwickler oder Hosting-Anbieter |
| LCP | Langsame Serverantwort (hoher TTFB) | Serverantwortzeit und Caching | Hosting- oder Backend-Team |
| INP | Lange JavaScript-Aufgabe blockiert den Main Thread | Bei welcher Nutzeraktion hakt es? | Frontend-Entwickler |
| INP | Umfangreiche Drittanbieter-Skripte (Werbung, Chat-Widgets, Tracker) | Prüfen, welche Skripte bei einer Interaktion laufen | Marketing und Entwicklung gemeinsam |
| CLS | Bilder oder Anzeigen ohne reservierte Maße | Verschiebt sich das Layout nach dem Laden? | Frontend-Entwickler oder Content-Team |
| CLS | Webfonts verursachen einen Textumbruch | Ist eine Fallback-Schrift richtig gesetzt? | Frontend-Entwickler |
Häufige Fehler von Teams bei Core-Web-Vitals-News
Die meisten Fehler entstehen, weil Teams die Core Web Vitals als einen Wert behandeln, den es zu maximieren gilt, statt als drei getrennte, voneinander unabhängige Probleme.
- Der Jagd nach der perfekten 100 in PageSpeed Insights. Google interessiert nur, ob Sie die „Good“-Schwelle erreichen. Darüber hinaus stecken Sie Budget in unsichtbare Verbesserungen.
- Nur die Startseite zu testen. Ihre Startseite kann in Ordnung sein, während jede Produktseite durchfällt. Nutzen Sie die Ansicht nach URL-Gruppen, keine einzelne Stichprobe.
- Mobile Daten zu ignorieren. Die Desktop-Werte sehen meist besser aus als die mobilen. Auf Mobilgeräten finden die meisten Besuche und die meisten Abbrüche statt.
- Alle gelben Warnungen auf einmal zu beheben. Priorisieren Sie zuerst Seiten, die mit Umsatz oder Leads zusammenhängen. Ein langsames Blog-Archiv kann warten.
- Echte Interaktionstests für INP auszulassen. Eine Seite kann beim Laden schnell wirken und trotzdem bei INP durchfallen, sobald jemand ein Dropdown oder einen Filter antippt.
- Das Ticket zu schließen, bevor die Daten nachgezogen haben. Felddaten brauchen nach einer Korrektur echte Besuche, in der Regel einige Wochen, bevor sich der Status aktualisiert.
Die Core Web Vitals stehen außerdem neben einem weiteren Qualitätssignal, das Google seit Jahren fördert: Barrierefreiheit. Eine Seite mit schlechtem Farbkontrast oder fehlenden Alt-Texten scheitert oft an denselben Kriterien aus den Web Content Accessibility Guidelines (WCAG) des W3C, dem offiziellen Standard hinter den meisten Barrierefreiheits-Audits. Und sie hat oft dieselben Grundursachen wie eine Seite mit Layoutverschiebungen. Das ist ein Grund, warum die Behebung von Barrierefreiheitsproblemen in der Regel zugleich das SEO verbessert. Wenn Sie nicht sicher sind, wo Ihr rechtliches Risiko liegt, lohnt es sich, parallel zu Ihrer Core-Web-Vitals-Bereinigung nachzulesen, was das Barrierefreiheitsrecht tatsächlich verlangt und was Sie zuerst beheben sollten.
Core-Web-Vitals-News für Publisher und Nachrichtenseiten
Wenn Ihre Website als Nachrichtenverlag läuft, hat Core-Web-Vitals-News eine zusätzliche Wendung: Geschwindigkeits- und Stabilitätsprobleme verschärfen sich mit Indexierungsproblemen. Ein langsames Template riskiert nicht nur einen schlechten CLS-Wert („Poor“), es kann auch bremsen, wie schnell neue Artikel überhaupt gecrawlt werden.
Wenn Sie sowohl schnelle Indexierung als auch saubere Core-Web-Vitals-Werte anstreben, gehören ein paar verwandte Korrekturen meist zusammen:
- Beseitigen Sie Fehler in der Google-News-Sitemap, damit neue Artikel schnell erscheinen.
- Prüfen Sie unter WordPress, dass Ihre Yoast-News-SEO-Einrichtung den Artikel-Templates keine render-blockierenden Skripte hinzufügt.
- Sehen Sie sich das umfassendere Vorgehen für schnelle Indexierung und gute Rankings von Nachrichtenartikeln an, denn ein schweres Artikel-Template fällt oft bei INP und bei den Crawl-Geschwindigkeits-Prüfungen gleichzeitig durch.
Und wenn Ihr Unternehmen auch in der lokalen Suche auftaucht, sollten Sie aktuelle Änderungen am Google Business Profile parallel zu Ihrer Core-Web-Vitals-Arbeit im Blick behalten. Beides fließt in dasselbe Gesamtbild der Seitenerfahrung ein, das Google sich von Ihrer Marke macht.
Warum das mit dem Klickverhalten zusammenhängt
Erinnern Sie sich an den NavBoost-Mechanismus von oben: Google wertet Klicks, die sofort zur Ergebnisseite zurückspringen, als negatives Signal. Eine langsame oder instabile Seite erzeugt mehr davon. Wenn Sie Ihre Core Web Vitals verbessern, schützen Sie damit im Grunde Ihre Klickrate. Wenn Sie die Rechnung dahinter kennen möchten, was als starkes Ergebnis gilt, lohnt sich ein kurzer Blick auf die Formel und die Richtwerte zur Klickrate. Eine schnelle, stabile Seite ist eine der günstigsten Möglichkeiten, diese Zahl zu schützen.
Korrekturen priorisieren: ein einfaches Vorgehen
Statt jede markierte URL in der Reihenfolge zu beheben, in der die Search Console sie auflistet, gehen Sie diese Schritte durch:
- Wählen Sie zuerst die Templates, die mit Umsatz oder Leads zusammenhängen: Produktseiten, Leistungsseiten, Landingpages.
- Prüfen Sie Felddaten vor Labordaten. Der Bericht der Search Console und die CrUX-Felddaten spiegeln echte Besuche wider; Labortools wie Lighthouse simulieren nur einen einzelnen Durchlauf.
- Bestimmen Sie die konkret durchfallende Metrik. LCP, INP und CLS brauchen jeweils eine andere Lösung, und ein pauschales Ticket „Mach es schneller“ verschwendet Entwicklerzeit.
- Testen Sie eine repräsentative URL aus der Gruppe, bevor Sie das ganze Template ändern.
- Validieren Sie in einem Labortool, bevor Sie ausspielen, und validieren Sie die Korrektur danach in der Search Console.
- Beobachten Sie die Entwicklung einige Wochen. Felddaten brauchen Zeit, um eine ausgespielte Korrektur nachzuvollziehen.
Häufig gestellte Fragen
Was sind die neuesten Core-Web-Vitals-News Stand 2026?
Die größte jüngste Änderung bleibt der Austausch von First Input Delay gegen Interaction to Next Paint am 12. März 2024. Seitdem bestand das meiste, was als „News“ galt, aus Analysen geleakter Google-Dokumentation, die bestätigen, wie Klickverhalten und Core Web Vitals zusammenwirken, und nicht aus einer neuen offiziellen Metrik.
Hat Google die Core Web Vitals aus dem Ranking entfernt?
Nein. Google hat wiederholt gesagt, dass die Core Web Vitals eines von vielen Signalen sind und dass Relevanz und Inhaltsqualität weiterhin mehr Gewicht haben. Schlechte Core Web Vitals verhindern nicht grundsätzlich, dass eine Seite rankt, sie können aber dazu führen, dass eine sonst gleichwertige Seite gegen einen schnelleren Wettbewerber verliert.
Wie lange dauert es, bis eine Korrektur in der Search Console sichtbar wird?
Die Felddaten brauchen nach einer ausgespielten Korrektur eine frische Stichprobe echter Besuche. Das dauert in der Regel ein paar Wochen bis einen Monat, bevor sich der Status im Core-Web-Vitals-Bericht aktualisiert.
Ist PageSpeed Insights dasselbe wie der Core-Web-Vitals-Bericht in der Search Console?
Nein. PageSpeed Insights testet jeweils eine URL und mischt Labor- und Felddaten. Der Bericht der Search Console gruppiert viele URLs nach Template und nutzt ausschließlich Felddaten echter Besuche. Das eignet sich besser, um Korrekturen für eine ganze Website zu priorisieren.
Ersetzt INP die Core Web Vitals ganz oder nur eine Metrik?
INP hat nur FID ersetzt. LCP und CLS sind unverändert. Die drei aktuellen Core Web Vitals sind LCP, INP und CLS.
Was Sie jetzt tun sollten
Öffnen Sie noch heute den Core-Web-Vitals-Bericht in der Search Console, sortieren Sie nach Status und wählen Sie die eine „Poor“-URL-Gruppe, die zu Ihrem Template mit dem meisten Traffic gehört. Lassen Sie eine Seite aus dieser Gruppe durch den kostenlosen Website Speed Test laufen, um zu bestätigen, welche der drei Metriken, LCP, INP oder CLS, tatsächlich durchfällt, bevor Sie einen Entwickler briefen. Wenn Sie sehen möchten, was eine vollständige technische Prüfung Ihrer Website samt Core Web Vitals tatsächlich zutage fördern würde, sprechen Sie mit dem Team und lassen Sie sich einen Beispielbericht zu Ihren eigenen URLs erstellen. Das sind die praktischen Core-Web-Vitals-News, die Rankings wirklich bewegen: keine neue Metrik, der man hinterherjagt, sondern ein behobenes Template.
Ressourcen / Referenzen
Quellen
Über den Autor
SearchBlueprint hat diesen Artikel mit der Content-Pipeline recherchiert, geschrieben und bewertet, die unsere Kunden auf ihren eigenen Websites einsetzen. Die Bewertung in der Autorenzeile ist die, die unsere Content-Engine dieser Seite vor der Veröffentlichung gegeben hat. Nichts davon wird von Hand geprüft, und genau das ist der Punkt: Es ist das Ergebnis des Produkts, veröffentlicht dort, wo jeder es nachprüfen kann.