Die besten Tipps zur Behebung von CLS-Problemen in der Search Console

Table of contents

CLS: Der Hintergrund

Cumulative Layout Shift misst unerwartete Layoutverschiebungen. Jedes Mal, wenn ein sichtbares Element seine Position verändert, während eine Seite lädt oder mit ihr interagiert wird, wird ein Layout-Shift-Score berechnet. Der kumulierte Wert ergibt den CLS.

Häufige Ursachen:

• Bilder oder iframes ohne explizite width- und height-Attribute
• Anzeigen, die sich ausdehnen, nachdem der umgebende Inhalt bereits gerendert wurde
• Dynamisch eingefügter Inhalt (Banner, Cookie-Hinweise, Chat-Widgets), der oberhalb des bestehenden Inhalts eingesetzt wird
• Webfonts, die beim Laden einen Flash und ein Reflow verursachen (FOUT/FOIT)
• JavaScript von Drittanbietern, das nach dem initialen Rendering UI-Elemente einfügt

Weiterführend: Wie man LCP-Probleme in der Search Console behebt

CLS messen

Google Search Console

Der Core Web Vitals-Bericht in der Search Console ist der Ausgangspunkt. Er zeigt Seiten, die als „Schlecht” (CLS ≥ 0,25) oder „Verbesserungswürdig” (0,1–0,25) markiert sind, gruppiert nach Problemtyp. Nutze diesen Bericht, um die Liste der betroffenen URLs zu erhalten.

PageSpeed Insights

PageSpeed Insights (PSI) zeigt sowohl Labordaten (Lighthouse-Simulation) als auch Felddaten von echten Nutzern über den Chrome UX Report (CrUX). Die Felddaten sind für das Ranking relevanter — sie spiegeln echte Nutzererfahrungen wider, nicht nur einen synthetischen Test.

PSI simuliert beim Laden nur den initialen Viewport, sodass es CLS, der durch Scrollen oder Nutzerinteraktion ausgelöst wird, möglicherweise nicht erfasst. Für diese Fälle eignet sich Chrome DevTools.

Chrome DevTools und die Web Vitals-Erweiterung

Die Web Vitals-Chrome-Erweiterung (von Google gepflegt) zeigt Live-CLS-Werte beim Scrollen und Interagieren mit einer Seite an. Das ist der schnellste Weg, um Layoutverschiebungen manuell zu reproduzieren. Das Performance-Panel von Chrome DevTools hebt außerdem Layout-Shift-Einträge mit Anmerkungen hervor, die zeigen, welche Elemente sich verschoben haben und um wie viel.

CLS-Probleme beheben

width und height zu allen Bildern und iframes hinzufügen

Das ist die wirkungsvollste Maßnahme für die meisten Websites. Ohne explizite Abmessungen weiß der Browser nicht, wie viel Platz er reservieren soll, während ein Bild lädt – der Inhalt darunter wird nach unten verschoben, wenn das Bild erscheint.

<!-- Schlecht: keine Abmessungen -->
<img src="photo.jpg" alt="…">

<!-- Gut: explizite Abmessungen ermöglichen dem Browser, Platz zu reservieren -->
<img src="photo.jpg" alt="…" width="800" height="450">

Modernes CSS (aspect-ratio) erzielt denselben Effekt bei responsiven Bildern, aber das Setzen von width- und height-Attributen direkt im HTML ist der zuverlässigste Ansatz und wird von den meisten modernen Frameworks und CMS-Bild-Pipelines automatisch übernommen.

Platz für Anzeigen reservieren

Anzeigen sind die häufigste Ursache für hohen CLS auf monetarisierten Websites. Werbenetzwerke liefern dynamische Größen, und wenn kein Platz reserviert ist, fließt die Seite neu, wenn die Anzeige geladen wird.

1. Reserviere einen festen Container (min-height passend zur häufigsten Anzeigengröße), bevor das Anzeigen-Tag lädt.
2. Reduziere den Container nicht, wenn keine Anzeige ausgeliefert wird — ein leerer Platzhalter verhindert ein zweites Reflow.
3. Sei besonders vorsichtig bei Anzeigen in der Nähe des oberen Viewport-Bereichs. Nicht-sticky Anzeigen, die über dem Fold eingefügt werden, verursachen die schlechtesten CLS-Werte.
4. Nutze historische Impressionsdaten deines Werbenetzwerks, um zu bestimmen, welche Anzeigengrößen für jeden Slot am häufigsten sind, und dimensioniere den Container entsprechend.

Das Einfügen von Inhalten über bestehendem Inhalt vermeiden

Cookie-Zustimmungs-Banner, Benachrichtigungs-Prompts und Chat-Widgets, die asynchron laden und oberhalb bestehenden Inhalts erscheinen, sind eine häufige CLS-Quelle. Optionen:

• Lade sie in einem Overlay mit fester Position (sie beeinflussen den Dokumentenfluss nicht).
• Weise im Layout vorab Platz zu, wenn sie inline erscheinen müssen.
• Bei Cookie-Bannern speziell empfiehlt sich eine Platzierung am unteren Bildschirmrand — das vermeidet CLS vollständig und ist rechtlich ebenso konform.

Webfont-Laden korrigieren (FOIT und FOUT)

FOIT (Flash of Invisible Text) tritt auf, wenn ein Browser Text ausblendet, bis eine benutzerdefinierte Schrift geladen ist. FOUT (Flash of Unstyled Text) tritt auf, wenn zuerst eine Fallback-Schrift angezeigt und dann ausgetauscht wird — der Unterschied in den Schriftmetriken verursacht eine Layoutverschiebung.

Die Lösung ist font-display: swap kombiniert mit <link rel="preload"> für kritische Schriften:

<link rel="preload" href="/fonts/my-font.woff2" as="font" type="font/woff2" crossorigin>

@font-face {
  font-family: 'MyFont';
  src: url('/fonts/my-font.woff2') format('woff2');
  font-display: swap;
}

font-display: swap verursacht FOUT (sichtbarer, aber ungestylter Text) statt FOIT (unsichtbarer Text), was besser für CLS ist, da der Text sofort sichtbar ist. Um den Metrik-Einfluss des Austauschs weiter zu reduzieren, verwende die CSS-Eigenschaft size-adjust, um die Fallback-Schriftmetriken an die benutzerdefinierte Schrift anzupassen — das minimiert das Reflow, wenn die benutzerdefinierte Schrift aktiviert wird.

JavaScript von Drittanbietern

Skripte von Drittanbietern (Share-Buttons, Kommentar-Widgets, Live-Chat, Analytics-Popups) laden asynchron und fügen oft UI-Elemente ein, nachdem die Seite bereits gerendert wurde. Um deren CLS-Auswirkung zu minimieren:

• Verschiebe visuelle Drittanbieter-Elemente nach Möglichkeit unter den initialen Viewport — Inhalte weiter unten auf der Seite haben mehr Zeit zum Laden, bevor der Nutzer sie erreicht.
• Definiere Container-Abmessungen vorab, bevor das Skript ausgeführt wird, damit der Browser bereits weiß, wie viel Platz er reservieren soll.
• Nutze den Netzwerk-Tab in Chrome DevTools, gefiltert nach Drittanbieter-Ursprüngen, um zu identifizieren, welche Skripte zu Layoutverschiebungen beitragen.

Lazy Loading und Platzhalter

Lazy Loading verzögert das Laden von Bildern, bis sie sich in der Nähe des Viewports befinden, was Bandbreite spart. Wenn aber kein Platzhalter gesetzt ist, kollabiert der Bild-Container auf null Höhe und springt dann auf, wenn das Bild lädt.

Stelle immer sicher, dass lazy-geladene Elemente explizite Abmessungen oder ein via CSS gesetztes aspect-ratio haben, damit der Browser den richtigen Platz reserviert, bevor das Bild lädt. Das gilt sowohl für das native loading="lazy" als auch für JavaScript-basierte Lazy Loader.

CLS — FAQ 2026

Ist FID 2026 noch ein Rankingfaktor?

Nein. Google hat FID (First Input Delay) im März 2024 offiziell als Core Web Vital abgelöst und durch INP (Interaction to Next Paint) ersetzt. Das aktuelle CWV-Trio lautet LCP, INP und CLS. Aktualisiere jede interne Dokumentation oder jedes Tool, das noch auf FID verweist.

Was ist ein guter CLS-Zielwert?

Googles Schwellenwerte: unter 0,1 ist „gut”, 0,1–0,25 ist „verbesserungswürdig”, über 0,25 ist „schlecht”. Ziel ist ein Wert unter 0,1. Der Score wird beim 75. Perzentil der Seitenladungen in CrUX-Felddaten gemessen.

Beeinflusst CLS das Ranking?

Ja, aber es ist ein Signal unter vielen. Core Web Vitals sind seit Mitte 2021 ein Page-Experience-Rankingfaktor. Ein schlechter CLS wird eine starke Seite nicht versenken, kann aber bei Gleichstand entscheidend sein und wirkt sich eigenständig direkt negativ auf die Nutzer-Engagement-Metriken aus (Absprungrate, Sitzungstiefe).

Mein PSI-Score zeigt guten CLS, aber Search Console markiert die Seite als schlecht — wem soll ich vertrauen?

Vertraue bei Konflikten der Search Console (Felddaten) gegenüber den PSI-Labordaten. PSI-Labortests simulieren nur den initialen Viewport-Ladevorgang; sie erfassen keinen CLS, der durch Nutzer-Scrollen, Schrift-Austausch bei langsameren Verbindungen oder nach Interaktion geladene Anzeigen ausgelöst wird. Die CrUX-Felddaten in der Search Console spiegeln echte Nutzer unter realen Bedingungen wider.

Weiterführende Lektüre:

• Wie man LCP-Probleme in der Search Console behebt
• Wie man die Website-Geschwindigkeit optimiert
• Technisches SEO-Audit

Die Kurzversion

Wenn du das liest, weil der beschriebene Workflow deine ganze Woche frisst, ist das genau die Art von Schleife, für die ich KI-Agenten baue. Zwei Entwicklungsplätze gleichzeitig verfügbar.

Aktualisiert für Mai 2026

Googles Geschichte 2026 lautet AI Overviews überall: Das SGE-Experiment von 2023 wurde im Mai 2024 zu einem Standardfeature und erscheint jetzt bei schätzungsweise ~60 % der informativen US-Suchanfragen. Für SEO- und Anzeigen-Betreiber:

• Organische CTR bei Suchanfragen mit AI Overviews ist im Durchschnitt um 15–30 % gesunken laut veröffentlichten Studien von Ahrefs, Authoritas und ähnlichen Quellen (Daten 2024–25).
• Google Ads hat mehrere PMax-Features unter dem Namen AI-powered Search neu gebrandmarkt; die Kampagnenverwaltungs-UI schlägt jetzt standardmäßig KI-Gebotsstrategien vor.
• Search Console hat Ende 2025 einen Filter für „AI Overview-Impressionen” hinzugefügt — wenn ein Beitrag hier auf GSC-Reporting verweist, muss das Playbook aktualisiert werden.
• Googles Anzeigeneinnahmen überschritten 2024 ~265 Mrd. USD; Search macht weiterhin ~57 % der Gesamteinnahmen von Alphabet aus.

Die Antwort auf „Wie verdient Google Geld?” im Jahr 2026: immer noch Search-Anzeigen (dominant), aber YouTube-Anzeigen, Cloud und Abonnements (YouTube Premium + Google One) sind inzwischen bedeutende Umsatzpositionen.