Czy warto blokować AI w robots.txt? Jak blokować, by być nadal widoczny w modelach AI?

Klienci coraz częściej pytają mnie o jedno: czy skoro treści na stronie kosztowały realne pieniądze, to trzeba je zabezpieczyć przed botami AI? To pytanie nie jest teoretyczne. W logach serwera widać dziś nie tylko Googlebota, ale też boty takie jak gptbot, ccbot, claudebot, różne fetchery AI, crawlery wyszukiwania AI i tokeny sterujące typu google-extended. Problem polega na tym, że źle ustawiony robots.txt może jednocześnie ograniczyć wykorzystanie treści do treningu modeli i przypadkiem odciąć stronę od widoczności w odpowiedziach AI. W tym artykule pokażę, czy warto blokować AI, kiedy ma to sens, kiedy jest strzałem w kolano i jak zrobić to technicznie tak, żeby nie wylać widoczności razem z kąpielą.

Z tego artykułu dowiesz się:

• Najpierw trzeba rozdzielić dwie rzeczy: trening AI i widoczność w AI
• Dlaczego proste „Disallow: /” dla wszystkich botów AI jest ryzykowne?
• Jak działają najważniejsze boty AI i co realnie blokujesz?
• GPTBot – blokada treningu, niekoniecznie blokada widoczności
• CCBot – Common Crawl i dane wykorzystywane szeroko w ekosystemie AI
• ClaudeBot, Claude-User i Claude-SearchBot – trzy różne funkcje, trzy różne decyzje
• GeminiBot, Google-Extended i Googlebot – tutaj łatwo o nieporozumienie
• Czy warto blokować AI? Moja praktyczna odpowiedź: czasem tak, ale prawie nigdy hurtowo
• Kiedy blokowanie botów AI ma sens?
• Kiedy blokowanie AI szkodzi marketingowi?
• Jak blokować boty AI, by nadal być widocznym w modelach i odpowiedziach AI?
• Model 1: Chcę być widoczny w AI, ale nie chcę trenowania na moich treściach
• Model 2: Mam treści publiczne i chcę maksymalnej dystrybucji
• Model 3: Mam treści wrażliwe i chcę mocniejszej ochrony
• Robots.txt nie jest zabezpieczeniem treści. To prośba do botów, które chcą jej słuchać
• Dlaczego robots.txt nie wystarczy przy treściach premium?
• Jak sprawdzać, czy boty AI rzeczywiście odwiedzają stronę?
• Jak nie zepsuć SEO, blokując AI?
• Nie blokuj Googlebota, jeśli chcesz mieć widoczność w Google
• Nie blokuj zasobów potrzebnych do renderowania strony
• Nie blokuj bloga, jeśli blog ma budować autorytet
• Blokować całą domenę czy wybrane katalogi? Tu zaczyna się prawdziwa strategia
• Strony ofertowe zwykle powinny zostać dostępne
• Treści premium można blokować selektywnie
• Parametry, wyniki wyszukiwania i koszyk blokuj niezależnie od AI
• Czy llms.txt zastąpi robots.txt?
• Jaką konfigurację robots.txt poleciłbym większości firm usługowych?
• Podsumowanie

Najpierw trzeba rozdzielić dwie rzeczy: trening AI i widoczność w AI

Największy błąd, jaki widzę w rozmowach o botach AI, polega na wrzucaniu wszystkiego do jednego worka. Dla wielu właścicieli stron „bot AI” oznacza po prostu robota, który przychodzi, pobiera treści i wykorzystuje je w modelu. W praktyce wygląda to zupełnie inaczej niż w teorii.

Część botów służy do pobierania treści, które mogą być wykorzystane przy trenowaniu modeli. Część służy do wyszukiwania i wyświetlania źródeł w odpowiedziach. Część działa dopiero wtedy, gdy użytkownik wklei link do narzędzia AI i poprosi o analizę strony. To nie są te same scenariusze i nie powinny mieć tych samych reguł w robots.txt.

OpenAI opisuje rozdzielenie między botami tak: GPTBot jest związany z treściami, które mogą być używane do trenowania modeli, a OAI-SearchBot służy do wyszukiwania i pojawiania się stron w funkcjach wyszukiwania ChatGPT. Co ważne, te ustawienia są niezależne – można zablokować GPTBot, a jednocześnie pozwolić OAI-SearchBotowi na dostęp do treści.

I to jest sedno całego tematu. Jeśli firma pyta mnie: „czy warto blokować AI?”, odpowiadam: nie blokuj wszystkiego hurtowo, jeśli zależy Ci na widoczności marki w odpowiedziach generatywnych. Blokowanie może mieć sens, ale tylko selektywne.

Dlaczego proste „Disallow: /” dla wszystkich botów AI jest ryzykowne?

Bo to rozwiązanie wygląda dobrze tylko w arkuszu z polityką bezpieczeństwa. W realnym SEO może odciąć stronę od nowych miejsc, w których użytkownicy szukają rekomendacji, porównań i odpowiedzi.

Wyobraźmy sobie firmę usługową, która przez 3 lata inwestowała w eksperckie artykuły, poradniki, case studies i lokalne landing page’e. Potem ktoś dodaje do robots.txt kilka hurtowych blokad dla botów AI, bez sprawdzenia różnicy między crawlerem treningowym a botem wyszukiwania. Efekt? Strona nadal może być widoczna w Google, ale część narzędzi AI nie będzie mogła jej pobierać, analizować lub cytować w odpowiedziach.

W projektach SEO widziałem już podobny mechanizm przy klasycznym robots.txt. Ktoś chciał zablokować „śmieciowe adresy”, a zablokował katalog z produktami. Ktoś chciał wyłączyć parametry, a odciął filtry, które generowały sprzedaż. Przy AI będzie tak samo, tylko konsekwencje są mniej widoczne na pierwszy rzut oka.

Google jasno opisuje, że Google-Extended jest tokenem sterującym wykorzystywaniem treści w kontekście Gemini i Vertex AI, a nie osobnym user-agentem w żądaniach HTTP. Google podaje też, że Google-Extended nie wpływa na obecność strony w Google Search ani nie jest sygnałem rankingowym w Google Search.

To znaczy, że jedna linijka w robots.txt może mieć zupełnie inny skutek w zależności od tego, jakiego bota dotyczy.

Jak działają najważniejsze boty AI i co realnie blokujesz?

Nie da się sensownie odpowiedzieć na pytanie, czy blokować AI, bez zrozumienia kilku nazw. Nie chodzi o naukę listy botów na pamięć. Chodzi o decyzję biznesową: co chcesz chronić, a gdzie nadal chcesz być widoczny.

GPTBot – blokada treningu, niekoniecznie blokada widoczności

GPTBot to bot OpenAI używany do pobierania treści, które mogą być wykorzystane do trenowania generatywnych modeli AI. Jeśli zablokujesz GPTBot, sygnalizujesz, że treści z Twojej strony nie powinny być używane do trenowania modeli OpenAI. OpenAI dokumentuje GPTBot jako crawler związany z trenowaniem modeli, a OAI-SearchBot jako bota związanego z widocznością w wynikach wyszukiwania ChatGPT.

Praktyczna interpretacja jest taka: jeśli chcesz ograniczyć użycie treści do treningu, ale nadal zależy Ci na obecności w wynikach wyszukiwania ChatGPT, nie blokuj OAI-SearchBot razem z GPTBot.

Przykład selektywnej konfiguracji:

User-agent: GPTBot
Disallow: /

User-agent: OAI-SearchBot
Allow: /

Ten zapis nie jest magiczną gwarancją ruchu z ChatGPT. On tylko nie zamyka drzwi. O widoczności nadal decyduje jakość treści, autorytet, dostępność techniczna, linkowanie, struktura i to, czy dany system uzna stronę za przydatne źródło.

CCBot – Common Crawl i dane wykorzystywane szeroko w ekosystemie AI

CCBot to crawler Common Crawl. Common Crawl udostępnia duże zbiory danych z publicznej sieci, które są używane w badaniach, analizach i projektach uczenia maszynowego. Common Crawl opisuje CCBot jako crawler, który najpierw sprawdza robots.txt, a dopiero potem pobiera stronę, jeśli crawling jest dozwolony.

Common Crawl podaje, że CCBot identyfikuje się m.in. jako CCBot/2.0, a blokada w robots.txt wygląda klasycznie: User-agent: CCBot i Disallow: /. Common Crawl zwraca też uwagę, że część crawlerów może fałszywie podawać się za CCBot, więc przy analizie logów trzeba weryfikować autentyczność żądań.

Jeżeli prowadzisz serwis z bardzo cennymi treściami płatnymi, danymi specjalistycznymi lub unikalną bazą wiedzy, blokowanie CCBot może być częścią polityki ochrony treści. Jeśli jednak prowadzisz stronę usługową, blog ekspercki lub serwis firmowy, sprawa jest bardziej złożona. Blokując CCBot, ograniczasz udział strony w jednym z dużych publicznych zbiorów danych, z których korzysta wiele podmiotów. To nie znaczy automatycznie „znikniesz z AI”, ale zmniejszasz szansę, że Twoje treści będą dostępne w niektórych łańcuchach danych.

Kod blokujący CCBot:

User-agent: CCBot
Disallow: /

Kod spowalniający CCBot, zamiast całkowitej blokady:

User-agent: CCBot
Crawl-delay: 2

W praktyce ten drugi wariant bywa rozsądniejszy, jeśli problemem nie jest sama obecność bota, tylko obciążenie serwera.

ClaudeBot, Claude-User i Claude-SearchBot – trzy różne funkcje, trzy różne decyzje

Przy Claude temat jest szczególnie ciekawy, bo Anthropic rozróżnia kilka botów. ClaudeBot służy do zbierania treści, które mogą wspierać rozwój modeli. Claude-User działa przy zapytaniach użytkowników, gdy Claude ma pobrać treść na życzenie człowieka. Claude-SearchBot jest związany z poprawą jakości wyników wyszukiwania i indeksowaniem treści dla funkcji search. Anthropic opisuje też, że blokada Claude-User może zmniejszyć widoczność strony w user-directed web search, a blokada Claude-SearchBot może ograniczyć indeksowanie treści dla wyników wyszukiwania.

To jest dokładnie ten niuans, którego brakuje w wielu prostych poradnikach. Jeśli zablokujesz wszystko z nazwą „Claude”, możesz ograniczyć nie tylko trening, ale też sytuacje, w których użytkownik chce, aby Claude przeczytał Twoją stronę lub wykorzystał ją w odpowiedzi.

Selektywny wariant może wyglądać tak:

User-agent: ClaudeBot
Disallow: /

User-agent: Claude-User
Allow: /

User-agent: Claude-SearchBot
Allow: /

Taki zapis mówi: nie chcę udostępniać treści do treningu ClaudeBotowi, ale nie blokuję pobierania strony na żądanie użytkownika i nie zamykam drogi do widoczności w wyszukiwaniu Claude.

GeminiBot, Google-Extended i Googlebot – tutaj łatwo o nieporozumienie

W przypadku Google trzeba uważać z uproszczeniami. Wiele osób mówi „GeminiBot”, ale w dokumentacji Google częściej trzeba patrzeć na konkretne tokeny i crawlery, w tym Google-Extended oraz Google-CloudVertexBot. Google-Extended nie jest osobnym user-agentem w żądaniach HTTP; działa jako token w robots.txt, który zarządza tym, czy treści pobrane przez Google mogą być wykorzystywane do określonych zastosowań związanych z Gemini i Vertex AI.

Przykład blokady Google-Extended:

User-agent: Google-Extended
Disallow: /

To nie blokuje Googlebota od klasycznego indeksowania strony w Google Search. I tu pojawia się praktyczny wniosek: nie próbuj blokować AI przez blokowanie Googlebota, jeśli zależy Ci na SEO. To byłby techniczny sabotaż własnej widoczności.

W przypadku firm, które inwestują w pozycjonowanie stron, Googlebot powinien mieć dostęp do treści, które mają się indeksować i rankować. Google-Extended to osobna decyzja dotycząca wybranych zastosowań AI, a nie zamiennik dla reguł indeksowania Google.

Czy warto blokować AI? Moja praktyczna odpowiedź: czasem tak, ale prawie nigdy hurtowo

Gdybym miał skrócić ten artykuł do jednego zdania, napisałbym tak: blokuj konkretne zastosowania AI, nie całe AI jako zjawisko.

Po kilkunastu latach pracy w SEO wiem, że najgorsze decyzje techniczne powstają pod wpływem emocji. Ktoś przeczyta, że AI „kradnie treści”, więc blokuje wszystko. Ktoś inny słyszy, że trzeba być widocznym w AI, więc pozwala wszystkim botom na wszystko. Obie reakcje są zbyt proste.

Kiedy blokowanie botów AI ma sens?

Blokowanie ma sens, gdy serwis zawiera treści, których nie chcesz udostępniać do dalszego przetwarzania przez modele. Mam tu na myśli zamknięte bazy wiedzy, treści premium, materiały licencyjne, unikalne raporty, dokumentacje, dane badawcze, treści prawnie wrażliwe albo zasoby, które są głównym produktem firmy.

Przykład z praktyki: firma inwestuje kilkadziesiąt tysięcy złotych w specjalistyczne raporty branżowe. Udostępnia część materiałów publicznie jako lead magnet, a część ma charakter sprzedażowy. W takim przypadku rozważyłbym blokowanie crawlerów treningowych na wybranych katalogach, np. /raporty/, /premium/, /baza-wiedzy-pro/, ale niekoniecznie na całej domenie.

Kod przykładowy:

User-agent: GPTBot
Disallow: /raporty/
Disallow: /premium/

User-agent: ClaudeBot
Disallow: /raporty/
Disallow: /premium/

User-agent: CCBot
Disallow: /raporty/
Disallow: /premium/

To jest dużo rozsądniejsze niż:

User-agent: *
Disallow: /

Ten drugi zapis zamyka stronę dla wszystkich botów respektujących robots.txt, w tym dla tych, których prawdopodobnie chcesz wpuścić.

Kiedy blokowanie AI szkodzi marketingowi?

Blokowanie szkodzi, gdy firma chce budować widoczność ekspercką, a jednocześnie odcina narzędzia, które mogą pomóc tę widoczność rozszerzyć. Dotyczy to szczególnie branż, w których użytkownicy długo porównują rozwiązania: SEO, prawo, medycyna, finanse, budownictwo, nieruchomości, B2B, IT, e-commerce, HR, logistyka.

Jeśli Twoim celem jest pozyskiwanie zapytań z treści poradnikowych, to całkowite blokowanie botów AI może ograniczyć jeden z kierunków dystrybucji wiedzy. Nie chodzi o to, że AI zastąpi Google. Nie zastąpi. Chodzi o to, że użytkownik coraz częściej robi research równolegle: Google, YouTube, ChatGPT, Gemini, Perplexity, LinkedIn, opinie, porównywarki. Jeśli znikasz z części tych miejsc, oddajesz pole konkurencji.

Dlatego przy stronie agencji, kancelarii, firmy usługowej albo lokalnego biznesu rekomendowałbym najpierw audyt logów i celów, a dopiero potem blokady. W profesjonalnej agencji reklamowej decyzja o robots.txt nie powinna być dodatkiem „na końcu wdrożenia”, tylko elementem strategii widoczności.

Jak blokować boty AI, by nadal być widocznym w modelach i odpowiedziach AI?

Najbezpieczniejsza strategia to model warstwowy. Osobno traktujesz boty treningowe, osobno boty wyszukiwania, osobno fetchery użytkownika, osobno klasyczne boty wyszukiwarek.

Model 1: Chcę być widoczny w AI, ale nie chcę trenowania na moich treściach

To najczęstszy scenariusz, który ma sens dla firm usługowych. Chcesz, żeby narzędzia AI mogły znaleźć Twoje treści, pokazać je jako źródło albo pobrać na żądanie użytkownika. Jednocześnie nie chcesz dawać zielonego światła botom treningowym.

Przykładowy robots.txt:

User-agent: GPTBot
Disallow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Claude-User
Allow: /

User-agent: Claude-SearchBot
Allow: /

User-agent: Google-Extended
Disallow: /

User-agent: Googlebot
Allow: /

Sitemap: https://twojadomena.pl/sitemap.xml

Ten schemat nie jest uniwersalny dla każdego biznesu, ale pokazuje logikę: blokujesz wybrane użycie treningowe, a nie cały dostęp do treści.

Model 2: Mam treści publiczne i chcę maksymalnej dystrybucji

To scenariusz dla firm, które traktują content jako narzędzie dotarcia. Blog ekspercki, poradniki, rankingi, instrukcje, treści edukacyjne, lokalne strony ofertowe – im szerzej są widoczne, tym lepiej dla marki.

W takim przypadku często nie blokowałbym głównych botów AI na całej stronie. Zamiast tego kontrolowałbym tylko katalogi techniczne, koszyk, panel klienta, wyniki wyszukiwania wewnętrznego, parametry i treści, które nie powinny być crawlowane niezależnie od AI.

Przykład:

User-agent: *
Disallow: /wp-admin/
Disallow: /koszyk/
Disallow: /moje-konto/
Disallow: /checkout/
Disallow: /search/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://twojadomena.pl/sitemap.xml

W tym wariancie nie tworzysz specjalnych blokad dla AI. Skupiasz się na czystości indeksowania i dostępności treści, które mają budować widoczność.

To ma sens, gdy strona żyje z ruchu organicznego, leadów i rozpoznawalności. Przy działaniach takich jak pozycjonowanie stron w Chojnicach, pozycjonowanie stron w Gdyni czy pozycjonowanie stron w Gdańsku lokalna treść ma pracować jak najdłużej i w jak największej liczbie miejsc styku z klientem.

Model 3: Mam treści wrażliwe i chcę mocniejszej ochrony

Jeśli masz serwis z treściami płatnymi, dokumentacją techniczną, regulaminowo chronioną bazą danych albo materiałami, które stanowią produkt sam w sobie, blokowanie AI może być znacznie bardziej agresywne.

Przykład:

User-agent: GPTBot
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: OAI-SearchBot
Disallow: /premium/
Disallow: /raporty/

User-agent: Claude-SearchBot
Disallow: /premium/
Disallow: /raporty/

User-agent: *
Disallow: /panel/
Disallow: /konto/
Disallow: /premium/

W tym wariancie akceptujesz, że część widoczności w AI może być mniejsza. To decyzja biznesowa. Nie ma sensu udawać, że można jednocześnie maksymalnie chronić treść i maksymalnie zwiększać jej dystrybucję.

Robots.txt nie jest zabezpieczeniem treści. To prośba do botów, które chcą jej słuchać

To jeden z tych mitów SEO, które wyjątkowo trudno się obalają. Robots.txt nie jest firewallem. Nie chroni treści przed człowiekiem. Nie blokuje dostępu do adresu URL w sensie technicznym. Nie sprawia, że strona przestaje istnieć. To standard komunikacji z crawlerami.

Jeśli bot respektuje robots.txt, zastosuje się do reguł. Jeśli nie respektuje, sam plik nie wystarczy. Dlatego przy treściach naprawdę wrażliwych trzeba stosować logowanie, autoryzację, płatny dostęp, blokady serwerowe, kontrolę CDN, WAF albo inne rozwiązania techniczne.

Dlaczego robots.txt nie wystarczy przy treściach premium?

Bo publicznie dostępny URL nadal jest publicznie dostępny. Jeśli raport PDF leży pod adresem /raport-2026.pdf, a jedyną ochroną jest wpis w robots.txt, to nie jest ochrona. To sugestia dla botów.

W projektach, gdzie klient realnie sprzedaje wiedzę, rekomendowałbym prostą zasadę: to, czego nie chcesz pokazać światu, nie powinno być dostępne bez kontroli dostępu. Robots.txt może ograniczać crawling, ale nie zastępuje zabezpieczeń.

Jak sprawdzać, czy boty AI rzeczywiście odwiedzają stronę?

Tu wchodzą logi serwera. Google Analytics nie pokaże pełnego obrazu, bo boty często nie wykonują JavaScriptu i nie uruchamiają kodu analitycznego. Jeśli chcesz zobaczyć, kto faktycznie pobiera stronę, patrzysz w access logi.

Szukasz user-agentów takich jak:

GPTBot
OAI-SearchBot
CCBot
ClaudeBot
Claude-User
Claude-SearchBot
Google-Extended
Google-CloudVertexBot
PerplexityBot

Przy większych serwisach dobrze jest analizować też liczbę żądań, statusy HTTP, najczęściej pobierane katalogi, obciążenie serwera, częstotliwość wizyt i zgodność z robots.txt. W e-commerce z 50 tysiącami URL-i jeden agresywny crawler potrafi zrobić bałagan w logach i wydajności. W małej stronie usługowej kilka wizyt dziennie zwykle nie jest problemem.

Common Crawl zwraca uwagę, że część crawlerów może podszywać się pod CCBot i zaleca weryfikację user-agentów oraz źródeł żądań. To dobry nawyk nie tylko przy CCBot, ale przy całej analizie botów AI.

Jak nie zepsuć SEO, blokując AI?

Najważniejsza zasada: nie dotykaj klasycznych botów wyszukiwarek bez bardzo dobrego powodu. Googlebot, Bingbot i inne crawlery wyszukiwarek to nie to samo co ai-crawler używany do treningu modeli.

Nie blokuj Googlebota, jeśli chcesz mieć widoczność w Google

Brzmi banalnie, ale takie błędy naprawdę się zdarzają. Ktoś próbuje zablokować „Google AI”, nie rozumie różnicy między Googlebotem a Google-Extended i robi wpis:

User-agent: Googlebot
Disallow: /

To nie jest blokada AI. To odcięcie Google od strony.

Jeśli firma inwestuje w SEO, taki zapis może doprowadzić do spadku indeksacji, widoczności i ruchu organicznego. Przy dużej stronie skutki mogą być bardzo kosztowne, bo nawet po poprawieniu robots.txt odbudowa crawl budgetu i zaufania do struktury może zająć czas.

Nie blokuj zasobów potrzebnych do renderowania strony

Drugi błąd to blokowanie katalogów z CSS, JS albo obrazami. W starym SEO zdarzało się to często. Ktoś uznawał, że /assets/, /scripts/ albo /wp-content/ nie są potrzebne do indeksowania. Potem Google nie mógł poprawnie wyrenderować strony.

Przy AI i wyszukiwarkach problem jest podobny. Jeśli chcesz, żeby system mógł zrozumieć stronę, musi mieć dostęp do treści i zasobów potrzebnych do jej interpretacji. Dotyczy to szczególnie stron mocno opartych o JavaScript.

W przypadku profesjonalnych stron internetowych techniczna dostępność treści powinna być zaplanowana na etapie projektu. Strona może wyglądać świetnie, ale jeśli boty widzą pusty szkielet i kilka skryptów, to z punktu widzenia SEO i AI masz problem.

Nie blokuj bloga, jeśli blog ma budować autorytet

Czasem widzę konfiguracje, w których ktoś blokuje /blog/, bo „to tylko treści poradnikowe”. To fatalne podejście. Blog, baza wiedzy, poradniki i case studies to często najlepsze miejsca do budowania widoczności w AI.

Użytkownik nie pyta modelu AI: „daj mi stronę główną firmy X”. Pyta: „jak rozpoznać dobrą agencję SEO?”, „ile kosztuje strona internetowa?”, „czy film reklamowy pomaga w sprzedaży?”, „jak mierzyć ruch z AI?”. Odpowiedzi prowadzą zwykle do treści poradnikowych, nie do generycznej strony głównej.

Jeżeli prowadzisz działania contentowe, nie odcinaj ich od kanałów, w których użytkownicy szukają wiedzy. Przy usługach takich jak wideo marketing właśnie treści edukacyjne pomagają wyjaśnić klientowi, kiedy film ma sens, jaki format wybrać i jak mierzyć efekt.

Blokować całą domenę czy wybrane katalogi? Tu zaczyna się prawdziwa strategia

Hurtowe blokowanie jest łatwe. Strategiczne blokowanie wymaga zrozumienia, które części strony mają pracować na widoczność, a które powinny być chronione.

Strony ofertowe zwykle powinny zostać dostępne

Jeśli strona ofertowa opisuje usługę, proces, zakres, lokalizację i przewagi firmy, zwykle nie blokowałbym jej przed botami wyszukiwania AI. To są treści, które mają sprzedawać i budować zaufanie. Im więcej jakościowych punktów styku, tym lepiej.

Dotyczy to zarówno usług ogólnych, jak i lokalnych. Strony typu pozycjonowanie stron w Toruniu czy pozycjonowanie stron w Bydgoszczy mają odpowiadać na lokalną intencję użytkownika. Jeśli AI zaczyna pomagać użytkownikom w wyborze wykonawców w mieście, taka treść może stać się dodatkowym źródłem zapytań.

Treści premium można blokować selektywnie

Jeśli masz raporty, płatne poradniki, zamknięte materiały szkoleniowe, analizy konkurencji albo zasoby tylko dla klientów, blokuj konkretne katalogi. Nie całą domenę.

Przykład:

User-agent: GPTBot
Disallow: /materialy-premium/
Disallow: /raporty/
Disallow: /szkolenia-klientow/

User-agent: ClaudeBot
Disallow: /materialy-premium/
Disallow: /raporty/
Disallow: /szkolenia-klientow/

User-agent: CCBot
Disallow: /materialy-premium/
Disallow: /raporty/
Disallow: /szkolenia-klientow/

Jeszcze lepiej: nie udostępniaj takich materiałów publicznie bez logowania. Robots.txt traktuj jako warstwę dodatkową, nie główny zamek w drzwiach.

Parametry, wyniki wyszukiwania i koszyk blokuj niezależnie od AI

Są części strony, które zwykle nie powinny być crawlowane przez nikogo: wyniki wyszukiwania wewnętrznego, koszyk, checkout, konto użytkownika, filtry generujące nieskończone kombinacje URL-i, panele administracyjne, adresy testowe.

Tu nie chodzi o AI. Tu chodzi o higienę techniczną.

Przykład:

User-agent: *
Disallow: /koszyk/
Disallow: /checkout/
Disallow: /moje-konto/
Disallow: /search/
Disallow: /*?sort=
Disallow: /*?filter=

W większych sklepach takie reguły potrafią uratować crawl budget. W małych stronach usługowych pomagają uniknąć indeksowania śmieciowych adresów.

Czy llms.txt zastąpi robots.txt?

Nie. I nie planowałbym strategii technicznej na założeniu, że zastąpi.

llms.txt może być ciekawym dodatkiem jako plik porządkujący informacje dla modeli językowych: wskazujący najważniejsze treści, opisujący strukturę serwisu, pomagający zrozumieć, które adresy są najistotniejsze. Ale robots.txt nadal jest miejscem, w którym boty sprawdzają reguły crawlability.

Mówiąc prościej: robots.txt mówi, gdzie bot może wejść, a llms.txt może pomagać zrozumieć, co na stronie jest najważniejsze. To dwa różne zastosowania.

Jeśli miałbym ustawiać priorytety, najpierw zrobiłbym porządny robots.txt, sitemapę, strukturę linkowania, dane schema.org, indeksację, logi i analitykę. Dopiero później dokładałbym llms.txt jako warstwę wspierającą AI.

W projektach SEO widziałem wiele sytuacji, w których firma chciała wdrażać nowinki, a miała bałagan w podstawach: brak sitemap, błędy 404, duplikację tytułów, zablokowane zasoby, źle ustawione canonicale. AI nie naprawi fundamentów. Ono tylko szybciej pokaże, że ich brakuje.

Jaką konfigurację robots.txt poleciłbym większości firm usługowych?

Dla większości firm usługowych nie zaczynałbym od agresywnego blokowania AI. Zacząłbym od odpowiedzi na trzy pytania:

Czy treści na stronie są produktem, czy narzędziem sprzedaży?Czy większa widoczność ekspercka pomaga firmie zdobywać klientów?Czy firma ma konkretne treści, które naprawdę wymagają ochrony?

Jeżeli mówimy o typowej stronie firmowej, blogu eksperckim i ofertach usług, rekomendowałbym zwykle selektywną konfigurację: klasyczne wyszukiwarki mają dostęp, boty wyszukiwania AI mają dostęp, fetchery użytkownika mają dostęp, a boty treningowe można ograniczyć w zależności od polityki firmy.

Przykład roboczy dla firmy usługowej:

User-agent: *
Disallow: /wp-admin/
Disallow: /koszyk/
Disallow: /checkout/
Disallow: /moje-konto/
Disallow: /search/
Allow: /wp-admin/admin-ajax.php

User-agent: GPTBot
Disallow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Claude-User
Allow: /

User-agent: Claude-SearchBot
Allow: /

User-agent: CCBot
Crawl-delay: 2

User-agent: Google-Extended
Disallow: /

Sitemap: https://twojadomena.pl/sitemap.xml

Czy to jest gotowiec dla każdej strony? Nie. To jest punkt wyjścia do rozmowy. Inaczej podejdę do kancelarii z bazą wiedzy, inaczej do sklepu internetowego, inaczej do portalu z płatnymi raportami, inaczej do lokalnej firmy usługowej.

Zarówno jako freelancer, jak i w realiach dużej agencji obserwowałem ten sam schemat: najlepsze efekty daje nie gotowiec, tylko konfiguracja wynikająca z modelu biznesowego. SEO techniczne nie polega na kopiowaniu reguł z bloga. Polega na rozumieniu konsekwencji.

Podsumowanie

Na pytanie czy warto blokować AI nie odpowiadam prostym „tak” albo „nie”, bo taka odpowiedź byłaby nieuczciwa wobec realiów SEO. Najrozsądniejsze podejście to selektywne blokowanie: osobno boty treningowe, osobno boty wyszukiwania, osobno fetchery użytkownika i osobno klasyczne crawlery wyszukiwarek. Jeśli treści mają budować widoczność, zapytania i autorytet marki, nie odcinałbym ich hurtowo od narzędzi AI. Następny krok jest prosty: sprawdź swój robots.txt, przeanalizuj logi serwera i dopiero wtedy zdecyduj, które boty naprawdę chcesz blokować – a jeśli chcesz podejść do tego strategicznie, Gregor Media może pomóc połączyć SEO techniczne, content i widoczność w nowych środowiskach wyszukiwania.