Chunking treści – czym jest i czy warto się tym interesować w kontekście optymalizacji GEO?

Masz świeży, ekspercki artykuł na 4000 słów, z dobrym researchem i konkretami? To dobrze. Niestety gorsza wiadomość jest taka, że ChatGPT, Gemini czy Perplexity wyciągną z niego, powiedzmy, trzy zdania. Resztę potraktują jak szum, i to wcale nie dlatego, że artykuł jest słaby, tylko dlatego, że nikt nie zaprojektował go pod sposób, w jaki maszyna dosłownie „go pokroi”.

Modele językowe nie skanują stron jako całości. Tną je na mniejsze fragmenty, zwane chunkami, i każdy z nich ocenia osobno, często bez wiedzy o reszcie tekstu. Jeśli nie zaprojektujesz swojej treści z myślą o tym cięciu, zrobi to za Ciebie losowy algorytm, i zwykle wychodzi na tym gorzej niż na zamierzonym podziale. W branży to zjawisko ma nazwę: content chunking, czyli w wolnym tłumaczeniu dzielenie treści na fragmenty pod kątem tego, jak przetwarzają ją systemy AI.

Czym jest chunking?

Nie jest to nowy temat na tym blogu. O samej idei chunków i o tym, że RAG ocenia fragmenty w oderwaniu od reszty artykułu, pisałam już przy okazji opisów produktów pod AI i query fan-out. Nie będę tego powtarzać od zera. Tym razem interesuje mnie coś węższego i bardziej praktycznego, czyli chunking tekstu pod LLM w praktyce: nie dlaczego to ma znaczenie, tylko jak konkretnie zaprojektować podział długiego tekstu, żeby maszyna cięła go tam, gdzie chcesz, a nie tam, gdzie akurat wypadnie jej limit znaków.

Jedno zastrzeżenie terminologiczne:

• chunking działa na poziomie pojedynczej strony, to podział jednego artykułu na fragmenty.
• Content clustering – to grupowanie wielu osobnych stron wokół jednego tematu nadrzędnego (pisałam przy okazji architektury pillar page i klastrów tematycznych), działa na poziomie całej domeny,
• Oba mechanizmy działają najlepiej razem, ale to dwie różne decyzje projektowe, nie jedna i ta sama rzecz pod inną nazwą.

Nowe podejście do dzielenia treści

Zanim przejdziemy do konkretów, jedno ważne zastrzeżenie, bo bez niego cały ten tekst mógłby zabrzmieć jak instrukcja „jak oszukać algorytm”. Chunking treści w SEO stał się w ostatnim roku modnym hasłem, więc warto zacząć od tego, co o nim mówi sama branża, zanim przejdziemy do techniki.
Danny Sullivan, wieloletni Search Liaison Google, powiedział w styczniu 2026 roku na podcaście Search Off the Record coś, co warto potraktować poważnie: rozmawiał z inżynierami Google i razem odradzają dzielenie treści na „bite-sized chunks” specjalnie pod LLM-y. Jego słowa: „We don’t want you to do that. We really don’t.”
Argument jest prosty: nawet jeśli taka taktyka działa dziś, w niektórych przypadkach, systemy będą ewoluować w stronę nagradzania treści pisanej dla ludzi, a to, co zrobiłaś specjalnie pod dzisiejszy ranking, nie przetrwa tej zmiany.

Mike King, analityk SEO, od razu to złagodził: chunking i pisanie dla użytkowników nie wykluczają się wzajemnie, a mechanizm RAG jest realny i, w miarę jak systemy zyskują coraz więcej pamięci kontekstowej, struktura będzie zyskiwać na znaczeniu, nie tracić je. Obaj mają trochę racji, i to jest dokładnie ten punkt, w którym warto się zatrzymać.

Bo prawda jest taka, że rada „pisz zwięźle, buduj sekcje, które da się przeskanować, i spraw, żeby każda odpowiadała na jedno pytanie” nie jest wynalazkiem epoki AI. To dosłownie zalecenie Jakoba Nielsena z 1997 roku, jednego z twórców współczesnego UX, z jego klasycznego tekstu o pisaniu skanowalnych treści do sieci.
Zmieniło się tylko to, kto teraz skanuje: kiedyś tylko oko czytelnika, dziś także parser, który dosłownie tnie Twój tekst na kawałki i ocenia każdy z osobna.

Ahrefs poszedł w tym kierunku jeszcze dalej, w tekście wprost zatytułowanym „SEO Chunk Optimization is Overrated„: SEO-wcy nie mają realnej kontroli nad tym, gdzie konkretny model przetnie ich treść, bo to decyzja inżynierska, zależna od modelu i kosztów obliczeniowych, nie od Twoich nagłówków. To samo zdanie może wylądować na początku chunku, w jego środku, albo zostać rozcięte na dwie części, w zależności od tego, jaki akurat pipeline przetwarza Twoją stronę tego dnia.
Zamiast gonić za precyzyjnym „zaprojektowaniem” granic cięcia, Ahrefs proponuje myśleć w kategoriach atomic content: sekcji, które są kompletne i zrozumiałe same w sobie, niezależnie od tego, gdzie akurat wypadnie cięcie.

Semrush dorzuca do tego jeszcze jedno, praktyczne zastrzeżenie: chunking działa tylko wtedy, gdy jest tam substancja. Przeanalizowali, które artykuły wygrały w AI Overview dla zapytania o najlepszy czas wysyłki mailingu, i wygrały nie dzięki formatowaniu, tylko dzięki oryginalnym danym, jedno ze źródeł opierało się na analizie 1,7 miliona kampanii mailingowych. Struktura pomogła to wyciągnąć, ale to dane dały temu artykułowi w ogóle prawo do bycia zacytowanym.

Trzymaj się więc tego, co niżej, jako zestawu obserwacji do sprawdzenia przy redakcji, nie listy do odhaczenia punkt po punkcie.

Mechanika w skrócie: bot wchodzi na stronę, zamienia tekst na tokeny, a potem dzieli go na mniejsze porcje, które da się zapisać jako wektory w bazie danych (embeddingi). Jeśli cięcie wypadnie w środku złożonego zdania albo rozerwie tabelę specyfikacji na pół, model dostaje fragment bez podmiotu i kontekstu. Z takiego fragmentu ciężko cokolwiek sensownie zacytować, więc model go pomija, albo, gorzej, próbuje dociągnąć brakujący sens i zaczyna zmyślać.

Trzy sposoby, w jakie maszyna tnie Twój tekst

Nie każdy system tnie tekst tak samo, i warto znać różnicę, bo pisanie „pod jeden konkretny algorytm cięcia” to gra w ciemno.

1. Fixed-size chunking to najprostsza metoda: tekst dzielony na sztywną liczbę znaków czy tokenów, bez oglądania się na to, co akurat wypada na granicy. Potrafi przeciąć zdanie, a nawet słowo, w połowie. Szybkie i tanie obliczeniowo, ale ślepe na sens.
2. Recursive character chunking jest inteligentniejszy i, co ważne, to domyślna strategia w LangChain, jednym z najczęściej używanych frameworków do budowy systemów RAG. Zamiast ciąć na oślep, sprawdza po kolei: najpierw próbuje ciąć na złamaniach akapitów, potem na końcach zdań, dopiero na końcu, w ostateczności, na pojedynczych znakach. To metoda, która najbardziej szanuje naturalną strukturę tekstu, jaką sam jej dajesz.
3. Semantic chunking idzie o krok dalej: model analizuje podobieństwo znaczeniowe kolejnych zdań (przez embeddingi) i stawia granicę tam, gdzie wyczuwa zmianę tematu. Teoretycznie najdokładniejsza metoda, w praktyce droższa obliczeniowo i, jak pokazał jeden z inżynierów w swoim własnym teście na realnym, 2209-słownym artykule blogowym, wcale nie zawsze wygrywa z prostszymi metodami. W jego przypadku semantic chunker wyprodukował chunki o rozmiarach od 16 do 1257 znaków, jeden akapit listy wypunktowanej został odcięty jako samodzielny, szesnastoznakowy fragment, bo miara podobieństwa nie złapała granicy tematu tam, gdzie faktycznie przebiegała.

Z tego wynika jedno: nie masz kontroli nad tym, którą metodą konkretny model pokroi Twój tekst, ale możesz pisać w taki sposób, że niezależnie od metody wynik będzie sensowny. Zespół Pinecone, jednej z popularniejszych baz wektorowych używanych w budowie systemów RAG, ujął to jedną, bardzo praktyczną zasadą: jeśli fragment tekstu ma sens dla człowieka bez otaczającego kontekstu, będzie miał sens także dla modelu językowego. To w gruncie rzeczy ten sam test ekstrahowalności, o którym pisałam w książce, tylko sformułowany przez inżynierów, nie copywriterów.

Ile dokładnie słów powinien mieć jeden chunk? Szczerze, nie znalazłam na to jednej, jasnej odpowiedzi, na którą mogłabym się powołać z czystym sumieniem, a przekopałam się przez sporo źródeł. Microsoft, w oficjalnej dokumentacji Azure AI Search, rekomenduje start od 512 tokenów, czyli około 2000 znaków, z zakładką 25%. Inne źródła branżowe mówią o 200 do 800 tokenów jako typowym zakresie dla systemów RAG w ogóle.
Polskie źródła szacują to luźniej, na 150 do 300 słów. Rozstrzał jest spory, bo zależy od typu systemu, długości okna kontekstowego i przeznaczenia treści, i nikt nie poda Ci tu jednej liczby, którą możesz bezpiecznie wkleić do briefu dla copywritera.

Ważniejsze niż konkretna liczba jest zresztą coś innego. Olaf Kopp, analityk AI i SEO, cytowany w tym kontekście przez branżowy serwis Lumar, ostrzega wprost przed sztywnym trzymaniem się jednej długości: liczy się jasna segmentacja i to, żeby każdy fragment miał sens sam w sobie, nie to, czy zmieścisz się dokładnie w trzystu słowach. Jeśli musisz wybrać między pilnowaniem konkretnej liczby a testem samodzielności Pinecone z akapitu wyżej, wybierz test. Liczba to tylko przybliżony drogowskaz, nie cel sam w sobie.

Żeby jednak dać Ci coś fizycznie wyobrażalnego: LangChain, najpopularniejsze środowisko do budowy RAG, ma fabrycznie ustawiony chunk na 1000 znaków. Dla języka polskiego to średnio 120 do 150 słów, czyli mniej więcej jeden solidny akapit w Wordzie. Jeśli Twoja główna myśl, nazwa produktu i jego kluczowa cecha nie zmieszczą się w tym oknie, model może ich po prostu nie połączyć ze sobą.

Warto też wiedzieć, dlaczego inżynierowie celowo nie idą w drugą stronę i nie robią chunków ogromnych, mimo że nowoczesne modele embeddingów techniczne mogłyby to udźwignąć. Zespół badaczy ze Stanforda, w pracy „Lost in the Middle” z 2023 roku, pokazał, że modele językowe gorzej radzą sobie z informacją umieszczoną w środku długiego kontekstu niż z tą na początku czy końcu. Im większy, bardziej rozwodniony chunk, tym większe ryzyko, że kluczowy fakt utonie gdzieś pośrodku i model go efektywnie zgubi, mimo że technicznie wciąż ma go „przed oczami”.

Architektura chunków w praktyce

Poniższe punkty najczęściej decydują o tym, czy Twoja treść rozpada się na bezsensowne kawałki, czy trzyma się w całości niezależnie od tego, gdzie akurat wypadnie cięcie.

Jedna domknięta myśl na akapit to fundament wszystkiego innego. Jeśli w jednym akapicie piszesz o cenie produktu, jego wadze i historii marki naraz, każdy chunk, który wypadnie w środku tego akapitu, wyrwie tylko część tej układanki, i model dostanie fragment bez pełnego sensu. Rozdziel te wątki fizycznie, osobnymi akapitami, nawet jeśli w klasycznym, płynnym tekście naturalnie by się przenikały.

Nagłówki działają jak kotwice, nie jak ozdoba. Dla parsera każdy H2 czy H3 to sygnał: tu prawdopodobnie zaczyna się nowa, samodzielna jednostka treści. Ale to działa tylko wtedy, gdy nagłówek faktycznie coś opisuje. „Coś więcej o parametrach” nie daje modelowi żadnej wskazówki. „Jakie parametry techniczne ma fotel biurowy X” już tak, bo sam nagłówek niesie kontekst, którego chunk pod nim może potrzebować.

Warto myśleć o tym dwupoziomowo. H2 tworzy makro-chunk, czyli większy blok tematyczny, cały akapit lub kilka akapitów odpowiadających na szersze pytanie. H3, lista czy pojedyncze zdanie definicyjne w środku tworzą mikro-chunk, mniejszy, bardziej precyzyjny fragment, który częściej ląduje w featured snippets czy krótkich odpowiedziach AI Overview. Dobra architektura ma oba poziomy naraz: makro-chunk daje kontekst, mikro-chunk daje konkret.

Jest jeszcze jeden trik, o którym rzadko się mówi, a który kosztuje dosłownie jedno słowo więcej na akapit: powtarzanie podmiotu zamiast zaimka. Systemy RAG często konfigurowane są tak, żeby chunki się częściowo zakładkowały, końcówka jednego staje się początkiem drugiego, właśnie po to, żeby nie zgubić kontekstu na granicy cięcia. Ty możesz to wzmocnić sama, pisząc „membrana kurtki ma” zamiast „ma ona” na początku nowego akapitu. Jeśli chunk zacznie się akurat od tego zdania, zaimek nie będzie miał do czego się odnieść, a pełna nazwa, owszem.

Do tego dochodzą listy i tabele, które warto domykać jako całość, w czystym kodzie HTML, nie jako obrazek czy fragment tekstu rozbity półśrodkami. To nie jest tylko dobra rada estetyczna: nowoczesne parsery używane w systemach RAG, na przykład MarkdownElementNodeParser z biblioteki LlamaIndex, mają wbudowaną funkcję wyodrębniania tabel HTML jako osobnych, nierozerwalnych węzłów, zamiast tnąć je razem z resztą tekstu na sztywną liczbę znaków. Ale to działa tylko wtedy, gdy tabela jest realnym kodem HTML, który parser może rozpoznać, nie grafiką ani czymś wygenerowanym wyłącznie przez JavaScript po stronie klienta. Wiersz tabeli, który zostanie mimo wszystko przecięty w połowie przez granicę chunku, traci sens tak samo jak zdanie przecięte w połowie, tylko trudniej to zauważyć na pierwszy rzut oka, bo wizualnie tabela nadal wygląda spójnie na stronie.

Ten sam fragment, dwa sposoby cięcia

Zobaczmy to na jednym, krótkim przykładzie. Wersja pierwsza, napisana klasycznie, z dbałością o płynność i storytelling:

„Nasz najnowszy fotel biurowy powstał z myślą o osobach spędzających długie godziny przy komputerze, a jego cena, mimo zaawansowanej konstrukcji wykorzystującej materiały znane z projektowania lotniczego, pozostaje zaskakująco przystępna, co wynika z wieloletniego doświadczenia naszej marki w produkcji mebli biurowych dla korporacji na całym świecie.”

Ładne zdanie. Ale skleja w jedno cenę, materiał, i historię marki. Jeśli parser przetnie je w połowie, powiedzmy zaraz po słowie „przystępna”, jeden chunk dostanie informację o cenie bez kontekstu produktu, a drugi, o historii marki, zupełnie oderwany od tego, czego w ogóle dotyczy.

Wersja druga, ta sama treść, rozłożona pod cięcie:

„Fotel biurowy X kosztuje 890 zł. Konstrukcja wykorzystuje materiały kompozytowe znane z projektowania lotniczego, co pozwala ograniczyć wagę fotela do 12 kg bez utraty stabilności. Producent tego fotela od piętnastu lat dostarcza meble biurowe do korporacji w Europie i Azji.”

Trzy osobne, krótkie zdania, każde samodzielnie zrozumiałe, każde z jasno powtórzonym podmiotem („fotel biurowy X”, „konstrukcja”, „producent tego fotela”). Niezależnie od tego, gdzie akurat wypadnie granica cięcia, dowolny fragment tego akapitu ma sens sam w sobie. To dokładnie test Pinecone w praktyce.

Zastrzeżenie jest jednak ważne: wersja druga, czytana przez człowieka, brzmi trochę jak protokół policyjny, nie jak tekst, który ma cokolwiek sprzedać. Pisanie wyłącznie pod maszynę, kosztem żywego języka, to inna skrajność tego samego błędu. Da się to pogodzić, wystarczy trochę więcej rzemiosła niż w wersji pierwszej i drugiej naraz:

„Fotel biurowy X w cenie 890 zł, mimo konstrukcji z materiałów kompozytowych znanych z projektowania lotniczego. Ta sama konstrukcja pozwala ograniczyć wagę fotela do 12 kg, bez utraty stabilności. Producent tego fotela ma za sobą piętnaście lat dostarczania mebli biurowych do korporacji w Europie i Azji, i to doświadczenie widać w każdym detalu wykończenia.”

Rytm jest tu naturalny, zdania mają różną długość, jest nawet lekka narracja w ostatnim zdaniu. Ale każde zdanie nadal trzyma się jednego wątku i nadal zaczyna się od powtórzonego podmiotu, nie od zaimka. Różnica między wersją drugą a trzecią to różnica między pisaniem pod robota a pisaniem dla człowieka, który akurat czyta w towarzystwie robota.

Jak podzielić istniejące treści na chunki? I czy naprawdę warto to robić?

Zacznijmy od uczciwej odpowiedzi na drugą część pytania, bo bez niej pierwsza część nie ma sensu. Warto, ale nie dlatego, że to magiczna sztuczka podnosząca cytowania z dnia na dzień, tylko dlatego, że dobrze podzielona treść i tak jest łatwiejsza do przeczytania dla człowieka, a poprawa czytelności dla AI wychodzi przy okazji, nie zamiast tego. Jeśli ktoś obiecuje Ci konkretny procent wzrostu cytowań po wdrożeniu chunkingu, podchodź do tego z rezerwą, bo nikt niezależny takich liczb dotąd wiarygodnie nie potwierdził.

Samo dzielenie istniejącego tekstu, w praktyce, sprowadza się do trzech pytań zadanych sobie przy redakcji, nie do przepisywania artykułu od zera. Po pierwsze: czy każdy nagłówek H2 i H3 da się odpowiedzieć jednym zdaniem, czy próbuje odpowiadać na kilka pytań naraz? Jeśli na kilka, rozbij tę sekcję na mniejsze. Po drugie: czy pierwsze zdanie pod każdym nagłówkiem ma sens, jeśli przeczytasz je w oderwaniu od reszty artykułu? Jeśli zaczyna się od „jak wspomniałam wyżej” albo podobnego odwołania wstecz, przepisz je tak, żeby stało samodzielnie. Po trzecie: czy w środku sekcji nie kryją się dwa albo trzy różne wątki sklejone w jeden akapit (cena, historia, parametry), tak jak pokazywałam wyżej na przykładzie fotela? Jeśli tak, rozdziel je fizycznie.

To wystarczy w większości przypadków. Nie musisz przepisywać całego artykułu, wystarczy przejść przez niego raz z tymi trzema pytaniami w głowie, i zacząć raczej od kilku najważniejszych tekstów niż od całego archiwum naraz, o czym więcej za chwilę.

Copywriting a inżynieria informacji

Nie musisz przepisywać całego archiwum na raz. Search Engine Land sugeruje sensowną kolejność: zacznij od tekstów, które mają duży ruch, ale wysoki współczynnik odrzuceń, potem te, które dobrze rankują, ale nigdy nie są cytowane w AI, i te, które poruszają złożone tematy, gdzie czytelnik szuka jednej konkretnej odpowiedzi w gąszczu informacji. Reszta może poczekać do naturalnej aktualizacji.

W erze GEO to, ile słów napiszesz, ma coraz mniejsze znaczenie. Liczy się, jak łatwo da się je poszatkować i złożyć z powrotem w oknie czatu, bez utraty sensu po drodze. To nie jest kolejna sztywna zasada do odhaczenia. To zmiana w tym, jak w ogóle myślisz o akapicie, zanim jeszcze napiszesz pierwsze zdanie.

Ten tekst domyka „trylogię o architekturze treści pod AI”, którą opisałam na tym blogu. To, jak bot potnie Twój tekst na chunki, dzieje się wcześniej niż cokolwiek innego w tym łańcuchu, bo indeksowanie i cięcie treści zachodzi, zanim jakikolwiek użytkownik zada jakiekolwiek pytanie. Dopiero na tak pociętym, zaindeksowanym materiale działa mechanizm query fan-out, o którym pisałam wcześniej, wyszukując osobno dla każdej podintencji wśród gotowych już chunków.
Jeśli architektura Twoich chunków jest niechlujna, cały fan-out szuka odpowiedzi w fragmentach, które od początku nie miały sensu, i to samo dotyczy opisów produktów pod AI, które w praktyce są tylko jednym z wielu typów treści przechodzących przez ten sam proces cięcia.

Źródła:

1. Pinecone, „Chunking Strategies for LLM Applications” – https://www.pinecone.io/learn/chunking-strategies/
2. LangChain, dokumentacja RecursiveCharacterTextSplitter (opisana m.in. w: MyEngineeringPath, „RAG Chunking Strategies – Semantic, Recursive & Agentic Chunking”) – https://myengineeringpath.dev/genai-engineer/rag-chunking/
3. Gaurav (gauravbytes.dev), „Chunking Strategies in LangChain RAG: A Deep Dive” (eksperyment na realnym, 2209-słownym artykule blogowym) – https://gauravbytes.dev/chunking-strategies-in-langchain-rag-a-deep-dive
4. LlamaIndex, dokumentacja MarkdownElementNodeParser (ekstrakcja tabel HTML jako osobnych węzłów) – https://docs.llamaindex.ai/en/stable/api_reference/node_parsers/markdown_element/
5. Microsoft Learn, „Chunk Documents – Azure AI Search” (rekomendacja 512 tokenów, zakładka 25%) – https://learn.microsoft.com/en-us/azure/search/vector-search-how-to-chunk-documents
6. Genrank, AEO Glossary, „Chunking (Content)” (zakres 200-800 tokenów) – https://www.genrank.co/glossary/chunking/
7. Lumar, „Content Chunking & AI Extractability”, cytujące Olafa Koppa (ostrzeżenie przed sztywnym trzymaniem się jednej długości) – https://www.lumar.io/blog/best-practice/content-chunking-ai-extractability-geo-aeo-explainer/
8. Search Engine Land, „How to chunk content and when it’s worth it” (priorytetyzacja treści do przepisania) — https://searchengineland.com/chunk-content-470751
9. Senuto, „Czym jest chunking i jakie ma znaczenie w optymalizacji treści?” (rozróżnienie chunking vs content clustering) – https://www.senuto.com/pl/blog/czym-jest-chunking-i-jakie-ma-znaczenie-w-optymalizacji-tresci/
10. marketingonline.pl, „Jak zwiększyć czytelność treści dla człowieka i dla AI?” (rozróżnienie makro-chunk i mikro-chunk) – https://www.marketingonline.pl/blog-jak-zwiekszyc-czytelnosc-tresci-dla-czlowieka-i-dla-ai/
11. Liu, Lin, Hewitt, Paranjape, Bevilacqua, Petroni, Liang, „Lost in the Middle: How Language Models Use Long Contexts” (arXiv 2307.03172, 2023) – https://arxiv.org/abs/2307.03172
12. Barry Schwartz, Search Engine Roundtable, „Google: Don’t Turn Your Content Into Bite-Sized Chunks” (wypowiedź Danny’ego Sullivana, Search Off the Record, styczeń 2026) – https://www.seroundtable.com/google-content-bite-sized-chunks-40728.html
13. Jakob Nielsen, Nielsen Norman Group, „Concise, SCANNABLE, and Objective: How to Write for the Web” (1997) – https://www.nngroup.com/articles/concise-scannable-and-objective-how-to-write-for-the-web/
14. Despina Gavoyannis, Ahrefs, „SEO 'Chunk Optimization’ is Overrated” – https://ahrefs.com/blog/seo-chunk-optimization/
15. Tushar Pol, Semrush, „Content Chunking: What Is It & Should You Care?” (badanie Chrisa Greena, przykład MailerLite) – https://www.semrush.com/blog/content-chunking/
16. Mike King, iPullRank, „Moving from a Google-shaped Web to an Agent-shaped Web: A Refutation of Misinformation about Chunking” – https://ipullrank.com/misinformation-about-chunking