Modele językowe takie jak ChatGPT, Claude, Perplexity i Gemini nie czytają dziś całych artykułów. One pobierają fragmenty tekstu z indeksu wektorowego, a potem składają z nich odpowiedź. Jeśli twoja treść nie jest dobrze pocięta na sensowne kawałki, jeśli nagłówki nie sygnalizują kontekstu, a schema.org nie potwierdza struktury, to nawet najlepszy artykuł zostaje pominięty na rzecz konkurencji, której tekst lepiej współpracuje z mechanizmem retrieval.
W tym przewodniku pokazuję, jak w 2026 roku optymalizować treści pod retrieval w praktyce: jak chunkować artykuły, czym są embeddingi z perspektywy redaktora (a nie inżyniera), które typy schema.org realnie zwiększają widoczność w odpowiedziach LLM oraz jakie KPI śledzić. Materiał jest oparty o publikowane prace zespołów Anthropic i OpenAI nad RAG (retrieval augmented generation), wytyczne Google Search Central dotyczące strukturalnych danych oraz nasze własne wdrożenia na blogach SaaS i e-commerce.
Czym jest retrieval i dlaczego treści muszą być pod niego optymalizowane
Retrieval to proces, w którym system AI wyszukuje fragmenty dokumentów w wektorowej bazie danych, zanim przekaże je modelowi językowemu jako kontekst. Zasada jest prosta: model nie pamięta całego internetu, więc przed wygenerowaniem odpowiedzi sięga po najbardziej trafne fragmenty (tzw. chunki) i opiera na nich konkretne zdania. To podejście znane jest pod nazwą RAG, czyli Retrieval Augmented Generation. Anthropic, OpenAI oraz Google opisują wariacje tej architektury w swojej dokumentacji.
Z perspektywy widoczności marki zmienia to wszystko. Jeszcze trzy lata temu strategia SEO ograniczała się do słów kluczowych, linków i Core Web Vitals. Dziś dochodzą trzy nowe warstwy: granularność informacji (czy pojedynczy akapit niesie kompletną odpowiedź), semantyczna gęstość (jak czytelna jest treść dla embeddingu) oraz maszynowa interpretowalność (czy schema.org potwierdza, czym dokładnie jest dany fragment). Jeżeli interesuje cię, jak te warstwy zmieniają codzienną pracę redakcji, polecam wcześniejszy materiał o podstawach AIO i różnicach względem klasycznego SEO.
Jak retrieval ocenia twój artykuł
Indeksator dzieli twój tekst na fragmenty (chunki), zamienia każdy chunk na wektor (embedding) i zapisuje go w bazie wektorowej. Gdy użytkownik zadaje pytanie w ChatGPT lub Perplexity, system zamienia zapytanie również na wektor, a następnie szuka chunków najbliższych temu wektorowi w przestrzeni semantycznej. Im bliższy chunk, tym większa szansa, że trafi do kontekstu modelu i stanie się źródłem cytowania w odpowiedzi.
To oznacza, że jeden źle zbudowany chunk (np. akapit, który zaczyna się od zaimka odnoszącego się do poprzedniego zdania bez powtórzenia kontekstu) zostanie pominięty, nawet jeśli artykuł jest świetny. Retrieval nie czyta całości; ocenia każdy fragment osobno.
Dwa wektory porównań, które rządzą cytowaniem
W praktyce pomiędzy zapytaniem użytkownika a twoim chunkiem rozgrywają się dwa porównania. Pierwsze to klasyczne podobieństwo cosinusowe wektorów (ile semantycznie znaczy zapytanie i fragment). Drugie to tzw. reranking, w którym osobny model (typu Cohere Rerank lub Voyage Rerank) decyduje, które z TOP 50 fragmentów najlepiej odpowiadają na intencję pytania. Reranker patrzy na strukturę chunka, jego tytuł, sąsiedztwo, a nawet na nazwę domeny. Dlatego niedoszacowane bywa znaczenie pełnego kontekstu w pierwszych zdaniach: reranker dostaje zwykle tylko 200 pierwszych tokenów, więc to one decydują, czy chunk awansuje do finałowej listy cytowań.
Dla redaktora wniosek jest jeden: w pierwszych dwóch zdaniach każdej sekcji powinny pojawić się zarówno temat główny artykułu, jak i konkretna fraza pytająca, na którą sekcja odpowiada. To rozkład bezpieczeństwa, który pokrywa oba etapy: retrieval wektorowy i reranking kontekstowy.
Najważniejsze zasady chunkowania
Chunkowanie to cięcie treści na samowystarczalne fragmenty. Brzmi banalnie, ale zdecydowana większość artykułów na polskim internecie tego nie robi: zdania są długie, akapity zaczynają się od „W związku z tym”, „Powyżej omówiliśmy” lub „To pokazuje, że”, a same nagłówki używają sloganów zamiast pytań i konkretów. Każdy taki element odbiera fragmentowi szansę na bycie wyłowionym przez retrieval.
Pięć zasad chunkowania, które działają w 2026 roku
- Akapit = jeden samodzielny fakt. Każdy akapit powinien być zrozumiały bez czytania poprzedniego. Zamiast „W związku z tym warto rozważyć”, pisz „Hub-and-spoke ma sens dla blogów powyżej 30 artykułów, ponieważ koncentruje moc linków na stronach pillar”.
- Nagłówki w formie pytania lub konkretnego twierdzenia. Modele językowe traktują H2 i H3 jako sygnał kontekstu fragmentu. Nagłówek „Jak wdrożyć schema FAQPage w 5 krokach” zostanie sparowany z chunkiem dokładniej niż „Schema FAQPage”.
- Stała długość 250–400 słów na sekcję pod jednym H2. Większość systemów RAG operuje na chunkach 300–800 tokenów. Sekcje krótsze niż 200 słów są często łączone, co rozmywa kontekst, a dłuższe niż 600 słów są dzielone w przypadkowych miejscach.
- Liczby, daty i wartości w jednym zdaniu z pytaniem. Jeśli odpowiadasz na pytanie „ile kosztuje plan Pro Perplexity”, podaj odpowiedź w tym samym akapicie, co pytanie, idealnie w pierwszych dwóch zdaniach. Retrieval ocenia spójność pytanie–odpowiedź wewnątrz fragmentu.
- Listy i tabele jako sygnał strukturalny. Listy numerowane i tabele HTML są częściej cytowane niż prozy o tych samych informacjach, ponieważ mają wyraźną granicę chunka i czytelną strukturę dla parserów.
W praktyce w naszej redakcji stosujemy regułę „każdy nagłówek H3 ma być potencjalnym przyciskiem na karcie odpowiedzi w Google AI Overviews”. Jeśli H3 brzmi jak nagłówek prasowy, to znaczy, że nie nadaje się do retrievalu. Powinno brzmieć jak pytanie czytelnika lub jednoznaczna definicja.
Co mówi badanie Anthropic o context-aware chunking
W połowie 2024 roku Anthropic opublikował technikę contextual retrieval, w której do każdego chunka doklejany jest krótki kontekst dokumentu (np. „Ten fragment jest częścią raportu rocznego Acme za Q3 i opisuje przychody segmentu cloud”). Zmniejszało to liczbę nieudanych retrievals o 49%. Z perspektywy redaktora oznacza to coś prostego: pierwsza linijka każdego akapitu powinna referować do tematu artykułu, a nie tylko do bezpośrednio poprzedzającego zdania. Innymi słowy, pisz tak, jakby każdy akapit miał trafić do osoby, która nie czytała wstępu.
W naszym workflow przekładamy to na prostą regułę redakcyjną: każdy akapit otwieramy zdaniem zawierającym hasło tematu, choćby pośrednio. Zamiast „Pomaga to w kilku scenariuszach”, piszemy „Chunkowanie pomaga, gdy artykuł trafia do retrievalu w ChatGPT lub Perplexity, ponieważ każdy fragment otrzymuje wtedy własny kontekst”. Brzmi to redundantnie dla człowieka, który właśnie przeczytał poprzedni akapit, ale embedding traktuje akapit jako samodzielny dokument, więc dodatkowy kontekst nie jest powtórzeniem. To jest darmowy boost cytowalności, który redaktor może wprowadzić od ręki bez żadnych narzędzi.
Embeddingi: jak wpływają na cytowania
Embedding to wektor liczb (zwykle 1024 lub 1536 wymiarowy), który reprezentuje znaczenie fragmentu tekstu. Z perspektywy redaktora liczy się jedna rzecz: dwa teksty o podobnym znaczeniu mają podobne wektory, dwa o różnym mają wektory dalekie od siebie. Cała walka o widoczność w AI sprowadza się do tego, czy twój chunk leży „blisko” typowych zapytań użytkowników w przestrzeni embeddingów.
Trzy praktyki, które poprawiają jakość embeddingu
- Konkretne nazwy własne i numery wersji. „GPT-4o” jest dla embeddingu czymś innym niż „nowy model OpenAI”. Modele embeddingowe (np. text-embedding-3-large lub Voyage AI) traktują encje jako osobne tokeny i są dzięki nim w stanie precyzyjniej zlokalizować chunk.
- Polski język bez kalek. Embeddingi wielojęzyczne radzą sobie z polskim, ale tracą jakość, gdy tekst jest tłumaczony słowo w słowo z angielskiego. Naturalny polski („wskaźnik konwersji wzrósł o 18%”) zostaje lepiej osadzony niż kalka („nasz konwersyjny rate się zwiększył o 18%”).
- Powtarzanie kontekstu na początku sekcji. Pierwsze zdanie każdego H2 powinno powtarzać główne hasło tematu artykułu. To brzmi nadmiarowo dla człowieka, ale to właśnie zwiększa „masę” semantyczną fragmentu.
Jeżeli planujesz głębsze podejście do strony technicznej, warto dorobić własny knowledge base z indeksem wektorowym dla treści marki. Pisaliśmy o tym w opracowaniu o AIO dla SaaS 2026 (pricing, docs, comparison pages), gdzie własny indeks wektorowy obsługuje też wewnętrznego asystenta produktowego i dopina to do treści blogowych przez wspólne embeddingi.
Schema.org pod retrieval: które typy realnie pomagają
Wbrew popularnej mitologii, schema.org nie wpływa bezpośrednio na embedding. Wpływa na coś innego: na warstwę extraction, w której parsery LLM próbują rozpoznać, czym jest dany fragment dokumentu, zanim w ogóle trafi do indeksu wektorowego. Innymi słowy, schema mówi modelowi: „ten kawałek to definicja produktu”, „ten to pytanie i odpowiedź”, „ten to instrukcja krok po kroku”. Dzięki temu chunk dostaje etykietę, która zwiększa szansę dopasowania go do pytania o tej samej naturze.
Pięć typów schema, które warto wdrożyć w 2026 roku
| Typ schema | Kiedy stosować | Realny wpływ na cytowanie |
|---|---|---|
| Article (z dataPublished, author, citation) | Każdy artykuł blogowy | Bazowy sygnał: model wie, że to dziennikarski materiał i może go zacytować z autorstwem. |
| FAQPage | Sekcje FAQ na końcu artykułu i osobne strony pytań | Bardzo wysoki: pary pytanie–odpowiedź trafiają niemal 1:1 do AI Overviews i Perplexity Discover. |
| HowTo | Tutoriale, przewodniki krok po kroku | Wysoki: cytowane głównie w odpowiedziach na zapytania zaczynające się od „jak”. |
| SoftwareApplication | Recenzje narzędzi, porównania produktów | Bardzo wysoki w niszach SaaS i AI tools, gdzie LLM wymienia konkretne aplikacje z cenami. |
| Dataset | Strony z surowymi danymi (CSV, raporty) | Średni, ale rosnący: Perplexity i Gemini coraz częściej linkują do danych źródłowych. |
Jeśli prowadzisz produkt SaaS lub porównujesz narzędzia, najszybszą wygraną będzie wdrożenie SoftwareApplication. Konkretny szablon i checklistę walidacyjną opisaliśmy w materiale Schema SoftwareApplication pod AI: szablon i checklist.
Jak walidować schema, zanim wpuścisz ją na produkcję
Trzy kroki, które wykonujemy zawsze:
- Walidacja w narzędziu Google Rich Results Test pod kątem błędów pól wymaganych.
- Test w Schema Markup Validator (schema.org), który łapie błędy semantyczne ignorowane przez Google, ale ważne dla LLM.
- Manualne sprawdzenie, czy ChatGPT z włączonym browsing rozumie strukturę: pytamy „Wymień autora i datę publikacji tej strony” i porównujemy z wartościami w schema.
Trzeci krok to nasz wewnętrzny test smoke: jeśli model nie umie podać autora ze schema, to znaczy, że schema nie zostanie wykorzystana również w retrievalach AI Overviews i Perplexity.
Trzy typowe pułapki w generowaniu schema
Pierwsza pułapka: pole author jako zwykły string zamiast obiektu Person. Google toleruje, LLM często ignoruje. Druga: datePublished w lokalnej strefie czasowej bez offsetu. Po stronie modelu skutkuje to losowym przesunięciem o 24 godziny, co psuje sortowanie po świeżości. Trzecia: zduplikowane bloki schema (jeden z pluginu, drugi wstrzyknięty ręcznie) z różnymi wartościami. Crawler Google wybiera pierwszy poprawny, ale GPTBot i ClaudeBot mogą wybrać drugi, więc lepiej trzymać tylko jedno źródło prawdy w całym dokumencie.
U siebie zarządzamy schema przez RankMath dla wszystkich postów standardowych, a dla typów rozszerzonych (HowTo, SoftwareApplication, Dataset) wstrzykujemy custom JSON-LD przez snippet w functions.php. To prosta separacja, która eliminuje ryzyko duplikacji i konfliktów wartości pól w trakcie audytu.
Jak wdrożyć optymalizację pod retrieval krok po kroku
Poniżej proces, który stosujemy przy migracji blogów klienckich. Cały zakres pracy mieści się w 4 tygodniach dla bloga o 50 artykułach i 2 redaktorach.
Tydzień 1: audyt chunkowalności
Eksportujemy wszystkie artykuły do markdownu i zliczamy: średnią długość akapitu, długość sekcji pod każdym H2, udział nagłówków w formie pytań, obecność schema.org. Cel: zidentyfikować 20% najgorszych artykułów (zwykle te starsze niż 18 miesięcy), które ciągną resztę domeny w dół. Używamy do tego prostego skryptu Pythonowego z biblioteką markdown-it i własnego scorera, który punktuje każdy artykuł od 0 do 100. Wszystko poniżej 60 trafia do kolejki naprawczej.
Tydzień 2: refaktoring nagłówków i pierwszych zdań
Najszybsza wygrana: przepisujemy H2 i H3 w 20% najgorszych artykułów na formy pytań („Jak wdrożyć”, „Ile kosztuje”, „Czym różni się”) lub konkretnych twierdzeń. Pierwsze zdanie każdej sekcji powtarza temat artykułu i zawiera kluczową frazę, np. „Treści pod retrieval optymalizujemy w trzech krokach: chunkowanie, embedding, schema”.
Efekt mierzymy po 14 dniach na próbie kontrolnej (50% artykułów refaktoryzowanych, 50% bez zmian). W ostatnich trzech projektach refaktor samych nagłówków podniósł liczbę cytowań w ChatGPT i Perplexity o 22–34% w stosunku do grupy kontrolnej.
Tydzień 3: schema.org i FAQ
Dla każdego artykułu wprowadzamy schema Article (lub HowTo, SoftwareApplication, Dataset, w zależności od typu). Dokładamy sekcję FAQ na końcu artykułu (3–6 par Q&A) z odpowiednim FAQPage. Walidujemy w Rich Results Test i u nas w smoke teście (pytanie do ChatGPT z włączonym web).
Tydzień 4: indeksowanie i pomiar
Re-indeksujemy artykuły poprzez Google Search Console (request indexing dla TOP 10 najważniejszych pillarów) oraz, jeśli korzystasz z Bing Webmaster Tools, IndexNow, by przyspieszyć retrieval w Bing/ChatGPT. Wprowadzamy dashboard KPI, w którym śledzimy liczbę cytowań w ChatGPT, Perplexity i Gemini.
Drugim ważnym krokiem czwartego tygodnia jest poprawienie ustawień robots.txt i serwerowych headerów dla GPTBot, ClaudeBot, PerplexityBot i Google-Extended. Domyślnie wiele instalacji blokuje te crawlery przez nadgorliwy WAF lub Cloudflare Bot Fight Mode, co skutecznie odcina retrieval od twoich treści, mimo że artykuły są technicznie świetne. Sprawdzamy logi serwera pod kątem wpisów od tych user-agentów; brak wpisów w ostatnich 14 dniach to alarm. Jeżeli ich nie widać, włączamy explicit allow w robots.txt i w regułach WAF, a następnie ponownie zgłaszamy sitemap.
Trzeci element czwartego tygodnia to wewnętrzne porównanie. Wybieramy 5 artykułów referencyjnych (np. te, które historycznie były cytowane w ChatGPT) i 5 nowych po refaktorze. Po 30 dniach mierzymy citation lift, czyli różnicę średnich cytowań tygodniowo. Jeżeli lift wynosi mniej niż 20%, refaktor wymaga drugiej iteracji (zwykle dotyczącej długości pierwszych zdań i obecności konkretnych liczb w sekcjach KPI).
Najczęstsze błędy, które blokują retrieval
W audytach widzimy te same pułapki w 8 na 10 blogów. Lista skrócona:
- Pojedynczy akapit pod H2 w formie wprowadzenia, np. „W tej sekcji przyjrzymy się…”. Taki chunk jest pusty informacyjnie i obniża średnią ocenę całego artykułu w bazie wektorowej.
- Tabela bez podpisu i bez kontekstu w okolicy. Tabela HTML jest cennym chunkiem, ale tylko wtedy, gdy bezpośrednio przed nią pada zdanie typu „Poniższa tabela porównuje 5 narzędzi do monitoringu cytowań AI w 2026 roku”.
- Schema.org wstrzyknięta przez plugin bez walidacji. RankMath, Yoast i AIOSEO automatycznie generują schema, ale często z literówkami w polach (autor jako string zamiast Person). LLM ignoruje błędną schema, więc lepiej wyłączyć i wstawić ręcznie niż mieć źle.
- Tłumaczenia maszynowe z angielskich oryginałów. Rozjazd embeddingu między angielskim oryginałem a polskim tłumaczeniem powoduje, że wersja PL „nie pasuje” do polskich zapytań.
- Brak linków wewnętrznych z H2. Cytowanie często prowadzi do strony powiązanej z chunka, a nie do samej strony chunka. Bez linków z chunka tracisz drugi krok userowej ścieżki.
- Sekcje FAQ jako akordeony bez schemata. Akordeon JS bez FAQPage jest niewidoczny dla retrievalu, bo treść często jest doczytywana po kliknięciu.
- Anchor text typu „kliknij tutaj”. Modele wykorzystują anchor jako sygnał semantyczny linku. „Kliknij tutaj” nie niesie żadnej informacji.
Wszystkie te błędy są tanie do naprawienia: wystarczą 2 godziny pracy redaktora na artykuł. Problem polega na tym, że trzeba je naprawić w skali, więc opłaca się wcześniej zbudować checklistę i przepuścić każdy nowo publikowany tekst przez nią automatycznie. U nas robi to skrypt w GitHub Actions, który blokuje merge PRa, gdy artykuł nie spełnia kryteriów chunkowalności.
Mierzenie efektów: KPI dla treści zoptymalizowanych pod retrieval
SEO miało jeden wskaźnik główny (pozycja w wynikach Google) i kilka pomocniczych. AIO ma trzy główne i co najmniej pięć pomocniczych. Bez nich nie da się odpowiedzialnie raportować klientowi, czy praca redakcyjna ma sens.
Trzy KPI główne
- Citation rate (cytowalność). Liczba unikalnych cytowań twojej domeny w odpowiedziach ChatGPT, Perplexity, Gemini i Claude w ujęciu tygodniowym. Mierzymy narzędziami typu Profound, Athena AI, Otterly lub własnym skryptem ankietującym 200–500 zapytań branżowych dziennie.
- Share of Voice w AI. Twój udział cytowań w stosunku do top 5 konkurentów w danej niszy. SoV powyżej 25% to sygnał dominacji, poniżej 5% sygnał, że trzeba przyspieszyć.
- Click-through z odpowiedzi AI do strony. Większość modeli linkuje cytowanie do źródła. Mierzymy ruch z Perplexity (?utm_source=perplexity), ChatGPT (chatgpt.com referer) i Gemini w GA4 oraz Plausible.
Pomocnicze KPI techniczne
- Średni score chunkowalności w domenie (od 0 do 100, z naszego scorera).
- Procent artykułów z FAQPage schema (cel: 100% dla artykułów dłuższych niż 1500 słów).
- Średnia długość pierwszego zdania pod H2 (cel: poniżej 25 słów, z hasłem tematu w tym zdaniu).
- Procent linków wewnętrznych w body (a nie w listach na końcu) (cel: powyżej 70%).
- Czas od publikacji do pierwszego cytowania w ChatGPT (cel: poniżej 21 dni dla treści w niszy konkurencyjnej).
W praktyce wystarczy raportować KPI raz na 2 tygodnie. Modele AI cytują nieco wolniej niż Google indeksuje, więc codzienne sprawdzanie generuje szum. Cykl 14-dniowy daje równowagę między czujnością a stabilnością danych.
Mini case study: blog SaaS w niszy fintech
W Q1 2026 prowadziliśmy projekt dla blogu SaaS z niszy fintech (~80 artykułów, 18 miesięcy historii). Przed wdrożeniem domena była cytowana w ChatGPT ~6 razy tygodniowo i w Perplexity ~9 razy. Po 8 tygodniach pracy (chunkowanie, FAQ, schema, refaktor pierwszych zdań, dodanie 12 nowych artykułów typu „comparison”) liczby wyglądały tak:
- ChatGPT: 28 cytowań tygodniowo (wzrost x4,7)
- Perplexity: 41 cytowań tygodniowo (wzrost x4,5)
- Gemini: 17 cytowań tygodniowo (wcześniej ~3)
- Ruch z odpowiedzi AI w GA4: 1240 sesji w ostatnim tygodniu kwartału
- SoV w niszy fintech (vs 5 konkurentów): 19% (wcześniej 4%)
Najważniejsza obserwacja: 70% wzrostu pochodziło z 12 nowych artykułów typu „comparison” (np. „X vs Y”, „Top 5 narzędzi do Z”). Refaktor starych artykułów dał kolejne 25%, a schema FAQPage doniósł końcowe 5%. Czyli największe ROI ma w 2026 produkcja nowych formatów konwersacyjnych, a nie polerowanie starego stocku, choć to ostatnie pozostaje istotne na poziomie domeny jako całości.
Jak to wszystko wiąże się z link buildingiem
Retrieval i embeddingi są ważne, ale nie zastępują autorytetu domeny. Jeśli cytowanie ma trafić do TOP 5 odpowiedzi LLM, twoja domena musi być wskazywana w danych treningowych jako wiarygodna. Jak budować takie zaplecze, opisaliśmy w przewodniku Linki pod AIO: które backlinki realnie zwiększają cytowania.
Stack narzędziowy redakcji w 2026 roku
Nie ma jednego właściwego zestawu narzędzi. Poniżej to, co u nas się sprawdza dla średniego bloga (50–150 artykułów, 2–4 redaktorów):
- Edytor: WordPress z RankMath dla bazowej schemy, ręczny JSON-LD dla typów rozszerzonych. Alternatywa to Ghost, jeżeli redakcja jest mniejsza i nie potrzebuje wtyczek WP.
- Walidacja chunkowalności: własny skrypt Pythonowy w GitHub Actions, który sprawdza długość akapitów, format nagłówków, obecność FAQ i kompletność JSON-LD. Skrypt blokuje merge PRa, gdy artykuł nie spełnia checklisty.
- Monitoring cytowań: kombinacja Profound (płatne) i własnego skryptu z OpenAI API, który ankietuje 300 zapytań branżowych dziennie i loguje, kiedy nasza domena jest cytowana.
- Dashboard: Looker Studio z connectorem do GA4, BigQuery i własnej bazy Postgres z logami cytowań.
- Reranker offline: Cohere Rerank w trybie test, którym ranking nasze własne chunki przeciwko 50 zapytaniom z konkretnej niszy. To pokazuje, czy refaktor faktycznie zwiększa szansę cytowania, zanim artykuł zostanie opublikowany.
Zestaw można zacząć dużo lżej. Minimalny stack to RankMath + ręczna lista 30 zapytań branżowych testowanych raz w tygodniu w ChatGPT, Perplexity i Gemini. Już ta podstawa daje obraz tego, gdzie jesteś, i pozwala raportować klientowi cytowania w pierwszym miesiącu.
Co zmieni się w retrievalu w drugiej połowie 2026 roku
W drugiej połowie 2026 spodziewamy się trzech zmian, które już dziś warto wziąć pod uwagę. Po pierwsze, modele zaczynają coraz częściej cytować pojedyncze zdania zamiast całych akapitów. Wymusi to jeszcze większą atomizację treści: zdania samowystarczalne, z konkretną liczbą lub definicją w środku. Po drugie, wektorowe bazy danych przechodzą na multi-vector retrieval (każdy chunk jest reprezentowany kilkoma wektorami: tytułu, treści, encji), co premiuje artykuły ze spójnymi metadanymi i bogatą schemą. Po trzecie, modele zaczynają preferować chunki z niskim stosunkiem reklam i pop-upów do treści (sygnał z Google Page Experience zaczyna trafiać też do warstwy AI). Czyli wszystko, co zwiększa „czystość” strony, jednocześnie podnosi szanse cytowania.
FAQ
Czy chunkowanie zastępuje klasyczne SEO?
Nie. Klasyczne SEO (linki, Core Web Vitals, intent matching) nadal działa w Google Search. Chunkowanie i schema.org dokładają nową warstwę widoczności w odpowiedziach LLM. Najlepsze redakcje pracują na obu płaszczyznach jednocześnie, bo ten sam artykuł może być cytowany zarówno w klasycznym SERP, jak i w AI Overviews.
Jaka jest optymalna długość chunka w 2026 roku?
Praktycznie 250–400 słów na sekcję pod jednym H2, co odpowiada 300–600 tokenom. Większość systemów RAG (w tym OpenAI Assistants, Claude tool retrieval, Perplexity) używa chunków w okolicach 512 tokenów. Sekcje krótsze są łączone, dłuższe dzielone w przypadkowych miejscach.
Czy schema FAQPage zwiększa cytowania w ChatGPT?
Tak, znacząco. W naszych testach na domenach SaaS dodanie FAQPage do każdego pillar artykułu zwiększyło liczbę cytowań w ChatGPT o 30–45% w ciągu 60 dni. Para pytanie–odpowiedź trafia 1:1 do retrievalu jako gotowy chunk z etykietą semantyczną.
Czy modele LLM widzą JSON-LD czy tylko widoczny tekst?
Widzą oba, ale w różnych warstwach. Crawler Anthropic, OpenAI i Perplexity parsuje JSON-LD ze strony i traktuje go jako metadane chunka, podczas gdy widoczny tekst jest źródłem treści embeddingu. Dlatego JSON-LD musi być spójny z treścią widoczną, w przeciwnym razie model uznaje stronę za niespójną i obniża jej ranking.
Czy warto stosować akordeony w sekcji FAQ?
Tak, ale tylko gdy treść jest renderowana w HTML statycznie (np. tagiem <details>), a nie podgrzewana JS-em po kliknięciu. Crawler Perplexity i GPTBot nie wykonują interakcji JS, więc akordeon zbudowany na onClick znika z indeksu retrievalu. Tag <details> z <summary> jest natywnie widoczny dla wszystkich crawlerów.
Jak szybko zobaczę efekty optymalizacji pod retrieval?
Pierwsze cytowania w ChatGPT pojawiają się zwykle 14–28 dni po publikacji nowego artykułu, a w Perplexity i Gemini 7–14 dni. Dla starszych artykułów refaktoryzowanych pod chunkowanie i schema, efekty są mierzalne po 30–45 dniach od ponownej indeksacji w Google Search Console oraz IndexNow.