Optymalizacja pod silniki generatywne: notatki z pierwszych 90 dni
SEO, jakie znałem, polegało na sygnałach. Backlinki, gęstość słów kluczowych, crawl budget. Optymalizowałeś pod algorytm rankingowy, któremu głównie zależało na tym, co o Twojej stronie myślą inne strony.
Optymalizacja pod silniki generatywne to coś innego. Gdy ChatGPT, Perplexity albo Claude odpowiada na pytanie, nie rankuje stron — syntezuje informacje. Pytanie nie brzmi „czy jestem wysoko?” Brzmi: „czy jestem cytowany?” i dokładniej: „czy model może wiernie przedstawić to, czym się zajmuję?”
To przeformułowanie zmienia to, co budujesz.
Co GEO naprawdę oznacza
Silnik generatywny czyta Twoją witrynę tak, jak badacz czyta artykuł naukowy. Chce struktury, jasnych twierdzeń i dowodów. Nie obchodzi go gęstość słów kluczowych. Obchodzi go, czy może wyciągnąć użyteczny fakt ze strony w pięć sekund.
Efektem nie jest niebieski link w SERP. To zdanie w odpowiedzi AI: „Według Szymona Dziaka, najlepszym podejściem do…” albo cytat w odpowiedzi Perplexity. Żeby na to zasłużyć, Twoje treści muszą być indeksowalne, parsowalne i naprawdę warte zacytowania.
Większość witryn taka nie jest. Są zaprojektowane dla ludzi czytających w spokoju, nie dla modeli przeglądających z prędkością inferencji.
Pięć rzeczy, które przyniosły efekty
1. llms.txt i llms-full.txt
Specyfikacja llms.txt (zaproponowana przez Jeremy’ego Howarda) daje crawlerom AI czystą, płaską mapę tekstową witryny. Dodałem oba pliki w katalogu głównym: llms.txt z krótkim opisem witryny i linkami do kluczowych stron, llms-full.txt z pełnym tekstem wszystkich stron w jednym pliku. Modele obsługujące tę specyfikację mogą odczytać wszystko w jednym żądaniu, zamiast pełzać po stronie za stroną. Perplexity zaczął cytować simondziak.com w odpowiedziach o programowaniu we Flutterze w ciągu dwóch tygodni od dodania tych plików.
2. Schema FAQPage z odpowiedzią na początku
FAQPage w formacie JSON-LD to jeden z najsilniejszych typów schematu dla GEO. Dodałem go na każdej stronie, która mogła odpowiedzieć na jakieś pytanie. Kluczowe jest to, że tekst odpowiedzi w schemacie musi być samodzielny — model może go przytaczać dosłownie. Dlatego pisałem każdą odpowiedź tak, żeby działała w izolacji: pytanie, a po nim pełna odpowiedź — bez odwołań „jak opisano powyżej”.
Struktura w kodzie: @type: FAQPage z tablicą mainEntity zawierającą obiekty Question, każdy z name (pytanie) i acceptedAnswer.text (odpowiedź). Odpowiedzi do 150 słów. Dłuższe model parafrazuje, co może wprowadzić błędy.
3. BreadcrumbList + rozbudowany graf Person/Organization w JSON-LD
Zbudowałem połączony graf encji: Person powiązany z Organization (App369), z sameAs wskazującym na GitHub, LinkedIn i obie domeny. BreadcrumbList na każdej stronie mówi modelowi dokładną ścieżkę: Strona główna → Eseje → Ten esej. Schema Article na każdym eseju odsyła z powrotem do Person jako autora.
Powiązane encje mają znaczenie, bo modele uczą się relacji. Model, który widział wystarczająco dużo danych strukturalnych, połączy „Szymon Dziak” z „App369” z „Flutter” bez potrzeby, żeby wszystkie trzy słowa były na tej samej stronie. Graf wykonuje tę pracę skojarzeniową.
4. robots.txt z jawnym zaproszeniem dla crawlerów AI
Domyślne User-agent: * pozwala crawlerom wejść, ale nie mówi crawlerom AI, że są mile widziane. Dodałem jawne reguły Allow dla GPTBot, ClaudeBot, PerplexityBot, OAI-SearchBot, Anthropic-AI i Google-Extended. Co ważniejsze, dodałem dyrektywę Sitemap wskazującą na pełną mapę witryny oraz odwołanie do llms-full.txt w sekcji <head> strony. Część crawlerów sprawdza robots.txt jako pierwszą rzecz — jeśli jest cicho na temat ich user-agenta, domyślnie przyjmują postawę zachowawczą.
5. Bloki TLDR z odpowiedzią na początku każdego eseju
Każdy esej na tej witrynie otwiera się teraz blokiem <Tldr> — streszczeniem w 2-4 zdaniach, które mogłoby funkcjonować samodzielnie jako kompletna odpowiedź. To GEO i dostępność w jednym. Model przeglądający mój esej w poszukiwaniu cytatu znajdzie czystą, samodzielną odpowiedź w pierwszych 100 słowach — nie musi jej wywnioskować ze środka akapitu.
Format ma znaczenie: zacznij od twierdzenia, dodaj dowód, zakończ implikacją. Taka sama struktura jak w dobrze napisanym abstrakcie naukowym. Modele są trenowane na dużej ilości tekstów naukowych.
Co nie przyniosło efektów
Upychanie słów kluczowych. Wypróbowałem gęstsze użycie zwrotów jak „programista Flutter Miami”. Żadnej mierzalnej zmiany w cytowaniach AI. Modele nie ważą gęstości słów kluczowych tak jak tradycyjne crawlery.
Generyczne „treści eksperckie”. Akapity o „pomaganiu firmom odnosić sukcesy dzięki technologii” i podobne frazesy. Modele je ignorują. Są zbyt ogólne, żeby je cytować, i zbyt mało wiarygodne, żeby im ufać.
Nadmierne linkowanie wewnętrzne. Spędziłem czas na budowaniu głębokiego grafu linków wewnętrznych — każdy esej wspominający projekt linkował do tego projektu. Nieco pomogło w tradycyjnym SEO. Dla GEO nie przyniosło nic mierzalnego. Linki wewnętrzne nie pomagają modelowi zrozumieć Twoich encji — robią to dane strukturalne w schemacie.
Co robię inaczej teraz
Każdą treść piszę z pytaniem w głowie: „o co ktoś pyta, gdy trafia na tę stronę?” TLDR odpowiada na to pytanie wprost. Treść główna uzasadnia tę odpowiedź.
Traktuję schemat jak treść, a nie jak znaczniki. Tekst w FAQPage i Article jest tak samo ważny jak treść eseju — może nawet bardziej, bo model najprawdopodobniej to przeczyta w pierwszej kolejności.
Jestem też mniej obsesyjny na punkcie metryk ruchu. Sygnał GEO, który mnie interesuje, to cytowania: czy Perplexity wspomina tę witrynę, gdy ktoś pyta o programowanie we Flutterze albo studia appowe w Miami? To trudniejsze do zmierzenia niż pozycja w rankingu, ale to właśnie efekt, o który mi chodzi.
Szczera podsumowanie: GEO to w większości dobra strategia contentowa z danymi strukturalnymi na wierzchu. Strony, które na tym wygrają, to nie te z najsprytniejszym setupem technicznym — to te z jasnymi, konkretnymi, wiarygodnymi treściami, które model może streścić bez zmyślania.