Cumulative Layout Shift (CLS): Was ist das und wie beheben?

Was ist Cumulative Layout Shift (CLS)?

Cumulative Layout Shift (CLS) ist eine Core Web Vitals Kennzahl. Sie misst, wie stark sich sichtbare Inhalte beim Laden und während des Besuchs unerwartet verschieben. Ein niedriger Wert bedeutet eine stabile Seite. Google bewertet ein CLS von 0,1 oder weniger als gut.

Ein Alltagsbeispiel: Sie lesen einen Artikel, ein Bild lädt spät, und der Text rutscht nach unten. Oder Sie wollen auf einen Button tippen, eine Anzeige erscheint, und Sie treffen das Falsche. Beide Momente sind Layout Shifts.

Unser Team sieht das regelmäßig in Audits. Besucher benennen das Problem selten, aber sie spüren es. Dann sinkt ihr Vertrauen, und sie verlassen die Seite. Deshalb behandeln wir Messung, Schwellenwerte, Ursachen und Lösungen auf Basis der offiziellen web.dev Dokumentation.

LCP und INP vertiefen wir hier nicht. Wenn Sie alle drei Kennzahlen zusammen sehen möchten, lesen Sie unseren Core Web Vitals Leitfaden. Daher bleibt dieser Beitrag bei der visuellen Stabilität.

Warum ist Cumulative Layout Shift wichtig?

CLS ist wichtig, weil es Nutzer zu Fehlern verleitet. Fehlklicks, verlorene Leseposition und ein springender Bezahlbutton sind typische Beispiele. Außerdem senken solche Probleme die Conversion.

Der zweite Blickwinkel ist also die Suche. Denn Google zählt Core Web Vitals zu den Signalen der Seitenerfahrung. Allerdings hebt die Korrektur von CLS allein Ihr Ranking nicht spürbar, denn die inhaltliche Relevanz steht immer vorn. Trotzdem kann sie zwei ähnliche Seiten voneinander trennen.

Für das größere Bild zur Geschwindigkeit lesen Sie, wie die Ladezeit das SEO beeinflusst. Wir empfehlen, CLS aus drei Gründen zu priorisieren:

• Es verringert den Frust durch Fehlklicks.
• Es hilft, Abbrüche in Formularen und im Checkout zu senken.
• Es macht technische Schulden früh sichtbar, sodass die Kosten später nicht wachsen.

Kurz gesagt: CLS wirkt klein, beeinflusst aber das Vertrauen direkt. Zudem ist die Korrektur meist günstiger als bei den anderen beiden Kennzahlen.

Zum Beispiel kann ein Bild mit zwei fehlenden Attributen mehr kosten als ein langsamer Server. Außerdem prägen Verschiebungen die Markenwahrnehmung: Eine springende Unternehmensseite wirkt nachlässig, egal wie gut der Inhalt ist.

Wie berechnen Sie den Cumulative Layout Shift Wert?

Eine einzelne Verschiebung bewerten Sie mit einer Formel: Impact Fraction mal Distance Fraction. web.dev schreibt sie als layout shift score = impact fraction * distance fraction.

Die Impact Fraction zeigt, welchen Teil des Viewports die instabilen Elemente zwischen zwei Frames betreffen. Die Distance Fraction teilt die größte Distanz, die ein instabiles Element zurücklegt, durch die größte Dimension des Viewports.

Dazu ein Rechenbeispiel (angenommene Werte, nicht von einer echten Seite). Konkret schiebt ein spätes Bild Inhalt, der die Hälfte des Viewports belegt. Die Impact Fraction beträgt also 0,5. Der Inhalt rutscht um 20 Prozent der Bildschirmhöhe nach unten, die Distance Fraction beträgt daher 0,2. Der Wert ist dann 0,5 x 0,2 = 0,10.

Somit kann ein einziges Bild Ihre Seite allein an die Schwelle bringen. Deshalb verdienen auch kleine Verschiebungen Aufmerksamkeit. Außerdem summieren sie sich: 0,04 + 0,05 + 0,03 ergibt 0,12, also drei harmlos wirkende Sprünge über der Grenze von 0,1.

Denken Sie daher an das Gesamterlebnis, nicht an ein einzelnes Ereignis.

Welcher CLS Wert ist gut?

web.dev empfiehlt, bei mindestens 75 Prozent der Seitenaufrufe ein CLS von 0,1 oder weniger zu erreichen. Sie beurteilen also das 75. Perzentil und nicht den Durchschnitt.

Mobil und Desktop messen Sie getrennt. Denn auf kleinen Bildschirmen erzeugt dieselbe Verschiebung eine größere Impact Fraction. Deshalb fällt der mobile Wert oft schlechter aus.

Sehen Sie diese Schwellen also als Ziele, nicht als Urteile. Entscheidend ist ein Trend in die richtige Richtung und echte Nutzerdaten, die im 75. Perzentil grün erreichen.

Zum Beispiel: Zeigt der Desktop 0,05 und das Handy 0,22, hat mobil klar Vorrang. Beim Berichten nennen Sie beide Werte, die betroffenen URL Gruppen und den Trend zusammen. Somit erkennen Entscheider die Prioritäten schneller.

Was ist ein Session Window bei Layout Shifts?

Ein Session Window fasst Verschiebungen zusammen, die dicht beieinander liegen. Laut web.dev liegt zwischen den Verschiebungen weniger als 1 Sekunde Pause, und das gesamte Fenster dauert höchstens 5 Sekunden.

Ihr CLS ist der Gesamtwert des größten Fensters im Leben der Seite. Sie addieren also nicht jede Verschiebung des gesamten Besuchs. Stattdessen entscheidet die schlimmste Serie.

Das ist deshalb wichtig bei Seiten, die lange offen bleiben. Bei Single Page Apps und endlosem Scrollen konnte der ältere Ansatz den Wert aufblähen, je länger die Seite offen war. Fenster mildern diese Ungerechtigkeit.

Die Konsequenz in der Praxis: Bereinigen Sie zunächst die Verschiebungen beim Laden. Prüfen Sie dann auch Elemente, die beim Scrollen erscheinen. Denn das schlimmste Fenster kann mitten auf der Seite beginnen.

Welche Layout Shifts zählen nicht zum CLS?

Verschiebungen innerhalb von 500 Millisekunden nach einer Nutzeraktion gelten als erwartet. Zum Beispiel gehören Klicks, Taps und Tastatureingaben dazu. Der Browser setzt bei diesen Verschiebungen das Flag hadRecentInput, sodass Sie sie ausschließen können.

Dauerhafte Interaktionen wie Scrollen, Ziehen und Pinch Zoom zählen nicht als Ausnahme. Springt der Inhalt also beim Scrollen, belastet das Ihren Wert.

Die Regel liefert zudem ein Designprinzip. Ein Menü, das nach einem Klick aufgeht, ist unproblematisch. Dagegen ist ein Element, das ohne jede Nutzeraktion erscheint, ist das Problem.

• Ein Akkordeon, das sich beim Klick öffnet: zählt nicht.
• Ein Banner, das beim Laden von selbst erscheint: zählt.
• Karten, die beim endlosen Scrollen nachladen: zählen, wenn Sie keinen Platz reserviert haben.

Daher ist es ein günstiger und zuverlässiger Weg, Inhalte an eine Nutzeraktion zu binden, um das CLS zu senken.

Wie messen Sie CLS?

CLS messen Sie auf zwei Wegen: mit Labordaten und mit Felddaten. Erstens liefert ein Labortool einen Wert in einem kontrollierten Ladevorgang. Zweitens zeigen Felddaten dagegen, was echte Besucher erlebt haben.

Für den Einstieg nutzen Sie diese Werkzeuge:

• PageSpeed Insights: zeigt echte Nutzerdaten (CrUX) neben dem Laborergebnis.
• Chrome DevTools Performance Panel: Die Spur Layout Shifts markiert Verschiebungen mit lila Balken.
• Lighthouse: listet Bilder ohne Abmessungen und die verschobenen Elemente auf.
• Search Console Bericht Core Web Vitals: zeigt, welche URL Gruppen Probleme haben.

Die Grundlagen zu Lighthouse finden Sie in unserem Beitrag zum Lighthouse Performance Test. Außerdem hilft Ihnen die Live Ansicht von Chrome, CLS während der Interaktion zu beobachten.

Schauen Sie zuerst in die Felddaten und suchen Sie dann im Labor die Ursache. Sonst jagen Sie Problemen hinterher, die es gar nicht gibt.

Warum unterscheiden sich Felddaten und Labordaten beim CLS?

Denn ein Labortest läuft auf einem Gerät, mit einer Verbindung und meist beim ersten Laden. Echte Nutzer dagegen scrollen, schließen Cookie Banner, wechseln Tabs und nutzen viele verschiedene Geräte.

Es überrascht daher nicht, wenn Sie im Labor 0,02 und im Feld 0,18 sehen. Die Lücke entsteht meist durch diese Quellen:

• Späte Anzeigen und Einbettungen, die beim Scrollen laden.
• Einwilligungs- oder Personalisierungsskripte, die nur bei echten Besuchern laufen.
• Schriften, die bei langsamer Verbindung spät eintreffen.
• Bildformate, die sich je nach Bildschirmgröße ändern.

Ein grünes Laborergebnis reicht deshalb nicht aus. Um eine Verschiebung nachzustellen, drosseln Sie das Netzwerk, leeren den Cache und testen durch Scrollen.

Felddaten brauchen außerdem Zeit. Denn CrUX arbeitet mit einem gleitenden Zeitraum und nicht tageweise. Erwarten Sie also nach einer Korrektur keine sofortige Bestätigung.

Was sind die häufigsten Ursachen für CLS?

Der Optimierungsleitfaden von web.dev nennt vier Hauptursachen: Bilder ohne Abmessungen, Anzeigen und Einbettungen ohne Abmessungen, dynamisch eingefügte Inhalte und Webfonts. Wir ergänzen Animationsfehler.

Die meisten dieser Ursachen haben eine gemeinsame Wurzel: Der Browser weiß nicht, wie viel Platz der Inhalt braucht. Jede Lösung macht deshalb dasselbe, nämlich die Größe vorab zu nennen.

Deshalb gehen wir als Nächstes jede Ursache einzeln durch. Zunächst die häufigste: Bilder.

Wie verursachen Bilder ohne Abmessungen Layout Shifts?

Kennt der Browser die Größe eines Bildes nicht, reserviert er keinen Platz. Dann rutscht der Inhalt nach unten, sobald das Bild eintrifft. Somit ist das die häufigste und am leichtesten behebbare Ursache.

Die Lösung ist einfach. Ergänzen Sie bei jedem img und video Element die Attribute width und height. Denn moderne Browser berechnen daraus das Seitenverhältnis und reservieren den Platz, bevor die Datei lädt. Das Verhältnis bleibt sogar dann erhalten, wenn Ihr CSS die Breite auf 100 Prozent setzt.

Bei responsiven Bildern sollte jede srcset Variante dasselbe Seitenverhältnis haben. Sonst kann der Browser beim Eintreffen der gewählten Variante trotzdem springen.

Lighthouse findet Bilder ohne Abmessungen. Die Dateigröße ist ein eigenes Thema; dazu lesen Sie unseren Beitrag zur Bildoptimierung.

Nutzen Sie Lazy Loading, lassen Sie die Größenangabe trotzdem nicht weg. Lazy Loading verringert die Verzögerung, erhöht aber das Risiko für Verschiebungen, wenn Sie keinen Platz reservieren.

Wie reservieren Sie Platz für Anzeigen, Einbettungen und iframes?

Anzeigenplätze, Videoeinbettungen und Social Widgets kommen oft ohne Abmessungen. Füllen sie sich spät, rutscht alles darunter nach unten.

web.dev empfiehlt diesen Weg: Reservieren Sie vorab Platz mit min-height oder aspect-ratio und setzen Sie spät ladende Inhalte weiter unten in den Viewport. Nutzen Sie einen Platzhalter, statt Inhalte ohne Nutzeraktion einzufügen.

Werbenetzwerke liefern mitunter mehrere Größen. Reservieren Sie dann den Platz für die Größe, die am häufigsten kommt. Bleibt die Anzeige aus, haben Sie einen leeren Slot, doch der schadet weniger als springender Inhalt.

• Geben Sie eingebettetem Video ein aspect-ratio wie 16 / 9.
• Setzen Sie bei Karten und Social Einbettungen eine feste Höhe.
• Vermeiden Sie spät gefüllte Anzeigen im oberen Seitenbereich.

Dabei müssen Sie Einnahmen und Nutzererlebnis abwägen. Vergleichen Sie dabei kurzfristige Erlöse mit langfristigem Vertrauen.

Wie verursachen Webfonts Layout Shifts?

Der Browser zeichnet den Text zuerst mit einer Ersatzschrift und zeichnet ihn neu, sobald der Webfont da ist. Haben beide Schriften unterschiedliche Buchstabenbreiten, brechen Zeilen neu um, und der Textblock verschiebt sich.

web.dev nennt mehrere Maßnahmen. Laden Sie kritische Schriften mit link rel=preload vor. Nutzen Sie font-display: optional, um Neuberechnungen ganz zu vermeiden. Wählen Sie eine passende Ersatzschrift und nähern Sie sie mit size-adjust und ascent-override an den Webfont an.

Auch die Schriftwahl beeinflusst die Performance. Zur Gestaltung lesen Sie Web Typografie: die richtige Schrift wählen. Außerdem sollten Sie Schriftschnitte, die Sie nie nutzen, nicht laden, etwa ungenutzte Kursivschnitte. Dann gewinnen Sie Tempo und senken das Risiko.

Verursachen dynamische Inhalte und Cookie Banner Layout Shifts?

Ja, das können sie. Fügt sich ein Cookie Banner oben in die Seite ein, schiebt es den gesamten Inhalt nach unten. Benachrichtigungsleisten, Anmeldeboxen und Aktionsstreifen wirken ebenso.

Die Lösung: Nehmen Sie diese Elemente aus dem Dokumentfluss. Zum Beispiel heften Sie das Banner unten an, oder reservieren Sie oben von Anfang an einen Platz. Bei Inhalten mit Nutzeraktion, etwa einem Button Mehr laden, erscheint der neue Inhalt nach der Eingabe, deshalb zählt er nicht.

Für Pop ups lohnt außerdem ein Blick auf Exit Intent Popups. Ein gut gestaltetes Pop up liegt über der Seite und schiebt sie nicht weg.

• Positionieren Sie das Banner fest, damit es keinen Inhalt schiebt.
• Aktualisieren Sie neue Inhalte in einem Container fester Größe.
• Binden Sie späte Serverinhalte an eine Nutzeraktion.

Wie wirken sich Animationen auf CLS aus?

Animieren Sie Eigenschaften wie top, left, box-shadow und box-sizing, berechnet der Browser das Layout neu, und Nachbarelemente können springen. Diese Verschiebungen belasten Ihren Wert.

Die Antwort von web.dev ist eindeutig: Nutzen Sie transform für Animationen. transform: translate() und transform: scale() verändern den Layoutfluss nicht, also erzeugen sie keine Verschiebung. Außerdem laufen sie flüssig auf der GPU.

Zum Beispiel nutzen Sie bei einem Menü, das herunterfährt, translateY statt top zu ändern. Das Ergebnis sieht gleich aus, allerdings die umliegenden Elemente bleiben stehen.

Inspiration finden Sie in unseren Mikroanimationen Beispielen.

Wie beheben Sie CLS bei WordPress und Onlineshops?

Denn bei Seiten mit fertigen Themes und Plugins stammt die Verschiebung meist aus einer einzigen Komponente. Slider, Pop ups, Bewertungs Plugins, Live Chat Bubbles und Produktgalerien sind die üblichen Verdächtigen.

Im E-Commerce bringen drei Änderungen viel: Geben Sie Produktbildern Abmessungen, verhindern Sie späte Preis und Bestandsangaben, und legen Sie den Warenkorbhinweis in einen festen Bereich. Allerdings kostet eine Verschiebung im Checkout Sie direkt Bestellungen.

Technisch prüfen Sie diese Punkte:

• Definiert der Slider des Themes eine Höhe?
• Fügt das Bewertungs Plugin Inhalte spät ein?
• Schiebt die Live Chat Bubble die Seite, oder liegt sie darüber?
• Haben die Bilder der Produktgalerie width und height?

Zur Plattformwahl lesen Sie WordPress oder individuelle Website. Gehört der Code Ihnen, hält eine Korrektur an der Quelle länger, als Plugin auf Plugin zu stapeln.

Wie messen Sie CLS bei Single Page Apps?

Bei Single Page Apps (SPA) gelten Routenwechsel nicht als Ladevorgang im Browser. Ein Nutzer kann also viele Ansichten besuchen, und der Browser sieht trotzdem nur eine Seitenlebensdauer.

Session Windows mildern das, denn nur das schlimmste Fenster zählt. Trotzdem sollten Sie bei jedem Routenwechsel Skeleton Screens nutzen und die Containergröße fest halten, während Sie auf Daten warten.

Zum Beispiel kann eine Liste, die bis zum Dateneingang leer bleibt, kann um Hunderte Pixel wachsen. Zeichnen Sie daher einen Platzhalter in der erwarteten Höhe. Dann bleiben die Elemente darunter an Ort und Stelle, wenn sich der Inhalt füllt.

Eine weitere Falle beim Routenwechsel: alten Inhalt löschen und den neuen erst später einfügen. Behalten Sie den alten Bildschirm, bis der neue bereit ist, oder nutzen Sie einen Container fester Größe.

Außerdem spielt das Gewicht von JavaScript hinein. Späte Skripte fügen Inhalt ein und erzeugen Verschiebungen; Details finden Sie im Beitrag JavaScript und Ladezeit.

Wie verbessern Sie den Cumulative Layout Shift Schritt für Schritt?

Den Cumulative Layout Shift verbessern Sie in einer systematischen Schleife: zuerst messen, dann die größte Verschiebung finden, beheben und erneut messen. Die folgende Reihenfolge ist das Vorgehen unseres Teams in Projekten.

1. Ermitteln Sie in der Search Console die problematischen URL Gruppen.
2. Vergleichen Sie in PageSpeed Insights Feld und Labordaten derselben URL.
3. Öffnen Sie in den DevTools die Spur Layout Shifts und suchen Sie die größte Verschiebung.
4. Ordnen Sie das Element zu: Bild, Anzeige, Schrift, dynamischer Inhalt oder Animation.
5. Setzen Sie die Lösung um: Größenattribute, reservierter Platz, Schrifteinstellungen oder transform.
6. Prüfen Sie im langsamen Netz und auf einem Handy, dass die Verschiebung wirklich weg ist.
7. Warten Sie auf die Aktualisierung der Felddaten und berichten Sie das Ergebnis.

Das Kernprinzip lautet: Beheben Sie zuerst die einzelne Verschiebung mit dem höchsten Wertanteil. Denn auf den meisten Seiten erzeugen wenige Elemente den größten Teil der Summe.

Ein Beispiel auf Codeebene: Schreiben Sie width="800" height="450" in das img Tag und nutzen Sie in CSS height: auto. So bleibt das Verhältnis erhalten, und der Platz ist vorab reserviert.

In welcher Reihenfolge beheben Sie CLS Probleme?

Allerdings kostet nicht jede Korrektur gleich viel und bringt gleich viel. Wägen Sie deshalb Wirkung, Aufwand und Risiko gemeinsam ab. Die folgende Tabelle zeigt eine allgemeine Startreihenfolge; Ihre Seite kann abweichen.

Diese Reihenfolge ist ein Startpunkt aus der Praxis, keine Garantie. Die tatsächliche Reihenfolge ergibt sich aus der größten Verschiebung, die Sie in den DevTools sehen.

Messen Sie außerdem nach jedem Schritt erneut. Dann sehen Sie, welche Änderung gewirkt hat, und können die wirkungslose zurücknehmen.

Wie sieht eine CLS Diagnose an einer echten Seite aus?

Gehen wir ein angenommenes Beispiel durch (ein Szenario zur Veranschaulichung, kein echter Kunde). Ein Blog Template zeigt mobil ein CLS von 0,21, und die Search Console ordnet die Seite der Gruppe Verbesserungsbedarf zu.

In der DevTools Spur Layout Shifts sehen Sie drei Verschiebungen. Erstens lädt das Titelbild spät. Zweitens erscheint oben ein Cookie Banner. Drittens wechselt die Textschrift.

Diese Werte sind eine Beispielrechnung. Sie ergeben zusammen 0,21, und allein die Korrektur des Bildes bringt die Seite auf 0,09, also unter die Schwelle.

Beachten Sie: Der größte Gewinn kommt aus der einfachsten Korrektur. Bei der Diagnose schauen Sie deshalb zuerst auf die größte Verschiebung und schließen den Rest der Reihe nach. So sehen Sie die Wirkung jedes Schritts und erzählen im Bericht eine klare Geschichte.

Beeinflusst der Back/Forward Cache das CLS?

Ja, und zwar positiv. Laut web.dev sollte der CLS Wert auf null zurückgehen, wenn eine Seite aus dem Back/Forward Cache wiederhergestellt wird, denn Nutzer erleben das als eigenen Seitenbesuch.

Bessere bfcache Eignung beseitigt daher Verschiebungen durch erneutes Laden bei Nutzern, die mit der Zurück Taste wiederkommen. Ob Ihre Seite geeignet ist, testen Sie im Application Panel der Chrome DevTools.

Allerdings können alte Gewohnheiten wie ein unload Listener die Eignung zerstören. Nehmen Sie deshalb eine bfcache Prüfung in Ihre technischen Audits auf.

Für einen allgemeinen technischen Gesundheitscheck lesen Sie unsere Tipps zum technischen SEO.

Wie hängen CLS, LCP und INP zusammen?

Core Web Vitals bestehen aus drei Kennzahlen: LCP misst die Ladegeschwindigkeit, INP die Reaktion auf Interaktion und CLS die visuelle Stabilität. Jede erfasst also ein anderes Nutzererlebnis.

LCP behandeln wir hier nicht im Detail, doch es hilft zu wissen, wo sich die Kennzahlen überschneiden. Zum Beispiel verbessert das frühe Laden eines Hero Bildes das LCP, aber ohne Abmessungen schaden Sie dem CLS.

Ebenso belastet schweres JavaScript das INP und kann über spät eingefügte Inhalte auch das CLS verschlechtern. Mobil verschärfen sich die Probleme zudem; den Ansatz erklärt der Beitrag Mobile First Design.

Optimieren Sie daher nicht eine Kennzahl und zerstören die andere. Messen Sie also nach jeder Änderung alle drei.

Wie überwachen Sie CLS dauerhaft?

Allerdings ist eine CLS Korrektur keine einmalige Aufgabe. Ein neues Plugin, ein neues Werbenetzwerk oder ein Theme Update kann Verschiebungen zurückbringen. Machen Sie die Überwachung deshalb zur Routine.

• Prüfen Sie den Bericht Core Web Vitals in der Search Console jeden Monat.
• Speichern Sie das PageSpeed Insights Ergebnis für wichtige Templates: Startseite, Kategorie, Produkt, Blog.
• Führen Sie nach jedem größeren Release einen schnellen Verschiebungscheck in den DevTools durch.
• Schreiben Sie einen Plan zur Platzreservierung, bevor Sie eine neue Anzeige oder ein Fremdskript einbinden.

Klären Sie außerdem die Zuständigkeit im Team. Das Design verantwortet Abmessungen und reservierten Platz, die Entwicklung Schriften und Ladereihenfolge, das Marketing Anzeigen und Banner.

Gutes CLS ist am Ende keine einmalige Korrektur. Es ist eine Gewohnheit, die fest im Veröffentlichungsprozess verankert ist.

Welche CLS Fehler passieren am häufigsten?

In Audits sehen wir diese Fehler oft:

• Nur auf den Laborwert schauen und das echte Problem im Feld übersehen.
• Bildern width und height geben und das Verhältnis dann im CSS zerstören.
• Anzeigenplatz reservieren, aber die falsche Größe wählen.
• Eine Schrift komplett entfernen, statt das Laden zu korrigieren.
• Mobile Tests auslassen, obwohl der mobile Wert oft schlechter ist.

Ein weiterer Fehler ist das Vertrauen auf eine einzige Messung, denn ein Test verbirgt vieles. Denn eine Verschiebung zeigt sich manchmal nur auf einem bestimmten Gerät oder bei einer bestimmten Verbindungsgeschwindigkeit. Testen Sie daher mit mehreren Szenarien.

Schauen Sie schließlich nicht nur auf den Wert. Öffnen Sie die Seite dann wie ein echter Nutzer, scrollen Sie und drücken Sie Buttons. Stört Sie ein Sprung, spüren ihn Ihre Besucher ebenso.

Wann sollten Sie Expertenhilfe holen?

Ist das Problem ein einzelnes Bild, lösen Sie es also selbst. Kommt die Verschiebung dagegen aus einem Mix aus Theme, Plugins und Fremdskripten, kostet die Ursachensuche Zeit.

Als Talha Aslan und Team prüfen wir CLS in technischen SEO Audits gemeinsam mit Felddaten. Bei Bedarf bauen wir im Rahmen unseres Webdesigns das Template um und definieren in der SEO Beratung eine Überwachungsroutine.

Zunächst legen wir das Ziel fest: welche Templates, welche Geräte und welche Schwelle. Somit erhalten wir am Ende einen messbaren Vorher Nachher Vergleich. Nach Abschluss übergeben wir Ihnen die Überwachungsliste.

Zur Vorbereitung sammeln Sie Ihren Search Console Bericht, Ihre Plugin Liste und Ihre Werbenetzwerke. Dann gehen wir im ersten Gespräch direkt an die Ursache.

Quellen: web.dev CLS, web.dev CLS optimieren und Google Search Central Core Web Vitals.