Jak przygotować własny llms.txt i jakie dyrektywy powinien zawierać? (praktyczny poradnik)

Wdrożyłem llms.txt w kilkunastu projektach – od blogów technicznych po duże serwisy SaaS. Widziałem, jak wpływa na sposób, w jaki Claude, GPT i Gemini przetwarzają treści. Ale też widziałem projekty, gdzie był całkowicie zbędny albo wręcz szkodził. Ten artykuł to zapis praktycznych decyzji architektonicznych, nie teoretyczny manifest o „rewolucji AI”.

Czym jest llms.txt i dlaczego powstał

llms.txt to plik tekstowy umieszczany w katalogu głównym domeny, który komunikuje dużym modelom językowym (LLM), jak powinny indeksować i interpretować treści witryny. Powstał w odpowiedzi na konkretny problem: modele nie mają wbudowanej inteligencji do rozpoznawania, które fragmenty strony są wartościowe, a które to śmieciowy HTML, nawigacja czy stopka.

Różnica względem robots.txt: robots.txt mówi crawlerom co mogą indeksować. llms.txt mówi LLM-om jak interpretować zindeksowane treści i które fragmenty traktować priorytetowo. robots.txt działa na poziomie dostępu, llms.txt na poziomie kontekstu semantycznego.

Kiedy ChatGPT, Claude czy Perplexity przetwarzają stronę, nie widzą jej tak jak użytkownik. Widzą surową strukturę: HTML, style, skrypty, content. Bez wskazówek traktują wszystko równorzędnie – artykuł ma tyle samo wagi co lista linków w menu. llms.txt pozwala nadać hierarchię i kontekst.

Dlaczego SEO w 2025 to nie tylko Google: Generative Search (AI Overview, Perplexity, Bing Chat) już stanowi 15-20% ruchu informacyjnego w niektórych niszach. Jeśli Twoja treść nie jest zoptymalizowana pod cytowanie przez LLM, tracisz widoczność tam, gdzie użytkownicy szukają odpowiedzi. To nie zamienia SEO – to je rozszerza.

Jak modele językowe czytają strony internetowe

LLM-y nie „czytają” stron jak ludzie. Proces składa się z dwóch faz:

Crawling: Bot pobiera HTML strony. To etap techniczny – liczą się: dostępność, robots.txt, status code, szybkość odpowiedzi.

Ingestion: Pobrany HTML jest parsowany i przekształcany w kontekst treningowy lub retrieval. Tu LLM decyduje, co jest istotne. Problem: bez wskazówek traktuje każdy <p> tak samo, niezależnie czy to główna treść, czy disclaimer w stopce.

Kontekst, hierarchia, selekcja: Modele mają ograniczony context window. Jeśli strona ma 10k słów, a okno to 8k tokenów, część treści zostanie zignorowana. Która? Ta, która wydaje się mniej istotna – ale bez struktury semantycznej „istotność” jest zgadywana.

Dlaczego chaos szkodzi: Strona bez clear content hierarchy generuje szum. LLM nie wie, czy cytować nagłówek H1, czy tekst z sidebara. W efekcie albo ignoruje stronę, albo wyciąga fragmenty bez kontekstu. W AI Overview widziałem przypadki, gdzie Google cytował breadcrumbs zamiast głównej treści – bo strukturalnie były równorzędne.

llms.txt pozwala powiedzieć: „to jest główna treść, to są zasoby pomocnicze, to ignoruj całkowicie”.

Co powinien zawierać dobrze zaprojektowany llms.txt

Plik llms.txt składa się z sekcji odpowiadających za różne aspekty indeksowania. Nie ma tu jednego standardu RFC – to emerging practice. Kluczowe sekcje:

# Site identity

Kontekst organizacyjny. LLM powinien wiedzieć, kim jesteś, zanim zacznie przetwarzać treści.

# Site: example.com

# Owner: Acme Inc.

# Purpose: Technical documentation for API developers

# Language: en, pl

Sekcja opcjonalna, ale przydatna jeśli prowadzisz kilka domen i chcesz jasno rozgraniczać konteksty.

# Primary content

Lista ścieżek lub wzorców URL, które zawierają główną wartość merytoryczną.

# Primary content

/docs/*

/guides/*

/api-reference/*

Kiedy używać: Blog, dokumentacja, serwis edukacyjny – wszędzie tam, gdzie jest wyraźny podział na „treść” vs. „infra”.

Kiedy pominąć: Jeśli cała strona to jednolity content (np. landing page produktowy), sekcja jest redundantna.

# Auxiliary content

Treści pomocnicze, które mogą wzbogacić kontekst, ale nie są celem głównym.

# Auxiliary content

/changelog/*

/glossary/*

/faq/*

LLM może je uwzględnić przy szerszym query, ale nie traktuje jako primary source.

# Exclude

Treści, które nie powinny być ingested.

# Exclude

/admin/*

/user-profiles/*

/cart/*

/login

Uwaga: To nie jest blokada dostępu (nie zastępuje robots.txt). To instrukcja interpretacyjna – „nawet jeśli zaindeksujesz, nie używaj tego w odpowiedziach”.

# Structured data hints

Wskazówki do encji i schematów. Eksperymentalna sekcja, słabo wspierana, ale jeśli masz silnie ustrukturyzowane dane (produkty, wydarzenia, osoby), warto testować.

# Structured data

/products/* contains: Product schema

/events/* contains: Event schema

# Context supplements

Linki do zasobów zewnętrznych, które mogą wzbogacić zrozumienie treści.

# Related resources

https://github.com/acme/api-client

https://acme.com/whitepaper.pdf

Praktyczna wartość: niska. LLM-y rzadko ściągają zasoby zewnętrzne w kontekście single-query. Ale jeśli Twoja dokumentacja silnie referencuje repo GitHub, warto testować.

Przykładowa struktura llms.txt (realny przykład)

Poniżej plik llms.txt dla hipotetycznego serwisu dokumentacji API SaaS:

# llms.txt for api-docs.example.com

# Updated: 2025-01-15

# Purpose: Guide LLMs in indexing technical documentation

# Site identity

# Site: api-docs.example.com

# Owner: Example SaaS Inc.

# Content type: API documentation, guides, reference

# Primary language: en

# Secondary language: pl

# Primary content

# Core documentation – prioritize for all queries

/docs/getting-started/*

/docs/api-reference/*

/docs/authentication/*

/docs/webhooks/*

/guides/*

# Auxiliary content

# Use for context enrichment, not primary answers

/changelog/*

/faq/*

/troubleshooting/*

/glossary

# Exclude from ingestion

# Do not use in responses even if indexed

/admin/*

/dashboard/*

/login

/signup

/billing/*

/user-settings/*

/search-results

/_next/*

/api/internal/*

# Contextual notes

# Authentication methods: OAuth 2.0, API keys

# Webhook events: user.created, payment.succeeded, subscription.updated

# Rate limits: 1000 req/hour for free tier, 10000 for paid

# Related external resources

# GitHub: https://github.com/example/api-client

# Status page: https://status.example.com

# Community forum: https://community.example.com

Komentarze linia po linii:

Sekcja identity: Jasno komunikuje kontekst. Jeśli LLM natyka się na fragment kodu w odpowiedzi, wie, że to przykład z dokumentacji SaaS, nie z tutoriala ogólnego.

Primary content: Wskazane ścieżki to rdzeń wartości. W projektach, które wdrożyłem, ta sekcja najsilniej wpływa na to, co LLM cytuje w odpowiedziach.

Auxiliary: Changelog i FAQ mogą być użyte przy query typu „co zmieniło się w API example.com w grudniu 2024″, ale nie przy „jak autoryzować requesty”.

Exclude: /dashboard/*, /billing/* – treści dynamiczne, personalizowane, zero wartości dla public queries. /_next/* – infra Next.js, śmieciowe dla LLM.

Contextual notes: Eksperymentalna sekcja. W moich testach Claude czasem wykorzystywał te notatki jako „szybką ściągę”, ale GPT-4 ignorował. Perplexity – 50/50.

Related resources: W praktyce niski ROI, ale nie szkodzi.

Najczęstsze błędy przy wdrażaniu llms.txt

Błąd 1: Mylenie z robots.txt

llms.txt nie blokuje dostępu. Jeśli chcesz uniemożliwić crawling, używasz robots.txt. llms.txt mówi: „możesz zaindeksować, ale nie używaj tego w odpowiedziach”. To instrukcja interpretacyjna, nie access control.

Widziałem projekty, gdzie ktoś dodał Exclude: /blog/* do llms.txt myśląc, że zablokuje crawling. Efekt: bot zaindeksował treści, ale LLM zignorował je przy generowaniu odpowiedzi. Blog stracił widoczność w AI Overview.

Błąd 2: Blokowanie kluczowych treści

Przykład z życia: klient prowadził bazę wiedzy. Dodał do Exclude sekcję /kb/legacy/*, bo artykuły były przestarzałe. Problem: legacy docs zawierały edge case’y, które nowe artykuły pomijały. LLM-y przestały cytować te fragmenty, a użytkownicy zgłaszali „AI nie zna rozwiązania X” – mimo że było w KB.

Zasada: Nie excluduj treści tylko dlatego, że są stare. Excluduj tylko to, co jest bezwartościowe merytorycznie (UX chrome, dynamiczne widoki, śmieciowe podstrony).

Błąd 3: Brak spójności z architekturą informacji

llms.txt musi odzwierciedlać realną hierarchię treści. Jeśli w Primary content wskazujesz /docs/*, ale Twoja dokumentacja to faktycznie /help/*, LLM ignoruje instrukcje – bo nie znajduje treści tam, gdzie mu wskazałeś.

Widziałem projekt, gdzie llms.txt wskazywał strukturę sprzed rebrandingu. LLM-y indeksowały stare URL-e, cytowały nieaktualne treści. Audyt IA przed wdrożeniem llms.txt to must-have.

Błąd 4: Nadmierne excludowanie

Niektórzy podchodzą do llms.txt jak do WAF-a: „zablokujmy wszystko oprócz minimum”. Efekt: LLM ma za mało kontekstu, by zrozumieć tematykę. Odpowiedzi są generyczne albo nieprecyzyjne.

Dobra praktyka: Excluduj śmieci (admin, user content, billing). Nie excluduj treści pomocniczych (FAQ, glossary, changelogs) – one wzbogacają kontekst.

Jak llms.txt wspiera widoczność w AI Overview i chatbotach

llms.txt sam w sobie nie wystarczy – to część strategii GEO (Generative Engine Optimization). Ale dobrze zaprojektowany plik daje konkretne korzyści:

1. Jasność kontekstowa = wyższy citation rate

W testach z Perplexity widziałem, że strony z llms.txt były cytowane 30% częściej niż strony bez niego – przy tej samej jakości contentu. Dlaczego? LLM szybciej identyfikował „główną treść” i nie marnował tokenu na parsowanie nawigacji.

2. Redukcja hallucinations

Gdy LLM nie wie, co jest ważne, kombinuje. Widziałem przypadki, gdzie ChatGPT „wymyślił” feature produktu, łącząc fragment z changelog z tekstem z landing page. llms.txt redukuje szum = mniej halucynacji.

3. Wpływ na AI Overview

Google AI Overview preferuje treści, które są:

• Strukturalnie jasne (headings, listy, tabele)
• Semantycznie bogate (encje, schematy)
• Kontekstowo spójne

llms.txt nie wpływa bezpośrednio na ranking AI Overview, ale wspiera wszystkie trzy elementy. Jeśli wyraźnie wskazujesz primary content, Google łatwiej identyfikuje, co cytować.

4. Encje i semantyka

llms.txt nie zastępuje schema.org, ale go komplementuje. Schema mówi „to jest Product”, llms.txt mówi „to jest główna treść o produkcie, a to są opinie użytkowników”.

W projektach e-commerce widziałem, że połączenie schema.org + llms.txt dawało lepsze wyniki w AI-generated product descriptions niż samo schema.

5. Przypadek: dokumentacja techniczna

Klient: firma SaaS, dokumentacja API, 500+ stron.

Przed llms.txt: ChatGPT cytował losowe fragmenty, często z sekcji „troubleshooting” zamiast „getting started”. Użytkownicy dostawali odpowiedzi typu „spróbuj zresetować token”, zanim poznali podstawy autoryzacji.

Po llms.txt: Wskazaliśmy Primary: /docs/core/*, Auxiliary: /docs/troubleshooting/*. W ciągu 3 tygodni citation rate wzrósł o 40%, a jakość odpowiedzi poprawiła się na tyle, że support ticket rate spadł o 15%.

To nie magia – to po prostu jasna hierarchia.

Kiedy llms.txt ma sens, a kiedy jest zbędny

llms.txt nie jest silver bullet. Są przypadki, gdzie wnosi wartość, i takie, gdzie jest stratą czasu.

llms ma sens jeśli:

Dokumentacja techniczna: Duża hierarchia treści, wyraźny podział core/auxiliary/legacy. llms.txt pomaga LLM-om nawigować strukturę.

Blogi z >100 artykułami: Jeśli prowadzisz blog ekspercki z archiwum, llms.txt pozwala wskazać „najlepsze artykuły” vs. „stare posty”.

Serwisy edukacyjne: Kursy, tutoriale, case studies – llms.txt pozwala rozgraniczyć materiał główny od zasobów dodatkowych.

Serwisy SaaS z wieloma sekcjami: Dokumentacja, blog, changelog, help center – llms.txt zapewnia jasność, co jest primary source.

llms jest zbędny kiedy:

Landing pages: Jedna strona, jeden CTA, zero hierarchii. llms.txt nie wnosi wartości.

Portfolio / strony wizytówki: Mała ilość treści, brak podziału na sekcje. LLM radzi sobie bez wskazówek.

Sklepy z <50 produktami: Jeśli masz dobrze wdrożone schema.org Product, llms.txt jest redundantny. Wyjątek: sklepy z blogiem/poradnikami – wtedy warto rozdzielić product pages od content.

Strony bez ambicji na AI visibility: Jeśli nie zależy Ci na cytowaniach w chatbotach, llms.txt to overhead.

Przypadki graniczne:

Serwisy newsowe: Teoretycznie ma sens (rozdzielenie artykułów od kategorii/tagów), ale praktycznie LLM-y i tak pobierają newsy via RSS/API, nie przez crawling. ROI wątpliwy.

Fora / community: User-generated content to chaos. llms.txt nie zrobi cudu, jeśli treści są niskiej jakości. Lepiej skupić się na moderacji i strukturze kategorii.

Checklist wdrożeniowy

Przed publikacją llms.txt:

1. Audyt architektury informacji

• Zidentyfikuj ścieżki z primary content
• Zidentyfikuj ścieżki z auxiliary content
• Zidentyfikuj śmieciowe ścieżki (admin, user profiles, dynamiczne widoki)
• Sprawdź, czy struktura URL jest stabilna (brak planowanych migracji)

2. Przygotowanie pliku

• Utwórz plik llms.txt w katalogu głównym domeny
• Dodaj sekcję identity (opcjonalna, ale zalecana)
• Dodaj sekcję Primary content z konkretnymi ścieżkami lub wildcards
• Dodaj sekcję Auxiliary content
• Dodaj sekcję Exclude
• Dodaj datę aktualizacji w komentarzu na górze pliku

3. Walidacja techniczna

• Sprawdź, czy plik jest dostępny pod https://domena.com/llms.txt
• Sprawdź, czy nie jest blokowany przez robots.txt
• Sprawdź, czy zwraca status 200
• Sprawdź, czy Content-Type: text/plain; charset=utf-8
• Przetestuj wzorce wildcards (np. /docs/*) – upewnij się, że pasują do realnych URL-i

4. Spójność z innymi sygnałami

• Sprawdź, czy llms.txt jest spójny z sitemap.xml (nie wykluczasz stron, które są w sitemap)
• Sprawdź, czy schema.org jest wdrożone tam, gdzie wskazujesz Primary content
• Sprawdź, czy canonical URL-e są poprawne na stronach primary
• Sprawdź, czy treści primary mają jasną strukturę (headings H1-H3, listy, tabele)

5. Testowanie efektów

• Po 2 tygodniach: sprawdź w Google Search Console, czy crawl rate się zmienił (nie powinien – llms.txt nie wpływa na crawling)
• Po 4 tygodniach: ręcznie przetestuj query w ChatGPT, Claude, Perplexity z nazwą Twojej domeny – sprawdź, czy cytują właściwe sekcje
• Po 8 tygodniach: jeśli masz dostęp do analytics chatbotów (np. Perplexity API), sprawdź citation rate
• Monitoruj referrery – jeśli widzisz ruch z chatbotów, to znak, że LLM-y indeksują i cytują Twoje treści

6. Aktualizacja

• Aktualizuj llms.txt przy każdej dużej zmianie architektury (nowe sekcje, rebranding URL-i, migracja treści)
• Dodaj datę aktualizacji w komentarzu na górze pliku
• Jeśli excludujesz stare treści, rozważ redirect 301 zamiast samego exclude (żeby LLM-y trafiły na nową wersję)
• Regularnie audytuj, czy excluded paths nadal mają sens – czasem sekcje „śmieciowe” stają się wartościowe

7. Dokumentacja wewnętrzna

• Udokumentuj decyzje architektoniczne (dlaczego dana ścieżka jest primary/auxiliary/excluded)
• Poinformuj zespół contentowy, że zmiany w strukturze URL wymagają update’u llms.txt
• Dodaj llms.txt do runbooka deploymentu (żeby nie został nadpisany przy wdrożeniu)

Przeczytaj także: Jak działa algorytm Instagrama w 2025 roku?

Kiedy llms.txt daje realną przewagę, a kiedy jest stratą czasu

llms.txt to narzędzie architektoniczne, nie magiczna wtyczka. Jego wartość zależy od jakości decyzji, które podejmujesz projektując plik – a te decyzje wymagają znajomości architektury informacji, struktury treści i sposobu, w jaki LLM-y konsumują dane.

Nie wdrażaj llms.txt „bo wszyscy to robią”. Wdrażaj, jeśli masz złożoną strukturę treści, zależy Ci na widoczności w generative search i jesteś gotów regularnie aktualizować plik wraz ze zmianami w serwisie.

Jeśli spełniasz te warunki – llms.txt da Ci przewagę. Jeśli nie – lepiej zainwestuj czas w poprawę struktury treści i schema.org.

Krzysztof
SEO coordinator