Jak zbudować serwis pod GEO: architektura i treść, na których stoją cytowania w AI

Zanim zaczniesz poprawiać robots.txt i sprawdzać kody odpowiedzi dla GPTBota, zadaj sobie pytanie o piętro wyżej: czy Twój serwis w ogóle ma z czego być cytowany. Model językowy nie czyta strony tak jak Google sprzed dekady – nie wykonuje JavaScriptu, tnie treść na fragmenty i ocenia każdy akapit osobno. Jeśli architektura serwisu — rendering, szablony, struktura treści — nie jest do tego przygotowana na starcie, żadna konfiguracja firewalla tego nie odkupi. W tym tekście pokazuję, jakie decyzje architektoniczne trzeba podjąć, zanim w ogóle dojdzie do tematu dostępu botów.

Dwa różne problemy: dostęp i fundament

W serii o GEO, którą prowadzimy, część pierwsza rozkłada na czynniki pierwsze to, co dzieje się po wejściu bota na Twoją stronę: czy dostaje 200 czy 403, czy renderowanie odcina go od treści, czy jesteś w indeksie Google i Bing, jak mierzyć cytowania w logach. To dobry, twardy tekst. Jeśli jeszcze go nie czytałeś, zrób to najpierw, bo tam jest cała checklista bot po bocie i gotowa konfiguracja robots.txt:

Techniczne SEO a GEO: jak przygotować serwis pod cytowania w LLM

Ja biorę na warsztat pytanie, które pada wcześniej, a rzadziej się o nim mówi: co, jeśli dopiero budujesz serwis albo planujesz jego przebudowę? Wtedy nie naprawiasz dostępu — projektujesz go od razu tak, żeby nie było czego naprawiać. To dwie różne role w tym samym projekcie: dostęp botów to audyt i egzekucja na istniejącym serwisie, architektura to decyzje podejmowane przy desce kreślarskiej, zanim padnie pierwsza linijka kodu szablonu.

W projektach, które prowadziłem, ten drugi etap regularnie ginie. Zespół dogaduje robots.txt, konfigurację WAF, kody odpowiedzi i to naprawia symptom. Przyczyna zostaje: aplikacja renderowana po stronie klienta, treść produktowa dociągana przez API już po pierwszym malowaniu strony, JSON-LD wrzucony ręcznie na trzy podstrony zamiast być częścią szablonu. Za pół roku wraca się do tego samego audytu, bo architektura wciąż generuje te same problemy.

Krok 1: strategia renderowania — decyzja na starcie projektu, nie łatka na końcu

Wspólna analiza Vercela i MERJ, obejmująca ponad 500 mln pobrań GPTBota, nie znalazła ani jednego przypadku wykonania JavaScriptu przez tego bota. Stan na połowę 2026 roku jest podobny dla całej reszty stawki: GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-SearchBot, PerplexityBot i Meta-ExternalAgent nie renderują. Jedyny istotny wyjątek to Gemini, bo jedzie na infrastrukturze Google i korzysta z tego samego renderowania co Googlebot. To fakt, nie opinia, i już go tu przywołuję w skrócie — cały dowód i metodologia są w części pierwszej serii.

Konsekwencja dla architektury jest prostsza, niż się wydaje: strategia renderowania to pierwsza decyzja techniczna w projekcie, nie ostatnia. Nie da się jej „dorobić” fixami na produkcji bez przepisywania połowy frontendu. Dlatego wpisuję ją do specyfikacji technicznej na starcie, obok stacku i integracji:

Server-side rendering (SSR) albo static site generation (SSG) dla treści krytycznej. W Next.js to konkretnie App Router z React Server Components albo klasyczny getServerSideProps/getStaticProps — nie pozostawiaj tego domyślnym ustawieniom frameworka, wypisz to jako wymóg. W Astro renderowanie serwerowe jest domyślne dla większości komponentów, co jest jednym z powodów, dla których ten framework dobrze się sprawdza w projektach silnie zależnych od SEO.
Hydration nie może być warunkiem dostępu do treści. Jeśli opis produktu, cena, dostępność czy główny tekst artykułu pojawiają się dopiero po wykonaniu skryptu na kliencie, bot dostaje <div id="root"></div> i tyle. To nie „mniej treści” — to zero treści, dokładnie tak jak opisano w części pierwszej.
Islands architecture zamiast pełnego CSR tam, gdzie to możliwe. Interaktywne widgety (konfigurator, kalkulator, karuzela rekomendacji) mogą zostać po stronie klienta — ale treść, którą chcesz, żeby model zacytował, ma być w surowym HTML-u, zanim jakikolwiek skrypt się odpali.
Headless CMS + frontend rozdzielone to nie wymówka. Na architekturach headless (np. WordPress jako CMS + Next.js jako warstwa prezentacji) łatwo zgubić renderowanie po drodze, bo dwa zespoły odpowiadają za dwie różne warstwy. To musi być jawnie zapisane jako wymóg integracji, a nie założenie, że „przecież frontend jakoś to wyrenderuje”.

Test na szybko, zanim uwierzysz specyfikacji na słowo: curl -s -A "OAI-SearchBot/1.0" https://twojadomena.pl/produkt/xyz/ | grep -c "unikalne zdanie z opisu produktu". Zero w wyniku to zła wiadomość — i dokładnie ten sam test warto wpisać do checklisty odbioru projektu od agencji czy dewelopera, obok testów Lighthouse i Core Web Vitals. Rendering to fundament, na którym stoi reszta tego artykułu — jeśli tu jest dziurawo, dalsze kroki (dane strukturalne, treść pod fragmenty) nie mają czego dotyczyć, bo bot i tak tego nie zobaczy.

Realizm platformowy. Na zamkniętych platformach SaaS nie zawsze przestawisz to jednym przełącznikiem — to samo ograniczenie, o którym pisze część pierwsza serii. Różnica jest taka, że przy nowym projekcie masz wybór platformy przed podpisaniem umowy, nie po roku użytkowania. To jest moment, w którym pytanie „czy ten silnik renderuje treść krytyczną po stronie serwera” powinno paść na etapie doboru dostawcy, obok pytań o wydajność i koszt utrzymania.

Krok 2: architektura informacji pod ekstrakcję fragmentów

System RAG nie ocenia Twojej strony jako całości — tnie ją na fragmenty i porównuje znaczeniowo z pytaniem użytkownika. To oznacza, że jednostką konkurencji nie jest artykuł ani strona produktowa, tylko akapit albo sekcja. Architektura informacji — czyli to, jak dzielisz treść na strony, szablony i sekcje — decyduje, czy w ogóle powstają fragmenty, które mają sens wyjęte z kontekstu.

Trzy decyzje, które warto podjąć na etapie projektowania szablonów, a nie poprawiać w treści post factum:

Jeden typ treści, jeden spójny szablon. Strona kategorii, karta produktu, artykuł poradnikowy — każdy z tych typów potrzebuje własnego, przewidywalnego układu nagłówków: jeden <h1>, nieprzeskakująca hierarchia <h2>/<h3>, dane tabelaryczne w <table>, listy w <ul>/<ol>, daty w <time datetime="...">. To nie jest kwestia stylu redakcyjnego — to kwestia tego, żeby parser (czy to Googlebot budujący fragment do AI Overview, czy retrieval jednego z dostawców LLM) w ogóle rozpoznał strukturę. Czytelna, hierarchiczna struktura HTML wraca w badaniach nad cytowaniami jako czynnik, który realnie pomaga — i to jest coś, co ustawiasz raz w komponencie szablonu, zamiast pilnować w każdym artykule z osobna.

Krytyczne dane nie mogą siedzieć w komponencie, który renderuje się po fetchu z API. Klasyczny układ w e-commerce: strona kategorii renderowana serwerowo, bo ktoś kiedyś zrobił to pod Google, ale opis produktu, warianty, cena promocyjna i sekcja recenzji dociągane po stronie klienta z osobnego API. Efekt: bot widzi nazwę i breadcrumby, nie widzi ceny ani opinii. To błąd architektury szablonu, nie treści — i naprawia się go raz, na poziomie komponentu karty produktu, a nie w każdej z tysięcy podstron osobno.

Płaska, przewidywalna struktura URL i linkowanie wewnętrzne budowane od startu, nie doklejane później. Silnik odpytuje jakiś indeks wyszukiwania, dostaje listę adresów, dopiero potem pobiera treść — jeśli Twoja architektura URL jest chaotyczna albo strony kluczowe są osierocone (bez linków wewnętrznych prowadzących do nich), zmniejszasz szansę, że w ogóle znajdą się wśród kandydatów. To ta sama logika, która od lat działa w klasycznym SEO — tu po prostu stawka jest wyższa, bo kandydatów do wyboru jest więcej niż w klasycznym SERP-ie.

Krok 3: dane strukturalne wbudowane w szablon, nie doklejone na końcu

Google mówi wprost: do pojawienia się w generatywnych funkcjach Search nie jest wymagany żaden specjalny markup schema.org. Danych strukturalnych używaj wtedy, gdy opisują treść realnie widoczną na stronie i pomagają zrozumieć, czym ona jest — nie jako „dźwigni cytowań”. To ważne rozróżnienie, bo w wielu briefach GEO wciąż krąży mit, że specjalna schema załatwia sprawę. Nie załatwia. Ale to nie znaczy, że dane strukturalne są bez znaczenia — znaczenie mają jako element architektury, nie jako magiczny dopalacz.

Konkretnie, na poziomie projektu:

Organization z sameAs prowadzącym do spójnych profili marki w sieci — to materiał do rozpoznania Twojej firmy jako encji, przydatny zarówno w klasycznym SEO, jak i w budowaniu „znajomości” marki w modelu.
Article z author, datePublished i dateModified, Product z ceną i dostępnością, BreadcrumbList — wszystkie te typy wpisz do szablonu komponentu, nie do pojedynczych podstron. Nowy artykuł czy nowy produkt powinien automatycznie emitować poprawny JSON-LD, bo tak jest zbudowany komponent, a nie dlatego, że ktoś pamiętał, żeby go dokleić.
Nie licz na FAQPage jako dźwignię cytowań i nie buduj pod nią całej architektury treści. Jeśli sekcja FAQ działa dobrze, to dlatego że jest czytelna i jasno oddziela pytanie od odpowiedzi w strukturze HTML — nie dlatego że ma dodatkowy typ schematu.
Nie opisuj markupem treści, której na stronie nie ma. To ryzyko ręcznego działania po stronie Google, a zysku po stronie AI i tak nie ma.

Detal, który tłumaczy, czemu ta kolejność (rendering → szablon → dane strukturalne) ma znaczenie: JSON-LD jest częścią surowej odpowiedzi serwera. Bot, który nie wykonuje JavaScriptu, i tak go przeczyta — pod warunkiem że trafia tam w pierwszym HTML-u, a nie jest wstrzykiwany przez skrypt po stronie klienta razem z resztą treści z kroku 1. Na serwisie z mocno klienckim renderowaniem dane strukturalne bywają jedyną rzeczą, jaką model o Tobie widzi. To nie jest strategia, na której warto budować cały serwis, ale pokazuje, dlaczego kolejność decyzji architektonicznych ma znaczenie: rendering najpierw, bo od niego zależy, czy cokolwiek innego (szablon, dane strukturalne, treść) w ogóle dotrze do bota.

Krok 4: treść pisana pod fragment, nie pod czytelnika przewijającego stronę

Architektura daje fundament, ale ostatecznie to, co zostaje zacytowane, to konkretny akapit. Kilka zasad redakcyjnych, które warto wpisać do wytycznych contentowych zespołu, zanim jeszcze powstanie pierwszy tekst na nowym serwisie:

Odpowiedź na początku sekcji. Jeśli nagłówek zapowiada „ile kosztuje X”, pierwsze dwa–trzy zdania mają to mówić wprost. Rozgrzewka przed odpowiedzią to fragment bez wartości informacyjnej i to fragment, który system i tak pominie przy wyborze kandydatów.

Fragment ma się bronić sam, wyjęty z kontekstu.

Zdania typu „jak wspomniałem wyżej”, „ta metoda” bez nazwy, „w takim przypadku” bez doprecyzowania — wyjęte z otoczenia znaczą zero. Nazywaj rzeczy pełnymi nazwami także w środku tekstu, nie tylko przy pierwszym wystąpieniu. To akurat zwykła higiena redakcyjna, która działała dobrze na długo przed LLM-ami i przetrwa tę modę tak samo, jak przetrwała poprzednie.

Liczby z jednostką, źródłem i datą.

„Duży wzrost” nie mówi nic — parserowi ani czytelnikowi. „Wzrost o 34% w II kwartale 2026 według [źródło]” mówi wszystko. To samo dotyczy odsyłaczy do wiarygodnych źródeł zewnętrznych: statystyki, cytaty i jawne źródła podnoszą szansę na cytowanie wyraźnie bardziej niż upychanie fraz kluczowych.

Sygnały doświadczenia wbudowane w treść, nie doklejone jako stopka.

To jest miejsce, gdzie GEO spotyka się z E-E-A-T z klasycznego SEO — i to nie przypadek, tylko ten sam mechanizm oceny jakości działający po obu stronach. Konkretny autor z bio, terminologia użyta poprawnie, uczciwe wskazanie ograniczeń obok zalet — to buduje zaufanie zarówno u czytelnika, jak i u modelu, który ocenia wiarygodność źródła przed wyborem fragmentu do cytowania.

Chunking: gdzie jest granica.

Warto to powiedzieć wprost, bo część branży to pomija. Danny Sullivan z Google odradzał w podcaście Search Off the Record cięcie treści na drobne kawałki specjalnie pod modele — argument: nawet jeśli coś takiego działa dziś, systemy pójdą w stronę nagradzania treści pisanej dla ludzi. Odpowiedź Mike’a Kinga była taka, że pisanie dla użytkownika i świadomość struktury nie są sprzeczne, bo mechanizm RAG jest realny. Moim zdaniem obaj mają rację, tylko mówią o różnych rzeczach. Sztuczne siekanie tekstu na bloczki po pięćdziesiąt słów, z powtarzanym w każdym akapicie słowem kluczowym, to optymalizacja pod dzisiejszy pipeline i przeżyje jedną zmianę systemu. Pisanie tak, żeby akapit wyjęty z kontekstu nadal był zrozumiały, to zwyczajna dobra redakcja — rób drugie, nie pierwsze.

Częsty błąd na start. Zespół projektuje nowy serwis miesiącami, dopina każdy piksel w Figmie, a wytyczne contentowe („jak pisać akapity”, „jak budować nagłówki”) powstają dzień przed startem, jako dokument na pół strony. Efekt: architektura jest solidna, ale treść wlana do niej wygląda tak samo jak pięć lat temu, tylko w ładniejszym layoucie. Wytyczne redakcyjne to część specyfikacji projektu, nie dodatek na sam koniec.

Krok 5: utrzymanie — architektura, która nie wymaga gaszenia pożarów

Dobrze zaprojektowana architektura ma jedną przewagę, o której rzadko się mówi: mniej rzeczy się psuje po drodze. Jeśli rendering treści krytycznej jest wymogiem wpisanym do specyfikacji i pilnowanym w code review, a nie ustaleniem ustnym sprzed roku, to nowy deweloper nie wprowadzi regresji, przenosząc opis produktu do komponentu klienckiego „bo tak było szybciej”.

W praktyce to się przekłada na parę nawyków, które warto zautomatyzować, zamiast sprawdzać ręcznie:

Test renderowania jako część CI/CD, nie tylko jako coroczny audyt. Prosty curl sprawdzający obecność kluczowego zdania w surowym HTML-u dla wybranych typów szablonów, odpalany przy każdym większym release’ie — tania polisa ubezpieczeniowa.
Walidacja JSON-LD wbudowana w proces publikacji treści, żeby nowy artykuł czy produkt nie trafiał na produkcję bez poprawnego markupu — zamiast wykrywać braki miesiąc później przy okazji audytu.
Automatyzacja tam, gdzie się da. Sam wolę pipeline oparty o n8n albo prosty skrypt, który cyklicznie sprawdza kluczowe szablony, od ręcznego klikania po stronie raz na kwartał — bo to, co się robi ręcznie, prędzej czy później przestaje się robić w ogóle.

To nie jest lista rzeczy do zrobienia raz. To lista rzeczy, które — jeśli są częścią architektury projektu od początku — przestają być listą rzeczy do zrobienia w ogóle, bo dzieją się same przy okazji normalnego rozwoju serwisu.

Co dalej?

Rendering, architektura informacji, dane strukturalne wbudowane w szablon, treść pisana pod fragment — to fundament. Na nim ma sens dopiero to, co opisuje część pierwsza serii: kto ma dostęp w robots.txt, jak skonfigurować warstwę sieciową, jak zweryfikować się w indeksach i jak to wszystko mierzyć w logach. Odwrotna kolejność — najpierw dopieszczony robots.txt, potem odkrycie, że aplikacja renderuje się wyłącznie po stronie klienta — to najczęstszy scenariusz, jaki widuję w praktyce, i najdroższy do naprawienia, bo dotyka fundamentów, nie konfiguracji.

Jeśli budujesz albo przebudowujesz serwis teraz i chcesz przegadać, gdzie w Twojej architekturze jest najsłabsze ogniwo — zanim wyda się na to budżet na etapie, gdy poprawki są już drogie — „Napisz, obgadamy architekturę Twojego serwisu.