robots.txt odpowiada na pytanie: kogo wpuszczam i dokąd. To wystarczało przez trzydzieści lat, gdy crawlerów było kilku, a celem ich wizyty było jedno — indeksowanie do wyników wyszukiwania, które odsyłały użytkowników z powrotem na stronę.
Era agentów AI rozbiła ten model. Crawler dziś może odwiedzić twoją stronę po to, by wytrenować na niej model językowy, który będzie z nią konkurował. Może odwiedzić, by zasilić odpowiedź generative search, która użytkownikowi nie pokaże już linku do twojej strony. Może odwiedzić, by zaindeksować klasyczną wyszukiwarkę, która wciąż odsyła ruch. Trzy różne rodzaje użycia tej samej treści, z trzech różnych powodów, o trzech różnych konsekwencjach dla właściciela strony.
robots.txt klasyczny tego nie różnicuje. Allow albo Disallow — wszystko albo nic, na poziomie dostępu. Co dzieje się podostępie, było poza zasięgiem standardu.
Tę lukę wypełnia Content Signals.
Skąd Content Signals się wzięły
Inicjatywa została opublikowana 24 września 2025 roku przez Cloudflare, z dokumentacją na contentsignals.org i propozycją włączenia do prac IETF nad standardem AI Preferences (aipref). Tekst polityki został udostępniony pod licencją CC0, co oznacza, że każdy — nie tylko klient Cloudflare — może go zaadaptować bez ograniczeń.
Cloudflare uzasadnia powstanie standardu klasycznym problemem free-ridera. Domyślny układ internetu zakładał wymianę: bot pobiera treść, w zamian odsyła ruch albo daje atrybucję. Tę zasadę utrwalały licencje Creative Commons i MIT, które wymuszały atrybucję jako warunek użycia. W erze agentów ta wymiana przestała być symetryczna. Treść jest pobierana, ale ruch nie wraca. Atrybucja często znika. Pobrana treść może następnie być używana do trenowania modeli, które konkurują z jej autorem.
Content Signals jest odpowiedzią na to przesunięcie. Nie zmienia mechaniki crawlowania. Dodaje warstwę, w której właściciel strony może powiedzieć: „możesz pobrać, ale nie możesz użyć do X”.
Trzy sygnały
Standard definiuje trzy konkretne sygnały, każdy o precyzyjnym zakresie. Precyzja jest tu celowa — sygnały są wąskie, by boty mogły je przestrzegać bez interpretacji i bez wymówek typu „nie wiedzieliśmy, co właściciel miał na myśli”.
search — „budowanie indeksu wyszukiwania i zwracanie wyników wyszukiwania, na przykład hiperlinków i krótkich fragmentów z zawartości twojej strony”. To jest klasyczne SEO. Bot pobiera treść, indeksuje, użytkownik widzi link, klika, wraca na twoją stronę. Modelu wymiany sprzed ery AI. Co istotne — search w definicji standardu nie obejmujegenerowania odpowiedzi AI typu AI Overviews w Google czy podsumowań w Perplexity. Te są osobnym sygnałem.
ai-input — „wprowadzanie treści do jednego lub więcej modeli AI, na przykład retrieval-augmented generation, grounding, lub innego pobierania treści w czasie rzeczywistym dla generatywnych odpowiedzi wyszukiwania”. To jest RAG — agent pobiera twoją treść w momencie odpowiedzi użytkownikowi, używa jej jako kontekstu, generuje odpowiedź. Użytkownik nie widzi twojego linku — widzi gotową odpowiedź modelu. Klasyczny przypadek to AI Overviews w Google, ChatGPT z włączonym browsing, Perplexity, Claude z connectors do MCP.
ai-train — „trenowanie lub fine-tuning modeli AI”. To jest najgłębszy poziom użycia. Twoja treść staje się częściąmodelu — nie jest pobierana w momencie zapytania, jest wpleciona w wagi modelu, użyta do nauki wzorców, generowania odpowiedzi w przyszłości bez bezpośredniego pobierania.
Trzy sygnały, trzy różne zastosowania, trzy różne decyzje dla właściciela strony. Można pozwalać na search, blokować ai-input, zezwalać na ai-train — każda kombinacja jest dopuszczalna i ma swoje uzasadnienia biznesowe.
Składnia w robots.txt
Content Signals są linią w robots.txt, obok User-Agent, Allow i Disallow. Nie nagłówkiem HTTP, nie meta tagiem — wpisem w pliku tekstowym, który już od trzydziestu lat funkcjonuje pod adresem /robots.txt.
Konkretny przykład — strona, która chce pozwolić na wyszukiwanie, zablokować trening i nie wyrazić preferencji wobec ai-input:
User-Agent: *
Content-Signal: search=yes, ai-train=no
Allow: /Wartości to wyłącznie yes lub no. Składnia comma-delimited. Sygnał można pominąć — i to ma znaczenie semantyczne, do którego zaraz wrócimy.
Pełna deklaracja zawiera dodatkowo blok komentarzy, który jest częścią standardu — Cloudflare zaleca ich włączenie, by interpretacja była jednoznaczna dla każdego, kto czyta plik. Komentarze są ignorowane przez boty, ale stanowią human-readable część polityki, do której bot może być prawnie odwołany:
# As a condition of accessing this website, you agree to abide by the following content signals:
# (a) If a content-signal = yes, you may collect content for the corresponding use.
# (b) If a content-signal = no, you may not collect content for the corresponding use.
# (c) If the website operator does not include a content signal for a corresponding use,
# the website operator neither grants nor restricts permission via content signal
# with respect to the corresponding use.
#
# The content signals and their meanings are:
# search: building a search index and providing search results
# (e.g., returning hyperlinks and short excerpts).
# Search does not include providing AI-generated search summaries.
# ai-input: inputting content into one or more AI models
# (e.g., retrieval augmented generation, grounding).
# ai-train: training or fine-tuning AI models.
User-Agent: *
Content-Signal: search=yes, ai-train=no
Allow: /Brak sygnału ≠ brak preferencji
To jest rozróżnienie, które w samej polityce Cloudflare jest wprost wyłożone, ale na pierwszy rzut oka łatwo je przegapić. Cytat z oficjalnej dokumentacji: „Jeśli operator strony pomija sygnał content dla danego zastosowania, nie oznacza to, że nie ma preferencji w sprawie tego użycia. Oznacza tylko, że nie wykorzystał tej części pliku robots.txt do jej wyrażenia”.
Trzy stany, nie dwa.
search=yes — pozwalam. search=no — zabraniam. Brak search — nie deklaruję, ani nie pozwalam, ani nie zabraniam przez ten kanał. Zachowuję sobie prawo wyrażenia tej preferencji innym sposobem.
Trzeci stan ma znaczenie prawne. Brak deklaracji nie oznacza domyślnej zgody — oznacza brak deklaracji. Operator, który chce być neutralny, jest neutralny. Operator, który chce zezwolić, deklaruje yes. Operator, który chce zablokować, deklaruje no. Każdy stan jest świadomy.
To jest celowy projekt. Pozwala na ekspresję preferencji wobec jednego sygnału, bez wymuszenia ekspresji wobec pozostałych dwóch.
Stan adopcji w 2026
Content Signals są mechanizmem młodym, ale rozwijają się szybko.
Po stronie Cloudflare: managed robots.txt jest włączony na ponad 3,8 miliona domen klientów Cloudflare. Każda z nich domyślnie serwuje deklarację Content-Signal: search=yes, ai-train=no. Cloudflare celowo nie ustawia ai-input w tej domyślnej konfiguracji — uzasadniając to tak: „nie znamy preferencji klienta, nie chcemy zgadywać”.
Po stronie standardów branżowych: prowadzone są prace w IETF nad grupą roboczą AI Preferences (aipref), która ma zaproponować formalny standard. Content Signals są jedną z propozycji, którymi grupa się zajmuje. Cloudflare, publikując politykę pod CC0, wprost zaprosił innych dostawców do dyskusji nad wspólnym standardem.
Po stronie integracji: Liferay opublikował przewodnik dodawania Content Signals do swoich szablonów robots.txt. W projekcie Vercel/Next.js toczy się dyskusja nad oficjalnym wsparciem dla Content Signals w API generowania robots.txt — z propozycją typu RobotsFile.contentSignal.
Po stronie respektowania: tu sytuacja jest jeszcze niejasna. Cloudflare otwarcie przyznaje: „content signals to preferencje, nie techniczne środki przeciwdziałania scrapowaniu. Niektóre firmy mogą je po prostu zignorować”. Powstaje sytuacja podobna do robots.txt klasycznego — sygnał działa tylko wobec aktorów, którzy chcą go honorować. Wobec atakujących, którzy nie chcą — pozostają mechanizmy techniczne (WAF, Bot Management, AI Crawl Control).
Po stronie Google: Google Search Console okazjonalnie raportuje „Syntax not understood” dla Content-Signal. Cloudflare deklaruje, że nie ma to wpływu na crawl rate, ale jest to znak, że w narzędziach Google’a wsparcie dla nowej dyrektywy jeszcze nie jest pełne.
Content Signals a robots.txt klasyczny
Te dwa mechanizmy nie konkurują. Działają na różnych warstwach decyzji.
robots.txt — „czy bot może wejść”. Decyzja na poziomie crawlowania. Allow / Disallow. Działa zanim bot wykona zapytanie.
Content Signals — „do czego bot może użyć tego, co już zobaczył”. Decyzja na poziomie wykorzystania. yes / no per sygnał. Działa po crawlowaniu, w decyzji o tym, jak wykorzystać pobraną treść.
Konfiguracja, która ma sens dla większości stron w 2026, używa obu warstw razem — Disallow dla wybranych user-agentów, plus Content-Signal dla wszystkich pozostałych. Przykład:
# Bot OpenAI — pełen dostęp i pełna zgoda
User-Agent: GPTBot
Content-Signal: search=yes, ai-input=yes, ai-train=yes
Allow: /
# CCBot — Common Crawl, blokujemy całkowicie
User-Agent: CCBot
Disallow: /
# Wszyscy pozostali — Content Signals jako preferencja
User-Agent: *
Content-Signal: search=yes, ai-train=no
Allow: /
Disallow: /wp-admin/
Sitemap: https://twojadomena.pl/sitemap_index.xmlW tym przykładzie GPTBot ma jasno wyłożone wszystkie zgody. CCBot nie ma dostępu w ogóle. Wszyscy inni dostają deklarację — pozwalamy na wyszukiwanie, blokujemy trening, ai-input pozostaje niezadeklarowany jako świadoma decyzja.
Content Signals a llms.txt
Content Signals i llms.txt rozwiązują różne problemy, choć oba dotyczą dostępu agentów AI.
Content Signals — „kogo wpuszczam i do czego może użyć”. Polityka. Bramkarz.
llms.txt — „co tu masz i jak to rozumieć”. Mapa. Przewodnik.
Plik llms.txt nie zastępuje Content Signals. llms.txt mówi modelom językowym: „oto skondensowane wprowadzenie do mojej strony, oto najważniejsze sekcje, oto co warto wiedzieć”. Content Signals mówi tym samym modelom: „oto co możesz robić z tym, co przeczytasz”. Pierwsze ułatwia. Drugie reguluje.
Strona w pełni przygotowana na agentów ma oba pliki. robots.txt z Content Signals reguluje, kto może wejść i do czego użyć. llms.txt ułatwia tym, którzy weszli, znaleźć to, czego szukają.
Content Signals a inne mechanizmy ekspresji preferencji wobec AI
Content Signals nie są pierwszym mechanizmem, który próbuje rozwiązać problem ekspresji preferencji wobec użycia treści przez AI. W ostatnich latach pojawiło się kilka konkurujących propozycji — różnie dojrzałych, różnie adoptowanych, o różnych zakresach. Warto je nazwać, żeby zrozumieć, w jakim kontekście Content Signals funkcjonuje.
noai i noimageai jako meta tagi
Najprostszy mechanizm. Pojawił się głównie w 2022-2023 roku w społecznościach artystów cyfrowych (DeviantArt, ArtStation) jako odpowiedź na trenowanie modeli generowania obrazów (Stable Diffusion, Midjourney). Składnia jest klasyczną meta-tagiem HTML:
<meta name="robots" content="noai, noimageai">Sygnalizuje „nie używaj treści tej strony do trenowania modeli AI” (noai) oraz „nie używaj obrazów” (noimageai). Mechanizm prosty, łatwy do wdrożenia, ale o ograniczonej adopcji — głównie w niszy artystycznej. Nie różnicuje typuużycia (search/RAG/training), działa jako pojedynczy sygnał blokujący.
TDM Reservation Protocol (TDMRep)
Bardziej formalna propozycja z 2022 roku, opracowana w ramach W3C Community Group i wprost oparta na Artykule 4 Dyrektywy UE 2019/790. Używa trzech warstw deklaracji jednocześnie — pliku .well-known/tdmrep.json, nagłówków HTTP (tdm-reservation: 1) oraz meta tagów HTML. Implementacja istnieje w wybranych europejskich serwisach prasowych i wydawnictwach. Bardziej prawnie ukierunkowana niż Content Signals, ale operacyjnie cięższa do wdrożenia (trzy warstwy zamiast jednej linii).
ai.txt
Propozycja Spawning AI z 2023 roku, wzorowana na robots.txt, ale dedykowana wyłącznie AI. Plik tekstowy w katalogu głównym domeny, ze składnią analogiczną do robots.txt:
User-Agent: *
Disallow: /artwork/Adopcja głównie w niszy artystycznej (Have I Been Trained, Spawning ecosystem). Plus tej propozycji — niezależność od robots.txt, czysty namespace dla AI. Minus — kolejny plik, który trzeba utrzymywać, plus żaden duży operator modelu nie zadeklarował publicznie respektowania.
X-Robots-Tag w nagłówkach HTTP
Mechanizm Google, istniejący od dawna jako sposób na wyrażenie dyrektyw indeksowania w nagłówkach HTTP odpowiedzi (zamiast w meta tagach HTML). Został rozszerzony o dyrektywy noai, noimageai. Przykład:
X-Robots-Tag: noai, noimageaiPlus — działa na poziomie HTTP, więc obejmuje też zasoby nie-HTML (PDFy, JSON, obrazy). Minus — wymaga konfiguracji serwera, mniej widoczne niż meta tagi czy robots.txt.
Dlaczego Content Signals są inne
Trzy cechy Content Signals, których pozostałe mechanizmy nie mają w komplecie.
Po pierwsze — różnicowanie typów użycia. noai/noimageai i ai.txt są monolityczne: wszystko albo nic. Content Signals rozdzielają trzy kategorie (search/ai-input/ai-train), pozwalając na świadomy wybór per kategoria.
Po drugie — standaryzacja w robots.txt. Pozostałe mechanizmy wymagają nowego pliku (ai.txt, tdmrep.json), nowych meta tagów lub nagłówków HTTP. Content Signals są linią w pliku, który już obsługujesz.
Po trzecie — droga do standardu IETF. Content Signals są jedną z propozycji w pracach grupy roboczej AI Preferences (aipref). To nie gwarantuje, że staną się standardem, ale wskazuje poważne zaplecze instytucjonalne, którego pozostałe propozycje nie mają.
W praktyce te mechanizmy mogą współistnieć. Strona, która chce być maksymalnie wyraźna, może mieć Content Signals w robots.txt, meta tag noai w HTML, plus X-Robots-Tag w nagłówkach. Każdy mechanizm trafia do trochę innej kategorii botów, każdy jest redundantnym sygnałem dla tych, którzy honorują tylko jeden ze standardów.
Article 4 Dyrektywy UE 2019/790
Polityka Cloudflare zawiera explicit klauzulę prawną:
„JAKIEKOLWIEK OGRANICZENIA WYRAŻONE PRZEZ CONTENT SIGNALS SĄ WYRAŹNYMI ZASTRZEŻENIAMI PRAW NA PODSTAWIE ARTYKUŁU 4 DYREKTYWY UNII EUROPEJSKIEJ 2019/790 W SPRAWIE PRAW AUTORSKICH I PRAW POKREWNYCH NA JEDNOLITYM RYNKU CYFROWYM”.
Artykuł 4 wspomnianej dyrektywy reguluje text and data mining (TDM) jako wyjątek od praw autorskich — z istotnym zastrzeżeniem: „właściciel praw może wyrazić zastrzeżenie wobec użycia jego treści dla celów TDM w odpowiedni sposób, w szczególności przez maszynowo czytelne środki w przypadku treści udostępnionych publicznie w sieci”.
Content Signals z deklaracją ai-train=no jest takim „maszynowo czytelnym środkiem”. To znaczy, że dla treści dostępnych w UE i jej rynku, deklaracja ai-train=no ma potencjalnie umocowanie prawne — nie jest tylko „prośbą o nieużywanie”, ale „wyrażonym zastrzeżeniem prawa”.
To jest istotny punkt dla polskich autorów i właścicieli stron. Dyrektywa UE jest implementowana w polskim prawie autorskim. Content Signals z deklaracją ai-train=no na polskiej stronie to nie tylko sygnał techniczny — to prawnie znaczący akt zastrzeżenia praw wobec text and data mining.
To nie znaczy, że żaden bot nie zignoruje deklaracji. Znaczy, że jeśli zignoruje — autor strony ma podstawę prawną, której bez Content Signals by nie miał.
Praktyczna konfiguracja na 2026
Rekomendowana minimalna konfiguracja dla typowej strony w polskim rynku, która chce być widoczna w wyszukiwaniu, ale chronić treść przed użyciem do trenowania modeli:
# As a condition of accessing this website, you agree to abide by the following content signals:
# (a) If a content-signal = yes, you may collect content for the corresponding use.
# (b) If a content-signal = no, you may not collect content for the corresponding use.
# (c) If the website operator does not include a content signal for a corresponding use,
# the website operator neither grants nor restricts permission via content signal
# with respect to the corresponding use.
#
# The content signals and their meanings are:
# search: building a search index and providing search results.
# Does NOT include AI-generated search summaries.
# ai-input: inputting content into AI models (RAG, grounding, generative search).
# ai-train: training or fine-tuning AI models.
#
# ANY RESTRICTIONS EXPRESSED VIA CONTENT SIGNALS ARE EXPRESS RESERVATIONS OF RIGHTS
# UNDER ARTICLE 4 OF THE EUROPEAN UNION DIRECTIVE 2019/790.
User-Agent: *
Content-Signal: search=yes, ai-train=no
Allow: /
Disallow: /wp-admin/
Disallow: /wp-login.php
Sitemap: https://twojadomena.pl/sitemap_index.xmlKonfiguracja zezwala na klasyczne wyszukiwanie, blokuje używanie do trenowania modeli, pomija deklarację wobec ai-input — pozostawiając tę kwestię świadomie nierozstrzygniętą do późniejszej decyzji.
Brak decyzji to też decyzja
Jak w przypadku robots.txt klasycznego — właściciel strony, który nie ma świadomej polityki Content Signals, w praktyce decyduje się na brak deklaracji. Bot może zinterpretować to na różne sposoby — Cloudflare deklaruje, że brak sygnału neither grants nor restricts, ale nie wszyscy operatorzy modelu będą tej interpretacji się trzymać.
Im więcej dużych stron przyjmuje konkretne deklaracje, tym bardziej brak deklaracji zaczyna być traktowany jako anomalia. W ciągu kolejnych miesięcy 2026 prawdopodobnie zobaczymy, jak modele językowe zaczynają traktować brak Content Signals jako sygnał sam w sobie — nie zawsze korzystny dla właściciela strony.
Decyzja, którą strona podejmuje teraz, gdy mechanizm jest świeży, ma większe znaczenie niż decyzja podjęta za rok. Jest częścią ustanawiania zasad — nie tylko reagowania na nie.
Źródła: contentsignals.org, blog Cloudflare 2025-09-24 (Will Allen — „Giving users choice with Cloudflare’s new Content Signals Policy”), dokumentacja Cloudflare „managed robots.txt”, IETF AI Preferences (aipref) working group