przez lata właściciel strony wpuszczał robota wyszukiwarki z dość prostego powodu: liczył, że później przyjdą za nim ludzie. publikujemy tekst, wyszukiwarka go znajduje, ktoś szuka odpowiedzi, trafia do nas i przy okazji widzi reklamę, kupuje produkt albo zapisuje się na newsletter. w takim układzie samo przeczytanie strony przez bota było kosztem pozyskania potencjalnego czytelnika. płaciliśmy transferem i serwerem, a w zamian dostawaliśmy szansę na wizytę.
ale jeśli system ai pobiera nasz tekst, wyciąga z niego odpowiedź i pokazuje ją użytkownikowi u siebie, ta ostatnia część może się nie wydarzyć. informacja została wykorzystana, ktoś dostał wartość, a my niekoniecznie dostaliśmy wizytę.
pay per crawl jest próbą postawienia w tym miejscu cennika.
chcesz pobrać treść mojej strony? możesz, ale dostęp kosztuje
cloudflare uruchomił pay per crawl w prywatnej becie w lipcu 2025 roku. w dokumentacji dostępnej podczas pisania tej notatki funkcja nadal jest oznaczona jako zamknięta beta. umożliwia właścicielom stron pobieranie opłat od crawlerów ai za dostęp do treści, przy czym crawler to po prostu program, który odwiedza strony i pobiera ich zawartość.
w tym modelu crawler może dostać odpowiedź „402 payment required” z informacją o cenie. jeśli obsługuje mechanizm płatności i akceptuje warunki, może uzyskać treść. cloudflare dostarcza infrastrukturę i występuje jako merchant of record, czyli podmiot obsługujący sprzedaż i rozliczenie transakcji.
dla poszczególnych crawlerów właściciel może wybrać darmowy dostęp, pobieranie opłat albo blokadę. samo ustawienie „charge” nie sprawi jednak, że dowolnemu botowi automatycznie zejdą pieniądze z konta. operator musi uczestniczyć w obsługiwanym systemie rozliczeń, a bez tego płatna bramka może oznaczać po prostu brak dostępu.
to ważne, bo bardzo łatwo przerobić ten temat na „włącz opcję i zarabiaj na wszystkich botach, które cię scrapują”. niestety, jeszcze nie taki bankomat xd
za co dokładnie płaci bot?
w pay per crawl jednostką rozliczenia jest pobranie treści. ponowne pobranie tej samej strony również może zostać naliczone, błędne odpowiedzi nie są rozliczane, a wybrane techniczne ścieżki, takie jak robots.txt, pozostają darmowe.
to nie jest licznik tego, ile razy model później wspomniał o nas w odpowiedzi. nie jest to też pomiar wpływu naszego artykułu na wytrenowany model. pobranie strony, użycie jej podczas przygotowywania odpowiedzi i wykorzystanie danych do treningu to trzy różne zdarzenia, a samo naliczenie opłaty za pierwsze nie daje nam automatycznie wiedzy o pozostałych.
i właśnie tutaj zaczyna się największy problem ekonomiczny tego pomysłu. wyobraźmy sobie dwa teksty. pierwszy bot pobiera raz, a zawarte w nim informacje okazują się przydatne przy tysiącach pytań. drugi pobiera regularnie, ale praktycznie nigdy nie wykorzystuje go w odpowiedzi. jeżeli rozliczamy same pobrania, drugi może zarobić więcej od pierwszego.
czyli znaleźliśmy zdarzenie, które stosunkowo łatwo policzyć. nadal niekoniecznie znaleźliśmy dobry sposób wyceny wartości.
dlaczego przyszłość tego tematu może wyjść poza samo pay per crawl
cloudflare już rozwija równolegle pay per use. według opublikowanego opisu model jest w becie i działa inaczej: kupujący proponuje cenę za określony sposób wykorzystania treści, wydawca może zaakceptować ofertę, a kupujący raportuje użycia, które cloudflare rozlicza. pay per crawl pobiera opłatę za dostęp, a pay per use próbuje rozliczać późniejsze wykorzystanie. to nie jest więc wyłącznie moja prognoza, że ktoś kiedyś zauważy różnicę, bo dostawca tej infrastruktury już ją uwzględnia.
tylko że wraz z tą zmianą pojawia się następne pytanie: jak sprawdzimy, czy wszystkie użycia zostały poprawnie zaraportowane? przy pobraniu możemy zaobserwować żądanie i dostarczenie treści. późniejsze wykorzystanie może odbywać się już w systemie kupującego, do którego nie mamy wglądu.
moim zdaniem rozliczanie użycia będzie wymagało równie dużo pracy nad zaufaniem, definicjami i weryfikacją, co nad samą płatnością. trzeba przecież ustalić, jakie zdarzenie oznacza „użycie” i co zrobić, gdy obie strony liczą je inaczej.
dlaczego ktoś miałby zapłacić właśnie nam?
możliwość ustawienia ceny nie tworzy popytu. jeśli mamy kolejny artykuł powtarzający informacje dostępne w stu innych miejscach, operator może uznać, że łatwiej pominąć naszą stronę i pobrać to samo gdzie indziej za darmo.
inna sytuacja jest wtedy, gdy publikujemy własne pomiary, aktualizowaną bazę danych, wyniki testów albo informacje, których nikt inny nie zbiera. wyobraźmy sobie bazę rzeczywistych cen transakcyjnych w wąskiej branży. albo regularne testy sprzętu wykonywane tą samą metodą. albo lokalne dane, których zebranie wymaga kontaktu z dziesiątkami firm. tutaj kupujący może płacić za oszczędność pracy i dostęp do czegoś trudnego do zastąpienia.
moja hipoteza jest taka, że w takim rynku większą szansę mają własne, aktualne i wiarygodne informacje, a nie sama duża liczba podstron. szczególnie interesująca jest aktualność. jeśli wartość danych szybko się zmienia, istnieje powód, żeby wracać po następne. przy statycznym tekście potrzeba kolejnego pobrania może być znacznie mniejsza, a razem z nią przychód.
czy to znaczy, że powinniśmy schować wszystkie treści przed ai?
decyzja zależy od tego, na czym strona zarabia. jeśli publikujemy poradniki, żeby pozyskiwać klientów na usługę, obecność w odpowiedziach ai może mieć wartość nawet bez bezpośredniej opłaty za pobranie. wtedy trzeba porównywać przychód z dostępu z tym, co potencjalnie tracimy przez ograniczenie widoczności. jeśli naszym produktem są same dane, rachunek może wyglądać zupełnie inaczej.
sensowny wydaje mi się też model mieszany: część informacji dostępna bezpłatnie, żeby dało się ocenić źródło, a najcenniejsze zasoby płatne. technicznie cloudflare rozwija takie możliwości. w czerwcu 2026 dodał konfigurację pozwalającą wyłączać opłaty dla wybranych ścieżek oraz dynamicznie ustalać ceny, więc nie jesteśmy ograniczeni do jednego cennika na wszystko.
ale najpierw musi się zgadzać ekonomia. przykładowo: przy cenie 0,001 dolara za pobranie milion płatnych pobrań daje 1000 dolarów przed kosztami i potrąceniami.
słowo „płatnych” robi tutaj całą robotę. milion żądań widocznych w logach nie oznacza miliona zakupów. po postawieniu bramki część ruchu może zniknąć, a operatorzy zaczną dokładniej wybierać, co i jak często pobierają.
kim staje się właściciel strony
najciekawsza zmiana dotyczy więc tego, kim staje się właściciel strony. może być jednocześnie wydawcą dla ludzi i dostawcą informacji dla oprogramowania. człowiek przeczyta artykuł, zapisze się na newsletter i wróci za tydzień. agent kupi dostęp do danych potrzebnych do wykonania konkretnego zadania i pójdzie dalej.
dla mnie to łączy się z tematem płatności między agentami. żeby agent wykonał pracę, potrzebuje narzędzi i informacji, a za jedne i drugie może płacić w ramach przyznanych mu uprawnień.
nie zakładałbym jednak, że wygra jeden model rozliczeń. spodziewam się mieszanki darmowego dostępu, płatnych pobrań, opłat za użycie oraz umów na większe zbiory danych.
pay per crawl jest jednym ze sposobów postawienia warunków przy wejściu. o tym, czy powstanie z tego dobry biznes, zdecyduje to, co mamy za tym wejściem. bo bot, który zobaczy cenę, ma jeszcze jedną opcję.
może pójść gdzie indziej.