Sprachen

Paywalls und SEO

So bleiben hinter Paywalls und Registrierung geschützte Inhalte indexierbar, ohne als Cloaking zu gelten – flexibles Sampling, isAccessibleForFree/cssSelector-Markup, die JavaScript-Paywall-Falle und Metering-Strategie.

Erstveröffentlicht: 3. Juli 2026 · Zuletzt aktualisiert: 3. Aug. 2026 · Fortgeschritten
Sprachen
AIVerfasst vonAI v2

Eine Paywall schadet SEO nicht grundsätzlich – Google hat keine Voreingenommenheit gegenüber geschützten Inhalten, und die größten Paywall-Publisher ranken gut. Was schadet, ist, dass Google nicht genug Inhalt sehen kann, um die Seite zu verstehen. Die unterstützte Lösung ist flexibles Sampling: Lassen Sie Googlebot den vollständigen Artikel crawlen und deklarieren Sie dann den geschützten Teil mit strukturierten Daten (isAccessibleForFree plus cssSelector). Das ist eine explizite, sanktionierte Ausnahme vom Cloaking – Cloaking geht es um Täuschungsabsicht; dies ist ein deklarierter Mechanismus. Verwenden Sie Metering (beginnen Sie mit etwa 6–10 kostenlosen Artikeln pro Monat) oder Lead-in, sperren Sie serverseitig (nicht mit JavaScript, das Inhalte nur im DOM versteckt), geben Sie Login-Seiten einzigartigen Text und verwenden Sie niemals robots.txt, um private URLs zu verbergen.

TL;DR — Paywalls schaden Rankings nicht grundsätzlich; Google, das Ihre Inhalte nicht sehen kann, schon. Das unterstützte Modell ist flexibles Sampling — Metering oder Lead-in — deklariert mit strukturierten Daten (isAccessibleForFree: false plus ein hasPart/cssSelector, das den gesperrten Abschnitt markiert, nur Klassen-Selektoren). Diese Deklaration ist es, die das Ausliefern des vollständigen Artikels an Googlebot nicht zu Cloaking macht: Cloaking erfordert die Absicht zu manipulieren und in die Irre zu führen, und Googles Spam-Richtlinie nimmt Paywalls explizit von dieser Definition aus. Sperren Sie serverseitig (das Update der Dokumentation von 2025 und Muellers Hinweis zu Screenreadern zielen beide auf denselben JS-Versteck-Fehler), geben Sie Login-Seiten eindeutigen Text, verwenden Sie niemals robots.txt für private URLs, und nutzen Sie noarchive, um zu verhindern, dass eine gecachte Kopie den vollständigen Text preisgibt. Registrierungswände verwenden dasselbe Markup wie bezahlte.

Was tatsächlich Ranking-Probleme verursacht (nicht die Sperre)

Die Paywall-Berechtigung hängt von crawlbarem Inhalt und korrektem Markup ab; das Vorhandensein einer Paywall allein ist nicht als Strafe dokumentiert. Evidence for this claim Official or primary documentation supporting the adjacent article claim, with scope limited to the source's published description. Scope: No ranking guarantee or undisclosed system mechanics are inferred beyond the cited source. Confidence: high · Verified: Google: Paywalled content structured data Sampling-Entscheidungen bleiben Verlagsentscheidungen mit Nutzer- und Geschäftsabwägungen. Evidence for this claim Official or primary documentation supporting the adjacent article claim, with scope limited to the source's published description. Scope: No ranking guarantee or undisclosed system mechanics are inferred beyond the cited source. Confidence: high · Verified: Google: Flexible sampling

Google hat keine Strafe für Paywall-Inhalte, und der übergeordnete Hub dieses Artikels sagt genau das: gesperrte Inhalte sind in Ordnung, solange Google sie über den unterstützten Ansatz lesen kann. Der Fehlermodus liegt vor dem Ranking – es ist Verständnis. Wenn Googlebot nur einen Teaser sieht, ist das alles, was es indexieren und für das es Sie ranken kann. Jede unten beschriebene Technik dient dazu, ein Problem zu lösen: der Engine das Lesen des Ganzen zu ermöglichen, während nicht authentifizierte Menschen weiterhin auf die Sperre stoßen.

Zwei Grenzen, die es wert sind, klar ausgesprochen zu werden, da man leicht in beide Richtungen übertreiben kann. Erstens ist dieses Markup ein Werkzeug für Inhalte, die Sie indexiert haben möchten, unter einer deklarierten Sperre – kein Mechanismus, um Inhalte offenzulegen, die Sie überhaupt nicht indexiert haben möchten. Wirklich private Konto-/Admin-URLs sind ein anderer Fall (siehe Entscheidungsbaum unten): Diese erhalten noindex oder eine Authentifizierungsweiterleitung, nicht isAccessibleForFree. Zweitens sind gültiges Markup und vollständiger Crawl-Zugriff keine Ranking-Garantie. Googles Richtlinien für strukturierte Daten sagen direkt, dass “Google nicht garantiert, dass Funktionen, die strukturierte Daten verwenden, in den Suchergebnissen erscheinen” – das Markup ist die Deklaration, die Sie aus dem Cloaking-Bereich heraushält, kein Versprechen für Indexierung, Ranking, Traffic oder ein Rich Result.

Historisch gesehen stammt hier die größte warnende Geschichte. Als das Wall Street Journal 2017 aus Googles altem First Click Free-Programm ausstieg, meldete es einen Rückgang des Google-Suchverkehrs um ~44 % – nicht weil Paywalls bestraft werden, sondern weil Google die Artikel überhaupt nicht mehr sehen konnte. (Mehr zu First Click Free unten; es ist Geschichte, nicht aktuelle Richtlinie.)

Flexibles Sampling: Metering und Lead-in

Das aktuelle, aktive Modell ist flexibles Sampling, dargelegt in Googles Richtlinien für flexibles Sampling. Google beschreibt zwei Sampling-Typen: “Metering, das den Nutzern ein Kontingent an Artikeln bietet, bevor sie sich abonnieren oder anmelden müssen, wonach Paywalls erscheinen; und Lead-in, das einen Teil des Inhalts eines Artikels anbietet, ohne ihn vollständig zu zeigen.”

Die Zahlen, die zählen, alle aus Googles eigener Dokumentation:

  • Bevorzugen Sie monatliche statt täglicher Messung. Google: “In general, we think that monthly, rather than daily metering provides more flexibility and a safer environment for testing.” Eine Änderung um eine Einheit ist bei 10 monatlichen Stichproben weit weniger störend als bei 3 täglichen.
  • Beginnen Sie mit etwa 6–10 kostenlosen Artikeln pro Monat. “As a starting point for your explorations, we encourage you to provide 10 articles per month… for most daily news publishers, we expect the value to fall between 6 and 10 articles per user per month.”
  • Beachten Sie die Obergrenze der Sichtbarkeit. “Our analysis shows that general user satisfaction starts to degrade significantly when paywalls are shown more than 10% of the time (which generally means that about 3% of the audience has been exposed to the paywall).”
  • Ein Einstieg ist eine gute Praxis. Wenn Sie die ersten Sätze oberhalb der Paywall zeigen, können Nutzer “experience the value of the content.”

Keine dieser Zahlen ist eine Vorgabe. Google sagt direkt: “There is no single value for optimal sampling across different businesses” — die Zahl von 6–10/Monat ist ein Ausgangspunkt, den Google speziell für tägliche Nachrichtenverlage nennt, und selbst diese kommt mit “we leave the exact number to the discretion of individual publishers, who are best positioned to understand the particular demands of their businesses.” Behandeln Sie sie als getesteten Ausgangsbereich, nicht als Regel, die Sie wörtlich übernehmen müssen.

Der unterschätzte Punkt: Messung ist nicht nur ein Monetarisierungsregler. Google beginnt das Dokument mit dem Hinweis, dass “even minor changes to the current sampling levels could degrade user experience and, as user access is restricted, unintentionally impact article ranking in Google Search.” Eine strengere Messung kann Sie leise Rankings kosten.

Warum dies kein Cloaking ist – die Begründung, nicht nur die Regel

Dies ist der tragende Teil des gesamten Themas, und die meisten Leitfäden behaupten die Schlussfolgerung (“Paywalls sind kein Cloaking, wenn Sie strukturierte Daten verwenden”), ohne zu zeigen, warum. Hier ist die tatsächliche Begründung, direkt aus Googles Spam-Richtlinien.

Beginnen Sie mit der Definition. Cloaking ist “the practice of presenting different content to users and search engines with the intent to manipulate search rankings and mislead users.” Die Last liegt auf diesem Satzteil – Absicht zu manipulieren und in die Irre zu führen. Eine Paywall versucht nicht, jemanden zu täuschen; sie monetarisiert Inhalte und deklariert den Unterschied in der Behandlung durch Markup.

Dann die explizite Ausnahme, in derselben Richtlinie: “If you operate a paywall or a content-gating mechanism, we don’t consider this to be cloaking if Google can see the full content of what’s behind the paywall just like any person who has access to the gated material and if you follow our Flexible Sampling general guidance.”

Die Ausnahme hat also zwei Bedingungen: (1) Google sieht denselben vollständigen Inhalt, den ein zahlender Abonnent sehen würde, und (2) Sie befolgen Flexible Sampling – was in der Praxis die unten stehenden strukturierten Daten bedeutet. Googles Dokument zu Flexible Sampling bekräftigt dieselbe Logik: “Enclose paywalled content with structured data in order to help Google differentiate paywalled content from the practice of cloaking, where the content served to Googlebot is different from the content served to users.” Die strukturierten Daten sind die Deklaration, die “unterschiedliche Inhalte für Bots” von Täuschung in einen offengelegten, genehmigten Mechanismus verwandelt.

Implementierung der strukturierten Daten

Das Markup befindet sich in Googles Dokument zu Abonnements und Paywall-Inhalten. Zwei Eigenschaften übernehmen die Arbeit:

  • isAccessibleForFree (Boolean, erforderlich) — ob der Inhalt kostenlos oder gesperrt ist. Googles eigene Property-Referenz markiert diese als erforderlich; setzen Sie sie auf dem obersten CreativeWork/NewsArticle-Knoten und auf jedem gesperrten Abschnitt.
  • hasPart (empfohlen, nicht erforderlich) — ein Array von WebPageElement- Objekten, eines pro gesperrtem Abschnitt, jeweils mit eigenem isAccessibleForFree: false und einem cssSelector, der auf die Klasse verweist, in die Sie das gesperrte HTML eingebettet haben. So teilen Sie Google mit, welcher Teil des Beitrags gesperrt ist, wenn es sich um einen Abschnitt und nicht um das gesamte Stück handelt; dies ist der empfohlene Weg für abschnittsgenaue Präzision, nicht eine zweite erforderliche Property neben dem Top-Level-Flag.

Ein minimaler NewsArticle sieht so aus:

{
  "@context": "https://schema.org",
  "@type": "NewsArticle",
  "isAccessibleForFree": false,
  "hasPart": {
    "@type": "WebPageElement",
    "isAccessibleForFree": false,
    "cssSelector": ".paywall"
  }
}

Drei Implementierungsdetails, über die Menschen stolpern:

  • Nur Klassen-Selektoren. Der cssSelector “verweist auf den Klassennamen, den Sie im HTML festgelegt haben.” Verwenden Sie .paywall — keine ID (#paywall), keinen Nachfahren- oder Attribut-Selektor.
  • Mehrere gesperrte Abschnitte verwenden ein Array von hasPart-Objekten, jeweils mit eigenem klassenbasiertem Selektor. Verschachteln Sie die gesperrten Abschnitte nicht ineinander.
  • Nicht nur für Nachrichten. Das Markup wird auf jedem CreativeWork- Subtyp unterstützt — Article, NewsArticle, Blog, Comment, Course, HowTo, Message, Review, WebPage. Die breitere strukturierte-Daten-Anleitung behandelt isAccessibleForFree als allgemeine CreativeWork-Property, nicht als reine Nachrichten-Property.
  • Korrektes Markup garantiert kein Ergebnis. Selbst vollständig gültiges, korrekt verschachteltes Markup macht Google nur berechtigt, Ihre Sperrung zu verstehen — es ist keine Garantie für Ranking oder Rich Results. Behandeln Sie das Markup als Mechanismus, der Sie aus dem Cloaking-Bereich heraushält, nicht als Versprechen eines bestimmten Ergebnisses.

Registrierungswände verwenden dasselbe Markup. Google unterscheidet auf Schema-Ebene nicht zwischen “Zugang bezahlen” und “Zugang registrieren”. John Mueller sagte dies in Search Off the Record: der Mechanismus “could be maybe you require a login, maybe you require a payment, might be after a certain number of iterations you’re like, ‘Oh, this is enough free content.’ Now you have to pay for it… It can just be something like a login or some other mechanism that basically limits the visibility of the content.” (Übersetzung) „Es könnte sein, dass Sie einen Login verlangen, vielleicht eine Zahlung, vielleicht nach einer bestimmten Anzahl von Aufrufen denken Sie: ‚Oh, das ist genug kostenloser Inhalt.‘ Jetzt müssen Sie dafür bezahlen … Es kann einfach etwas wie ein Login oder ein anderer Mechanismus sein, der im Wesentlichen die Sichtbarkeit des Inhalts einschränkt.“ Wenn Sie es sperren, markieren Sie es — bezahlt oder nicht. Er kennzeichnet sogar A/B-Preistests als gültigen Grund: “if you have something like different thresholds where you say some people get to view five pages for free and others have the whole content available for free because you’re doing A/B testing… then you’d want to use a paywall structured data.” (Übersetzung) „Wenn Sie so etwas wie unterschiedliche Schwellenwerte haben, bei denen Sie sagen, einige Leute können fünf Seiten kostenlos ansehen und andere haben den gesamten Inhalt kostenlos verfügbar, weil Sie A/B-Tests durchführen … dann möchten Sie strukturierte Daten für Paywalls verwenden.“

Die JavaScript-Paywall-Falle

Hier ist der häufigste Fehler in der Praxis, und er unterscheidet sich vom “Vergessen der strukturierten Daten.” Viele Paywall-Lösungen liefern den vollständigen Artikel im HTML, das der Server sendet, und verwenden dann JavaScript, um ihn zu verbergen, bis der Abonnementstatus bestätigt ist. Google warnte 2025 in einer Ergänzung zu seinem JavaScript-Fehlerbehebungsdokument ausdrücklich davor: “Some JavaScript paywall solutions include the full content in the server response, then use JavaScript to hide it until subscription status is confirmed. This isn’t a reliable way to limit access to the content. Make sure your paywall only provides the full content once the subscription status is confirmed.” (Übersetzung) „Einige JavaScript-Paywall-Lösungen enthalten den vollständigen Inhalt in der Serverantwort und verwenden dann JavaScript, um ihn zu verbergen, bis der Abonnementstatus bestätigt ist. Dies ist kein zuverlässiger Weg, um den Zugriff auf den Inhalt zu beschränken. Stellen Sie sicher, dass Ihre Paywall den vollständigen Inhalt erst bereitstellt, sobald der Abonnementstatus bestätigt ist.“

Warum es in dreifacher Hinsicht schlecht ist:

  1. Es ist trivial umgehbar. Deaktivieren Sie JavaScript und der „versteckte“ Artikel ist direkt im Quelltext vorhanden. Sie sperren damit eigentlich nichts.
  2. Es verwässert die Cloaking-Ausnahme. Wenn der vollständige Text für alle im DOM liegt, kann Google nicht sauber erkennen, welche Inhalte eigentlich gesperrt sein sollten – genau das soll die strukturierte Daten-Deklaration ja klarmachen.
  3. Es ist ein Barrierefreiheitsproblem. Mueller hat genau das in Search Off the Record angesprochen: “when a user looks at your page, you don’t load the content into the HTML, but rather you make sure that it’s really not loaded into the page’s DOM so that, if a browser has something like… a screen reader, that the screen reader doesn’t go off and read all of this text that you’re trying to hide… make sure you don’t load it into the browser and use JavaScript to turn it on, but rather that it’s really only served to the user when you want to make it available.” (Übersetzung) „Wenn ein Nutzer Ihre Seite betrachtet, laden Sie den Inhalt nicht in das HTML, sondern stellen Sie sicher, dass er wirklich nicht in das DOM der Seite geladen wird, sodass, wenn ein Browser so etwas wie… einen Screenreader hat, der Screenreader nicht losläuft und all diesen Text vorliest, den Sie zu verbergen versuchen… stellen Sie sicher, dass Sie ihn nicht in den Browser laden und mit JavaScript aktivieren, sondern dass er wirklich nur dann an den Nutzer ausgeliefert wird, wenn Sie ihn verfügbar machen wollen.“ Das Dokument-Update von 2025 und Muellers Warnung sind derselbe Fehler aus zwei Blickwinkeln.

Die Lösung ist serverseitiges Gating: Bestätigen Sie den Abo-/Login-Status auf dem Server und nehmen Sie den vollständigen Artikel nur für authentifizierte Nutzer in die Antwort auf. Legen Sie dann isAccessibleForFree/cssSelector darüber, sodass Googlebot – der darf den vollständigen Text unter flexiblem Sampling sehen – weiterhin alles erhält, während nicht authentifizierte Menschen es wirklich nicht bekommen. Hier überschneiden sich Paywalls auch mit Mobile-First-Indexierung: Google crawlt und bewertet die mobile Version, daher muss der vollständige gesperrte Inhalt auch in der mobilen Serverantwort vorhanden sein, nicht nur auf dem Desktop.

Login-Seiten und Registrierungs-Gates: die leiseren Fallstricke

Zwei verschiedene Probleme treten rund um Login/Registrierung auf, beide aus derselben Search Off the Record-Episode.

Generische Login-Seiten werden zu Duplikaten zusammengefasst. Mueller: “if you have a very generic login page, we will see all of these URLs that show that login page, that redirect to that login page, as being duplicates… We’ll fold them together as duplicates, and we’ll focus on indexing the login page… If someone is searching for your service… the only thing… they find in search is like, ‘Here’s how to log in,’ that might be a kind of a weird experience for them.” (Übersetzung) „Wenn Sie eine sehr generische Login-Seite haben, sehen wir alle diese URLs, die diese Login-Seite zeigen, die auf diese Login-Seite weiterleiten, als Duplikate… Wir fassen sie als Duplikate zusammen und konzentrieren uns auf die Indexierung der Login-Seite… Wenn jemand nach Ihrem Dienst sucht… das Einzige… was er in der Suche findet, ist so etwas wie ‚So melden Sie sich an‘, das könnte eine seltsame Erfahrung für ihn sein.“ Die Lösung besteht darin, Login-Seiten eindeutigen kontextuellen Text pro Dienst zu geben, damit sie nicht alle identisch sind.

Blockieren Sie private URLs nicht per robots.txt. Das widerspricht einer verbreiteten Intuition. Mueller: “whether all of this should just be blocked by robots.txt, which is another common strategy… The problem, I think, with doing that is the URLs could become indexable so we wouldn’t see the contents of the login page… if it’s private content, serve it with a noindex or redirect it to a login page somewhere. Don’t use robots.txt.” (Übersetzung) „Ob das alles einfach durch robots.txt blockiert werden sollte, was eine weitere häufige Strategie ist… Das Problem dabei ist meiner Meinung nach, dass die URLs indexierbar werden könnten, sodass wir die Inhalte der Login-Seite nicht sehen würden… Wenn es private Inhalte sind, liefern Sie sie mit einem noindex aus oder leiten Sie sie irgendwohin auf eine Login-Seite weiter. Verwenden Sie nicht robots.txt.“ Eine per robots.txt blockierte URL kann trotzdem als nackte, inhaltslose URL indexiert werden – oft schlimmer als ein sauberes noindex. (Das betrifft wirklich private Inhalte, ein anderer Fall als Paywall-Inhalte, die indexiert werden sollten; verwechseln Sie die beiden nicht.)

Testen und die „Leaky“-Sorge

Testen Sie mit dem Rich Results Test. Google hat Paywall-Inhaltsunterstützung hinzugefügt zum Rich Results Test im Oktober 2023, sodass er isAccessibleForFree/cssSelector auf einer Live-URL validiert, getestet als Googlebot-Desktop oder -Smartphone. Wie Mueller es in einer Sprechstunde 2020 formulierte, “you would use the rich results test, like any other kind of structured data… the tricky part with some of these paywall implementations is that Googlebot, of course, needs to be able to see the full content.” (Übersetzung) „Sie würden den Rich Results Test verwenden, wie jede andere Art strukturierter Daten… das Knifflige bei einigen dieser Paywall-Implementierungen ist, dass Googlebot natürlich in der Lage sein muss, den vollständigen Inhalt zu sehen.“

Der Selbst-Audit-Trick: Öffnen Sie ein Inkognito-Fenster (von allem abgemeldet), suchen Sie nach Ihrer eigenen Marke oder Dienstleistung und sehen Sie, was angezeigt wird. Muellers Rat — “Wenn das oberste Ergebnis so etwas wie eine Anmeldeseite ist und auf dieser Seite sonst keinerlei Informationen vorhanden sind, dann ist das wahrscheinlich etwas, das Sie verbessern können.”

Ist es “undicht”, Googlebot den vollständigen Artikel zu zeigen? Nein. Danny Sullivan, Googles Search Liaison, ging auf die wiederkehrende Sorge ein, dass dadurch kostenpflichtige Inhalte offengelegt werden: “Unser System möchte den vollständigen Inhalt sehen, wenn ein Publisher das möchte. Wenn er das tut, verstehen wir mehr darüber. Wenn wir mehr verstehen, können wir ihn möglicherweise für mehr relevante Suchanfragen anzeigen,” und “Da nur wir das sehen, gibt es nichts ‘Undichtes’, wie Sie andeuten.” Der eigentliche Leck-Vektor, so stellte er fest, ist die zwischengespeicherte Kopie — gelöst mit noarchive, einer separaten Kontrolle vom Paywall-Markup selbst. Sullivans Bemerkungen werden über die Berichterstattung von Search Engine Roundtable weitergegeben; behandeln Sie sie als berichtet und nicht als Erstparteien-Transkript.

Bings Ansatz

Bings Leitfaden zu Abonnements und Paywalls (Fabrice Canel, Mai 2022) ist strukturell ähnlich, aber nicht schema-zentriert. Seine drei Punkte: (1) Bingbot den vollständigen, gesperrten Inhalt crawlen lassen, (2) noarchive/nocache (oder den X-Robots-Tag: noarchive-Header) verwenden, damit zwischengespeicherte Kopien nicht leaken, und (3) überprüfen, ob der Crawler wirklich Bingbot ist, indem die anfragende IP gegen Bings veröffentlichte Bereiche geprüft wird — nicht, indem man der User-Agent- Zeichenkette vertraut, die jeder fälschen kann. Es gibt kein veröffentlichtes Bing-Äquivalent zu isAccessibleForFree/cssSelector; Bings Modell ist Crawl-Zugang plus Cache-Kontrolle, während Googles Modell markup-zentriert ist. Gehen Sie nicht von Feature-Parität aus.

First Click Free — Geschichte, nicht Richtlinie

Sie werden immer noch Blogbeiträge und Forenantworten sehen, die First Click Free beschreiben, als ob es aktuell wäre. Das ist es nicht. Google hat es im Oktober 2017 eingestellt, und durch flexibles Sampling ersetzt. Richard Gingras, damals Googles VP of News: “Erstens wird Flexible Sampling First Click Free ersetzen. Publisher sind am besten in der Lage, zu bestimmen, welches Maß an kostenlosem Sampling für sie am besten funktioniert.” First Click Free hatte teilnehmende Publisher verpflichtet, von Google verwiesenen Besuchern das Lesen einer bestimmten Anzahl von Artikeln pro Tag (üblicherweise drei) zu ermöglichen, sogar über ihre eigene Paywall hinaus. Flexibles Sampling gab diese Entscheidung an die Publisher zurück. Wenn Sie FCF als etwas zitiert sehen, in das Sie sich heute einklinken können, ist diese Anleitung acht oder mehr Jahre veraltet.

Wo dies in der News-SEO einzuordnen ist

Die Paywall-Behandlung ist ein Teil des breiteren Themas News & Discover SEO — neben News-Sitemaps, der Berechtigung für Google News/Top Stories, Discover und Syndication (canonical vs. noindex). Wenn Sie ein Publisher sind, bringen Sie Ihr Paywall-Markup und Ihre Syndication-Richtlinie in Ordnung, bevor eines von beiden Sie stillschweigend Indexierung oder Zuschreibung kostet.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.