Ein Cookie-Banner klingt nach einem kleinen, überschaubaren Element auf Deiner Website. Ist er aber nicht. In unserem Agenturalltag sehen wir regelmäßig Websites, deren Sichtbarkeit schleichend oder abrupt einbricht. Die Ursache ist nicht immer ein Algorithmus-Update, eine Abstrafung oder ein großes technisches Problem. Oft ist es ein fehlerhaft implementierter Consent-Banner, den niemand auf dem Schirm hatte.

Dass schwere CMP-Skripte die Ladezeit drücken, ist bekannt. Dass ein Banner das Crawling durch den Googlebot vollständig unterbinden kann, steht in fast keinem Artikel. Genau diese Lücke schließen wir hier. Ich zeige Dir, welche SEO-Probleme durch Consent-Banner entstehen, wie Du typische Fehler erkennst und wie Du sie von Anfang an vermeidest.

Cookie-Banner entscheiden längst nicht mehr nur über Datenschutz, sondern auch über Sichtbarkeit.

Das Wichtigste in Kürze

• Ein fehlerhaft eingebundener Cookie-Banner kann das Crawling durch den Googlebot unterbinden – Sichtbarkeitsverluste entstehen oft schleichend über Monate.
• Das entscheidende Prinzip: Der Banner liegt als visuelles Overlay über dem Content. Alles, was Content versteckt oder blockiert (Gate) schadet der Indexierung, denn der Googlebot klickt keine Buttons und speichert keine Cookies.
• Schwere CMP-Skripte verschlechtern alle Core Web Vitals: LCP durch synchrones Laden, CLS durch nachträglich einspringende Banner, INP durch blockierten Main Thread.
• Gute Usability heißt: zwei klare Buttons auf der ersten Ebene, alles Weitere hinter einem zusätzlichen Klick.
• Schnellster Diagnosetest: Java Script im Browser deaktivieren – ist der Content noch da, ist die Grundlage sauber. Für die Tiefenprüfung: URL-Prüfung in der Google Search Console (HTML-Tab, nicht nur Screenshot).

Wie der Googlebot tickt

Bevor wir uns die konkreten Fehler anschauen, solltest Du verstehen, wie der Googlebot grundsätzlich funktioniert. Denn die meisten Cookie-Banner-Probleme entstehen nicht aus Unwissenheit über SEO, sondern aus Unwissenheit darüber, was der Googlebot überhaupt kann – und was nicht.

Der Googlebot ist kein Mensch

Der Googlebot ist ein automatisierter Crawler. Er öffnet Deine Seite, liest sie aus und interagiert nicht mit ihr. Das bedeutet konkret: Er klickt keine Buttons, akzeptiert keine Banner und scrollt nicht. Google klickt generell keine Elemente auf der Seite an – keine Tab-Inhalte, keine Cookie-Banner. Wer also darauf wartet, dass der Googlebot den Button „Alle akzeptieren“ drückt, wartet vergebens.

Google crawlt Webseiten ohne Klicks, Scrollen oder akzeptierte Cookies. Das ist problematisch für Inhalte hinter Consent-Bannern.

Hinzu kommt: Jeder Render-Vorgang findet in einer neuen Browser-Session statt (siehe „Die Render-Queue“) – ohne gespeicherte Cookies oder Status aus vorherigen Besuchen. Der Googlebot kommt bei jedem Crawl als Neubesucher auf Deine Seite. Ein „er hat ja schon einmal akzeptiert“-Szenario gibt es schlicht nicht.

Wie der Googlebot eine Seite verarbeitet

Der Crawl-Prozess läuft zweistufig ab:

1. Zunächst ruft der Googlebot das HTML der Seite Dieses initiale HTML wird sofort ausgewertet, Links werden extrahiert und Text wird gelesen.
2. In einem zweiten Schritt übergibt der Googlebot das HTML an den sogenannten Web Rendering Service (WRS). Dieser rendert die Seite wie ein moderner Browser und führt dabei Java Script aus. Der WRS arbeitet dabei zustandslos, d. h. er löscht lokalen Speicher sowie Session-Daten zwischen den Anfragen.

Für Dich als SEO bedeutet das: Was nicht im initialen HTML steht, existiert für den Googlebot zunächst gar nicht. Inhalte, die erst nach JS-Ausführung erscheinen, werden möglicherweise erst später hinzugefügt – mit einer zeitlichen Verzögerung und nur, sofern sie interpretiert werden können. Außerdem gilt: Der Googlebot crawlt die ersten 2 MB einer unterstützten Datei – jede referenzierte Ressource, wie CSS und Java Script, wird separat mit demselben Limit abgerufen. Schwere CMP-Skripte (Consent-Management-Platform-Skripte) oder aufgeblähte Banner-Bibliotheken fressen dieses Budget.

Wenn Du Dein Crawlbudget effizienter nutzen möchtest, schau Dir unbedingt unseren Blogbeitrag zur Crawlingsteuerung an.

Das eigentliche Problem: Gate vs. Overlay

Hier liegt der Kern aller SEO-Fehler bei Cookie-Bannern. Es gibt zwei grundlegend verschiedene Arten, einen solchen Banner zu bauen.

1.   Das Gate blockiert den Zugang zum Content

Entweder wird der Content per Java Script erst nach dem Klick auf den Consent-Banner gerendert oder der Content-Container wird per CSS versteckt, bis eine Zustimmung vorliegt. Für den Googlebot, der weder klickt noch Cookies speichert, existiert der dahinterliegende Content nicht.

2.   Das Overlay liegt visuell über dem Content, ohne ihn zu verstecken oder zu blockieren

Der Content ist vollständig im HTML-Code vorhanden und für den Googlebot lesbar. Der Banner ist lediglich eine zusätzliche Schicht, die nur der menschliche Nutzer sieht, während der Bot sie ignoriert.

Der einzige korrekte Ansatz ist das Overlay. Klingt selbstverständlich? Bei rund drei von zehn Neukund*innen, die mit einem Cookie-Banner-Problem zu uns kommen, ist das Gate-Modell die Ursache. Ob auch Du davon betroffen bist, erfährst Du im Teil „Diagnose: So findest Du bestehende Probleme“.

Ein Cookie-Banner kann ein fundamentales SEO-Problem verursachen: die fehlerhafte Crawlability. Kein anderer Fehlertyp hat so schwerwiegende Folgen: Wer nicht gecrawlt wird, wird nicht indexiert. Wer nicht indexiert wird, rankt nicht. Das Tückische daran ist, dass der Schaden oft schleichend über Monate entsteht, bevor er mit dem Banner in Verbindung gebracht wird.

Content hinter der Consent-Wall

Das häufigste und schwerwiegendste Problem ist das Gate-Modell aus dem vorherigen Abschnitt, das in der Praxis jedoch in einem deutlich subtileren Gewand auftritt. Es muss kein explizites „Bitte Cookies akzeptieren, um fortzufahren“ geben. Oft steckt das Problem tiefer im Code.

In unserer Praxis sehen wir diese Problematik bei unseren Kund*innen häufiger. Erst vor kurzem haben wir einen neuen Kunden gewonnen, dessen Shop unter anderem wegen eines Gated-Cookie-Banners enorm an Sichtbarkeit eingebüßt hatte.

Das ist kein Einzelfall. Headless-Architekturen, Single-Page-Applications und Java Script-lastige Frontends sind besonders anfällig für dieses Muster, da der Content oft vollständig über Java Script aufgebaut wird und die CMP genau in diesen Rendering-Prozess eingreift.

Java Script-abhängiges Rendering: Wenn Content erst nach Consent entsteht

In vielen modernen Implementierungen ist der Content nicht im initialen HTML vorhanden, sondern wird clientseitig per Java Script gerendert. Grundsätzlich ist das kein Problem, da der Googlebot Java Script ausführen kann. Ein Problem entsteht jedoch, wenn die CMP diesen Rendering-Prozess blockiert: Sie hält das Java Script an, bis ein Consent-Status vorliegt. Da der Googlebot keinen Consent-Status liefert, wird das Java Script nie geladen und der Content entsteht nie.

Typische Muster, die das auslösen, sind:

• Content-Komponenten, die per if (hasConsent) { renderContent() } gesteuert werden.
• Lazy-Loading, das an einen Consent-Listener gekoppelt ist.
• API-Calls für Content, die erst nach Consent-Klick gefeuert werden.
• Bildquellen, die erst nach Zustimmung als src-Attribut gesetzt werden.

In all diesen Fällen sieht der Web Rendering Service von Google das Ergebnis nach der Java Script-Ausführung – und das Ergebnis ist leer oder unvollständig, weil der Consent-Trigger niemals ausgelöst wurde.

Cloaking: Der unbeabsichtigte Regelverstoß

Ein Szenario, das viele nicht auf dem Schirm haben: User-Agent-basiertes Cloaking. Manche Systeme erkennen den Googlebot über seinen User-Agent-String und liefern ihm automatisch eine Banner-freie Seite – mit der guten Absicht, das Crawling nicht zu behindern. Das Ergebnis ist das genaue Gegenteil: Der Googlebot sieht eine andere Seite als menschliche Nutzer*innen. Das ist per Definition Cloaking – ein klarer Verstoß gegen Googles Webmaster-Richtlinien, der manuelle Maßnahmen nach sich ziehen kann.

Die Lösung ist keine technische Ausnahme für Bots. Die Lösung ist ein Banner, der so gebaut ist, dass er das Crawling nicht behindert.

Ein Cookie-Banner beeinflusst nicht nur, was der Googlebot sieht, sondern auch, wie schnell und stabil Deine Seite für echte Nutzer*innen lädt. Genau das misst Google mit den Core Web Vitals: drei Metriken, die die Ladegeschwindigkeit, visuelle Stabilität und Interaktivität bewerten. Sie fließen als Rankingfaktor ein. Ein schlecht eingebundenes CMP-Skript kann alle drei gleichzeitig verschlechtern.

Schlecht implementierte Cookie-Banner können die Core Web Vitals negativ beeinflussen – insbesondere LCP, CLS und INP.

LCP: Wenn der Banner die Ladezeit frisst

Der Largest Contentful Paint (LCP) misst die Zeit, die benötigt wird, um das größte sichtbare Element einer Seite vollständig zu rendern – typischerweise ein Hero-Bild oder ein großer Textblock. Der Zielwert liegt bei unter 2,5 Sekunden.

CMP-Skripte werden in der Regel früh im

der Seite eingebunden, weil sie vor jedem anderen Tracking-Skript aktiv sein müssen. Das Problem: Wird das Skript synchron geladen, blockiert es den Browser. Erst wenn das CMP-Skript vollständig geladen und ausgeführt ist, rendert der Browser den Rest der Seite. Dadurch verschiebt sich der FCP – der First Contentful Paint, also der Moment, in dem der*die Nutzer*in überhaupt irgendein Element sieht – nach hinten. Und mit ihm der LCP.

Hinzu kommt: Je mehr Dienste eine CMP verwalten muss, desto schwerer wird das Skript. Eine CMP, die für einen kleinen B2B-Blog konfiguriert ist, verhält sich völlig anders als eine Enterprise-Lösung mit 80 eingetragenen Drittanbietern. Das Gewicht des Skripts skaliert direkt mit der Komplexität der Consent-Konfiguration. Wer ein überdimensioniertes Tool für eine kleine Website einsetzt, bezahlt das mit unnötiger Ladezeit bei jedem einzelnen Seitenaufruf.

Die Lösung liegt im asynchronen Laden des CMP-Skripts – wie das konkret aussieht, zeigen wir Dir im Praxisteil.

CLS: Der Banner, der plötzlich auftaucht

Der Cumulative Layout Shift (CLS) misst, wie stabil das Layout Deiner Seite ist. Jedes Mal, wenn ein Element nach dem initialen Laden seine Position verändert und dabei andere Inhalte verschiebt, steigt der CLS-Wert. Ein Wert unter 0,1 gilt als gut. Wie Du das erreichst, erklärt Dir mein Kollege Björn in seinem Blogbeitrag „Cumulative Layout Shift (CLS) optimieren: So geht’s“.

Cookie-Banner sind klassische CLS-Verursacher, aber nicht immer auf die offensichtliche Art. Der häufigste Fall: Der Banner erscheint nicht sofort beim Laden der Seite, sondern mit einer Verzögerung von einer oder mehreren Sekunden. Der User sieht bereits den Seiteninhalt, beginnt vielleicht schon zu lesen oder zu scrollen, und dann schiebt sich der Banner ins Bild und verdrängt die Inhalte. Ein besonders unangenehmes Szenario, das wir regelmäßig in der Praxis sehen, ist: Die erste Seite lädt ohne Banner. Der User klickt auf einen internen Link und erst auf der zweiten Seite erscheint plötzlich der Banner vor der Nase. Frustrierend für den User und schlecht für den CLS.

Der technische Grund ist meist einer von dreien:

1. Das CMP-Skript lädt asynchron und greift ins Layout ein, sobald es fertig geladen ist.
2. Der Banner ist nicht als position:fixed-Overlay, sondern fest im Seitenfluss verankert und schiebt beim Erscheinen den Content nach unten.
3. Animierte Banner, die „hereinfliegen“, erzeugen ebenfalls messbare Shifts – abhängig davon, wie die Animation technisch umgesetzt ist.

INP: Wenn schwere Skripte die Interaktivität blockieren

Der Interaction to Next Paint (INP) ist seit März 2024 das dritte Core Web Vital und misst, wie schnell eine Seite auf Nutzereingaben reagiert – also nicht nur beim ersten Klick, sondern über die gesamte Sitzung hinweg. Der Zielwert liegt bei unter 200 Millisekunden.

Schwere Consent-Management-Platfrom-Skripte (CMP-Skripte) blockieren den Main Thread des Browsers.

Beispiel zur Konfiguration der einzelnen Consent-Optionen. Diese Daten werden in das CMP-Skript geladen und gespeichert. Sie bestimmen dann, was geladen werden darf.

Solange das Skript lädt, initialisiert und ausführt, kann der Browser nicht auf Nutzereingaben reagieren. Bei schlanken CMPs ist dieser Effekt vernachlässigbar. Bei komplexen Setups mit vielen konfigurierten Diensten, Event-Listenern und Callback-Funktionen (z. B. bei einer YouTube-Video-Einbindung mit einem Play-Button) kann das CMP-Skript den Main Thread spürbar belasten und somit den INP-Wert direkt beeinflussen.

Das betrifft vor allem Seiten mit hohem Interaktionsaufkommen. Dazu zählen beispielsweise Shops, bei denen Nutzer*innen schnell in den Warenkorb klicken, oder Publisher-Seiten mit vielen klickbaren Elementen. Genau dort, wo Interaktivität geschäftskritisch ist, fällt ein träges CMP-Skript am meisten ins Gewicht.

Dieser erste Eindruck entscheidet darüber, ob Nutzer*innen bleiben oder Deine Website wieder verlassen. Und genau hier machen viele Websites Fehler, die sich zwar nicht direkt im Crawling niederschlagen, aber langfristig über Nutzersignale die Sichtbarkeit beeinflussen.

Zum Zusammenhang mit SEO: Google bewertet keine Bannertexte und kennt keine Consent-Raten. Was Google aber bewertet, ist das Verhalten der Nutzer*innen nach dem Klick aus den Suchergebnissen. Ein Banner, der Nutzer*innen frustriert, verwirrt oder blockiert, sorgt dafür, dass sie die Seite verlassen, bevor sie überhaupt den Content gesehen haben.

Das Don’t-Make-Me-Think-Prinzip

Der User will keine Entscheidung treffen. Er will zu Deinem Content. Jede Sekunde, die er damit verbringt, Deinen Banner zu verstehen, ist eine Sekunde, in der er über den „Zurück“-Button nachdenkt.

Das klassische Fehlerbild: Ein Banner mit drei Spalten Cookie-Kategorien, sieben Absätzen Erklärungstext, einer Liste von 40 Drittanbietern und Buttons, die alle gleich aussehen. Das Ergebnis ist ein kognitiver Overload: Nutzer*innen sind überfordert, klicken auf einen beliebigen Button oder verlassen die Seite.

Das Gegenteil davon ist ein Banner, der zwei klare Entscheidungsmöglichkeiten anbietet: „Nur technisch notwendige Cookies“ oder „Alle akzeptieren“. Wer seine Einstellungen granular konfigurieren möchte, bekommt einen dritten Button – „Benutzerdefiniert“ oder „Einstellungen“ –, der auf eine separate Seite führt. So bleibt der Banner schlank, der Content-Zugang bleibt für die meisten Nutzer*innen ohne Umwege und der Platzbedarf des Banners bleibt minimal.

Beispiel für einen übersichtlichen Banner bei Zalando (Desktop-Ansicht) mit den drei klaren Buttons und nur dem nötigsten an Text.

Der farbige Button und das Eigentor

Ein Anti-Pattern (Worst Practice), das wir in der Praxis regelmäßig sehen: Der auffälligste, farblich hervorgehobene Button auf dem Banner ist – aus welchen Gründen auch immer – der „Alle ablehnen“-Button. Für den User ist das kein Problem. Für den*die Seitenbetreiber*in schon: Die visuelle Hierarchie des Banners lenkt aktiv in Richtung Ablehnung und das wollen wir grundsätzlich vermeiden.

Solange beide Optionen gleichwertig zugänglich sind, ist das kein rechtliches Problem. Laut TTDSG (Telekommunikations-Telemediendatenschutzgesetz) muss die Ablehnung auf erster Ebene möglich sein, sie darf also nicht versteckt werden. Es ist aber ein selbst verschuldetes Conversion-Problem. konversionsKRAFT hat in mehreren Tests gezeigt, dass allein die gestalterische Ausrichtung des Banners die Zustimmungsrate um bis zu 26 Prozent verändern kann – nach oben wie nach unten.

Mobile: Wenn der Banner die ganze Seite ist

Auf dem Desktop nimmt ein gut gestalteter Banner vielleicht ein Drittel des Screens ein. Auf einem Smartphone mit einer Breite von 375px kann derselbe Banner den gesamten Viewport blockieren, sodass Nutzer*innen nichts außer Datenschutztext sehen. Das ist nicht nur frustrierend, sondern berührt auch Googles Richtlinien zu Intrusive Interstitials: Ein Banner, der auf Mobilgeräten den gesamten Content verdeckt und sich nicht sinnvoll wegklicken lässt, riskiert eine Abstufung in den mobilen Suchergebnissen.

Die Lösung ist kein kleinerer Text, sondern ein konsequent reduzierter Banner: kurze, klare Headline, zwei bis drei Buttons, keine Romane. Alles, was über diese Grundentscheidung hinausgeht, gehört hinter einen weiteren Klick.

Dark Patterns: Kurzsichtig und rechtswidrig

Der Vollständigkeit halber: Alle Designtricks, die Nutzer*innen zur Zustimmung drängen sollen – wie vorausgewählte Checkboxen, versteckte Ablehnungsoptionen oder Buttons, die sich farblich kaum vom Hintergrund abheben – sind nach TTDSG rechtswidrig.

Abgesehen vom rechtlichen Risiko ist diese Vorgehensweise auch strategisch kurzsichtig: Nutzer*innen, die sich manipuliert fühlen, verlassen die Seite. Was nützen Trackingdaten von Nutzer*innen, die sofort abspringen?

Laut der repräsentativen Umfrage von konversionsKRAFT, über deren Ergebnisse wir bereits bei der Buttonfarbe berichtet haben, lesen 36 Prozent der Nutzer*innen Cookie-Hinweise grundsätzlich nicht. Sie wollen den Banner nur möglichst schnell loswerden. Genau deshalb ist Klarheit keine nette Option, sondern die einzig sinnvolle Designentscheidung. Wer den Banner schnell und ohne Frust wegbekommt, bleibt auf der Seite.

Praxisteil: So baust Du den Cookie-Banner richtig

Theorie hilft beim Verstehen. Der folgende Praxisteil hilft Dir bei der Umsetzung und beim Briefing Deines Entwicklers oder Deiner Entwicklerin.

Alles andere – jede technische Entscheidung, jede Implementierungsanforderung – leitet sich aus diesem einen Satz ab.

Anforderungen an das Entwicklerteam

Der folgende Abschnitt ist als direkte Übergabe an Dein Entwicklerteam gedacht. Du kannst ihn als Grundlage für ein Ticket oder eine User Story verwenden.

Titel: Cookie-Consent-Banner SEO- und CWV-konform implementieren

Als SEO-Verantwortliche*r möchte ich, dass der Cookie-Banner so implementiert wird, dass er das Crawling durch Suchmaschinen-Bots nicht behindert und die Core Web Vitals nicht negativ beeinflusst, damit unsere Inhalte vollständig indexiert werden und keine Ranking-Verluste entstehen.

Akzeptanzkriterien:

1. Der vollständige Hauptcontent – Text, Bilder, strukturierte Daten, interne Links – ist im initial ausgelieferten HTML enthalten, unabhängig vom Consent-Status des Nutzers.
2. Der Banner wird als Overlay mit position:fixed Es findet kein display:none, visibility:hidden oder aria-hidden=“true“ auf dem Hauptcontent statt.
3. Der Body bleibt scrollbar – kein overflow:hidden auf oder vor der Zustimmung.
4. Eigene Inhalte – Bilder, Fonts, Funktions-Java Script – laden ohne Consent. Nur Drittanbieter-Tracking wie Analytics, Marketing-Pixel und Embeds wird bis zum Consent blockiert.
5. Das CMP-Skript wird asynchron geladen, um FCP und LCP nicht zu blockieren.
6. Der Banner verwendet position:fixed mit definierter Größe, um CLS zu vermeiden.
7. Es findet kein User-Agent-Sniffing oder Cloaking statt – der Googlebot bekommt identisches HTML wie ein normaler Nutzer.
8. Google Consent Mode v2 ist mit default:denied für alle Consent-Typen konfiguriert.
9. Bei deaktiviertem Java Script ist der Hauptcontent weiterhin sichtbar und lesbar.

Definition of Done:

• Test mit deaktiviertem Java Script: Content vollständig sichtbar.
• URL-Prüfung in der Google Search Console → Live-Test: gerenderter Screenshot und HTML zeigen vollständigen Content.
• Lighthouse-Audit: CLS unter 0,1, kein Hinweis auf Intrusive Interstitials.
• Crawl mit Screaming Frog (JS-Rendering aktiv, User-Agent: Googlebot Smartphone): Body-Content vollständig extrahierbar.

Out of Scope: Rechtliche Prüfung der Bannertexte und Cookie-Kategorisierung liegen bei Datenschutz und Legal.

Die häufigsten CMPs und ihre Fallstricke

Kein CMP ist per se schlecht, aber jedes hat seine Stolperfallen. Im Folgenden stellen wir die drei vor, mit denen wir im Agenturalltag am häufigsten konfrontiert sind.

Cookiebot

Cookiebot ist im DACH-Raum weit verbreitet und lässt sich schnell einbinden. Seine Kernfunktion ist ein automatischer Cookie-Scan, der alle Skripte auf der Seite kategorisiert und entsprechend blockiert. Genau hier liegt das Risiko: Der Scanner arbeitet heuristisch und kann eigenes Funktions-Java Script fälschlicherweise als Marketing-Cookie klassifizieren, sodass es bis zum Consent blockiert wird. Wichtig außerdem: Cookiebot steuert die Skript-Blockierung über type=“text/plain“ statt type=“text/javascript“. Jedes Skript, das dieses Attribut trägt, wird vom Browser nicht ausgeführt, bis Cookiebot es nach dem Consent freigibt. Wer hier nicht aufpasst, blockiert versehentlich eigene Inhalte.

Usercentrics

Usercentrics ist eine Enterprise-Lösung mit einem umfangreichen Funktionsumfang – und entsprechend komplex in der Konfiguration. Die Skript-Steuerung läuft über einen Data-Processing-Services-Katalog, in dem jedes Drittanbieter-Tool einzeln eingetragen und freigeschaltet wird.

• SEO-Risiko Nummer eins: Wenn Entwickler*innen versehentlich eigenen Content an einen Eintrag im Katalog koppeln, wird dieser consent-abhängig.
• Risiko Nummer zwei: Usercentrics bietet einen sogenannten Consent-Wall-Modus, der die gesamte Seite blockiert, bis eine Entscheidung getroffen wurde. Diesen Modus solltest Du niemals aktivieren – er ist das Gate-Modell in seiner reinsten Form.
• Risiko Nummer drei: Das Usercentrics-Skript ist vergleichsweise schwer. Wird es synchron statt asynchron eingebunden, hat das direkten Einfluss auf FCP und LCP.

Borlabs Cookie

Borlabs ist die beliebteste CMP im WordPress-Ökosystem, günstig und unkompliziert. Borlabs arbeitet mit Shortcodes und Content-Blockern, die zum Beispiel eingebettete YouTube-Videos durch eine Platzhalter-Box ersetzen. Das ist für SEO grundsätzlich in Ordnung, weil die umgebende Seite vollständig geladen wird. Die Stolperfalle: Manche Themes und Page-Builder-Setups verpacken ganze Sektionen oder Seitenblöcke in Borlabs-Shortcodes. Diese Inhalte existieren für den Googlebot dann nicht. Außerdem laden ältere Borlabs-Versionen das Banner-CSS render-blocking, weshalb Du immer auf die aktuellste Version achten solltest. Im Lighthouse-Report solltest Du prüfen, ob Borlabs als render-blockierende Ressource auftaucht.

Diagnose: So findest Du bestehende Probleme

Du weißt jetzt, was schiefgehen kann. Der folgende Abschnitt zeigt Dir, wie Du herausfindest, ob es bei Dir schiefläuft – ohne teure Tools und ohne Entwicklerzugang, dafür mit kostenlos verfügbaren Mitteln.

Test 1: Java Script deaktivieren

Das ist der schnellste und aufschlussreichste Test überhaupt. Wenn Dein Content ohne Java Script nicht sichtbar ist, existiert er für den Googlebot bestenfalls eingeschränkt.

Installiere die kostenlose Web Developer Extension – verfügbar für Chrome und Firefox. Nach der Installation findest Du unter „Disable → Disable Java Script“ eine Ein-Klick-Option, um Java Script im aktuellen Tab zu deaktivieren. Lade die Seite anschließend neu.

Screenshot der Web Developer Extension: Hier kannst Du Java Script deaktivieren und hast sogar die Möglichkeit, die Cookies zu blocken. Ideal zum Testen!

Was Du siehst, ist in etwa das, was der Googlebot beim ersten Crawl sieht – noch vor dem Rendering durch den Web Rendering Service.

Prüfe konkret:

• Ist Dein Hauptcontent sichtbar?
• Sind Texte, Überschriften und Bilder vorhanden?
• Erscheint der Cookie-Banner als Overlay über vorhandenem Content – oder ist die Seite dahinter leer?

Ist die Seite ohne Java Script leer oder zeigt sie nur den Banner: roter Alarm.

Wenn Du lieber keine Extension installieren möchtest, kannst Du JavaSkript in den meisten Browsern in den Browsereinstellungen deaktivieren. Das ist nicht so schön und intuitiv, aber möglich.

Test 2: Den Quelltext lesen

Ein ergänzender Test: Öffne in Deinem Browser view-source: gefolgt von der URL Deiner Seite – also zum Beispiel view-source: Was Du dort siehst, ist das rohe HTML, das der Server ausliefert, bevor Java Script irgendetwas verändert hat.

Suche im Quelltext nach Deinen wichtigsten Inhalten: dem H1-Tag, dem ersten Absatz und dem Alt-Text Deines Hero-Bildes. Findest Du sie dort, ist das ein gutes Zeichen. Findest Du nur leere

-Container und Java Script-Aufrufe, ist das ein Hinweis darauf, dass der Content vollständig clientseitig gerendert wird.

Test 3: URL-Prüfung in der Google Search Console

Das ist der wichtigste Test, weil er Dir zeigt, was der Googlebot tatsächlich sieht, nicht was Du vermutest. Öffne die Google Search Console, gib die URL Deiner Seite in die URL-Prüfung ein und klicke auf „Live-URL testen“.

Wir können Dir helfen!

Suchst Du eine kompetente, flexbile und zuverlässige Online-Marketing-Agentur? Wir freuen uns auf Deine unverbindliche Anfrage.

Kontaktiere uns

In der GSC können alle URLs Deiner Domain, die crawl- und indexierbar sind, per Live-Abfrage getestet werden. Der Klick auf „Gecrawlte Seite anzeigen“ gibt den erfassten HTML-Text aus.

Die Search Console rendert die Seite so wie der User Agent „Googlebot Smartphone“ und liefert Dir zwei entscheidende Ansichten: den gerenderten Screenshot und das gerenderte HTML. Im Screenshot siehst Du, ob der Banner das Bild dominiert oder ob der Content dahinter erkennbar ist. Im HTML kannst Du gezielt nach Deinen wichtigsten Inhalten suchen.

Gerenderter Screenshot vs. HTTP-Antwort

Die GSC-URL-Prüfung zeigt Dir zwei Tabs: „HTML“ und „Screenshot“. Das HTML entspricht dem Ergebnis nach Java Script-Rendering durch den WRS – also dem, was der Googlebot nach dem zweistufigen Crawl-Prozess sieht. Der Screenshot zeigt die visuelle Darstellung davon.

Zeigt der Screenshot nur den Cookie-Banner, ist das allein kein Warnsignal. Entscheidend ist der HTML-Tab: Ist Dein Content dort vorhanden, indexiert der Googlebot ihn – unabhängig davon, was der Screenshot zeigt. Kritisch wird es nur, wenn der Content im HTML fehlt.

Beide Tabs gemeinsam geben Dir ein vollständiges Bild: Steht Dein Content im HTML, aber nicht im Screenshot, liegt ein visuelles Overlay-Problem vor. Fehlt der Content in beiden, ist es das Gate-Problem aus Kapitel drei.

Test 4: Core Web Vitals prüfen

Für die Performance-Seite – LCP, CLS, INP – nutze Google PageSpeed Insights. Gib Deine URL ein und schau Dir die Feldwerte an, sofern genug reale Nutzerdaten vorliegen. Besonders relevant sind:

• LCP über 2,5 Sekunden: Prüfe im Lighthouse-Report unter „Render-blocking resources“, ob Dein CMP-Skript dort auftaucht.
• CLS über 0,1: Lade die Seite mehrfach neu und beobachte, ob der Banner nach dem initialen Laden ins Layout einspringt oder Inhalte verschiebt.
• INP über 200 Millisekunden: Ein Hinweis auf einen überlasteten Main Thread. Suche im Lighthouse-Report unter „Avoid long main-thread tasks“ nach CMP-bezogenen Einträgen.

Test 5: Screaming Frog

Wer Zugang zum Screaming Frog hat, kann den Crawler mit aktiviertem Java Script-Rendering und dem User Agent „Googlebot Smartphone“ über die Seite laufen lassen und die Body-Text-Extraktion prüfen. Die kostenlose Version ist auf 500 URLs limitiert – für eine erste Einschätzung bei kleineren Websites ist das ausreichend.

Fazit & Cookie-Banner-Checkliste

Ein Cookie-Banner ist kein Beiwerk. Er ist ein technisches Element, das direkten Einfluss auf Crawling, Performance und User Experience hat. Die gute Nachricht: Die meisten Probleme kannst Du vermeiden, wenn der Banner von Anfang an als Overlay und nicht als Gate gedacht wird. Wer das Grundprinzip verstanden hat, trifft bei der Umsetzung automatisch die richtigen Entscheidungen.

Checkliste: Cookie-Banner & SEO

Technische Grundlage

• Hauptcontent ist im initialen HTML vorhanden – unabhängig vom Consent-Status
• Banner ist als position:fixed Overlay umgesetzt, kein display:none auf dem Content
• Body bleibt scrollbar, kein overflow:hidden vor der Zustimmung
• CMP-Skript wird asynchron geladen
• Google Consent Mode V2 ist mit default:denied konfiguriert

Drittanbieter & Tracking

• Eigene Inhalte, Bilder und Fonts laden ohne Consent
• Nur Drittanbieter-Tracking wird bis zum Consent blockiert
• Kein User-Agent-Sniffing oder Cloaking

Performance

• LCP unter 2,5 Sekunden (prüfen mit PageSpeed Insights)
• CLS unter 0,1 – Banner verursacht keinen Layout Shift
• CMP-Skript taucht nicht als render-blocking resource in Lighthouse auf

Diagnose

• Test mit deaktiviertem Java Script: Content vollständig sichtbar
• GSC URL-Prüfung: Content im gerenderten HTML vorhanden
• PageSpeed Insights: Keine CWV-Auffälligkeiten durch das CMP-Skript

 

Bildnachweis: Titelbild: generiert mit ChatGPT/seokratie.de; Bild 2 + 3: generiert mit ChatGPT/seokratie.de; Bild 4: Screenshot CMP-Abfrage; Bild 5: Screenshot der Startseite von zalando.de; Bild 6: Screenshot Google Search Console

Über Nicole Mank

Nicole Mank ist Senior SEO Consultant bei Seokratie und seit 2012 in der SEO-Branche tätig. Nach ihrem Einstieg aus dem kaufmännischen Bereich hat sie sich früh auf komplexe, technisch geprägte SEO-Themen spezialisiert und gehört seit vielen Jahren fest zur deutschsprachigen SEO-Szene.Ihr fachlicher Schwerpunkt liegt auf der Entwicklung und Umsetzung skalierbarer SEO-Strategien für Konzerne und international agierende Unternehmen. Dabei arbeitet sie regelmäßig an großen, gewachsenen Websites mit hoher technischer Komplexität, anspruchsvollen Organisationsstrukturen und internationalen Marktanforderungen. Nicole analysiert Rankingverluste, identifiziert strukturelle und technische Schwachstellen und entwickelt nachhaltige Lösungsansätze – häufig mit dem Anspruch, bestehende Konzepte kritisch zu hinterfragen und grundlegend zu verbessern. Ein besonderer Fokus liegt auf technischer SEO, Website-Architekturen, Performance-Optimierung sowie Usability-Aspekten im Zusammenspiel von SEO, Entwicklung und Business-Zielen. Zusätzlich erweitert sie ihren fachlichen Schwerpunkt zunehmend um Themen rund um Künstliche Intelligenz, AI-gestützte Suchsysteme und Generative Engine Optimization (GEO). Dabei beschäftigt sie sich insbesondere mit den Auswirkungen von KI auf Suchverhalten, Content-Bewertung und technische Anforderungen an moderne Websites. Hier findest Du alle Beiträge von Nicole Mank.