Content Signals w robots.txt — powiedz agentom AI co mogą zrobić z Twoją treścią

Artykuł 1 — czym jest agent-readiness i dlaczego większość stron WordPress startuje z 0/100

Artykuł 2 — rel="service-doc", strona /dla-agentow i pułapka LiteSpeed cache

Artykuł 3 — Markdown for Agents bez Cloudflare Pro i krytyczna pułapka z Vary: Accept

Artykuł 4 — Content Signals w robots.txt i dlaczego kolejność dyrektyw ma znaczenie

Artykuł 5 — JSON API z WordPress CPT i dwa domyślne błędy REST API

Artykuł 6 — diagnostyka przez curl, pełny raport w jednej chwili

Masz już sygnał dla agentów i efektywne serwowanie treści. Zostało jedno pytanie które agent zadaje zanim zacznie Cię cytować: co mi wolno?

Czy mogę użyć tej treści jako kontekstu do odpowiedzi? Czy mogę trenować na niej modele? Czy właściciel w ogóle wie że tu jestem i zgadza się na to?

Bez deklaracji z Twojej strony — agent zgaduje. Albo stosuje domyślną politykę platformy która może być bardziej restrykcyjna niż byś chciał.

Content Signals to standard który rozwiązuje ten problem. Trzy dyrektywy w robots.txt, pięć minut pracy.

Czym są Content Signals

Content Signals to standard w trakcie standaryzacji przez IETF — Draft RFC opisujący sposób deklarowania preferencji właściciela treści wobec systemów AI.

Cloudflare jest jednym z pierwszych dostawców który go wdrożył — ich narzędzie do oceny agent-readiness sprawdza obecność tych dyrektyw jako jeden z warunków Bot Access Control 100/100.

Mechanizm jest prosty: dodajesz do robots.txt dyrektywę Content-Signal z deklaracją dla trzech obszarów:

Content-Signal: ai-train=yes, search=yes, ai-input=yes

Każda wartość to deklaracja dla innego typu użycia Twojej treści.

Trzy wartości — co każda oznacza

ai-train — czy Twoja treść może być używana do trenowania modeli AI.

yes oznacza że zgadzasz się żeby systemy AI uczyły się na Twojej treści. no oznacza że nie.

To jest decyzja biznesowa i światopoglądowa jednocześnie. Argumenty za yes: Twoja treść wpływa na to jak modele rozumieją dany temat — jeśli jesteś ekspertem, to wpływ może być pozytywny. Argumenty za no: Twoja praca jest Twoja i nie chcesz jej oddawać za darmo firmom trenującym komercyjne modele.

Nie ma jednej właściwej odpowiedzi. WebFlux.pl wybrał yes — portal o agentic web który blokuje AI byłby lekko niespójny. Ale to Twoja decyzja.

search — czy Twoja treść może być indeksowana przez wyszukiwarki i systemy AI search.

Prawie zawsze yes. no oznacza że chcesz zniknąć z wyników — co jest rzadko pożądane dla portalu który żyje z ruchu organicznego.

ai-input — czy agenci mogą używać Twojej treści jako kontekstu do generowania odpowiedzi.

To jest kluczowe z perspektywy agent-readiness. yes oznacza że gdy agent szuka informacji o danym temacie i trafi na Twoją stronę — może ją przeczytać, przetworzyć i użyć jako podstawy do odpowiedzi. Może Cię cytować.

no oznacza że agent powinien pominąć Twoją treść. Jeśli chcesz być widoczny dla agentów — to musi być yes.

Implementacja w WordPress

Są dwa sposoby — przez Yoast lub przez kod.

Opcja 1: Yoast SEO — edytor plików

Jeśli używasz Yoast SEO (a większość stron WordPress tak):

1. WP Admin → SEO → Narzędzia → Edytor plików
2. Wybierz robots.txt
3. Dodaj na końcu pliku:

Content-Signal: ai-train=yes, search=yes, ai-input=yes

4. Zapisz

Opcja 2: functions.php

Jeśli wolisz mieć to w kodzie:

add_filter('robots_txt', function($output) {
    $output .= "\nContent-Signal: ai-train=yes, search=yes, ai-input=yes\n";
    return $output;
});

Obie opcje dają ten sam wynik. Różnica jest tylko w tym gdzie trzymasz konfigurację.

Pułapka: kolejność ma znaczenie

Tu jest rzecz której nie znajdziesz w dokumentacji Content Signals — bo standard jest nowy i nikt jeszcze tego dobrze nie opisał.

Jeśli Content-Signal trafi przed pierwszym blokiem User-agent w pliku — część parserów robots.txt może zignorować całość lub zachować się nieprzewidywalnie.

Standard robots.txt zakłada że plik zaczyna się od komentarzy (#) lub bloków User-agent. Nieznana dyrektywa przed pierwszym User-agent to dla rygorystycznych parserów błąd składniowy.

Gdy użyjesz filtra robots_txt w WordPress który dodaje dyrektywę przez $output .= "\nContent-Signal..." — dopisuje ją na końcu pliku, po bloku Yoast. To jest bezpieczne miejsce.

Problem pojawia się gdy dodasz Content-Signal ręcznie na początku pliku lub gdy plugin zrobi to w złej kolejności.

Właściwa struktura:

# START YOAST BLOCK
User-agent: *
Content-Signal: ai-train=yes, search=yes, ai-input=yes
Allow: /wp-json/twoja-przestrzen/v1/dane
Disallow: /wp-json/
Disallow: /?rest_route=

Sitemap: https://twoja-strona.pl/sitemap_index.xml
# END YOAST BLOCK

Content-Signal wewnątrz bloku User-agent — po deklaracji agenta, przed regułami Allow/Disallow.

Druga pułapka: Allow przed Disallow dla endpointów

Skoro jesteś już w robots.txt — warto przy okazji naprawić coś co blokuje wiele stron WordPress.

Jeśli masz własny endpoint JSON API dla agentów (o tym w następnym artykule) — domyślny WordPress blokuje cały REST API przez Disallow: /wp-json/. Twój endpoint jest niewidoczny dla crawlerów i agentów.

Rozwiązanie: Allow dla konkretnego endpointu przed globalnym Disallow:

User-agent: *
Content-Signal: ai-train=yes, search=yes, ai-input=yes
Allow: /wp-json/twoja-przestrzen/v1/slownik
Disallow: /wp-json/
Disallow: /?rest_route=

Kolejność Allow przed Disallow jest kluczowa — parsery robots.txt stosują pierwszą pasującą regułę. Jeśli Disallow: /wp-json/jest przed Allow: /wp-json/twoja-przestrzen/ — endpoint jest zablokowany mimo że Allow istnieje.

Weryfikacja

curl -s https://twoja-strona.pl/robots.txt

Powinieneś zobaczyć Content-Signal wewnątrz bloku User-agent, z Allow dla endpointów przed Disallow: /wp-json/.

Cloudflare checker:

Bot Access Control: 100/100 ✓

Podsumowanie trzech artykułów

Masz teraz trzy z czterech kategorii agent-readiness na 100/100:

• Discoverability 100 — rel="service-doc" i strona /dla-agentow ✓
• Content 100 — Markdown for Agents z obsługą LiteSpeed ✓
• Bot Access Control 100 — Content Signals w robots.txt ✓

Łączny wynik to 50/100 Level 4 „Agent-Integrated” — bo czwarta kategoria (API, Auth, MCP & Skill Discovery) wymaga wystawienia endpointów dla agentów, co jest osobnym tematem.

Ale możemy ten wynik poprawić — i o tym jest następny artykuł.

Co dalej

Czwarta kategoria w Cloudflare checkerze to Skill Discovery — czy agenci wiedzą co mogą zrobić na Twojej stronie, nie tylko co mogą przeczytać.

Najprostszym wejściem w ten temat jest dynamiczny JSON API z danych które już masz w WordPress. Nie wymaga zewnętrznych usług, nie wymaga VPS — kilkadziesiąt linii kodu i agenci mają ustrukturyzowany dostęp do Twoich treści.

W następnym artykule buduję taki endpoint dla słownika pojęć — i pokazuję dwie rzeczy które WordPress robi źle z REST API domyślnie, a które blokują agentów zanim w ogóle zaczną.

Ten artykuł jest częścią serii „WordPress Agent-Readiness”. Wszystkie wdrożenia zostały przetestowane na webflux.pl — włącznie z błędami i ich naprawą.