Paywalle i SEO

TL;DR — Paywall (subskrypcja, płatność jednorazowa lub po prostu bramka rejestracyjna/logowania) nie szkodzi automatycznie Twojemu SEO. Google ma wspierany sposób na obsługę tego, zwany elastycznym próbkowaniem: pozwalasz Googlebotowi przeczytać cały artykuł, a następnie używasz odrobiny danych strukturalnych, aby powiedzieć Google, która część jest za paywallem. Zrobione w ten sposób, pokazywanie Google pełnego artykułu, podczas gdy czytelnicy widzą skróconą wersję, nie jest cloakingiem — to zatwierdzony wyjątek.

Czy paywalle szkodzą SEO?

Google wspiera treści za paywallem, gdy crawlerzy mają do nich dostęp, a implementacja wykorzystuje udokumentowany wzorzec danych strukturalnych dla paywalli. Dowód potwierdzający to twierdzenie Official or primary documentation supporting the adjacent article claim, with scope limited to the source's published description. Zakres: No ranking guarantee or undisclosed system mechanics are inferred beyond the cited source. Poziom ufności: wysoki · Zweryfikowano: 2026-07-14 Google: Paywalled content structured data Wytyczne Google dotyczące elastycznego próbkowania opisują podejścia z licznikiem i wstępem, a nie gwarancję rankingu. Dowód potwierdzający to twierdzenie Official or primary documentation supporting the adjacent article claim, with scope limited to the source's published description. Zakres: No ranking guarantee or undisclosed system mechanics are inferred beyond the cited source. Poziom ufności: wysoki · Zweryfikowano: 2026-07-14 Google: Flexible sampling

Nie same w sobie. To pierwsza rzecz, którą należy zrozumieć, bo połowa poradników przedstawia paywalle jako problem SEO, który należy minimalizować. Tak nie jest. Google nie ma uprzedzeń wobec treści za paywallem — New York Times, Wall Street Journal, Financial Times i Washington Post mają paywalle i zajmują wysokie pozycje właśnie za historie, które blokują.

To, co naprawdę szkodzi rankingom, to brak możliwości zobaczenia przez Google wystarczającej ilości Twoich treści, aby zrozumieć, o czym jest strona. Jeśli bot widzi tylko dwuzdaniowy teaser, może Cię pozycjonować tylko za te dwa zdania. Więc cała gra z paywallami i SEO polega na tym: pozwól wyszukiwarce przeczytać pełny artykuł, podczas gdy zwykli odwiedzający nadal trafiają na bramkę.

Jedna rzecz, którą ten znacznik nie jest: obietnicą. Poprawne ustawienie isAccessibleForFree i reszty znaczników nie gwarantuje indeksowania, rankingu ani rozszerzonego wyniku — dokumentacja danych strukturalnych Google mówi wprost, że nie gwarantuje, że jakakolwiek funkcja pojawi się w wynikach wyszukiwania. To, co robi znacznik, to usunięcie ryzyka cloakingu związanego z pokazywaniem crawlerom więcej niż widzą użytkownicy; sam w sobie nie kreuje rankingów.

Wspierany sposób: elastyczne próbkowanie

Model Google nazywa się elastycznym próbkowaniem i ma dwa warianty:

• Licznik — odwiedzający dostają limit darmowych artykułów (Google sugeruje zacząć od około 6–10 miesięcznie), zanim paywall się uruchomi.
• Wstęp — pokazujesz początek artykułu, a resztę blokujesz.

Niezależnie od tego, który wybierzesz, dodajesz mały fragment danych strukturalnych do strony, który mówi Google: “ta sekcja jest za paywallem.” To ta etykieta sprawia, że wszystko jest legalne.

Czy pokazywanie Google pełnego artykułu to oszustwo?

To pytanie zadaje każdy, a odpowiedź brzmi nie — ponieważ to zadeklarowałeś. Cloaking (zła rzecz) to pokazywanie wyszukiwarkom innych treści niż użytkownikom w celu ich oszukania i manipulowania rankingami. Elastyczne próbkowanie jest przeciwieństwem: otwarcie mówisz Google, poprzez dane strukturalne, “hej, prawdziwi użytkownicy widzą coś bardziej ograniczonego niż to, co crawler przegląda.” Polityka spamu Google wyłącza paywalle z definicji cloakingu z nazwy, o ile postępujesz zgodnie z wytycznymi elastycznego próbkowania i pozwalasz Google zobaczyć pełną treść.

Jeden błąd, którego należy unikać

Nie buduj paywalla, wysyłając cały artykuł w HTML strony i po prostu ukrywając go za pomocą JavaScript lub CSS, dopóki ktoś się nie zaloguje. Wydaje się to łatwiejsze, ale się mści: każdy może wyłączyć JavaScript i czytać Twoje płatne treści za darmo, czytniki ekranu odczytają “ukryty” tekst na głos, a Google nie może niezawodnie stwierdzić, którą część chciałeś zablokować. Właściwy sposób to zablokowanie na serwerze — wysyłaj pełny artykuł tylko po potwierdzeniu, że osoba jest zalogowana lub ma subskrypcję.

Chcesz poznać pełne mechanizmy — dokładne dane strukturalne, liczby licznika, pułapkę JavaScript i dlaczego strony logowania powodują własne problemy? Przełącz się na zakładkę Zaawansowane.

TL;DR — Paywalle nie szkodzą pozycjom samym w sobie; problemem jest to, że Google nie widzi Twoich treści. Wspierany model to elastyczne próbkowanie — metering lub lead-in — zadeklarowane za pomocą danych strukturalnych (isAccessibleForFree: false plus hasPart/cssSelector oznaczające zamkniętą sekcję, wyłącznie selektory klas). To właśnie ta deklaracja sprawia, że serwowanie Googlebotowi pełnego artykułu nie jest cloakingiem: cloaking wymaga zamiaru manipulacji i wprowadzania w błąd, a polityka spamu Google wprost wyłącza paywalle z tej definicji. Blokuj po stronie serwera (aktualizacja dokumentacji z 2025 r. i ostrzeżenie Muellera o czytnikach ekranu dotyczą tego samego błędu ukrywania treści przez JS), nadaj stronom logowania unikalną treść, nigdy nie umieszczaj prywatnych URL-i w robots.txt i używaj noarchive, aby zapobiec wyciekowi pełnego tekstu z kopii w pamięci podręcznej. Ściany rejestracyjne używają tego samego znacznika co płatne.

Co faktycznie powoduje problemy z pozycjami (to nie brama)

Kwalifikowalność paywalla zależy od treści dostępnych do indeksowania i dokładnego znacznika; samo istnienie paywalla nie jest udokumentowane jako kara. Dowód potwierdzający to twierdzenie Official or primary documentation supporting the adjacent article claim, with scope limited to the source's published description. Zakres: No ranking guarantee or undisclosed system mechanics are inferred beyond the cited source. Poziom ufności: wysoki · Zweryfikowano: 2026-07-14 Google: Paywalled content structured data Wybory dotyczące próbkowania pozostają decyzjami wydawców z kompromisami użytkownika i biznesowymi. Dowód potwierdzający to twierdzenie Official or primary documentation supporting the adjacent article claim, with scope limited to the source's published description. Zakres: No ranking guarantee or undisclosed system mechanics are inferred beyond the cited source. Poziom ufności: wysoki · Zweryfikowano: 2026-07-14 Google: Flexible sampling

Google nie ma kary za treści za paywallem, a nadrzędny hub tego artykułu mówi to wprost: treści za bramą są w porządku, o ile Google może je przeczytać za pomocą wspieranego podejścia. Tryb awarii jest wcześniej niż pozycjonowanie — to zrozumienie. Jeśli Googlebot widzi tylko teaser, to teaser jest wszystkim, co może zaindeksować i na podstawie czego Cię pozycjonować. Każda technika poniżej istnieje, aby rozwiązać jeden problem: pozwolić wyszukiwarce przeczytać całość, podczas gdy niezalogowani użytkownicy nadal trafiają na bramę.

Warto jasno określić dwie granice, ponieważ łatwo przesadzić w którąkolwiek stronę. Po pierwsze, ten znacznik to narzędzie dla treści, które chcesz indeksować pod zadeklarowaną bramą — a nie mechanizm do ujawniania treści, których w ogóle nie chcesz indeksować. Prywatne URL-e kont/admina to inny przypadek (patrz drzewo decyzyjne poniżej): te otrzymują noindex lub przekierowanie uwierzytelniające, a nie isAccessibleForFree. Po drugie, poprawny znacznik i pełny dostęp do indeksowania nie są gwarancją pozycji. Wytyczne Google dotyczące danych strukturalnych mówią wprost, że “Google does not guarantee that features that consume structured data will show up in search results” (tłumaczenie) „Google nie gwarantuje, że funkcje korzystające z danych strukturalnych pojawią się w wynikach wyszukiwania” — znacznik to deklaracja, która trzyma Cię z dala od kategorii cloakingu, a nie obietnica indeksowania, pozycji, ruchu czy rozszerzonego wyniku.

Historycznie to właśnie stąd pochodzi największa przestroga. Gdy Wall Street Journal wycofał się z programu First Click Free Google w 2017 r., odnotował ~44% spadek ruchu z wyszukiwarki Google — nie dlatego, że paywalle są karane, ale dlatego, że Google nie mógł już w ogóle zobaczyć artykułów. (Więcej o First Click Free poniżej; to historia, nie obecna polityka.)

Elastyczne próbkowanie: metering i lead-in

Obecny, aktywny model to elastyczne próbkowanie, opisane w wytycznych Google dotyczących elastycznego próbkowania. Google opisuje dwa typy próbkowania: “metering, which provides users with a quota of articles to consume before requiring users to subscribe or log in, after which paywalls will start appearing; and lead-in, which offers a portion of an article’s content without it being shown in full.” (tłumaczenie) „metering, który zapewnia użytkownikom limit artykułów do przeczytania, zanim będą musieli subskrybować lub się zalogować, po czym pojawią się paywalle; oraz lead-in, który oferuje część treści artykułu bez pokazywania jej w całości”.

Liczby, które mają znaczenie, wszystkie z dokumentacji Google:

• Preferuj miesięczne rozliczanie zamiast dziennego. Google uważa, że licznik miesięczny daje większą elastyczność i bezpieczniejsze warunki testowania. Zmiana o jedną jednostkę jest znacznie mniej odczuwalna przy 10 próbkach miesięcznych niż przy 3 dziennych.
• Zacznij od około 6–10 bezpłatnych artykułów miesięcznie. “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.” (tłumaczenie) „Jako punkt wyjścia do eksperymentów zachęcamy do udostępniania 10 artykułów miesięcznie… w przypadku większości wydawców codziennych wiadomości spodziewamy się, że wartość ta będzie wynosić od 6 do 10 artykułów na użytkownika miesięcznie.”
• Uważaj na limit ekspozycji. “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).” (tłumaczenie) „Nasza analiza pokazuje, że ogólne zadowolenie użytkowników zaczyna znacząco spadać, gdy paywall jest wyświetlany częściej niż w 10% przypadków (co zazwyczaj oznacza, że około 3% odbiorców zostało wystawionych na działanie paywalla).”
• Lead-in to dobra praktyka. Pokazanie pierwszych kilku zdań nad paywallem pozwala użytkownikom “experience the value of the content.” (tłumaczenie) „doświadczyć wartości treści”.

Żadna z tych liczb nie jest nakazem. Google mówi wprost: “There is no single value for optimal sampling across different businesses.” (tłumaczenie) „Nie istnieje jedna wartość optymalnego próbkowania dla różnych firm.” Liczba 6–10/miesiąc to punkt wyjścia podany specjalnie dla wydawców codziennych wiadomości. Dokładną liczbę Google pozostawia wydawcom, którzy najlepiej rozumieją wymagania własnej działalności. Traktuj to jako przetestowany zakres wyjściowy, a nie regułę do skopiowania.

Niedoceniany punkt: rozliczanie to nie tylko pokrętło monetyzacji. Google otwiera dokument ostrzeżeniem, że nawet niewielkie zmiany poziomu próbkowania mogą pogorszyć doświadczenie użytkownika i, przez ograniczenie dostępu, nieumyślnie wpłynąć na pozycję artykułu w wyszukiwarce. Zaostrzenie limitu może więc po cichu kosztować Cię widoczność.

Dlaczego to nie jest cloaking — uzasadnienie, nie tylko reguła

To jest kluczowa część całego tematu, a większość przewodników stwierdza wniosek („paywalle nie są cloakingiem, jeśli używasz danych strukturalnych”) bez pokazywania dlaczego. Oto faktyczne uzasadnienie, wprost z polityk spamowych Google.

Zacznij od definicji. Cloaking polega na prezentowaniu innych treści użytkownikom i wyszukiwarkom z zamiarem manipulowania rankingiem i wprowadzania użytkowników w błąd. Ciężar spoczywa na tym fragmencie — zamiar manipulowania i wprowadzania w błąd. Paywall nie próbuje nikogo oszukać; monetyzuje treść i deklaruje różnicę w traktowaniu poprzez znaczniki.

Następnie wyraźne wyłączenie, w tej samej polityce: “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.” (tłumaczenie) „Jeśli prowadzisz paywall lub mechanizm ograniczania treści, nie uznajemy tego za cloaking, jeśli Google widzi pełną treść tego, co znajduje się za paywallem, tak jak każda osoba mająca dostęp do materiału, oraz jeśli postępujesz zgodnie z naszymi ogólnymi wytycznymi dotyczącymi elastycznego próbkowania.”

Zatem wyjątek ma dwa warunki: (1) Google widzi tę samą pełną treść, którą widziałby płatny subskrybent, oraz (2) stosujesz elastyczne próbkowanie — co w praktyce oznacza poniższe dane strukturalne. Dokument Google o elastycznym próbkowaniu wzmacnia tę samą 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.” (tłumaczenie) „Obejmij treść za paywallem danymi strukturalnymi, aby pomóc Google odróżnić treść za paywallem od praktyki cloakingu, gdzie treść serwowana Googlebotowi różni się od treści serwowanej użytkownikom.” Dane strukturalne są deklaracją, która zmienia „inną treść dla botów” z oszustwa w ujawniony, dozwolony mechanizm.

Implementacja danych strukturalnych

Znaczniki znajdują się w dokumencie Google Subscription and paywalled content. Dwie właściwości wykonują całą pracę:

• isAccessibleForFree (Boolean, wymagane) — czy treść jest darmowa, czy ograniczona. Własny opis właściwości Google oznacza tę jako wymaganą; ustaw ją na najwyższym poziomie węzła CreativeWork/NewsArticle oraz na każdej ograniczonej sekcji.
• hasPart (zalecane, nie wymagane) — tablica obiektów WebPageElement, po jednym na każdą ograniczoną sekcję, każdy z własnym isAccessibleForFree: false i cssSelector wskazującym na klasę, w którą opakowałeś ograniczony HTML. To sposób, w jaki mówisz Google, która część utworu jest ograniczona, gdy dotyczy to sekcji, a nie całości; to zalecany sposób uzyskania precyzji na poziomie sekcji, a nie druga wymagana właściwość obok flagi najwyższego poziomu.

Minimalny NewsArticle wygląda tak:

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

Trzy szczegóły implementacji, na których ludzie się potykają:

• Tylko selektory klas. cssSelector “odnosi się do nazwy klasy, którą ustawiłeś w HTML.” Użyj .paywall — nie ID (#paywall), nie selektora potomnego ani atrybutowego.
• Wiele ograniczonych sekcji używa tablicy obiektów hasPart, każdy z własnym selektorem opartym na klasie. Nie zagnieżdżaj ograniczonych sekcji wewnątrz siebie.
• To nie tylko dla wiadomości. Znacznik jest obsługiwany na dowolnym podtypie CreativeWork — Article, NewsArticle, Blog, Comment, Course, HowTo, Message, Review, WebPage. Szersze wytyczne dotyczące danych strukturalnych traktują isAccessibleForFree jako ogólną właściwość CreativeWork, a nie tylko dla wiadomości.
• Poprawny znacznik nie gwarantuje wyniku. Nawet w pełni poprawny, prawidłowo zagnieżdżony znacznik tylko sprawia, że Google jest kwalifikowany do zrozumienia Twojego ograniczenia — to nie jest gwarancja rankingu ani wyniku rozszerzonego. Traktuj znacznik jako mechanizm, który trzyma Cię z dala od kategorii cloakingu, a nie obietnicę konkretnego rezultatu.

Ściany rejestracyjne używają identycznego znacznika. Google nie rozróżnia “płać, aby uzyskać dostęp” od “zarejestruj się, aby uzyskać dostęp” na poziomie schematu. John Mueller powiedział to wprost w Search Off the Record: mechanizm “could be maybe you require a login, maybe you require a payment, maybe 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.” (tłumaczenie) „Może to być wymóg logowania, może wymóg płatności, może po określonej liczbie wyświetleń mówisz: ‚Och, to wystarczająco darmowych treści. Teraz musisz za nie zapłacić…’ To może być po prostu coś takiego jak logowanie lub inny mechanizm, który zasadniczo ogranicza widoczność treści.” Jeśli to ograniczasz, oznacz to — płatne czy nie. On nawet wskazuje testy cenowe A/B jako ważny powód: “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.” (tłumaczenie) „Jeśli masz coś takiego jak różne progi, gdzie mówisz, że niektórzy ludzie mogą zobaczyć pięć stron za darmo, a inni mają całą treść dostępną za darmo, ponieważ prowadzisz testy A/B… to chciałbyś użyć danych strukturalnych paywalla.”

Pułapka paywalla JavaScript

Oto najczęstszy błąd w świecie rzeczywistym, i jest on odrębny od “zapomnienia o danych strukturalnych.” Wiele rozwiązań paywallowych wysyła pełny artykuł w HTML, który serwer wysyła, a następnie używa JavaScript, aby go ukryć, dopóki status subskrypcji nie zostanie potwierdzony. Google wyraźnie ostrzegł przed tym w dodatku z 2025 roku do swojego dokumentu o rozwiązywaniu problemów z JavaScript: Google ostrzega, że wysłanie pełnej treści w odpowiedzi serwera i ukrycie jej JavaScriptem do czasu potwierdzenia subskrypcji nie ogranicza dostępu w niezawodny sposób. Pełną treść należy udostępnić dopiero po potwierdzeniu statusu subskrypcji.

Dlaczego to jest złe na trzech frontach:

1. Jest trywialnie do ominięcia. Wyłącz JavaScript, a „ukryty” artykuł jest od razu w źródle. Tak naprawdę niczego nie blokujesz.
2. Zamazuje wyjątek cloakingu. Jeśli pełny tekst siedzi w DOM dla wszystkich, Google nie może czysto odróżnić, która treść miała być zablokowana — a to właśnie to, co deklaracja danych strukturalnych ma wyjaśniać.
3. To problem dostępności. Mueller poruszył dokładnie to w podcaście Google: ukrywanej treści nie należy w ogóle ładować do HTML ani DOM, ponieważ czytnik ekranu może ją odczytać. Zamiast ładować tekst do przeglądarki i włączać go JavaScriptem, serwuj go dopiero wtedy, gdy rzeczywiście chcesz go udostępnić. Aktualizacja dokumentu z 2025 roku i ostrożność Muellera to ten sam błąd widziany z dwóch perspektyw.

Rozwiązaniem jest blokowanie po stronie serwera: potwierdź status subskrypcji/logowania na serwerze i dołącz pełny artykuł do odpowiedzi tylko dla uwierzytelnionych użytkowników. Następnie nałóż isAccessibleForFree/cssSelector na to, aby Googlebot — który może widzieć pełny tekst w ramach elastycznego próbkowania — nadal dostawał wszystko, podczas gdy nieuwierzytelnieni ludzie naprawdę nie. To także miejsce, gdzie paywalle przecinają się z indeksowaniem mobile-first: Google indeksuje i ocenia wersję mobilną, więc pełna zablokowana treść musi być obecna również w mobilnej odpowiedzi serwera, nie tylko na desktopie.

Strony logowania i bramki rejestracyjne: cichsze pułapki

Dwa różne problemy pojawiają się wokół logowania/rejestracji, oba z tego samego odcinka podcastu Google.

Ogólne strony logowania są składane w duplikaty. Mueller wyjaśnia, że Google może uznać wszystkie adresy pokazujące tę samą ogólną stronę logowania za duplikaty, złożyć je razem i skupić się na indeksowaniu strony logowania. Wtedy osoba szukająca usługi może zobaczyć tylko instrukcję logowania, co tworzy dziwne doświadczenie. Rozwiązaniem jest nadanie stronom logowania unikalnej treści kontekstowej dla każdej usługi, aby nie były wszystkie identyczne.

Nie blokuj prywatnych URL-i przez robots.txt. To przeczy powszechnej intuicji. Mueller wyjaśnia, że taki adres nadal może zostać zindeksowany, mimo że robot nie zobaczy zawartości strony logowania. Prywatną treść należy podać z noindex albo przekierować do strony logowania; nie należy używać do tego robots.txt. URL zablokowany przez robots może nadal być indeksowany jako goły, bez treści URL — często gorzej niż czysty noindex. (To naprawdę prywatna treść, co jest innym przypadkiem niż paywalled-ale-powinien-być-indeksowany; nie myl tych dwóch.)

Testowanie i obawa o „przeciek”

Przetestuj za pomocą Testu wyników rozszerzonych. Google dodał obsługę treści paywalled do Testu wyników rozszerzonych w październiku 2023, więc waliduje isAccessibleForFree/cssSelector na żywym URL-u, testując jako Googlebot desktop lub smartphone. Mueller wyjaśnił w godzinach biurowych w 2020 roku, że używa się go jak przy każdych innych danych strukturalnych, ale Googlebot musi widzieć pełną treść, aby poprawnie zrozumieć implementację paywalla.

Sztuczka z samooceną: otwórz okno incognito (wylogowane ze wszystkiego), wyszukaj swoją markę lub usługę i zobacz, co się pojawia. Rada Muellera — “Jeśli najlepszy wynik to na przykład strona logowania i na tej stronie nie ma żadnych informacji, to prawdopodobnie jest coś, co możesz poprawić.”

Czy pokazywanie Googlebotowi pełnego artykułu jest “nieszczelne”? Nie. Danny Sullivan, Search Liaison w Google, odniósł się do powracającego zmartwienia, że ujawnia to płatne treści: “Nasz system chce widzieć pełną treść, jeśli wydawca chce nam to umożliwić. Jeśli to zrobi, rozumiemy więcej. Jeśli rozumiemy więcej, możemy być w stanie pokazać ją dla większej liczby zapytań, gdzie jest istotna” oraz “Ponieważ tylko my to widzimy, nie ma nic ‘nieszczelnego’, jak sugerujesz.” Prawdziwy wektor wycieku, jak zauważył, to zarchiwizowana kopia — rozwiązany za pomocą noarchive, osobnego kontrolera od samego znacznika paywalla. Uwagi Sullivana są przekazane za pośrednictwem relacji Search Engine Roundtable; traktuj je jako relacjonowane, a nie jako transkrypcję z pierwszej ręki.

Podejście Binga

Wytyczne Bing dotyczące subskrypcji i paywalli (Fabrice Canel, maj 2022) są strukturalnie podobne, ale nie skoncentrowane na schematach. Jego trzy punkty: (1) pozwól Bingbotowi indeksować pełną zablokowaną treść, (2) użyj noarchive/nocache (lub nagłówka X-Robots-Tag: noarchive), aby zarchiwizowane kopie nie wyciekały, oraz (3) zweryfikuj, czy robot jest naprawdę Bingbotem, sprawdzając adres IP żądającego z opublikowanymi zakresami Bing — nie ufając stringowi user-agenta, który każdy może sfałszować. Nie ma opublikowanego odpowiednika Bing dla isAccessibleForFree/cssSelector; model Bing to dostęp do indeksowania plus kontrola pamięci podręcznej, podczas gdy Google jest skoncentrowany na znacznikach. Nie zakładaj parytetu funkcji.

First Click Free — historia, nie polityka

Nadal zobaczysz wpisy na blogach i odpowiedzi na forach opisujące First Click Free, jakby było aktualne. Nie jest. Google wycofał je w październiku 2017, zastępując je elastycznym próbkowaniem. Richard Gingras, ówczesny wiceprezes Google ds. wiadomości: “Po pierwsze, elastyczne próbkowanie zastąpi First Click Free. Wydawcy są w najlepszej pozycji, aby określić, jaki poziom darmowego próbkowania działa dla nich najlepiej.” First Click Free wymagało od uczestniczących wydawców umożliwienia odwiedzającym z Google przeczytania określonej liczby artykułów dziennie (zwykle trzech) nawet poza ich własnym paywallem. Elastyczne próbkowanie oddało tę decyzję wydawcom. Jeśli widzisz FCF cytowane jako coś, co możesz dziś włączyć, te wskazówki są nieaktualne od ponad ośmiu lat.

Gdzie to się mieści w SEO dla wiadomości

Obsługa paywalla to jeden element szerszego obrazu SEO dla wiadomości i Discover — obok map witryn dla wiadomości, kwalifikowalności do Google News/Top Stories, Discover i syndykacji (kanoniczna vs. noindex). Jeśli jesteś wydawcą, uporządkuj znaczniki paywalla i politykę syndykacji, zanim jedno lub drugie po cichu kosztuje Cię indeksację lub atrybucję.

Podsumowanie AI

Skrócona wersja wersji zaawansowanej:

• Paywalle nie szkodzą SEO same w sobie. Google nie ma uprzedzeń do treści za paywallem; największe wydawcy z paywallem plasują się dobrze. Szkodzi natomiast to, że Google nie może zobaczyć wystarczającej ilości treści, aby zrozumieć stronę — a sam znacznik jest deklaracją, a nie gwarancją rankingu (dokumentacja Google mówi wprost, że dane strukturalne nie gwarantują, że jakakolwiek funkcja pojawi się w wynikach wyszukiwania).
• Elastyczne próbkowanie to wspierany model (nie wycofany First Click Free, który zniknął w październiku 2017): licznik (zacznij od ~6–10 darmowych artykułów miesięcznie, preferuj miesięczny zamiast dziennego) lub lead-in (pokaż początek, resztę za paywallem). Google wprost stwierdza, że „nie ma jednej wartości optymalnego próbkowania dla różnych firm” — 6–10 miesięcznie to punkt wyjścia dla dziennych wiadomości, a nie uniwersalna zasada. Zadowolenie użytkowników spada po ~10% ekspozycji na paywall; zaostrzenie licznika może nawet kosztować pozycje.
• Dane strukturalne to mechanizm: isAccessibleForFree: false (właściwość wymagana) na węźle artykułu, plus zalecany hasPart/WebPageElement z klasowym cssSelector dla precyzji na poziomie sekcji. Działa na każdym podtypie CreativeWork, nie tylko wiadomościach. To dla treści, które chcesz indeksować pod zadeklarowaną bramą — prywatne adresy URL dostają noindex, a nie ten znacznik.
• Dlaczego to nie jest cloaking: cloaking wymaga zamiaru manipulacji i wprowadzenia w błąd; polityka spamu Google wprost wyłącza paywalle, gdy Google widzi pełną treść, a Ty postępujesz zgodnie z wytycznymi elastycznego próbkowania. Znacznik jest deklaracją.
• Ściany rejestracji/logowania używają identycznego znacznika jak płatne paywalle — Google nie rozróżnia płatności od rejestracji na poziomie schematu (według Muellera).
• Pułapka JS-paywall: nie wysyłaj pełnego artykułu w HTML i nie ukrywaj go za pomocą JS/CSS — to do obejścia, zaciemnia wyjątek cloakingu, a czytniki ekranu czytają „ukryty” tekst. Bramkuj po stronie serwera; pełna treść musi być też w odpowiedzi mobilnej (indeksowanie mobile-first).
• Pułapki strony logowania: ogólne strony logowania są składane jako duplikaty (nadaj im unikalną treść); nigdy nie blokuj prywatnych adresów URL w robots.txt (użyj noindex/przekierowania).
• Wyciek z pamięci podręcznej to osobna kontrola: noarchive/nocache zatrzymuje kopię w pamięci podręcznej ujawniającą tekst za paywallem (według Danny’ego Sullivana). Model Binga to dostęp do indeksowania + kontrola pamięci podręcznej + weryfikacja IP, bez odpowiednika isAccessibleForFree.
• Testuj za pomocą Rich Results Test (wsparcie paywalli od października 2023) i audytu incognito Muellera.

Oficjalna dokumentacja

Wytyczne z pierwotnych źródeł od wyszukiwarek.

Google

• Flexible Sampling — model podstawowy: metering vs. lead-in, punkt startowy 6–10 artykułów miesięcznie, limit ekspozycji 10 % oraz uzasadnienie różnicowania w kontekście cloakingu.
• Znaczniki treści subskrypcyjnych i za paywallem — isAccessibleForFree, hasPart/WebPageElement oraz cssSelector oparty na klasach.
• Zasady dotyczące spamu — Cloaking — definicja cloakingu i wyraźny wyjątek dla paywalli.
• Rozwiązywanie problemów z JavaScriptem związanych z wyszukiwaniem — wytyczne z 2025 r. dotyczące paywalli opartych na JavaScript.
• Lista popularnych robotów Google — rzeczywiste user-agenty robotów (użyte poniżej do obalenia zmyślonego twierdzenia o „Googlebot Subscriber”).
• Driving the future of digital subscriptions — przejście z 2017 r. z First Click Free na Flexible Sampling.
• Test wyników rozszerzonych — weryfikuje dane strukturalne paywalla na żywym adresie URL.

Bing / Microsoft

• Dobre praktyki SEO dla treści subskrypcyjnych i za paywallem — Fabrice Canel, maj 2022: dostęp do indeksowania, kontrola pamięci podręcznej i weryfikacja Bingbota na podstawie adresu IP.

Cytaty ze źródła

Oficjalne wypowiedzi Google i Bing. Każdy link prowadzi bezpośrednio do cytowanego fragmentu, jeśli strona źródłowa to umożliwia.

Google — dlaczego paywalle nie są cloakingiem (kluczowe cytaty)

• “Cloaking refers to the practice of presenting different content to users and search engines with the intent to manipulate search rankings and mislead users.” (tłumaczenie) „Cloaking odnosi się do praktyki prezentowania różnych treści użytkownikom i wyszukiwarkom w celu manipulowania rankingami wyszukiwania i wprowadzania użytkowników w błąd.” Przejdź do cytatu
• “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.” (tłumaczenie) „Jeśli stosujesz paywall lub mechanizm ograniczania treści, nie uznajemy tego za cloaking, jeśli Google może zobaczyć pełną treść za paywallem tak samo jak każda osoba mająca dostęp do tych materiałów oraz jeśli postępujesz zgodnie z naszymi ogólnymi wytycznymi Flexible Sampling.” Przejdź do cytatu
• “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.” (tłumaczenie) „Oznacz treści za paywallem danymi strukturalnymi, aby pomóc Google odróżnić treści paywallowe od praktyki cloakingu, gdzie treść dostarczana Googlebotowi różni się od treści dostarczanej użytkownikom.” Przejdź do cytatu

Google — flexible sampling i metering

• “There are two types of sampling we advise: metering, which provides users with a quota of articles to consume before requiring users to subscribe or log in, after which paywalls will start appearing; and lead-in, which offers a portion of an article’s content without it being shown in full.” (tłumaczenie) «Istnieją dwa rodzaje próbkowania, które zalecamy: licznik, który zapewnia użytkownikom limit artykułów do przeczytania, zanim będą musieli się zapisać lub zalogować, po czym pojawią się paywalle; oraz lead-in, który oferuje część treści artykułu bez pokazywania go w całości.» Przejdź do cytatu
• “In general, we think that monthly, rather than daily metering provides more flexibility and a safer environment for testing.” (tłumaczenie) «Ogólnie rzecz biorąc, uważamy, że licznik miesięczny, a nie dzienny, zapewnia większą elastyczność i bezpieczniejsze środowisko do testów.» Google dodaje: “There is no single value for optimal sampling across different businesses.” (tłumaczenie) „Nie istnieje jedna wartość optymalnego próbkowania dla różnych firm.” Przejdź do cytatu
• “As a starting point for your explorations, we encourage you to provide 10 articles per month to Google search users and iterate from there… for most daily news publishers, we expect the value to fall between 6 and 10 articles per user per month.” (tłumaczenie) «Jako punkt wyjścia do eksperymentów zachęcamy do udostępniania 10 artykułów miesięcznie użytkownikom wyszukiwarki Google i iterowania od tego miejsca… w przypadku większości wydawców codziennych wiadomości spodziewamy się, że wartość ta będzie wynosić od 6 do 10 artykułów na użytkownika miesięcznie.» Przejdź do cytatu
• “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).” (tłumaczenie) «Nasza analiza pokazuje, że ogólne zadowolenie użytkowników zaczyna znacząco spadać, gdy paywalle są wyświetlane częściej niż w 10 % przypadków (co zazwyczaj oznacza, że około 3 % odbiorców miało kontakt z paywallem).» Przejdź do cytatu

Google — pułapka paywalli JavaScript

• “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.” (tłumaczenie) «Niektóre rozwiązania paywalli JavaScript zawierają pełną treść w odpowiedzi serwera, a następnie używają JavaScriptu, aby ją ukryć do czasu potwierdzenia statusu subskrypcji. To nie jest niezawodny sposób ograniczania dostępu do treści. Upewnij się, że Twój paywall udostępnia pełną treść dopiero po potwierdzeniu statusu subskrypcji.» Przejdź do cytatu

Richard Gingras, wiceprezes ds. wiadomości w Google (październik 2017)

• “First, Flexible Sampling will replace First Click Free. Publishers are in the best position to determine what level of free sampling works best for them.” (tłumaczenie) «Po pierwsze, elastyczne próbkowanie zastąpi First Click Free. Wydawcy są w najlepszej pozycji, aby określić, jaki poziom darmowego próbkowania działa dla nich najlepiej.» Przeczytaj ogłoszenie

John Mueller, Google — podcast Google (wrzesień 2025)

• O bramkach rejestracyjnych vs. płatnych: “It also doesn’t have to be something that’s behind a clear payment thing. It can just be something like a login or some other mechanism that basically limits the visibility of the content.” (tłumaczenie) «To nie musi być coś za wyraźną płatnością. Może to być po prostu logowanie lub inny mechanizm, który zasadniczo ogranicza widoczność treści.»
• O ostrożności z DOM/czytnikiem ekranu: “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.” (tłumaczenie) «upewnij się, że treść naprawdę nie jest ładowana do DOM strony, aby jeśli przeglądarka ma coś takiego jak… czytnik ekranu, czytnik ekranu nie odczytał całego tego tekstu, który próbujesz ukryć.»
• O prywatnych URL-ach: “if it’s private content, serve it with a noindex or redirect it to a login page somewhere. Don’t use robots.txt.” (tłumaczenie) «jeśli to prywatna treść, serwuj ją z noindex lub przekieruj na stronę logowania. Nie używaj robots.txt.» Pełny zapis (PDF)

John Mueller, Google — SEO office-hours (grudzień 2020)

• “Essentially you would use the rich results test, like any other kind of structured data. I think the tricky part with some of these paywall implementations is that Googlebot, of course, needs to be able to see the full content so that we can understand what it is that we should be showing your site for.” (tłumaczenie) «Zasadniczo użyłbyś testu wyników rozszerzonych, jak w przypadku każdego innego rodzaju danych strukturalnych. Myślę, że trudną częścią niektórych implementacji paywalli jest to, że Googlebot oczywiście musi widzieć pełną treść, abyśmy mogli zrozumieć, za co powinniśmy wyświetlać Twoją witrynę.» Relacja (Search Engine Journal)

Danny Sullivan, Google Search Liaison — wyjaśnienie „nieprzeciekającego” paywalla

• “Our system is looking to be shown the full content, if a publisher wants to do that. If they do, we understand more about it. If we understand more, then we might be able to show it for more queries where it’s relevant.” (tłumaczenie) „Nasz system oczekuje pokazania pełnej treści, jeśli wydawca chce to zrobić. Wtedy rozumiemy ją lepiej i możemy wyświetlać ją dla większej liczby trafnych zapytań.” Oraz: “Since only we are seeing this, there’s nothing ‘leaky’ as you are suggesting.” (tłumaczenie) „Skoro widzimy ją tylko my, nie ma tu żadnego »wycieku«, który sugerujesz.” Coverage (Search Engine Roundtable)

Który model paywalla jest mi potrzebny?

Implementacje paywalli różnią się głównie tym, jak blokujesz treść i co chcesz, aby było indeksowane. Przejdź przez to — liść powie Ci, jakie znaczniki (jeśli w ogóle) i jaka kontrola ma zastosowanie.

Czego nie robić z paywallami

1. Traktowanie First Click Free jako aktualnej polityki. Wiele nieaktualnych wpisów opisuje First Click Free tak, jakby nadal można było z niego korzystać. Google wycofał je w październiku 2017 roku i zastąpił elastycznym próbkowaniem. Rozwiązanie: projektuj treść w oparciu o licznik odsłon/lead-in i dane strukturalne; jeśli widzisz FCF cytowane jako aktualne wytyczne, ignoruj to.

2. Ukrywanie pełnego artykułu za pomocą JavaScript/CSS zamiast blokowania po stronie serwera. Wysyłanie całego artykułu w HTML i ukrywanie go do czasu zalogowania można obejść (wyłącz JS i treść jest czytelna), utrudnia Google rozpoznanie paywalla i sprawia, że czytniki ekranu odczytują „ukryty” tekst na głos. Rozwiązanie: potwierdzaj status subskrypcji/logowania na serwerze i wysyłaj pełną treść tylko autentykowanym użytkownikom — a następnie dodaj dane strukturalne na wierzch.

3. Zakładanie, że każdy paywall to cloaking. Polityka spamu Google wprost wyłącza paywalle z definicji cloakingu, pod warunkiem że pozwolisz Google zobaczyć pełną treść i zastosujesz się do wytycznych dotyczących elastycznego próbkowania. Rozwiązanie: nie ukrywaj treści przed Google ze strachu przed cloakingiem — zadeklaruj ją za pomocą znaczników, co jest dozwolonym mechanizmem.

4. Wiara w istnienie specjalnego robota „Googlebot Subscriber”. Kilka niskiej jakości poradników (prawdopodobnie jeden kopiowany przez inne) twierdzi, że musisz zezwolić na robota „Googlebot Subscriber” lub „Googlebot Registered User”. Taki user-agent nie istnieje — opublikowana przez Google lista robotów zawiera Googlebot, Googlebot-Image, Googlebot-Video i Googlebot-News, a nic związanego z subskrybentami. Rozwiązanie: zignoruj to; nie ma osobnego robota do dodania na listę dozwolonych.

5. Blokowanie prywatnych/adresów URL logowania za pomocą robots.txt. Adres URL zablokowany w robots może nadal być indeksowany jako goły, pozbawiony treści adres URL — często gorzej niż czysty noindex, i Mueller to potwierdza. Rozwiązanie: użyj noindex lub przekierowania dla prywatnych treści; zarezerwuj robots.txt do kontroli budżetu indeksowania, nie do usuwania z indeksu.

6. Cytowanie „minimalnego lead-inu 80 słów” jako polityki Google. Ta liczba krąży, jakby była oficjalna, ale nie prowadzi do żadnego dokumentu Google. Rzeczywiste ilościowe wytyczne Google dotyczą częstotliwości próbkowania (6–10 artykułów/miesiąc), a nie liczby słów lead-inu. Rozwiązanie: traktuj każdy limit słów jako niezweryfikowaną heurystykę praktyków, a nie politykę.

7. Zapominanie, że pokazanie Google pełnego tekstu wymaga kontroli pamięci podręcznej. Znaczniki paywalla pozwalają Googlebotowi zobaczyć pełny artykuł, ale zapisana w pamięci podręcznej kopia może wyciec do każdego, kto znajdzie pamięć podręczną. Rozwiązanie: dodaj noarchive/nocache (lub nagłówek X-Robots-Tag: noarchive), jeśli to problem — to osobna kontrola od znaczników paywalla.

Fragmenty kodu do sprawdzania konfiguracji paywalla

Praktyczne sprawdzenia, czy Twoje blokowanie i znaczniki faktycznie działają. Zamień https://example.com/article i .paywall na własne.

1. Czy pełny artykuł jest wysyłany w HTML? (test pułapki JS)

Jeśli Twoja płatna treść jest obecna w surowym odpowiedzi serwera, to nie jest naprawdę zablokowana — to tylko wizualnie ukryta. Pobierz HTML bez wykonywania JavaScript i poszukaj płatnego zdania.

macOS / Linux (curl + grep)

# Fetch the raw HTML (no JS execution) and look for a line that should be gated.
curl -s "https://example.com/article" | grep -i "a sentence only subscribers should see"
# Empty result = the gated text isn't in the raw HTML (good, server-side gated).
# A match = the full content is shipping to everyone and merely hidden (the JS trap).

Compare what Googlebot vs. a logged-out user receives

# As a normal visitor:
curl -s "https://example.com/article" -o guest.html
# Emulating Googlebot's user-agent (only meaningful if you serve UA-based content):
curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  "https://example.com/article" -o googlebot.html
# Diff the visible article body — Googlebot should get the full text under flexible sampling.
diff <(grep -o '<p>.*</p>' guest.html) <(grep -o '<p>.*</p>' googlebot.html)

2. Wyodrębnij i zweryfikuj dane strukturalne paywalla

Pobierz bloki JSON-LD za pomocą fragmentu w konsoli Chrome DevTools. Otwórz artykuł, otwórz DevTools → Konsola, wklej:

// Dump every JSON-LD block and flag paywall properties.
[...document.querySelectorAll('script[type="application/ld+json"]')]
  .map(s => { try { return JSON.parse(s.textContent); } catch { return null; } })
  .filter(Boolean)
  .forEach(obj => {
    const json = JSON.stringify(obj);
    if (json.includes('isAccessibleForFree') || json.includes('cssSelector')) {
      console.log('Paywall markup found:', obj);
    } else {
      console.log('JSON-LD (no paywall props):', obj['@type']);
    }
  });

Potwierdź, że cssSelector faktycznie pasuje do elementu (tylko selektory klasowe — #id i złożone selektory nie są obsługiwane):

// Paste your declared selector; it MUST match at least one element, and be a .class.
const sel = '.paywall';
console.log('Matches on page:', document.querySelectorAll(sel).length);
console.log('Is a class selector:', /^\.[\w-]+$/.test(sel)); // true = supported form

3. Zakładka: czy ta strona jest oznaczona jako ukryta?

Przeciągnij do zakładek ten jednolinijkowiec (lub wklej w pasku adresu), aby sprawdzić dowolny artykuł pod kątem isAccessibleForFree: false bez otwierania DevTools:

javascript:(()=>{const b=[...document.querySelectorAll('script[type="application/ld+json"]')].map(s=>s.textContent).join('');alert(b.includes('"isAccessibleForFree":false')||b.includes('"isAccessibleForFree": false')?'Gated: isAccessibleForFree:false present':'No paywall markup found on this page');})();

4. Potwierdź, że kopia w pamięci podręcznej nie przecieka (sprawdzenie noarchive)

# Check for a noarchive directive in the meta robots tag or the X-Robots-Tag header.
curl -s "https://example.com/article" | grep -i 'name="robots"'
curl -sI "https://example.com/article" | grep -i 'x-robots-tag'
# You want "noarchive" (or nocache) present if you don't want a cached copy exposing gated text.

Po tych krokach sprawdź aktywny URL w Rich Results Test jako Googlebot desktop i smartphone — to autorytatywne sprawdzenie, czy Google parsuje Twój isAccessibleForFree/cssSelector markup.

Objawy paywalla, przyczyny i rozwiązania

Rich Results Test nie waliduje ukrytej sekcji

Objaw: Aktywny URL nie pokazuje użytecznego znacznika treści za paywallem lub zgłoszony cssSelector nie identyfikuje ukrytej treści.

Prawdopodobna przyczyna: isAccessibleForFree brakuje lub jest ustawione niespójnie; hasPart jest nieprawidłowe; selektor używa ID lub złożonego selektora zamiast klasy; HTML nie zawiera zadeklarowanej klasy; lub Googlebot otrzymuje tylko teaser i nie może sprawdzić pełnej treści.

Rozwiązanie i potwierdzenie: Użyj isAccessibleForFree: false na treści i każdej ukrytej WebPageElement, wskaż każdy cssSelector na rzeczywistą klasę, taką jak .paywall, i udostępnij pełną treść równoważną subskrybentowi Googlebotowi przy elastycznym próbkowaniu. Uruchom ponownie aktywny URL w Rich Results Test jako smartphone i desktop, aż znacznik i ukryta sekcja będą parsowane zgodnie z zamierzeniem.

Wylogowane źródło zawiera pełny płatny artykuł

Objaw: Wyłączenie JavaScript, sprawdzenie HTML lub użycie czytnika ekranu ujawnia tekst, który widoczny paywall twierdzi, że jest niedostępny.

Prawdopodobna przyczyna: Serwer wysyła pełny artykuł wszystkim, a JavaScript lub CSS jedynie ukrywa go po załadowaniu strony.

Poprawka i potwierdzenie: Przenieś sprawdzanie uprawnień na serwer i wysyłaj pełny tekst dopiero po potwierdzeniu logowania/subskrypcji, jednocześnie nadal udostępniając Googlebotowi treść zgodnie z zadeklarowaną konfiguracją elastycznego próbkowania. Pobierz stronę bez logowania i z wyłączonymi skryptami, aby potwierdzić brak ukrytej treści; następnie zaloguj się i potwierdź, że pełny artykuł jest dostępny.

Wyniki wyszukiwania prowadzą głównie do gołej strony logowania

Objaw: Wyszukiwanie w trybie incognito marki/usługi pokazuje ogólną stronę logowania, a wiele prywatnych adresów URL sprowadza się do tej samej strony logowania bez treści.

Prawdopodobna przyczyna: Prywatne trasy przekierowują do jednej ogólnej strony bez kontekstu usługi, albo robots.txt blokuje prywatne adresy URL, jednocześnie pozwalając na indeksowanie gołych adresów.

Poprawka i potwierdzenie: Nadaj prawdziwym stronom logowania unikalny, kontekstowy tekst. W przypadku treści rzeczywiście prywatnych użyj uwierzytelniania oraz noindex lub celowego przekierowania do logowania, zamiast robots.txt jako mechanizmu kontroli indeksowania. Powtórz wyszukiwanie w trybie incognito i sprawdź reprezentatywne adresy URL, aby potwierdzić, że wynik jest informacyjny, a prywatne adresy URL nie pojawiają się jako gołe wpisy.

Google może indeksować tylko zajawkę

Objaw: Strona jest indeksowana, ale wydaje się istotna tylko dla wstępu, a nie dla tematu całego artykułu.

Prawdopodobna przyczyna: Googlebot otrzymuje tę samą krótką zajawkę co niezalogowany czytelnik, więc wyszukiwarka nie może zrozumieć ukrytej treści.

Poprawka i potwierdzenie: Wdróż elastyczne próbkowanie, aby zweryfikowany Googlebot mógł indeksować tę samą pełną treść, którą otrzymuje subskrybent, oznacz ukrytą sekcję danymi strukturalnymi i zweryfikuj działającą stronę. Po ponownym indeksowaniu użyj URL Inspection, aby potwierdzić, że Google może wyrenderować zamierzony artykuł; odzyskanie pozycji w wynikach nie jest natychmiastowym sygnałem weryfikacji.

Lista kontrolna uruchomienia paywalla

Model próbkowania i dostępu

• Świadomie wybierz licznik lub zajawkę; nie dziedzicz arbitralnego domyślnego ustawienia dostawcy.
• Jeśli używasz licznika, najpierw przetestuj próbkowanie miesięczne i potraktuj zakres 6–10 darmowych artykułów miesięcznie od Google jako punkt wyjścia, a nie uniwersalny nakaz.
• Monitoruj, jak często pojawia się paywall; Google twierdzi, że zadowolenie spada, gdy jest pokazywany częściej niż w 10 % przypadków.
• Googlebot ma dostęp do tej samej pełnej treści, którą otrzymuje uprawniony czytelnik, w ramach zadeklarowanej konfiguracji elastycznego próbkowania.

Znaczniki

• Najwyższy poziom Article, NewsArticle lub inny CreativeWork deklaruje isAccessibleForFree: false, gdy treść jest ukryta.
• Każda ukryta sekcja ma element hasPart typu WebPageElement z isAccessibleForFree: false.
• Każdy cssSelector używa rzeczywistego selektora klasy, takiego jak .paywall, a nie ID lub złożonego selektora potomnego.
• Wiele ukrytych sekcji to osobne, niezagnieżdżone wpisy hasPart.
• Ściany rejestracji używają tych samych znaczników paywalla co ściany płatnego dostępu.

Dostarczanie i prywatność

• Uprawnienia są egzekwowane po stronie serwera; HTML bez logowania nie zawiera ukrytego pełnego artykułu, który JavaScript lub CSS mógłby ujawnić.
• Odpowiedź mobilna zachowuje to samo poprawne ukrywanie i próbkowanie.
• Rzeczywiście prywatne adresy URL używają uwierzytelniania i noindex lub przekierowania do logowania, a nie robots.txt jako mechanizmu prywatności.
• Strony logowania zawierają przydatny, specyficzny dla usługi kontekst, a nie jedną ogólną stronę powieloną na każdej trasie.
• noarchive/nocache jest obecne tam, gdzie kopie w pamięci podręcznej nie mogą ujawniać ukrytego tekstu.

Dowód przed uruchomieniem

• Działający kandydat przechodzi walidację w Rich Results Test jako smartfon i komputer stacjonarny.
• Pobranie bez logowania i z wyłączonym JavaScript nie ujawnia pełnej ukrytej treści.
• Uwierzytelniona sesja otrzymuje kompletny artykuł.
• Wyszukiwanie marki/usługi w trybie incognito nie sprowadza witryny do gołego wyniku logowania.
• Analityka rejestruje zużycie licznika i ekspozycję na paywall bez uwzględniania prywatnego tekstu artykułu w danych zdarzeń.

Udowodnij, że paywall jest zadeklarowany i egzekwowany

Test ustrukturyzowanych danych paywalla

• Test do uruchomienia: Przetestuj działający adres URL w teście wyników rozszerzonych Google jako smartfon i komputer stacjonarny, sprawdzając isAccessibleForFree, hasPart i każdy cssSelector.
• Oczekiwany wynik: Google analizuje ograniczony CreativeWork, a każda zadeklarowana klasa mapuje się na zamierzoną sekcję ograniczoną, podczas gdy Googlebot ma dostęp do pełnego artykułu.
• Interpretacja błędu: Brakujące właściwości, niezgodności selektorów, nieprawidłowe zagnieżdżenie lub odpowiedź Googlebota zawierająca tylko zwiastun oznaczają, że deklaracja elastycznego próbkowania jest uszkodzona.
• Okno monitorowania: Natychmiast po każdym wdrożeniu szablonu lub dostawcy paywalla.
• Wyzwalacz wycofania: Produkcyjny szablon przestaje poprawnie deklarować lub ujawniać ograniczone treści w całym zestawie artykułów i nie można go naprawić przed szerokim wdrożeniem.

Test uprawnień po stronie serwera

• Test do uruchomienia: Pobierz ten sam artykuł wylogowany, z wyłączoną obsługą JavaScript, a następnie pobierz go w uwierzytelnionej sesji z uprawnieniami; dołącz sprawdzenie czytnika ekranu w odpowiedzi dla wylogowanych.
• Oczekiwany wynik: Wylogowani użytkownicy otrzymują tylko zamierzoną próbkę i nie mogą znaleźć ograniczonej treści w HTML/DOM, podczas gdy użytkownicy z uprawnieniami otrzymują pełny artykuł.
• Interpretacja błędu: Pełny tekst w odpowiedzi dla wylogowanych oznacza, że paywall ukrywa treść tylko po stronie klienta; brak tekstu po uwierzytelnieniu oznacza, że dostarczanie uprawnień zawodzi.
• Okno monitorowania: Natychmiast w środowisku testowym i produkcyjnym po każdej zmianie JavaScriptu paywalla, szablonu, pamięci podręcznej, CDN lub uwierzytelniania.
• Wyzwalacz wycofania: Nieuwierzytelnieni użytkownicy mogą pobrać pełny płatny artykuł lub uprawnieni czytelnicy masowo tracą dostęp po zmianie.

Test kontroli pamięci podręcznej i prywatnych adresów URL

• Test do uruchomienia: Sprawdź meta robots strony i X-Robots-Tag pod kątem noarchive lub nocache zgodnie z wymaganiami, a następnie sprawdź reprezentatywne, prawdziwie prywatne adresy URL pod kątem uwierzytelniania i zachowania noindex.
• Oczekiwany wynik: Kontrole kopii w pamięci podręcznej są obecne na ograniczonych artykułach tam, gdzie to zamierzone; prywatne adresy URL są chronione i nie polegają wyłącznie na robots.txt, aby zapobiec indeksowaniu.
• Interpretacja błędu: Brak dyrektyw pamięci podręcznej stwarza ryzyko wycieku kopii, podczas gdy blokada tylko przez robots może pozostawić goły prywatny adres URL kwalifikujący się do indeksowania.
• Okno monitorowania: Natychmiast po zmianach nagłówków, CDN, robots lub uwierzytelniania; sprawdź ponownie dotknięte szablony po wdrożeniu.
• Wyzwalacz wycofania: Wdrożenie ujawnia prywatne treści, usuwa kontrolę dostępu lub masowo czyni prywatne adresy URL indeksowalnymi i nie można go natychmiast poprawić.

Bieżące metryki elastycznego próbkowania

Wskaźnik wyświetlania paywalla

• Metryka: Odsetek wyświetleń kwalifikujących się treści, w których pokazywany jest paywall.
• Co mówi: Jak restrykcyjny jest model próbkowania w poszczególnych wizytach; jest to miara ekspozycji, którą Google bezpośrednio wiąże z zadowoleniem użytkowników.
• Jak to wyciągnąć: Podziel wyświetlenia bramki z serwera lub platformy paywallowej przez kwalifikujące się wyświetlenia artykułów, segmentując według kohorty użytkowników, źródła pozyskania i urządzenia.
• Punkt odniesienia / realistyczny zakres: Google twierdzi, że ogólne zadowolenie znacząco spada, gdy paywall jest pokazywany częściej niż 10% czasu, zazwyczaj eksponując około 3% odbiorców. Traktuj to jako górny limit ostrożnościowy i testuj względem własnych subskrybentów, modelu biznesowego i miksu artykułów.
• Częstotliwość: Co tydzień w przypadku nagłych zmian konfiguracji i co miesiąc dla stabilnego trendu; to wiodąca kontrola doświadczenia/monetyzacji.

Miesięczny limit darmowych artykułów i konsumpcja

• Metryka: Skonfigurowany miesięczny limit darmowych artykułów oraz rozkład liczby darmowych artykułów konsumowanych przez użytkowników przed napotkaniem płatnej zapory.
• Co Ci to mówi: Czy licznik daje czytelnikom wystarczającą próbkę, aby zrozumieli produkt, jednocześnie docierając do monitu o subskrypcję.
• Jak to pobrać: Użyj dzienników licznika po stronie serwera lub platformy paywall, pogrupowanych według anonimowej tożsamości licznika i miesiąca; podaj skonfigurowany limit wraz z percentylami konsumpcji.
• Benchmark / realistyczny zakres: Google zaleca 10 artykułów miesięcznie jako punkt wyjścia do eksploracji i oczekuje 6–10 na użytkownika miesięcznie dla większości wydawców codziennych wiadomości. To zakres wyjściowy, a nie nakaz dla każdej publikacji.
• Częstotliwość: Miesięcznie, zgodnie z zalecanym okresem licznika; przeglądaj po celowych eksperymentach z limitem, a nie reagując na codzienny szum.

Sprawdź się: Paywalle a SEO

Pięć szybkich pytań o utrzymywanie treści za paywallem w indeksie bez cloakingu. Wybierz odpowiedź na każde, a następnie sprawdź.

Dziennik zmian