Ta sama informacja potrafi zachowywać się w wyszukiwarkach AI zupełnie inaczej w zależności od tego, w jakiej formie ją podasz. Zdanie o cenie wtopione w długi akapit i to samo zdanie w wierszu tabeli mają różną szansę, że model wyciągnie je jako gotową odpowiedź. Nie chodzi o magię ani o preferencje estetyczne algorytmu. Chodzi o to, że zanim model cokolwiek zacytuje, twoja strona zostaje pocięta na fragmenty, a format decyduje o tym, gdzie przebiegną cięcia.
Jak treść trafia do fragmentów przetwarzanych przez model
System retrieval nie czyta artykułu tak jak człowiek, od góry do dołu. Pobiera HTML, usuwa nawigację i elementy poboczne, a resztę dzieli na fragmenty o zbliżonej długości. Każdy fragment dostaje swój wektor i trafia do indeksu. Kiedy pojawia się pytanie użytkownika, system szuka najbliższych fragmentów, a nie najlepszych artykułów. To prosta, ale brutalna konsekwencja: oceniany jest kawałek tekstu wyrwany z kontekstu, nie całość twojej pracy.
Dlatego dobry format treści pod LLM to taki, który sam z siebie jest zrozumiały po wycięciu. Jeśli fragment zawiera podmiot, liczbę i warunek, model ma z czego zbudować zdanie. Jeśli zawiera wyłącznie zaimki odnoszące się do akapitu wyżej, fragment jest bezużyteczny, choć merytorycznie poprawny. Mechanikę samego podziału opisaliśmy szerzej w tekście o chunkowaniu treści pod retrieval, a wpływ długości sekcji i nagłówków na granice fragmentów rozkładamy na części w materiale o chunkingu treści pod RAG.
Praktyczny wniosek jest taki: format wygrywa wtedy, gdy zamyka jedną myśl w granicach jednego fragmentu. Każdy z opisanych niżej formatów robi to inaczej dobrze i inaczej źle.
Tabela: kiedy jest najlepszym wyborem
Tabela ma jedną cechę, której nie da się podrobić akapitem: wiąże wartość z jej etykietą w sposób jednoznaczny. Model, który widzi wiersz z nazwą planu, ceną i limitem, nie musi niczego domyślać. Dlatego tabele wygrywają w pytaniach porównawczych, cenowych, parametrycznych oraz wszędzie tam, gdzie użytkownik szuka konkretnej liczby.
Tabela ma też słabość. Jeśli jest szeroka i długa, fragment może objąć tylko jej środek, bez nagłówków kolumn. Wiersz bez etykiet to zestaw liczb bez znaczenia. Dwie rzeczy ograniczają ten problem:
- Pierwsza kolumna powinna nazywać obiekt, a nie numerować go. Wiersz zaczynający się od nazwy produktu jest samowystarczalny, wiersz zaczynający się od cyfry 7 nie jest.
- Krótkie tabele, po 5–10 wierszy, mieszczą się w jednym fragmencie razem z nagłówkiem. Tabela na 40 wierszy niemal zawsze zostanie przecięta.
Pod tabelą warto zostawić jedno zdanie podsumowujące wniosek. To zdanie jest tanim ubezpieczeniem: jeśli tabela zostanie pocięta nieszczęśliwie, model nadal ma gotową frazę z kontekstem.
Lista punktowana i numerowana: różnica w odbiorze
Lista to format, który najczęściej pojawia się w odpowiedziach modeli, i to nie przez przypadek. Punkty są krótkie, równoległe składniowo i łatwe do przepisania. Problem polega na tym, że lista bywa nadużywana. Trzy słowa w punkcie nie przenoszą informacji, tylko ją sygnalizują. Punkt w stylu „szybkość” nie da się zacytować, punkt „czas odpowiedzi serwera poniżej 200 ms obniża liczbę porzuconych sesji” już tak.
Różnica między listą punktowaną i numerowaną jest mniejsza technicznie, niż się wydaje, ale ma znaczenie semantyczne. Numeracja komunikuje kolejność i kompletność, więc model chętniej traktuje taką listę jako procedurę. Lista punktowana sugeruje zbiór równorzędnych cech, z którego można wziąć dowolny element. Jeśli kolejność naprawdę nie ma znaczenia, numeracja wprowadza w błąd i obniża trafność cytowania.
Dobra lista pod wyszukiwarki AI ma zwykle od 3 do 7 punktów, każdy po jednym pełnym zdaniu. Dłuższe wyliczenia lepiej rozbić na dwie listy pod osobnymi nagłówkami H3, bo wtedy każda z nich ma własny kontekst. Temat hierarchii nagłówków i proporcji między akapitem a wyliczeniem opisujemy dokładniej w przewodniku o strukturze artykułu pod AI.
Akapit wprowadzający jako kotwica odpowiedzi
Akapit ma najgorszą prasę i jednocześnie wykonuje pracę, której nie wykona żadna tabela. Definicje, przyczyny, zastrzeżenia i warunki brzegowe wymagają zdań, nie komórek. Modele cytują akapity bardzo często, pod warunkiem że akapit odpowiada na pytanie w pierwszym zdaniu.
Najskuteczniejszy wzorzec wygląda tak: pierwsze zdanie zawiera bezpośrednią odpowiedź wraz z nazwą rzeczy, o której mowa, drugie i trzecie dokładają warunek oraz liczbę, czwarte opcjonalnie zastrzeżenie. Taki akapit mieści się w jednym fragmencie, nie wymaga poprzednika i daje się przepisać bez utraty sensu. Akapity dłuższe niż 5–6 zdań zaczynają obejmować dwie myśli, a wtedy cięcie wypada w środku rozumowania.
Osobna sprawa to akapit pod nagłówkiem sformułowanym jako pytanie. Nagłówek w formie pytania zwiększa zgodność między zapytaniem użytkownika a fragmentem, bo powtarza jego sformułowanie. Nie jest to trik, tylko dopasowanie leksykalne, które nadal ma wpływ na wyniki wyszukiwania semantycznego.
Format kroków i instrukcji
Pytania zaczynające się od „jak” prowadzą do fragmentów z krokami, i tutaj numerowana lista bije wszystko. Kluczowe jest, by każdy krok był czynnością z dopełnieniem, a nie tytułem etapu. Krok „konfiguracja” nie mówi nic, krok „w panelu wklej token API do pola Authorization i zapisz zmiany” mówi wszystko.
Instrukcje zyskują też na danych uzupełniających podanych wewnątrz kroku: czas wykonania, wymagane uprawnienia, miejsce w interfejsie. Model, który przepisuje procedurę, chętniej wybierze tę wersję, bo zawiera więcej faktów na zdanie. Procedury warto dodatkowo opisać znacznikami schema, choć korzyść jest tu pośrednia. Który typ schema faktycznie pomaga, a który jest już tylko porządkiem w kodzie, porównaliśmy w analizie Schema FAQ kontra HowTo. Techniczne wymagania samych znaczników opisuje dokumentacja Google Search Central.
Czego modele nie odczytają: grafiki, ikony, treść w skryptach
Najczęstszy błąd w optymalizacji formatu nie polega na wyborze złego formatu, lecz na umieszczeniu treści tam, gdzie jej nie widać. Tabela na grafice nie istnieje dla systemu retrieval. To samo dotyczy liczb w infografice, porównań w karuzeli obrazków oraz list zapisanych ikonami zamiast tekstem.
Druga pułapka to treść wstrzykiwana przez JavaScript po interakcji użytkownika. Zakładka, akordeon czy modal, który pobiera zawartość po kliknięciu, zwykle nie trafi do zasobu pobranego przez bota. Fragment, który nigdy nie pojawił się w HTML, nie ma szans na cytowanie, niezależnie od jakości. Warto to sprawdzić najprościej, jak można: pobrać stronę bez wykonywania skryptów i policzyć, czy kluczowe zdania są w źródle.
Trzecia sprawa to Markdown wklejony do edytora bez konwersji. Gwiazdki i kreski widoczne w treści nie tworzą listy ani pogrubienia, więc struktura, którą autor widzi w głowie, dla parsera nie istnieje.
Praktyczna zasada doboru formatu do pytania
Zamiast pytać, który format jest lepszy, warto odwrócić pytanie: jakiego typu zapytanie ma zostać obsłużone przez tę sekcję. Poniższa tabela porządkuje wybór.
| Typ pytania | Najlepszy format | Co musi zawierać fragment |
|---|---|---|
| Ile to kosztuje, jakie limity | Tabela | Nazwa obiektu w pierwszej kolumnie, jednostka przy liczbie |
| Czym to jest, dlaczego tak działa | Akapit | Odpowiedź w pierwszym zdaniu, nazwa pojęcia zamiast zaimka |
| Jak to zrobić | Lista numerowana | Czasownik na początku kroku, miejsce i warunek wykonania |
| Jakie są rodzaje, co brać pod uwagę | Lista punktowana | Pełne zdania, równoległa składnia, 3–7 pozycji |
| Czy X jest lepsze od Y | Tabela plus zdanie wniosku | Te same kryteria dla obu stron porównania |
Najlepsze wyniki daje mieszanka, nie monokultura. Sekcja złożona z nagłówka w formie pytania, krótkiego akapitu odpowiedzi i jednej tabeli lub listy pod nim obsługuje jednocześnie zapytanie definicyjne i zapytanie o szczegół. Jeśli masz wybierać jedno usprawnienie na dziś, zacznij od pierwszych zdań pod każdym H2. To one najczęściej stają się cytatem.
FAQ
Czy tabele są bezpieczniejsze od akapitów, jeśli chodzi o cytowania?
Nie w ogólności. Tabele wygrywają w pytaniach o liczby i porównania, akapity w pytaniach o definicje i przyczyny. Tabela źle zbudowana, bez nazw w pierwszej kolumnie, cytuje się gorzej niż dobrze napisany akapit.
Ile punktów powinna mieć lista pod wyszukiwarki AI?
Zwykle od 3 do 7, każdy w formie pełnego zdania. Dłuższe wyliczenia warto podzielić na dwie listy pod osobnymi nagłówkami H3, żeby każda miała własny kontekst w indeksie.
Czy numerowanie listy, w której kolejność nie ma znaczenia, szkodzi?
Tak, choć subtelnie. Numeracja sygnalizuje procedurę i kompletność, więc model może potraktować zbiór cech jako kolejne kroki. W takich miejscach lepiej użyć listy punktowanej.
Jak sprawdzić, czy moja treść w akordeonie jest widoczna dla modelu?
Pobierz stronę bez wykonywania JavaScriptu, na przykład zwykłym żądaniem HTTP, i sprawdź, czy kluczowe zdania znajdują się w zwróconym HTML. Jeśli ich nie ma, treść jest poza zasięgiem systemu retrieval.
Czy warto powtarzać tę samą informację w tabeli i w akapicie?
Jedno zdanie wniosku pod tabelą ma sens i działa jak zabezpieczenie na wypadek niekorzystnego podziału na fragmenty. Pełne duplikowanie całej tabeli prozą już nie, bo rozmywa gęstość faktów w sekcji.