Pop-ups und SEO: welche Interstitials Google abstraft

Wer nach "Pop-ups SEO" sucht, will meistens eine einfache Antwort: Bestraft Google Overlays auf einer Seite, oder nicht? Die ehrliche Antwort ist differenziert. Google unterscheidet nicht nach dem Wort "Pop-up", sondern bewertet, ob ein Interstitial die eigentlichen Inhalte einer Seite auf Mobilgeräten unangemessen verdeckt. Seit Januar 2017 ist das ein eigenständiges Rankingsignal für die mobile Suche, und weil heute praktisch jede Website über den Mobile-First-Index bewertet wird, wirkt es sich faktisch auch auf das Gesamtranking aus.

Nicht jedes Overlay fällt unter diese Regel. Newsletter-Pop-ups, Exit-Intent-Banner, App-Install-Aufforderungen und gesetzlich vorgeschriebene Altersabfragen werden unterschiedlich behandelt, je nachdem, wann sie erscheinen, wie viel Fläche sie einnehmen und aus welchem Grund sie existieren. Dieser Artikel geht diese Fälle einzeln durch und zeigt anschließend, wie sich der Effekt eines Pop-ups auf die Sichtbarkeit tatsächlich überprüfen lässt, jenseits von Bauchgefühl.

Was Google unter einem aufdringlichen Interstitial versteht

Googles Ankündigung von 2017 richtete sich gezielt gegen Seiten, bei denen Nutzer nach dem Klick auf ein mobiles Suchergebnis nicht sofort an den gesuchten Inhalt kommen, weil ein Overlay dazwischen liegt. Das Signal betrifft also vor allem den Moment des Übergangs von der Suche auf die Seite, nicht jede Interaktion, die später während des Seitenbesuchs passiert.

Google nennt drei konkrete Muster, die als problematisch gelten: ein Pop-up, das den Hauptinhalt sofort nach der Ankunft oder während des Scrollens verdeckt, ein eigenständiges Interstitial, das erst weggeklickt werden muss, bevor der Inhalt sichtbar wird, und ein Layout, bei dem der sichtbare Bereich oberhalb des Falzes wie eine vollwertige Zwischenseite wirkt, während der eigentliche Inhalt lediglich weiter unten eingebettet ist.

Wichtig ist die Einordnung: Das ist ein algorithmisches Rankingsignal, keine manuelle Maßnahme. Es gibt keine Benachrichtigung in der Search Console, wenn eine Seite betroffen ist, und keinen Reconsideration Request, den man stellen könnte. Die einzige Reaktion ist, das Overlay-Verhalten selbst zu ändern.

Weil es sich um ein algorithmisches Signal handelt, das erst bei einem erneuten Crawling der Seite neu bewertet wird, zeigt sich der Effekt einer Änderung nicht sofort. Ein Team, das ein Pop-up entfernt und schon am nächsten Tag ins Ranking-Reporting schaut, sieht in der Regel noch keine Veränderung und zieht daraus fälschlich den Schluss, das Overlay habe ohnehin nichts bewirkt.

• Pop-up verdeckt den Inhalt direkt nach der Ankunft von der Suche
• Eigenständiges Interstitial muss geschlossen werden, bevor der Inhalt zugänglich ist
• Above-the-fold-Bereich sieht wie eine Zwischenseite aus, Inhalt ist nur weiter unten eingebettet

Newsletter-Pop-ups: Zeitpunkt entscheidet

Ein Newsletter-Pop-up, das exakt in dem Moment aufklappt, in dem ein Besucher von einem Suchergebnis auf der Seite ankommt, trifft ziemlich genau das Muster, das Google beschreibt. Eine offizielle Mindestverzögerung, die als sicher gilt, nennt Google nicht, weil die Bewertung verhaltensbasiert und nicht zeitbasiert ist. In der Praxis reduziert es das Risiko trotzdem deutlich, das Pop-up nicht beim ersten Pageview zu zeigen, sondern erst nach einer gewissen Scrolltiefe, einer Verweildauer von einigen Sekunden oder nur bei wiederkehrenden Besuchern, die per Cookie oder localStorage erkannt werden.

Neben dem Zeitpunkt zählt die Form. Eine schmale Leiste am unteren Bildschirmrand, die eine E-Mail-Adresse abfragt und dabei den restlichen Inhalt sichtbar und scrollbar lässt, ist etwas anderes als ein zentriertes Modal mit dunklem Hintergrund, das den gesamten Viewport abdeckt und das Scrollen der Seite darunter blockiert. Google beschreibt explizit Overlays, die den Inhalt verdecken, nicht jede Form von Werbefläche auf einer Seite.

Ein häufiger Fehler ist außerdem ein Schließen-Button, der zu klein oder schwer zu treffen ist. Ein Overlay, das sich technisch schließen lässt, aber auf einem Touchscreen kaum zu treffen ist, verhält sich für die meisten Nutzer wie ein Overlay, das sich gar nicht schließen lässt.

• Hohes Risiko: sofortiges Erscheinen beim ersten Pageview von der Suche
• Hohes Risiko: dunkler Vollbild-Hintergrund, der die Seite darunter blockiert
• Geringeres Risiko: schmale Leiste, die den Rest der Seite scrollbar lässt
• Geringeres Risiko: Anzeige erst nach Scrolltiefe oder nur für wiederkehrende Besucher

Exit-Intent-Pop-ups: ein Sonderfall

Ein Exit-Intent-Pop-up wird technisch meist über eine Mausbewegung ausgelöst, die auf ein Verlassen des Browserfensters hindeutet, typischerweise eine schnelle Bewegung Richtung oberer Bildschirmrand. Weil dieser Auslöser erst greift, nachdem der Nutzer den Inhalt bereits gesehen hat, und nicht im Moment der Ankunft von der Suche, deckt er sich meist nicht mit dem Muster, das Google konkret beanstandet. Der Inhalt war zu diesem Zeitpunkt bereits zugänglich.

Auf Mobilgeräten gibt es allerdings kein echtes Mouseleave-Ereignis. Viele Skripte behelfen sich dort mit einem Abfangen des Zurück-Buttons oder mit einer Erkennung schnellen Nach-oben-Scrollens als Ersatzsignal. Dieses Ersatzsignal feuert wieder während der aktiven Nutzung der Seite, also näher am riskanten Muster als die Desktop-Variante. Wer Exit-Intent einsetzt, sollte es deshalb eher auf Desktop beschränken und auf Mobilgeräten, falls überhaupt, eine deutlich zurückhaltendere Variante zeigen, etwa eine kleine Einblendung statt eines Vollbild-Overlays.

Ein häufiger Fehler in der Umsetzung ist, den mobilen Ersatz-Trigger zusätzlich mit dem Sichtbarkeitswechsel des Tabs zu koppeln, also mit dem visibilitychange-Ereignis. Wechselt ein Nutzer während des Lesens kurz zu einer eingehenden Nachricht oder einem Anruf, feuert das Skript in diesem Fall genauso wie bei einem echten Verlassen der Seite, obwohl der Nutzer den Inhalt eigentlich weiterlesen wollte. Das Overlay erscheint dann in einer Situation, die dem Ankunftsmoment von der Suche wieder deutlich ähnlicher ist als dem ursprünglich gedachten Absprungmoment.

Eine zusätzliche Absicherung ist eine Mindestverweildauer, bevor der Exit-Intent-Trigger überhaupt aktiv wird, etwa erst nach einigen Sekunden auf der Seite oder erst nach einer bestimmten Scrolltiefe. Ohne diese Schwelle kann ein Nutzer, der aus Versehen sofort wieder die Zurück-Taste drückt, ein Overlay auslösen, das inhaltlich exakt dem sofortigen Pop-up beim Seitenaufruf entspricht, nur über einen anderen technischen Weg ausgelöst.

App-Install-Banner: die ausdrückliche Ausnahme

Google nennt Banner, die einen angemessenen Anteil der Bildschirmfläche einnehmen und sich leicht schließen lassen, ausdrücklich als erlaubtes Muster, mit dem App-Install-Banner als Referenzbeispiel. Gemeint sind schmale Leisten wie der native Smart App Banner in Safari über das apple-itunes-app-Meta-Tag oder die entsprechende Android-Variante über die eingebaute Installationsaufforderung des Browsers. Beide rendern als schmaler Streifen am oberen oder unteren Bildschirmrand, nicht als Vollbild-Overlay.

Der typische Fehler ist, diesen nativen, schlanken Banner durch eine selbst gebaute Vollbild-Sperre zu ersetzen, die den Artikel komplett verdeckt, bis der Nutzer auf "Trotzdem im Browser weiterlesen" tippt. Funktional ist das exakt das Muster, das Google bei Newsletter-Pop-ups beanstandet, nur mit einem anderen Ziel. Die Ausnahme gilt für die Form, die Google beschreibt, also die schmale, leicht wegwischbare Leiste, nicht für jedes Overlay, dessen Zweck ein App-Download ist.

Ein praktisches Beispiel: Eine Nachrichtenseite, die von einer mobilen Suche aus aufgerufen wird, zeigt am oberen Rand einen schmalen, nativen Banner mit App-Icon und einem Install-Button, während der Artikel darunter vollständig lesbar und scrollbar bleibt. Das entspricht der von Google beschriebenen Ausnahme. Eine andere Seite, die stattdessen beim Laden ein Vollbild-Fenster mit der Wahl zwischen "App öffnen" und einem winzigen "Weiter im Browser"-Link einblendet, erzeugt dagegen exakt das Muster, das die Regel eigentlich verhindern soll, nur mit einem App-Ziel statt einem Newsletter-Ziel.

Altersabfragen und andere gesetzlich vorgeschriebene Interstitials

Interstitials, die aus rechtlicher Verpflichtung angezeigt werden, etwa zur Alters- oder Cookie-Bestätigung, sind ausdrücklich von der Regel ausgenommen. Das betrifft Alkoholmarken, Glücksspielanbieter, Tabakprodukte oder Erwachseneninhalte in Jurisdiktionen, die eine Bestätigung vor dem Betreten der Seite vorschreiben. Weil die Abfrage gesetzlich erzwungen ist und keine Marketingentscheidung, ist die Ausnahme nicht an Größe oder Zeitpunkt gekoppelt wie beim Newsletter-Beispiel. Eine Vollbild-Altersabfrage direkt beim ersten Aufruf ist zulässig, gerade weil sie nicht optional ist.

Sinnvoll ist trotzdem, die Abfrage so reibungsarm wie möglich zu halten und sie nicht mit unverbundenen Marketinginhalten zu vermischen, etwa einem Newsletter-Opt-in-Kästchen innerhalb derselben Pflichtabfrage. Dieser zusätzliche Teil ist rechtlich nicht vorgeschrieben und könnte das Risiko für genau diesen Bestandteil wieder einführen. Cookie-Einwilligungsbanner fallen unter dieselbe rechtliche Ausnahme, folgen aber eigenen Platzierungs- und Gestaltungsregeln, die in einem eigenen Artikel zu Cookie-Bannern behandelt werden und hier nicht wiederholt werden.

Ein Sonderfall ist die geografische Reichweite der gesetzlichen Pflicht. Eine Altersabfrage, die in einem Land vorgeschrieben ist, ist es in einem anderen oft nicht. Wird die Abfrage weltweit unabhängig vom Standort ausgespielt, gilt die Ausnahme zwar weiterhin technisch, weil die Einblendung insgesamt rechtlich begründet ist, sinnvoller ist aber, sie über eine Geo-Erkennung nur dort zu zeigen, wo sie tatsächlich verpflichtend ist. Das vermeidet unnötige Reibung für Besucher aus Märkten ohne diese Pflicht und macht die Ausnahme zugleich präziser begründbar, falls sie einmal hinterfragt wird.

Wie viel Fläche darf ein Overlay einnehmen?

Eine offizielle Prozentzahl, ab der ein Overlay als zu groß gilt, veröffentlicht Google nicht. Als Orientierung hilft das Prinzip der Verhältnismäßigkeit: Eine Leiste, die einen festen Rand des Bildschirms belegt und den Rest der Seite bedienbar lässt, ist etwas grundlegend anderes als ein zentriertes Modal mit halbtransparentem Hintergrund, der den restlichen Viewport abdunkelt und das Scrollen der Seite darunter unterbindet. In der Praxis fährt man sicherer mit einem festen Streifen am oberen oder unteren Rand als mit einem Modal, das den verbleibenden Bildschirm dimmt.

Unabhängig vom Interstitial-Signal gibt es einen zweiten Mechanismus, der dieselbe UI-Komponente treffen kann: Ein Pop-up, das erst nach dem ersten Rendern der Seite eingefügt wird, ohne dass vorher Platz dafür reserviert war, verschiebt den restlichen Inhalt und trägt zur Cumulative Layout Shift bei, einem der drei Core Web Vitals. Ein schlecht implementiertes Overlay kann damit gleich doppelt kosten: einmal über das Interstitial-Signal, einmal über die Layoutstabilität.

• Platz für das Overlay von Anfang an reservieren, statt es nachträglich einzufügen
• Schließen-Button groß genug für einen Fingertipp gestalten, nicht nur für einen Mauszeiger
• Scrollen der darunterliegenden Seite nicht blockieren
• Häufigkeit pro Sitzung oder pro Besucher per Cookie oder localStorage begrenzen

Den Effekt messen: was die Search Console zeigt und was nicht

Der Ende 2023 eingestellte Bericht zur Mobile Usability in der Search Console hatte nie eine eigene Kategorie für aufdringliche Interstitials. Er meldete Dinge wie einen fehlenden Viewport oder zu eng stehende Klickflächen, aber kein Overlay-Verhalten. Keine Warnung in diesem Bericht zu sehen bedeutete also nicht, dass eine Seite in Bezug auf Interstitials unauffällig ist.

Ein praktischer Test läuft über die URL-Prüfung: Der Live-Test erzeugt einen gerenderten Screenshot der Seite, wie Google sie sieht. Erscheint ein Pop-up dort genauso wie bei einem echten Besucher, der von der Suche kommt, ist das ein brauchbarer Anhaltspunkt dafür, was Googles Rendering tatsächlich erfasst. Auslöser, die auf einer Mausbewegung basieren, etwa Exit-Intent, tauchen in diesem Screenshot naturgemäß nicht auf, weil der Test keine Mausbewegung simuliert; sichtbar wird dort nur, was direkt beim Laden erscheint.

Weil es keinen eigenen Bericht für Interstitials gibt, bleibt der zuverlässigste Weg indirekt: den Leistungsbericht nach Gerät filtern, Mobil gegen Desktop stellen und Klicks, Impressionen und durchschnittliche Position für die betroffenen URLs über das Datum hinweg vergleichen, an dem ein neues Pop-up live ging. Ein Einbruch, der nur mobil auftritt und sich nicht durch andere gleichzeitige Änderungen erklären lässt, ist das Muster, das eine genauere Prüfung wert ist. Dabei über mehrere Wochen vergleichen, nicht über einen einzelnen Tag, weil sich ein Rankingsignal erst mit einiger Verzögerung in der Auswertung niederschlägt.

Belastbarer als ein reiner Vorher-Nachher-Vergleich ist ein Test, der die beiden Zustände gleichzeitig laufen lässt. Dazu wird ein Teil der Besucher, etwa über einen Cookie-basierten Bucket, dauerhaft ohne das neue Pop-up ausgespielt, während der Rest es sieht. Weicht die Entwicklung von organischem Mobil-Traffic zwischen den beiden Gruppen über mehrere Wochen erkennbar ab, lässt sich der Effekt dem Pop-up zuordnen, statt ihn mit einer allgemeinen saisonalen Schwankung oder einem unabhängigen Google-Update zu verwechseln, das zufällig im gleichen Zeitraum lag.

Checkliste: Pop-ups einsetzen, ohne abgestraft zu werden

Die einzelnen Fälle lassen sich auf eine Handvoll Entscheidungen herunterbrechen, die vor der Implementierung eines Overlays beantwortet werden sollten.

• Erscheint das Overlay im Moment der Ankunft von der Suche, oder erst nach Interaktion mit dem Inhalt?
• Bleibt der restliche Inhalt sichtbar und scrollbar, oder wird er vollständig verdeckt?
• Ist der Schließen-Button auch auf einem Touchscreen gut zu treffen?
• Handelt es sich um eine gesetzliche Pflicht, die die Ausnahme greifen lässt, oder um eine reine Marketingentscheidung?
• Ist für das Overlay von Anfang an Platz reserviert, oder verschiebt es nachträglich den Inhalt?
• Wird die Häufigkeit pro Besucher begrenzt, statt bei jedem Aufruf erneut zu erscheinen?
• Wurde der Live-Test der URL-Prüfung nach der Implementierung tatsächlich angeschaut?