Pliki llms.txt i ai.txt – nowe robots.txt dla WordPressa

Boty AI potrafią wejść na WordPressa jak niewidzialny użytkownik z bardzo dużym apetytem. Nie klikają w menu, nie oglądają layoutu, nie interesuje ich estetyka strony. Pobierają treść, przechodzą po linkach, czasem ignorują ścieżki, które właściciel serwisu uznał za mało ważne. Efekt? W logach hostingu rośnie liczba requestów, cache nie zawsze pomaga, a panel WordPressa zaczyna działać ciężej bez oczywistego powodu.

W audytach technicznych WordPressa coraz częściej widać ten sam schemat: właściciel strony ma robots.txt, ma sitemap.xml, czasem nawet ma poprawnie ustawione noindex dla archiwów, ale boty AI i tak chodzą po serwisie szerzej, niż powinny. Największy problem nie polega wtedy na tym, że brakuje kolejnego pliku tekstowego. Problem polega na tym, że strona nie mówi jasno: „to jest moja najlepsza treść”, „te adresy są techniczne”, „tych sekcji nie używaj jako reprezentacji marki”.

Dlatego llms.txt i ai.txt nie powinny być traktowane jako modne dodatki do SEO. To raczej warstwa porządkowa między klasycznym crawlingiem, widocznością w narzędziach AI i ochroną zasobów serwera. Nie gwarantują cytowania w ChatGPT, Gemini czy Perplexity. Nie zatrzymają też każdego scrapera. Dają jednak właścicielowi WordPressa coś bardzo konkretnego: sposób na uporządkowanie komunikacji z systemami AI, zanim te same wybiorą sobie przypadkowe tagi, stare wpisy i archiwa jako „źródło wiedzy” o firmie.

llms.txt, ai.txt i robots.txt: trzy pliki, trzy różne zadania

robots.txt działa jak tablica z prostymi zakazami i pozwoleniami dla crawlerów. Leży zwykle pod adresem:

https://twojadomena.pl/robots.txt

Przykład:

User-agent: GPTBot
Disallow: /wp-admin/
Disallow: /koszyk/
Disallow: /moje-konto/

User-agent: *
Allow: /

Taki plik mówi botom, do których ścieżek nie powinny wchodzić. Nie tłumaczy jednak, które podstrony są najważniejsze, co jest aktualne, które treści mają największą wartość ekspercką i czego nie należy traktować jako reprezentacji firmy.

Właśnie tu wchodzi llms.txt. Standard zaproponowany przez Jeremy’ego Howarda zakłada prosty plik Markdown umieszczony najczęściej w katalogu głównym domeny:

https://twojadomena.pl/llms.txt

Plik llms.txt ma prowadzić modele językowe i agentów AI do najważniejszych treści. Nie zastępuje sitemap.xml, bo nie jest pełną mapą wszystkich adresów. Nie zastępuje robots.txt, bo nie służy głównie do blokowania. Jego zadaniem jest selekcja i kontekst.

Dobrze przygotowany plik może wyglądać tak:

# CMspace

Firma specjalizuje się w stronach WordPress, SEO technicznym i automatyzacji treści dla małych oraz średnich firm.

## Najważniejsze strony

- [Strony WordPress](https://domena.pl/strony-wordpress/)
- [Audyt SEO](https://domena.pl/audyt-seo/)
- [Automatyzacja treści](https://domena.pl/automatyzacja-tresci/)
- [Blog](https://domena.pl/blog/)
- [Kontakt](https://domena.pl/kontakt/)

## Pomijaj

- Koszyk i konto użytkownika
- Wyniki wyszukiwania wewnętrznego
- Tagi bez unikalnych opisów
- Archiwa dat
- Paginację
- Strony testowe i robocze

W praktyce llms.txt powinien być krótki. Lepiej wskazać 15 dobrych adresów niż 300 przypadkowych. Jeżeli wrzucisz tam wszystkie wpisy, tagi, archiwa i podstrony regulaminowe, tworzysz nie przewodnik dla AI, tylko katalog bałaganu.

Standard przewiduje też opcjonalny plik llms-full.txt. Różnica jest prosta: llms.txt to skrócony przewodnik z opisem i linkami do najważniejszych sekcji, a llms-full.txt może zawierać pełniejszą, bardziej rozbudowaną treść przygotowaną do odczytu przez modele językowe. Dla małej strony firmowej zwykle wystarczy sam llms.txt. llms-full.txt ma większy sens przy dokumentacji, bazach wiedzy, kursach, serwisach SaaS i stronach technicznych, gdzie AI potrzebuje dłuższego, czystego kontekstu bez menu, stopki i przypadkowych elementów HTML.

ai.txt ma inne zadanie. To plik, w którym można opisać zasady użycia treści przez systemy AI: czy wolno streszczać, cytować, trenować modele, wykorzystywać treść komercyjnie albo modyfikować ją w odpowiedziach. Ten obszar nie jest jeszcze tak utrwalony jak robots.txt, dlatego nie warto udawać, że jeden plik załatwia kwestie prawne i techniczne. Mimo to ai.txt może być użyteczny jako jasna deklaracja polityki właściciela strony.

Prosty przykład:

AI-Training: disallow
AI-Summarization: allow
AI-Citation: required
Commercial-Use: disallow
Contact: kontakt@domena.pl

Taki zapis nie zablokuje technicznie pobierania treści. Robi coś innego: stawia granice i ułatwia późniejsze egzekwowanie zasad wobec narzędzi, które deklarują respektowanie takich instrukcji.

Najważniejsza hierarchia jest taka:

1. robots.txt — dostęp crawlerów do ścieżek.
2. sitemap.xml — lista adresów dla wyszukiwarek.
3. llms.txt — selekcja najważniejszych treści dla AI.
4. ai.txt — deklaracja zasad użycia treści przez AI.
5. WAF/CDN/hosting — realna blokada, gdy boty obciążają serwer.

Bez ostatniego punktu nie ma twardej ochrony. robots.txt i llms.txt są instrukcjami. Cloudflare, reguły serwerowe, firewall aplikacyjny i limity requestów są kontrolą techniczną.

Jak wdrożyć llms.txt w WordPressie bez automatycznego śmietnika

Najprościej zacząć od sprawdzenia, czy WordPress już potrafi wygenerować llms.txt z używanego zestawu narzędzi. W 2026 roku nie trzeba już w każdym przypadku pisać tego pliku ręcznie.

Jeżeli korzystasz z Yoast SEO, funkcja llms.txt jest dostępna w ustawieniach wtyczki. Ścieżka wygląda następująco:

Yoast SEO → Settings → Site features → AI tools → llms.txt

W praktyce warto wybrać tryb ręczny, jeżeli strona ma dużo treści, sklep WooCommerce, stare wpisy albo rozbudowane archiwa. Automatyczny wybór może być dobry na start, ale nie powinien decydować za właściciela serwisu, które treści reprezentują markę.

W repozytorium WordPressa są też dedykowane wtyczki, m.in.:

• LLMs.txt and LLMs-Full.txt Generator — generuje pliki llms.txt i llms-full.txt w katalogu głównym strony.
• Website LLMs.txt — tworzy i utrzymuje llms.txt, integruje się z Yoast SEO, Rank Math, SEOPress i AIOSEO oraz pomija treści oznaczone jako noindex lub nofollow.
• LLMs Text Generator — pozwala generować plik llms.txt bez ręcznego tworzenia struktury od zera.

To są narzędzia pomocnicze, nie strategia. Najczęstszy błąd przy wdrożeniu polega na kliknięciu „wygeneruj” i uznaniu pracy za skończoną. WordPress lubi produkować adresy techniczne: tagi, archiwa autora, archiwa dat, paginacje, strony filtrowania produktów, wyniki wyszukiwania wewnętrznego, warianty URL z parametrami. AI nie powinno dostawać tego jako przewodnika po stronie.

Dobra procedura wdrożenia wygląda tak:

1. Otwórz robots.txt i sprawdź, czy nie blokujesz ważnych treści
   Adres: https://twojadomena.pl/robots.txt.
   Szukaj szczególnie wpisów blokujących /wp-content/, /blog/, /oferta/, /produkty/ albo cały serwis przez przypadkowe Disallow: /.
2. Sprawdź sitemapę
   Najczęściej będzie to:
   https://twojadomena.pl/sitemap_index.xml
   albo
   https://twojadomena.pl/sitemap.xml.
3. Wybierz najważniejsze adresy ręcznie
   Dla małej strony firmowej zwykle wystarczy 10–30 linków. Dla sklepu lub bazy wiedzy można przygotować osobne sekcje, ale nadal trzeba wybierać. Priorytet mają:
   • strony usług,
   • najlepiej dopracowane poradniki,
   • aktualne kategorie produktowe,
   • dokumentacja,
   • strona kontaktowa,
   • strona o firmie,
   • treści z realną ekspertyzą.
4. Usuń wszystko, co zaniża jakość sygnału
   Do llms.txt nie dawaj:
   • tagów bez opisów,
   • archiwów dat,
   • archiwów autorów,
   • wyników wyszukiwania,
   • koszyka,
   • checkoutu,
   • konta użytkownika,
   • stron logowania,
   • polityk technicznych bez znaczenia dla oferty,
   • starych landing page’y,
   • roboczych wpisów,
   • duplikatów kategorii.
5. Sprawdź kod odpowiedzi HTTP
   Po wdrożeniu adres https://twojadomena.pl/llms.txt powinien zwracać 200 OK. Jeżeli widzisz 404, przekierowanie do strony HTML, błąd firewalla albo komunikat cache, plik nie działa tak, jak powinien.
6. Ustaw przegląd co 3 miesiące
   llms.txt starzeje się szybciej niż robots.txt. Wystarczy kilka zmian w ofercie, usunięcie usługi albo przebudowa bloga i plik zaczyna prowadzić AI do nieaktualnych treści.

Przy WordPressie z WooCommerce dochodzi dodatkowy problem: produkty rotują, a ich opisy bywają krótkie, powielone z katalogu producenta albo generowane masowo. W takim przypadku nie wrzucałbym do llms.txt każdego produktu. Lepiej wskazać kategorie, poradniki zakupowe, regulamin dostawy, stronę kontaktową i wybrane produkty flagowe, które mają unikalne opisy oraz stabilną dostępność.

W jednym z typowych audytów e-commerce problem nie leżał w samym llms.txt, tylko w tym, że crawlery AI masowo przechodziły po filtrach WooCommerce i parametrach sortowania. Sam wpis w robots.txt nie zmniejszył obciążenia, bo część ruchu i tak trafiała w zasoby serwera. Dopiero reguły w Cloudflare WAF ograniczające konkretne user-agenty, nietypowe tempo zapytań i wejścia w adresy z parametrami pozwoliły odciążyć hosting. W praktyce spadek użycia CPU trzeba mierzyć na danych z hostingu: porównując 7 dni przed wdrożeniem i 7 dni po wdrożeniu, z wyłączeniem kampanii reklamowych, mailingów i sezonowych pików ruchu. Bez takiego porównania procent wygląda efektownie, ale niczego nie dowodzi.

Jeżeli chcesz mierzyć to porządnie, sprawdzaj:

• średnie CPU usage w panelu hostingu,
• liczbę requestów do adresów z parametrami,
• user-agenty w logach,
• błędy 403 i 429 po wdrożeniu reguł,
• TTFB dla stron bez cache,
• liczbę wejść w /wp-json/,
• liczbę wejść w wyniki wyszukiwania wewnętrznego.

Dopiero wtedy można powiedzieć, czy blokady faktycznie działają. Jeżeli CPU spadło o 20–40% po ograniczeniu agresywnych crawlerów, to jest realny efekt infrastrukturalny. Jeżeli zmienił się tylko plik robots.txt, a logi requestów wyglądają tak samo, nie ma czego świętować.

Kiedy blokować boty AI, a kiedy dać im kontrolowany dostęp

Blokowanie wszystkich botów AI na oślep to rzucanie sobie kłód pod nogi. Tracisz szansę na ruch z narzędzi takich jak Perplexity, Gemini, ChatGPT Search czy inne systemy odpowiedzi, które potrafią kierować użytkowników do źródeł. Dla strony usługowej, bloga eksperckiego albo bazy wiedzy całkowita blokada często jest zbyt agresywna.

Inaczej wygląda sytuacja przy treściach premium, kursach, płatnych raportach, katalogach, bazach danych i serwisach opartych na licencjonowanych materiałach. Tam priorytetem nie jest „być wszędzie”, tylko kontrolować dostęp. Wtedy robots.txt jest tylko deklaracją, a prawdziwa praca dzieje się w konfiguracji serwera, CDN i aplikacji.

Dla strony firmowej sensowny model to kontrolowany dostęp:

User-agent: GPTBot
Disallow: /wp-admin/
Disallow: /koszyk/
Disallow: /moje-konto/
Disallow: /?s=
Allow: /

User-agent: Google-Extended
Disallow: /

User-agent: *
Allow: /

Ten przykład nie jest uniwersalną receptą. Pokazuje sposób myślenia. Możesz pozwolić wybranym botom czytać publiczne treści, ale jednocześnie blokować elementy techniczne, wyniki wyszukiwania, koszyk, konto i obszary bez wartości dla użytkownika.

Google-Extended wymaga osobnej decyzji. Ten token pozwala właścicielom stron kontrolować użycie treści w określonych funkcjach AI Google, ale nie jest tym samym co klasyczny Googlebot odpowiedzialny za indeksowanie w wyszukiwarce. Dlatego nie należy kopiować reguł bez zrozumienia. Zablokowanie niewłaściwego user-agenta może odbić się na widoczności, a zbyt szerokie pozwolenia mogą kłócić się z polityką ochrony treści.

Dobre podejście decyzyjne:

• Strona usługowa lub ekspercka
  Nie blokuj wszystkiego. Przygotuj llms.txt, uporządkuj sitemapę, wyklucz śmieciowe adresy i monitoruj logi.
• Sklep WooCommerce
  Nie dawaj AI całego katalogu bez kontroli. Wskaż kategorie, poradniki i produkty flagowe. Blokuj parametry filtrowania, sortowania, koszyk i konto.
• Portal treściowy
  Oddziel treści publiczne od premium. Dla publicznych materiałów przygotuj llms.txt. Dla premium zastosuj logowanie, paywall, WAF i twarde reguły dostępu.
• Kursy, raporty, bazy danych
  Najpierw ochrona, potem widoczność. ai.txt może opisać zasady użycia, ale nie zastąpi kontroli dostępu.
• Strona z małym ruchem i kilkoma podstronami
  Nie komplikuj. Wystarczy poprawny robots.txt, sitemap.xml i krótki llms.txt z najlepszymi adresami.

W praktyce największy priorytet ma usunięcie adresów, których AI nie powinno traktować jako wartościowej treści. Dopiero później warto dodawać bardziej szczegółowe instrukcje dla poszczególnych botów.

Minimalny zestaw dla WordPressa wygląda tak:

/robots.txt
/sitemap.xml lub /sitemap_index.xml
/llms.txt

Rozszerzony zestaw dla większej strony:

/robots.txt
/sitemap_index.xml
/llms.txt
/llms-full.txt
/ai.txt

Do tego dochodzą reguły w Cloudflare WAF, hostingu albo konfiguracji serwera. I tu warto postawić sprawę jasno: jeżeli bot zjada zasoby, nie zaczynaj od pisania pięknego ai.txt. Zacznij od logów, user-agentów, limitów requestów i blokad na poziomie infrastruktury. Pliki tekstowe porządkują komunikację. Nie są ochroniarzem przy drzwiach.

FAQ: llms.txt, ai.txt i WordPress

Czy plik llms.txt musi być zapisany w UTF-8?
Tak, najlepiej zapisać go jako zwykły plik tekstowy w UTF-8. Unikaj znaków specjalnych z edytorów tekstu typu Word, dziwnych cudzysłowów, ukrytego formatowania i kodowania Windows-1250. Najbezpieczniej edytować plik w edytorze kodu albo wygenerować go sprawdzoną wtyczką.

Czy llms.txt powinien zawierać wszystkie wpisy z bloga?
Nie. To częsty błąd. llms.txt powinien prowadzić do najlepszych i najbardziej aktualnych treści, a nie kopiować całą sitemapę. Jeżeli blog ma 300 wpisów, wybierz te, które faktycznie budują ekspertyzę i nie są przestarzałe.

Czy llms-full.txt jest potrzebny na zwykłej stronie firmowej?
Zwykle nie. Dla strony z kilkoma usługami, blogiem i kontaktem wystarczy llms.txt. llms-full.txt ma sens przy dokumentacji, bazie wiedzy, serwisie SaaS, kursie albo większym portalu, gdzie pełniejszy kontekst pomaga AI zrozumieć strukturę treści.

Co sprawdzić jako pierwsze po wdrożeniu?
Otwórz https://twojadomena.pl/llms.txt, sprawdź kod 200 OK, przejrzyj linki i upewnij się, że w pliku nie ma koszyka, konta użytkownika, tagów, archiwów, stron testowych ani nieaktualnych ofert. Najpierw usuń śmieciowe adresy. Dopiero potem dopracowuj opisy i sekcje.