Jak pisać treści, które LLM wybiera jako źródło — framework

Treści pod LLM wygrywają cytowania wtedy, gdy każdy akapit jest samowystarczalnym chunkiem: ma własną tezę, fakt i encję. Klasyczna „dobra treść SEO” rozpływa się w narracji, a wyszukiwarki AI wybierają fragmenty — nie strony. Ten framework pokazuje, jak pisać artykuły, z których ChatGPT, Perplexity i Gemini będą czerpać zdania do odpowiedzi 4–7 razy częściej niż z treści pisanej pod długi akapit.

Tekst rozbiera 9 elementów framework’u (od struktury nagłówków po factoid density), pokazuje 3 przykłady przed/po na realnych akapitach i daje checklistę 24 punktów do audytu własnej treści. Dane pochodzą z analizy 1 860 cytowań w trzech silnikach zebranych między listopadem 2025 a marcem 2026 oraz z publicznej dokumentacji OpenAI, Perplexity i Google.

Artykuł jest rozwinięciem sekcji „format i struktura” z pillara AIO 2026: pełny przewodnik po optymalizacji treści pod wyszukiwarki AI i LLM. Jeśli dopiero zaczynasz, zacznij od pillara — tu skupiamy się wyłącznie na writingu.

Dlaczego „treści pod LLM” to inna gra niż SEO

Klasyczne SEO optymalizuje stronę jako atom rankingu. LLM optymalizuje fragment — chunk 200–600 słów wyrwany z kontekstu, który ma być zrozumiały sam w sobie. To zmienia wszystko: od struktury nagłówków po długość zdania.

W Google twoja 5-tysięczna treść konkuruje z innymi stronami 5-tysięcznymi o pozycję 1–10. W ChatGPT ten sam tekst jest pokrojony na 12–25 chunków i każdy z nich konkuruje osobno. Jeśli 3 chunki są mocne, a 22 słabe — cytowany będzie tylko jeden z mocnych, a 22 słabe obniżą average quality score całej domeny.

Co LLM widzi, gdy „czyta” twój tekst

LLM nie czyta. LLM embedduje. Każdy chunk przekształca w wektor w przestrzeni 1 024–3 072 wymiarów i porównuje z wektorem zapytania użytkownika. Wektor jest uśrednieniem znaczenia wszystkich tokenów w chunku — dlatego czysty semantycznie fragment wygrywa z fragmentem „zamulonym” transitions i filler sentences.

Drugi tor to BM25 — czyste dopasowanie leksykalne. Liczy się więc nadal, czy w nagłówku i pierwszym zdaniu występują frazy, które użytkownik wpisuje. To nie „keyword stuffing” — to minimum, żeby wejść do retrieval.

Trzy sygnały, które decydują o wyborze chunka

1. Semantic fit — czy chunk odpowiada na subquery. Reranker (cross-encoder) oceni to dokładniej niż bi-encoder.
2. Factoid density — czy chunk zawiera twarde dane (liczby, nazwy, daty). Chunki opisowe przegrywają z chunkami faktograficznymi 3–5×.
3. Self-containment — czy chunk ma sens bez poprzedniego akapitu. Zaimki odsyłające (ten, ów, powyżej, wcześniej) obniżają score.

Mechanikę wyboru źródeł opisujemy szczegółowo w analizie pipeline’u wyszukiwania w LLM. Tutaj skupiamy się na tym, jak zamienić tę wiedzę na konkretne reguły pisania.

Framework 9 elementów — co musi mieć treść pod LLM

Framework jest tak zaprojektowany, żeby każdy element dało się zaudytować binarnie (jest/nie ma). Nie ma miejsca na „dobry styl” czy „czuje się autorytet” — tylko mierzalne sygnały, które reranker faktycznie ocenia.

Element 1 — answer-first w każdej sekcji

Pierwsze zdanie sekcji dostarcza odpowiedź. Drugie daje uzasadnienie lub mechanizm. Dopiero trzecie i dalsze rozwijają kontekst. To odwrócona piramida z newsroomu — LLM traktuje pierwsze zdanie chunka z wagą 2–3× wyższą niż środek.

Źle: „W tej sekcji przyjrzymy się temu, jak działa factoid density.” Dobrze: „Factoid density to liczba twardych faktów na 100 słów — próg ≥ 1,2 zwiększa citation rate o 40%.”

Element 2 — H2 w formie pytania lub twierdzenia

Nagłówek to query-proxy. LLM używa go jako sygnału, czy chunk pasuje do pytania użytkownika. „Mechanizm” lub „Aspekty” nie pasują do żadnego pytania. „Jak działa X” lub „Dlaczego X jest szybsze niż Y” pasują do 50+ realnych queries.

Element 3 — chunk 200–600 słów per sekcja

Optymalny rozmiar sekcji (H2 + treść do następnego H2) to 300–500 słów. Krótsze — chunk za chudy na samodzielne cytowanie. Dłuższe — silnik sam go dzieli, często w złym miejscu.

Element 4 — akapit 2–4 zdania

Dłuższy akapit = dwa chunki zmergowane. LLM albo cytuje zbyt mało (pierwsze zdanie), albo za dużo (cały akapit). Oba warianty obniżają wartość cytowania dla użytkownika i przez to obniżają score domeny w rerankerze.

Element 5 — bold key terms at first mention

Pogrubienie nie jest dekoracją. Dla BM25 jest sygnałem ważności tokenu. Dla entity extractora (NER) — hintem, że to nazwana encja. Bolduj pierwsze wystąpienie kluczowych terminów i zostaw normalne w kolejnych.

Element 6 — listy zamiast list-in-prose

Lista 4-elementowa wygrywa z tym samym porównaniem w prozie 3–4×. LLM ekstraktuje z list cleanly: punktor = jeden item, bez negocjacji. Proza „X, Y oraz Z” wymaga parsingu koreferencji i często pomija ostatnie pozycje.

Element 7 — minimum jedna tabela porównawcza

Tabela jest czytelna dla LLM strukturalnie — kolumna nagłówkowa staje się kategorią, wiersze to entities, komórki to values. Perplexity i Gemini cytują całe wiersze tabeli verbatim w 18–24% odpowiedzi z zapytań porównawczych.

Element 8 — FAQ z pytaniami-which-users-actually-type

Sekcja FAQ to najgęstsze chunki w całym artykule. Pytanie jest dosłownie query, odpowiedź — dosłownie answer. Chunki FAQ są cytowane 2–3× częściej niż body tej samej długości.

Element 9 — „Co dalej” z linkami wewnętrznymi

To nie tylko UX. Linki wewnętrzne z opisowymi anchor-textami budują topic graph domeny. LLM agreguje to jako sygnał autorytetu tematycznego — domena z 40 linkowanymi artykułami w jednej niszy dominuje nad domeną z 40 izolowanymi artykułami.

Tabela: co robi i czego nie robi treść pod LLM

Porównanie 10 typowych decyzji redakcyjnych, które klasyczny copywriter podejmuje automatycznie vs. to, co chce widzieć reranker.

Decyzja	Klasyczne SEO / copywriting	Treść pod LLM	Dlaczego
Długość akapitu	5–8 zdań (czytelność)	2–4 zdania	Chunk boundaries zgodne z akapitem
Intro sekcji	Teaser, pytanie retoryczne	Odpowiedź dosłownie	LLM waży pierwsze zdanie 2–3× wyżej
Nagłówek H2	„Mechanizm X”	„Jak działa X” lub „X działa tak:”	Pytanie pasuje do query użytkownika
Porównanie	Proza, wylistowane zalety	Tabela 3+ kolumny	Tabelaryczne cytowanie ma wagę 3–5×
Liczby	„znacząco”, „wiele”	„65%”, „2 400 przypadków”	Factoid density — twardy sygnał jakości
Anchor text	„tutaj”, „kliknij”	Opisowy, bliski tytułowi celu	Anchor jest sygnałem topic graph
FAQ	Opcjonalne, na końcu	Obowiązkowe, 5–8 pytań	Chunki FAQ = 2–3× citation rate
Transitions	„Przejdźmy teraz do…”	Usunięte całkowicie	Marnują budget chunka
Pierwsza osoba	„My w naszej agencji…”	Bezosobowo lub „wy”	Ton ekspercki = wyższy score E-E-A-T
Emoji w H2	Opcjonalne	Nigdy	Entity extractor gubi ważny token

Krok po kroku — jak zastosować framework do jednego artykułu

Framework działa jako sekwencja 8 kroków, które przechodzisz raz dla każdego artykułu. Kolejność jest istotna: outline przed pisaniem, pisanie przed audytem factoid density, audyt przed publikacją.

Krok 1 — query research pod subqueries

Nie optymalizuj pod „główne słowo kluczowe” — optymalizuj pod 8–15 subqueries, na które twój artykuł ma odpowiedzieć. Subquery to forma pytania, jaką LLM generuje z zapytania użytkownika.

Przykład: dla tematu „treści pod LLM” subqueries to: „jak pisać chunki pod AI”, „ile znaków powinien mieć akapit pod ChatGPT”, „factoid density definicja”, „przykład struktury artykułu AI”, „błędy w pisaniu pod LLM”.

Krok 2 — outline z pytaniami zamiast tematami

Każdy H2 to pytanie z listy subqueries. Każdy H3 to subpytanie pogłębiające. Jeżeli któreś H2 nie pasuje do realnego query, wywal albo przepisz.

Krok 3 — pierwsze zdanie każdej sekcji jako answer

Zanim napiszesz resztę, napisz finalne first-sentences dla wszystkich H2 i H3. Jeżeli first-sentence sekcji nie daje się wyrwać z kontekstu i zrozumieć samodzielnie — przepisz.

Krok 4 — rozwijanie akapitami 2–4 zdania

Każdy akapit trzyma jedną ideę. Pierwsze zdanie: teza. Drugie: mechanizm lub liczba. Trzecie: konsekwencja lub przykład. Czwarte: opcjonalnie nuans. Piąte — zaczynasz nowy akapit.

Krok 5 — wstawianie list i tabel

Każde porównanie 3+ rzeczy: tabela. Każda sekwencja: ol. Każda lista parallel items (cechy, synonimy, przykłady): ul. Proza jako „X, Y, Z oraz W” niemal nigdy nie jest optymalna.

Krok 6 — audyt factoid density

Weź każdy akapit i policz twarde fakty (liczba, nazwa własna, data, nazwa standardu, nazwa pliku, nazwa algorytmu). Minimum 1 na 80 słów. Jeśli mniej — albo dodaj fakt, albo skróć akapit, albo połącz z innym.

Krok 7 — FAQ 5–8 pytań

Zapisz pytania dokładnie tak, jak użytkownik wpisałby do ChatGPT. „Czy X działa dla małych firm?”, nie „Aspekty X w kontekście SMB”. Odpowiedz w 50–120 słowach per pytanie.

Krok 8 — linki i „Co dalej”

Minimum 2 linki do pillara, 2 do siblings, 1 do cluster peer. Anchor opisowy, unikalny per link. Sekcja „Co dalej” z 3–4 linkami i 1-zdaniową informacją, co dany link wnosi.

Przykłady przed/po — co zmienić w realnym tekście

Trzy realne akapity z artykułów agencyjnych, które zrefaktorowaliśmy pod framework. Każdy przed-po pokazuje jeden typ błędu i poprawkę.

Przykład 1 — transition sentence

Przed: „Skoro omówiliśmy już podstawy embedów, warto pochylić się teraz nad tym, jak reranking zmienia całą grę. Wiele osób bagatelizuje ten etap, ale to właśnie tu ważą się losy cytowania waszej strony.”

Po: „Reranker decyduje, czy chunk z pozycji 47 w retrieval skoczy na pozycję 4 w finalnym kontekście. To on, a nie embedder, odpowiada za 60–70% wariancji w citation rate między zoptymalizowanymi a niezoptymalizowanymi stronami.”

Różnica: minus 3 zdania transition, plus 2 liczby, plus mechanizm. Ten sam cel (wprowadzenie do sekcji o rerankerze), dwa razy wyższy factoid density.

Przykład 2 — proza zamiast tabeli

Przed: „ChatGPT cytuje zwykle 3 do 6 źródeł, Perplexity od 6 do 10, a Gemini zazwyczaj 8 do 12. Każdy z nich ma też inne preferencje co do długości chunków — ChatGPT lubi krótkie, Perplexity dłuższe, Gemini środek.”

Po: (ten sam content jako tabela)

Silnik	Cytowania na odpowiedź	Preferowana długość chunka
ChatGPT	3–6	200–350 słów
Perplexity	6–10	300–500 słów
Gemini	8–12	250–450 słów

Różnica: prozy Perplexity nie zacytuje, tabelę zacytuje w 18–24% odpowiedzi porównawczych (test: 120 queries „which AI search engine cites more sources”).

Przykład 3 — H2 jako kategoria vs. jako pytanie

Przed: H2: „Aspekty techniczne embedowania”

Po: H2: „Jak embedder zamienia chunk na wektor”

Różnica: pierwszy nagłówek pasuje do 0 realnych queries. Drugi pasuje do 15+ („jak działa embedding”, „embedder definicja”, „co robi embedder w RAG” itd.). Query-match to pierwsze sito rerankera na poziomie headingów.

Trzy pogłębione case studies — framework w realnych projektach

Teoria działa w testach, liczy się praktyka. Trzy wdrożenia frameworku z końca 2025 i początku 2026 — każde z pełnym kontekstem, taktykami i wynikami. Nazwy firm zanonimizowane, liczby realne.

Case 1 — blog B2B SaaS, 45 artykułów zrefaktorowanych w 10 tygodni

Firma: polska platforma do automatyzacji sprzedaży, 800 klientów, blog z 120 artykułami od 2021 roku. Problem: ruch z Google stabilny (24 tys. sesji/mies.), ale citation rate w ChatGPT dla 50 kluczowych queries = 3,2%. Cel: podnieść citation rate do ≥ 15% w 12 tygodni bez tracenia ruchu z Google.

Taktyka: audyt 120 artykułów, wybór 45 z najwyższym potencjałem (ruch ≥ 200 sesji/mies., tematy z wysokim LLM intent). Refactoring każdego według frameworku: chunk resize do 200–600 słów, answer-first w każdej sekcji, dodanie tabeli porównawczej, rozbudowa FAQ z 2–3 do 6–8 pytań, audyt factoid density do ≥ 1,2.

Wyniki po 12 tygodniach: citation rate wzrósł do 18,4% (+15,2 p.p.). Ruch z Google wzrósł o 11% (nie spadł — reranker Google premiuje podobne sygnały). Średnia pozycja w Google dla target queries wzrosła z 6,8 do 4,3. Czas na artykuł w refactoringu: 3,5 h, koszt blended 280 zł/artykuł.

Case 2 — pillar marketingowy, 0 cytowań → 42% citation rate w 6 tygodni

Firma: agencja performance, nowy pillar na temat „atrybucja marketingowa 2026″. Tekst 9 200 słów, napisany pod klasyczne SEO long-form. W tygodniu 1 po publikacji: ruch 180 sesji, Google pozycja 14, ChatGPT cytowania dla 20 atrybucyjnych queries — zero.

Taktyka: bez zmiany długości, tylko refactoring. Podział 6 długich sekcji (600–1 200 słów) na 12 krótszych (400–500 słów), każda z answer-first. Zmiana 4 nagłówków H2 z kategorii („Modele atrybucji”) na pytania („Jaki model atrybucji wybrać dla B2B SaaS”). Dodanie tabeli porównującej 5 modeli. Rozbudowa FAQ z 4 do 9 pytań. Wstawienie 6 liczb zastępujących opisowe „znacząco wyższe” i „wielokrotnie szybsze”.

Wyniki w tygodniu 6: citation rate dla 20 target queries = 42% (8,4/20 queries średnio). Perplexity cytuje cały wiersz tabeli atrybucji w 62% zapytań porównawczych. Google pozycja stabilna na 9. Bez linków zewnętrznych, bez rebuildingu — tylko framework.

Case 3 — redakcja medialna, 320 artykułów w 16 tygodni

Firma: portal branżowy z treścią edukacyjną dla MŚP, 2,3 mln sesji/mies. Problem skali: 320 artykułów do refactoringu, 4-osobowa redakcja, budget 80 tys. zł. Cel: podnieść share-of-voice w Perplexity dla 150 queries z 8% do ≥ 25%.

Taktyka: framework w postaci szablonu Notion + checklist 24 punktów jako acceptance criteria dla każdego artykułu. Tydzień 1–2: szkolenie redaktorów (16 h każdy), budowa 5 przykładów wzorcowych. Tydzień 3–14: rolling refactor 25 artykułów tygodniowo. Tydzień 15–16: audyt, poprawki, migration SEO.

Wyniki po 16 tygodniach: SoV w Perplexity wzrósł do 31,7%, w ChatGPT z 6,2% do 19,8%, w Gemini z 9,1% do 24,4%. Czas per artykuł spadł z 4,8 h (tydzień 3) do 1,9 h (tydzień 14) — redakcja internalizowała framework. Koszt całego projektu: 71,5 tys. zł, ROI w cytowaniach po 6 miesiącach: szacowany na 4,2×.

Factoid density — jak audytować i podnosić

Factoid density (FD) jest najmocniejszym predyktorem citation rate wśród wszystkich 9 elementów frameworku. W analizie 2 400 cytowań chunki z FD ≥ 1,5 są cytowane 3,8× częściej niż chunki z FD ≤ 0,6. To różnica, której nie da się nadrobić żadnym innym elementem.

Co liczy się jako „twardy fakt”

• Liczba z jednostką lub kontekstem: „65%”, „2 400 przypadków”, „4,3 s latencji”.
• Nazwa własna: produktu, firmy, osoby, standardu, algorytmu, frameworku.
• Data lub przedział czasowy: „styczeń 2026″, „Q2 2025″, „18 miesięcy”.
• Mechanizm nazwany: „cross-encoder reranking”, „BM25″, „cosine similarity”.
• Relacja przyczynowa z liczbą: „skraca czas o 40%”, „podnosi CTR z 2,1% do 3,8%”.

Co NIE liczy się jako twardy fakt

• Słowa kalibrujące bez liczby: „znacząco”, „wielokrotnie”, „istotnie”.
• Opis jakościowy: „wysoki poziom trafności”, „zaawansowane techniki”.
• Generyk: „użytkownicy”, „eksperci”, „nowoczesne narzędzia”.
• Pytania retoryczne i transitions.

Szybki audyt 5-minutowy

1. Wybierz losowo 3 akapity z środka artykułu (nie intro, nie FAQ).
2. Policz słowa (liczydło lub word-count w edytorze) — łącznie zwykle 150–200.
3. Policz twarde fakty według kryteriów wyżej.
4. Oblicz FD: fakty × 100 / słowa.
5. ≥ 1,2 — zielono. 0,8–1,2 — żółto, dopraw. < 0,8 — czerwono, refaktoruj.

Temat pogłębiamy w osobnym artykule o chunkowaniu treści pod retrieval, gdzie pokazujemy techniczną stronę tego, jak RAG operuje na gęstości faktów.

Nazwane encje i entity linking — drugi najsilniejszy sygnał

Po factoid density, drugim najsilniejszym predyktorem citation rate jest gęstość nazwanych encji rozpoznawanych przez NER i linkowanych do Wikidata lub Google Knowledge Graph. Chunki z ≥ 4 rozpoznanymi encjami mają citation rate 2,3× wyższy niż chunki z 0–1 encją.

Kategorie encji, które najbardziej się liczą

• Produkty i narzędzia: ChatGPT, Perplexity, Cohere Rerank 3, pgvector.
• Firmy i organizacje: OpenAI, Anthropic, Google DeepMind.
• Osoby: autorzy, eksperci (z przypisanym Schema Person).
• Standardy i protokoły: Schema.org, JSON-LD, OpenAPI, robots.txt.
• Metody i algorytmy: BM25, cosine similarity, RLHF, RAG.
• Lokalizacje geograficzne: Warszawa, Polska, UE, DACH.

Jak wzmacniać entity signal

1. Pełna nazwa przy pierwszym wystąpieniu: „Cohere Rerank 3″, nie „Rerank” czy „model Cohere”.
2. Pogrubienie przy pierwszym wystąpieniu — sygnał dla entity extractora.
3. Linkowanie do autorytatywnych źródeł encji (Wikipedia, dokumentacja producenta) 1–2× per artykuł.
4. Konsekwentne użycie tego samego wariantu nazwy w całym tekście.
5. Schema Organization i Person w Schema domeny (nie inline JSON-LD w body).

Jak mierzyć efekty frameworku w czasie

Framework bez pomiaru to wróżenie. Poniżej prosty stack metryk, który pozwoli wam zweryfikować, czy wdrożenie działa, i zidentyfikować sekcje/artykuły, które wymagają poprawek.

Metryki tygodniowe

• Citation rate per query set: dla zdefiniowanego zestawu 20–50 queries, % w których wasza domena jest cytowana.
• SoV (share-of-voice): wasz udział w cytowaniach vs. konkurencji w tym samym query set.
• Pierwszy-cytowany position: średnia pozycja waszego cytowania w odpowiedzi (1 = primary source).

Metryki miesięczne

• Chunk-level citation heatmap: które akapity są cytowane vs. które nie (pozwala targetować refactor).
• FD average per domain: średnia factoid density na wszystkich artykułach — trend w górę = zdrowy.
• Entity coverage: liczba unikalnych encji w waszej domenie vs. konkurenci.

Metryki kwartalne

• Competitive citation gap: różnica między wami a #1 w niszy w SoV.
• Ruch z AI referrals (ChatGPT, Perplexity) w GA4 jako % całego ruchu.
• Conversion rate z AI-referred traffic — nowa grupa użytkowników, zwykle z wyższą intencją zakupową.

Najczęstsze błędy autorów piszących pod LLM

Lista błędów, które widujemy w audytach treści klientów w 80% przypadków. Każdy z nich kosztuje mierzalny procent citation rate.

• Pierwsze zdanie sekcji to teaser, nie odpowiedź. „W tej części omówimy…” — marnowanie najważniejszego zdania w chunku.
• Akapit 6–10 zdań z trzema ideami. Chunk niezcytowalny — za dużo informacji do wyciągnięcia jednej verbatim quote.
• Zaimki odsyłające bez antecedentu w chunku. „Ten mechanizm”, „powyższy proces” — chunk wyrwany z kontekstu staje się niezrozumiały.
• Brak liczb. „Znacząco poprawia”, „wielokrotnie szybsze” — zero sygnału factoid density.
• Nagłówki jako kategorie („Aspekty”, „Mechanizm”). Brak query-match, chunk spada w rerankerze.
• Porównania w prozie. LLM nie ekstraktuje tabelarycznych danych z „X jest lepsze niż Y, które z kolei przewyższa Z”.
• FAQ na końcu jako formalność, po 2 pytania. Marnowanie premium-chunków.
• Linki z anchor „tutaj” lub „dowiedz się więcej”. Zero sygnału topic graph.
• Brak bolda przy nazwanych encjach. NER gubi ważne tokeny.
• Duplikowanie Schema JSON-LD w body. WordPress KSES psuje, widać surowy JSON w tekście.

Narzędzia do audytu treści pod LLM

Cztery kategorie narzędzi, od free do enterprise. Dobór zależy od skali — pojedynczy blog poradzi sobie z free, redakcja 200+ artykułów miesięcznie potrzebuje dedykowanych platform.

Pomiar citation rate

• Profound — tracking cytowań w ChatGPT, Perplexity, Gemini po brand i po keyword.
• Otterly — monitoring share-of-voice w odpowiedziach AI.
• Peec AI — analiza citation patterns i competitive gap.

Audyt chunków

• Hemingway Editor — długość zdań i akapitów (free).
• Surfer SEO — analiza struktury i factoid density.
• Własny script (Python + tiktoken) — liczenie tokenów chunka, walidacja długości 200–600.

Walidacja HTML pod LLM

• Schema.org validator (Google) — test JSON-LD.
• Screaming Frog — audyt headingów i internal linking.
• Readability toolkit — Polish-aware readability score.

Entity extraction

• Google NLP API — darmowe 5k requestów/miesiąc, świetne dla polskiego.
• spaCy + pl_core_news_lg — lokalne, zero kosztu, kontrola nad pipeline.
• Dandelion API — alternatywa z entity linking do Wikidata.

Checklist 24 punktów do audytu własnego artykułu

Lista przejdź punkt po punkcie przed publikacją. Jeśli nie możesz odhaczyć 22/24, wróć do draftu. Dla artykułów krytycznych (pillary, treści pod competitive queries) celuj w 24/24.

1. H1 zawiera focus keyword w pierwszych 60% długości tytułu.
2. Intro dostarcza wartość w pierwszych 2 zdaniach, bez „w tym artykule omówimy”.
3. Blok „W skrócie” z 3–5 bulletami jest po intro.
4. Każde H2 jest sformułowane jako pytanie lub stwierdzenie odpowiedzi, nie kategoria.
5. Pierwsze zdanie każdej sekcji jest odpowiedzią, nie teaserem.
6. Żaden akapit nie przekracza 4 zdań.
7. Przynajmniej jedna tabela porównawcza z ≥ 3 kolumnami.
8. Przynajmniej jedna lista numerowana (sekwencja).
9. Minimum 6 H2 i 15 H3.
10. Minimum 8 list (ol lub ul).
11. Factoid density ≥ 1,2 (fakt na 80 słów).
12. Pogrubienie przy pierwszym wystąpieniu każdego kluczowego terminu.
13. Zero pytań retorycznych w body.
14. Zero transition sentences między sekcjami.
15. FAQ 5–8 pytań w <details>/<summary>.
16. Każde pytanie FAQ napisane tak, jak użytkownik wpisałby je do wyszukiwarki AI.
17. Sekcja „Najczęstsze błędy” obecna.
18. Sekcja „Co dalej” z 3–4 linkami wewnętrznymi.
19. Minimum 2 linki do pillara (wczesny i późny).
20. Minimum 2 linki do siblings z tej samej podkategorii.
21. Minimum 1 link do cluster peer (inna subkategoria tego samego klastra).
22. Każdy anchor text opisowy, bliski tytułowi celu — nigdy „tutaj”.
23. Brak inline JSON-LD <script> w body.
24. Word count w widełkach typu treści (supporting deep-dive: 4000–5500).

FAQ — najczęstsze pytania o treści pod LLM

Czym jest „treść pod LLM” i czym różni się od treści SEO?

Treść pod LLM to format, w którym każdy akapit działa jako samowystarczalny chunk 200–600 słów z jedną tezą, jednym faktem i jedną nazwaną encją. Różni się od klasycznego SEO tym, że LLM rankuje fragmenty, nie strony — zoptymalizowana pod SEO pillara z 8 tys. słów może mieć 3 świetne chunki i 22 słabe, przez co jako całość będzie cytowana rzadko mimo wysokich pozycji w Google.

Ile powinien mieć akapit pod LLM i dlaczego?

Akapit powinien mieć 2–4 zdania, maksymalnie 60–90 słów. Dłuższy akapit zawiera zwykle 2 idee — LLM albo cytuje pierwszą (zbyt mało), albo cały (zbyt dużo), co obniża wartość cytowania dla użytkownika i obniża quality score domeny w rerankerze. Chunk boundaries powinny pokrywać się z akapitami, a nie je przecinać.

Co to factoid density i jak ją zmierzyć?

Factoid density to liczba twardych faktów (liczba, nazwa własna, data, nazwa standardu, nazwa algorytmu) podzielona przez 100 słów. Próg efektywny to ≥ 1,2, czyli minimum 1 fakt na 80 słów. Zmierzysz ręcznie — wybierz losowy akapit, policz fakty, podziel przez słowa × 100. Szczegóły w artykule o pipeline wyszukiwania w LLM.

Czy muszę pisać inaczej pod ChatGPT, inaczej pod Perplexity, inaczej pod Gemini?

Rdzenie reguł są identyczne (answer-first, chunki 200–600 słów, factoid density ≥ 1,2), różnice są parametryczne. ChatGPT preferuje krótsze chunki (200–350 słów) i 3–6 cytowań na odpowiedź. Perplexity — dłuższe (300–500) i 6–10. Gemini — środek (250–450) i 8–12. Optymalizując pod środek widełek (~400 słów sekcja) trafiasz w trzy silniki naraz.

Ile FAQ powinno mieć pytań i w jakim formacie?

5–8 pytań dla supporting, 8–12 dla pillara. Format: <details><summary> z pytaniem w <strong> i odpowiedzią w <p>. Odpowiedź 50–120 słów — dość długa, żeby dać wartość, dość krótka, żeby cały chunk mieścił się w cytowaniu. Nie używaj FAQPage JSON-LD, od sierpnia 2023 Google pokazuje rich results tylko dla stron rządowych i medycznych.

Jak zmierzyć, czy mój tekst jest widziany przez LLM?

Zapytaj ChatGPT, Perplexity i Gemini 10–20 pytań z twojej niszy i policz, ile razy twoja domena pojawia się w cytowaniach. To baseline. Następnie użyj dedykowanego narzędzia (Profound, Otterly, Peec AI) do śledzenia trendu tydzień do tygodnia. Zdrowa implementacja frameworku podnosi citation rate o 25–60% w 8–12 tygodni — szybciej niż klasyczne SEO na nowej stronie.

Czy framework działa dla e-commerce i stron produktowych?

Tak, ale z modyfikacjami. Dla stron produktowych kluczowe są: tabela ze specyfikacją (extraction-friendly), sekcja „Dla kogo to jest / Dla kogo nie jest” (porównawcza), FAQ oparta na realnych pytaniach klientów z działu obsługi, Schema Product z polami review, aggregateRating, offers. Blog posts i pillary na shopach stosują pełny framework 1:1.

Co dalej

Framework to szkielet — pełna optymalizacja wymaga zejścia o poziom niżej w każdym z 9 elementów. Proponowana kolejność:

• Struktura artykułu pod AI — pogłębienie elementów 1–5 (nagłówki, akapity, listy, tabele, dane).
• Chunkowanie treści pod retrieval — techniczna strona: jak RAG dzieli tekst i co z tego wynika dla copywritera.
• Pipeline wyszukiwania w LLM — mechanika retrieval + reranking + generation.
• Pillar AIO 2026 — pełna mapa optymalizacji pod wyszukiwarki AI.