Was ist Cumulative Layout Shift (CLS)?

Cumulative Layout Shift (CLS) ist eine der drei Core Web Vitals von Google und misst die visuelle Stabilität einer Webseite. Die Metrik erfasst, wie stark sich sichtbare Inhalte während des Ladens unerwartet verschieben – etwa wenn ein nachgeladenes Bild den bereits gelesenen Text nach unten springen lässt. Als gut gilt ein CLS-Wert von 0,1 oder weniger, gemessen am 75. Perzentil aller realen Seitenaufrufe.

CLS gehört seit 2021 zu den offiziellen Core Web Vitals, mit denen Google die Nutzererfahrung einer Seite bewertet. Während Largest Contentful Paint die Ladegeschwindigkeit und Interaction to Next Paint die Reaktionsfähigkeit misst, steht CLS für die visuelle Ruhe: Nichts soll unter den Fingern des Nutzers wegrutschen, während die Seite noch lädt.

Kurzprofil des Begriffs

Was misst Cumulative Layout Shift genau?

CLS misst die Summe aller unerwarteten Layout-Verschiebungen, die während der gesamten Lebensdauer einer Seite auftreten. Eine Layout-Verschiebung passiert immer dann, wenn ein bereits sichtbares Element seine Position zwischen zwei gerenderten Frames ändert, ohne dass der Nutzer eine Aktion ausgelöst hat.

Der Wert jeder einzelnen Verschiebung ergibt sich aus zwei Faktoren, die miteinander multipliziert werden:

• Impact Fraction – wie viel Anteil des sichtbaren Bildschirms von der Verschiebung betroffen ist.
• Distance Fraction – wie weit sich das Element relativ zum Viewport verschoben hat.

Ein Element, das die halbe Bildschirmhöhe einnimmt und um ein Viertel der Höhe nach unten rutscht, erzeugt also einen Layout-Shift-Score von 0,5 × 0,25 = 0,125. Wichtig: Seit 2021 summiert CLS nicht mehr alle Verschiebungen einer Sitzung, sondern nur die stärkste zusammenhängende Verschiebungsphase (das sogenannte Session Window). Das verhindert, dass langlebige Single-Page-Anwendungen künstlich schlechte Werte anhäufen.

Nur unerwartete Verschiebungen zählen. Bewegt sich Content als direkte Reaktion auf einen Klick oder eine Tastatureingabe innerhalb von 500 Millisekunden, wird die Verschiebung nicht gewertet – der Nutzer hat sie ja selbst ausgelöst.

Was ist ein guter CLS-Wert?

Ein guter CLS-Wert liegt bei 0,1 oder darunter. Google teilt die Skala in drei Bereiche: bis 0,1 gilt eine Seite als „gut“, zwischen 0,1 und 0,25 als „verbesserungswürdig“ und über 0,25 als „schlecht“. Entscheidend ist dabei nicht der beste oder der durchschnittliche Messwert, sondern das 75. Perzentil – also der Wert, den 75 Prozent aller echten Seitenaufrufe erreichen oder unterbieten.

Weil das 75. Perzentil zählt, reicht es nicht, wenn die Seite auf dem eigenen schnellen Testgerät stabil lädt. Google stützt sich auf die Felddaten echter Nutzer mit unterschiedlichen Geräten und Verbindungen. Ein einzelnes ruckelndes Banner auf langsamen Smartphones kann den Wert bereits über die Marke drücken.

Was verursacht Layout-Shifts?

Layout-Shifts entstehen fast immer dadurch, dass der Browser Platz für ein Element reservieren muss, das erst später eintrifft, und den bereits gerenderten Content dafür verschiebt. Die häufigsten Ursachen:

1. Bilder ohne Größenangabe: Fehlen width und height (oder eine aspect-ratio), kennt der Browser die Bildmaße erst beim Laden und schiebt den Folge-Content nach unten. Das passende Bildformat ändert daran nichts – entscheidend ist die reservierte Fläche.
2. Werbung, Embeds und iframes ohne feste Maße: Anzeigen, Social-Media-Einbettungen oder Videoplayer laden asynchron und drücken vorhandenen Content weg, wenn kein Platzhalter definiert ist.
3. Dynamisch nachgeladener Content: Cookie-Banner, Newsletter-Boxen oder „Ähnliche Artikel“, die per JavaScript oberhalb bestehender Inhalte eingefügt werden.
4. Webfonts (FOIT/FOUT): Wenn eine Schrift nachgeladen wird und der Text von der Ersatz- auf die Zielschrift umbricht, verändern sich Zeilenlängen und Höhen.
5. Unsauberes Lazy Loading: Verzögert geladene Bilder ohne reservierte Fläche verschieben das Layout genau in dem Moment, in dem der Nutzer scrollt.

Wie wird CLS gemessen?

CLS wird auf zwei Wegen erhoben: über Felddaten echter Nutzer und über Labortests. Für die Google-Bewertung zählen ausschließlich die Felddaten.

• Felddaten (Field Data): Der Chrome User Experience Report (CrUX) sammelt CLS-Werte anonym von echten Chrome-Nutzern. Diese Daten fließen in PageSpeed Insights und in den Core-Web-Vitals-Bericht der Google Search Console ein – die Grundlage der eigentlichen Bewertung.
• Labordaten (Lab Data): Werkzeuge wie Lighthouse oder die Chrome DevTools simulieren einen einzelnen Seitenaufruf unter kontrollierten Bedingungen. Sie eignen sich zur Ursachensuche, spiegeln aber nicht das reale Nutzerspektrum wider.
• JavaScript-Messung: Die offene web-vitals-Bibliothek von Google erfasst CLS direkt im Browser und lässt sich an jedes Analyse-Tool anbinden.

Ein Unterschied ist zentral: Lab-Tools messen CLS nur bis zum initialen Laden, Felddaten erfassen die gesamte Sitzung inklusive Scrollen und Interaktion. Deshalb kann ein Lighthouse-Wert grün sein, während die Search Console rot meldet.

Wie reduziert man CLS?

CLS reduziert man, indem man dem Browser von Anfang an mitteilt, wie viel Platz jedes Element braucht. Die wirksamsten Maßnahmen:

1. Bild- und Videomaße setzen: Immer width und height (oder aspect-ratio in CSS) angeben, damit der Browser die Fläche vorab reserviert.
2. Platz für Werbung und Embeds reservieren: Feste Container-Höhen für Anzeigen, iframes und dynamische Boxen definieren, statt sie den Content wegdrücken zu lassen.
3. Keinen Content über bestehendem einfügen: Banner und Hinweise unterhalb oder als Overlay statt oberhalb des sichtbaren Inhalts platzieren.
4. Webfonts optimieren: font-display: optional oder swap mit passender Fallback-Schrift nutzen und die wichtigste Schrift vorab laden (preload).
5. Animationen über transform lösen: Bewegungen mit transform statt mit layout-auslösenden Eigenschaften wie top oder height umsetzen.

In der Praxis lohnt es sich, mit den größten sichtbaren Elementen zu beginnen – dort wirkt jede Korrektur am stärksten auf den Score. Wer nicht weiß, welche Elemente die Verschiebung auslösen, findet die Verursacher im Bericht der Search Console oder in der Ebene „Layout Shift“ der Chrome DevTools. Eine strukturierte technische Prüfung dieser und der übrigen Core Web Vitals ist fester Bestandteil eines SEO-Audits.

Häufige Fragen zu CLS

Ist CLS ein Rankingfaktor?
Ja, CLS ist Teil der Core Web Vitals und damit ein bestätigtes, wenn auch schwaches Rankingsignal. Bei vergleichbarer Relevanz kann ein guter CLS-Wert den Ausschlag geben, ersetzt aber keine starken Inhalte.

Warum ist mein CLS auf dem Handy schlechter als am Desktop?
Auf Smartphones ist der Viewport kleiner und die gleiche Verschiebung nimmt relativ mehr Bildschirm ein. Zudem laden mobile Verbindungen Bilder und Anzeigen langsamer nach, was Layout-Shifts begünstigt.

Zählt eine Verschiebung nach einem Klick zum CLS?
Nein, Verschiebungen, die innerhalb von 500 Millisekunden auf eine Nutzeraktion folgen, gelten als erwartet und fließen nicht in den CLS-Wert ein.

Was ist das Crawl-Budget?

Das Crawl-Budget ist die Anzahl an URLs, die der Googlebot innerhalb eines bestimmten Zeitraums auf einer Website crawlt. Es ergibt sich aus zwei Faktoren: dem Crawl-Kapazitätslimit – wie viele Anfragen ein Server verträgt, ohne langsamer zu werden – und dem Crawl-Bedarf – wie wichtig und aktuell Google die Inhalte einschätzt. Für die meisten kleinen Websites ist das Crawl-Budget kein Thema; relevant wird es vor allem bei großen Websites mit vielen Tausend URLs.

Das Crawl-Budget beschreibt keine feste Zahl, die Google einer Website zuweist, sondern das Ergebnis aus Serverleistung und Nachfrage. Der Crawler ruft Seiten ab, folgt Links und meldet die Inhalte zur Indexierung. Je mehr URLs eine Website hat, desto stärker konkurrieren diese Seiten um die begrenzte Zahl an Abrufen – und desto wichtiger wird ein sauberes Crawl-Budget-Management.

Kurzprofil des Begriffs

Wie bestimmt Google das Crawl-Budget?

Google bestimmt das Crawl-Budget aus zwei Größen, die zusammenwirken: dem Crawl-Kapazitätslimit und dem Crawl-Bedarf. Das eine legt fest, wie viel gecrawlt werden kann, das andere, wie viel gecrawlt werden soll.

• Crawl-Kapazitätslimit (crawl capacity limit): die maximale Zahl gleichzeitiger Verbindungen, die der Googlebot zu einer Website öffnet, ohne den Server zu überlasten. Antwortet der Server schnell und fehlerfrei, hebt Google das Limit an. Wird er langsam oder liefert Serverfehler (5xx), drosselt Google das Crawling automatisch.
• Crawl-Bedarf (crawl demand): wie stark Google eine Website crawlen will. Er steigt mit der Popularität der URLs, ihrer Aktualität und der Häufigkeit von Änderungen. Beliebte und häufig aktualisierte Seiten werden öfter besucht, verwaiste oder statische Seiten seltener.

Das tatsächliche Crawl-Budget ist die kleinere der beiden Grenzen: Selbst wenn der Server viel verträgt, crawlt Google nicht mehr, als der Bedarf hergibt – und umgekehrt bremst ein schwacher Server auch bei hohem Bedarf das Crawling aus.

Wie viel Google auf einer Website tatsächlich crawlt, lässt sich im Bericht „Crawling-Statistiken“ der Google Search Console nachvollziehen – inklusive Anzahl der Anfragen pro Tag, durchschnittlicher Antwortzeit und der zurückgegebenen Statuscodes.

Für wen ist das Crawl-Budget relevant?

Das Crawl-Budget ist vor allem für große Websites mit sehr vielen URLs relevant. Google selbst nennt in seiner Dokumentation als Faustregel: Erst ab etwa 10.000 URLs oder bei häufig wechselnden Inhalten lohnt es sich, das Crawl-Budget aktiv zu steuern.

Konkret betroffen sind unter anderem:

• Große Onlineshops mit Tausenden Produkt-, Kategorie- und Filterseiten.
• Nachrichten- und Verlagsseiten, die täglich viele neue Artikel veröffentlichen und auf schnelle Indexierung angewiesen sind.
• Portale und Verzeichnisse mit dynamisch generierten Seiten, etwa Jobbörsen oder Immobilienplattformen.

Für eine typische Unternehmenswebsite mit einigen Hundert Seiten ist das Crawl-Budget dagegen kein Engpass: Google crawlt solche Seiten in aller Regel vollständig. Hier zahlt sich die Arbeit an Inhaltsqualität und Seitenstruktur stärker aus als an der Crawl-Steuerung. Trotzdem gilt: Was den Crawler schont, verbessert fast immer auch die technische Gesundheit einer Website insgesamt.

Was verschwendet Crawl-Budget?

Crawl-Budget wird immer dann verschwendet, wenn der Googlebot Zeit auf URLs verwendet, die keinen indexierbaren Mehrwert bieten. Jeder Abruf einer minderwertigen oder doppelten Seite geht von der Kapazität für die wirklich wichtigen Seiten ab.

Die häufigsten Ursachen im Detail:

1. Facettierte Navigation und URL-Parameter: Filter, Sortierungen und Session-IDs erzeugen unzählige URL-Varianten desselben Inhalts. In Onlineshops ist das der größte Budget-Fresser überhaupt.
2. Duplicate Content: Sind identische Inhalte über mehrere URLs erreichbar, crawlt Google jede Variante – und verschwendet Budget an Dubletten.
3. Soft-404- und Fehlerseiten: Seiten, die den Status 200 zurückgeben, aber leer oder inhaltslos sind, binden Abrufe ohne Gegenwert.
4. Weiterleitungsketten: Jede zusätzliche Weiterleitung in einer Kette kostet einen weiteren Abruf, bevor die eigentliche Seite erreicht wird.
5. Minderwertige und verwaiste Seiten: Thin Content, endlose Kalender-Archive oder verwaiste Seiten ohne interne Verlinkung senken den Gesamtwert einer Website und ziehen Bedarf von den starken Seiten ab.

Wie optimiert man das Crawl-Budget?

Crawl-Budget optimiert man, indem man dem Googlebot die wichtigen Seiten leicht zugänglich macht und unwichtige URLs konsequent vom Crawling ausschließt. Ziel ist, dass jeder Abruf auf einer indexierbaren, wertvollen Seite landet.

• Crawling steuern per robots.txt: URLs ohne Suchwert – Filterparameter, interne Suchergebnisse, Warenkorb – vom Crawling ausschließen. Die robots.txt verhindert das Crawling, nicht die Indexierung bereits bekannter URLs.
• Indexierung steuern per Noindex und X-Robots-Tag: Soll eine Seite gecrawlt, aber nicht indexiert werden, ist ein noindex per Meta-Tag oder HTTP-Header der richtige Weg. Wichtig: Eine per robots.txt gesperrte Seite kann Google das noindex nicht lesen.
• Saubere Sitemap pflegen: Die XML-Sitemap sollte nur indexierbare, kanonische URLs mit Statuscode 200 enthalten. Sie ist der wichtigste Hinweis an Google, welche Seiten Priorität haben.
• Serverleistung verbessern: Schnelle Antwortzeiten heben das Crawl-Kapazitätslimit. Ein performanter Server, Caching und ein CDN erlauben dem Googlebot, mehr Seiten in gleicher Zeit abzurufen.
• Weiterleitungsketten auflösen: Redirects direkt auf das finale Ziel zeigen lassen, statt über mehrere Zwischenstationen.
• Interne Verlinkung stärken: Wichtige Seiten flach verlinken und verwaiste Seiten anbinden oder entfernen. Eine klare Struktur führt den Crawler gezielt zu den relevanten Inhalten.

Welche dieser Hebel im Einzelfall zählen, zeigt eine strukturierte Analyse der Server-Logs und der Crawling-Statistiken. Genau diese technische Bestandsaufnahme ist Teil eines professionellen SEO-Audits, das Crawling-Verschwendung sichtbar macht und die stärksten Hebel priorisiert.

Häufige Fragen zum Crawl-Budget

Ist das Crawl-Budget ein Rankingfaktor?
Nein, das Crawl-Budget ist kein direkter Rankingfaktor. Es beeinflusst nur, wie schnell und vollständig Google Seiten crawlt und indexiert. Wird eine wichtige Seite gar nicht erst gecrawlt, kann sie aber auch nicht ranken – insofern ist ausreichendes Crawling die Voraussetzung für Sichtbarkeit.

Muss ich mich als kleine Website um mein Crawl-Budget kümmern?
In der Regel nein. Websites mit einigen Hundert bis wenigen Tausend URLs crawlt Google meist vollständig. Erst ab etwa 10.000 URLs oder bei sehr häufigen Inhaltsänderungen wird die aktive Steuerung des Crawl-Budgets zum Thema.

Erhöht eine höhere Crawl-Frequenz mein Ranking?
Nein. Häufigeres Crawling sorgt lediglich dafür, dass Änderungen schneller in den Index gelangen. Die Bewertung der Inhalte erfolgt unabhängig davon über die eigentlichen Rankingsignale.

Wo sehe ich, wie viel Google auf meiner Website crawlt?
Im Bericht „Crawling-Statistiken“ der Google Search Console. Er zeigt die Zahl der Crawling-Anfragen, die durchschnittliche Antwortzeit des Servers und die verteilten Statuscodes über die Zeit.

Was sind Core Web Vitals?

Core Web Vitals sind drei von Google definierte Messwerte, die die Nutzererfahrung einer Webseite technisch bewerten: Ladegeschwindigkeit, Reaktionsfähigkeit und visuelle Stabilität. Die drei Core Web Vitals heißen Largest Contentful Paint (LCP), Interaction to Next Paint (INP) und Cumulative Layout Shift (CLS). Google misst sie an echten Nutzerdaten und nutzt sie als Teil des Ranking-Signals „Page Experience“. Erreicht eine Seite in allen drei Werten den grünen Bereich, gilt sie als schnell, bedienbar und stabil.

Core Web Vitals übersetzen ein diffuses Gefühl in klare Zahlen: Statt „die Seite fühlt sich langsam an“ gibt es einen Sekundenwert für den Seitenaufbau, einen Millisekundenwert für die Reaktion auf Klicks und einen Punktwert für ruckelnde Layouts. Genau diese Messbarkeit macht die Core Web Vitals zum zentralen KPI der technischen SEO.

Kurzprofil des Begriffs

Welche drei Core Web Vitals gibt es?

Es gibt genau 3 Core Web Vitals, und jeder misst eine andere Dimension der Nutzererfahrung. Jede Metrik hat feste Richtwerte, die Google in „gut“, „verbesserungswürdig“ und „schlecht“ einteilt.

1. Largest Contentful Paint (LCP) – Ladezeit. LCP misst, wie lange es dauert, bis das größte sichtbare Element im Sichtbereich geladen ist, meist ein Bild oder eine Überschrift. Gut ist ein Wert von ≤ 2,5 Sekunden, schlecht sind mehr als 4,0 Sekunden.
2. Interaction to Next Paint (INP) – Reaktionsfähigkeit. INP misst, wie schnell die Seite auf Eingaben wie Klicks oder Tippen sichtbar reagiert. Gut ist ein Wert von ≤ 200 Millisekunden, schlecht sind mehr als 500 Millisekunden.
3. Cumulative Layout Shift (CLS) – visuelle Stabilität. CLS misst, wie stark sich Elemente während des Ladens unerwartet verschieben. Der Wert ist dimensionslos. Gut ist ein Wert von ≤ 0,1, schlecht sind mehr als 0,25.

Ein Wert im gelben Bereich („verbesserungswürdig“) reicht nicht: Google zählt eine Seite erst dann als „bestanden“, wenn alle drei Core Web Vitals im grünen Bereich liegen.

Wie werden Core Web Vitals gemessen?

Core Web Vitals werden auf zwei Arten gemessen: mit Felddaten und mit Labordaten. Beide beantworten unterschiedliche Fragen.

• Felddaten (Field Data): anonyme Messungen echter Chrome-Nutzer, gesammelt im Chrome User Experience Report (CrUX) über 28 Tage. Diese Daten fließen ins Ranking ein, weil sie die reale Erfahrung abbilden.
• Labordaten (Lab Data): simulierte Messungen unter standardisierten Bedingungen, etwa mit Lighthouse. Sie sind reproduzierbar und ideal zum Debuggen, spiegeln aber keine echten Geräte und Netze wider.

Entscheidend ist das 75. Perzentil: Google bewertet nicht den Durchschnitt, sondern den Wert, den 75 % der Nutzer erreichen oder unterbieten. Eine Seite besteht nur, wenn drei von vier Besuchern eine gute Erfahrung haben. Die wichtigsten Werkzeuge sind PageSpeed Insights, der Core-Web-Vitals-Bericht in der Google Search Console und die Chrome DevTools.

Was wurde aus FID?

INP hat FID ersetzt. Bis zum 12. März 2024 war First Input Delay (FID) die dritte Core-Web-Vitals-Metrik für Interaktivität. FID maß nur die Verzögerung der allerersten Eingabe, nicht die Reaktion auf spätere Klicks.

Interaction to Next Paint bewertet dagegen alle Interaktionen einer Sitzung und meldet die langsamste, statt nur den ersten Kontakt. INP ist damit strenger und näher an der tatsächlichen Bedienbarkeit. Wer noch alte Audits mit FID vorliegen hat, sollte die Werte neu erheben, weil FID seit 2024 kein Core Web Vital mehr ist.

Warum sind Core Web Vitals wichtig für SEO?

Core Web Vitals sind ein bestätigter Google-Rankingfaktor, eingebettet ins Signal „Page Experience“. Bei ähnlich relevanten Inhalten kann die schnellere, stabilere Seite besser ranken. Der Effekt ist kein Turbo, sondern ein Tiebreaker: Guter Content bleibt die Grundlage, schlechte Core Web Vitals bremsen ihn aber aus.

Der zweite Hebel ist die Conversion. Langsame Seiten und springende Layouts erhöhen die Absprungrate, weil Nutzer abbrechen, bevor die Seite bedienbar ist. Schnelle Core Web Vitals verbessern damit zwei Ziele gleichzeitig: Sichtbarkeit in der Suche und Verhalten der Besucher auf der Seite. Deshalb sind die Werte fester Bestandteil jedes technischen SEO-Audits.

Wie verbessert man die Core Web Vitals?

Jede der drei Metriken hat eigene Stellschrauben. Wer die Core Web Vitals verbessern will, optimiert gezielt pro Wert statt pauschal.

• LCP verbessern: Serverantwort (TTFB) beschleunigen, ein Content Delivery Network (CDN) und Cache einsetzen, Bilder in modernen Bildformaten wie WebP ausliefern und das LCP-Element vorladen. Wichtig: das größte Bild im Sichtbereich niemals per Lazy Loading verzögern.
• INP verbessern: lange JavaScript-Aufgaben aufteilen, Arbeit vom Haupt-Thread nehmen, unnötige Skripte von Drittanbietern entfernen und Eingabe-Handler schlank halten.
• CLS verbessern: feste Breite und Höhe (oder aspect-ratio) für Bilder und Einbettungen setzen, Platz für Werbung und Banner reservieren und Webfonts vorladen, damit kein Text nachträglich umbricht.

Die meisten Probleme lassen sich technisch lösen, ohne den Inhalt anzufassen. Wo Theme, Hosting oder Plugins die Werte drücken, hilft eine laufende SEO-Betreuung, die die Core Web Vitals dauerhaft im grünen Bereich hält.

Häufige Fragen zu Core Web Vitals

Wie viele Core Web Vitals gibt es?
Es gibt 3 Core Web Vitals: Largest Contentful Paint (LCP) für die Ladezeit, Interaction to Next Paint (INP) für die Reaktionsfähigkeit und Cumulative Layout Shift (CLS) für die visuelle Stabilität.

Sind Core Web Vitals ein Rankingfaktor?
Ja, Core Web Vitals sind Teil des Google-Signals „Page Experience“. Der Einfluss ist moderat und wirkt vor allem als Tiebreaker zwischen inhaltlich vergleichbaren Seiten.

Was ist ein guter LCP-Wert?
Ein guter LCP-Wert liegt bei 2,5 Sekunden oder darunter, gemessen am 75. Perzentil echter Nutzer. Zwischen 2,5 und 4,0 Sekunden gilt der Wert als verbesserungswürdig, über 4,0 Sekunden als schlecht.

Wo sehe ich die Core Web Vitals meiner Website?
Die Core Web Vitals findest du in PageSpeed Insights, im Core-Web-Vitals-Bericht der Google Search Console und in den Chrome DevTools. Search Console zeigt Felddaten echter Nutzer, PageSpeed Insights kombiniert Feld- und Labordaten.