Strona internetowa nie jest centrum obecności firmy w sieci. Jest jedną z projekcji czegoś ważniejszego: uporządkowanych danych o tym, kim firma jest, co oferuje, na jakich warunkach i co wolno jej o sobie twierdzić.Ta sama baza, z której powstaje strona, może generować dane strukturalne, plik llms.txt, ulotkę, kalendarz promocyjny i kontekst dla agenta AI piszącego w imieniu marki. Kto trzyma prawdę w danych, ten publikuje zrzuty. Kto trzyma prawdę w zrzutach, ten za każdym razem przepisuje ją ręcznie — i za każdym razem trochę inaczej.

Ten tekst jest architektonicznym dopełnieniem naszego wpisu-fundamentu o agentic web. Tamten opisuje, czego pierwszy czytelnik sieci potrzebuje od strony — sześć warstw, w których strona może odpaść. Ten opisuje, dlaczego większość stron odpada w kilku warstwach naraz i co musi się zmienić strukturalnie, żeby naprawa nie rozjeżdżała się co pół roku.

Strony zawsze były bazami danych

To nie jest nowa idea — to idea, którą sieć obiecała i zrealizowała w połowie. Budowanie stron od zawsze sprowadzało się do porządkowania danych: wpis, opis produktu, cennik, godziny otwarcia. WordPress trzyma to wszystko w relacyjnej bazie SQL. WooCommerce w ogóle nie mógłby powstać, gdyby nie ona — i właśnie WooCommerce jest najlepszym dowodem tezy tego manifestu. Zapytaj bazę sklepu "jaka jest cena produktu X", a odpowie natychmiast, bo Woo wypchnął cenę do osobnego, nazwanego pola. Struktura tam, gdzie jej dołożono, wygrała rynek.

Ale zapytaj tę samą bazę "co ten artykuł twierdzi", "jakie są warunki tej usługi", "jakim tonem mówi ta marka" — i baza milczy. Bo poza polami, które ktoś celowo ustrukturyzował, WordPress trzyma prawdę w jednej kolumnie: post_content. Jeden blob tekstu, w którym treść jest przemieszana z prezentacją — HTML, shortcody, markup buildera. Kanoniczną jednostką przechowywania jest wyrenderowany zrzut. To jest grzech pierworodny sieci, którą zbudowaliśmy: baza danych, która w najważniejszej kolumnie przechowuje nie dane, lecz ich projekcję.

Przez trzydzieści lat ten grzech był niewidoczny, bo jedyny czytelnik miał oczy. Człowiekowi jest wszystko jedno, czy cena przyszła z pola _price, czy z akapitu — przeglądarka renderuje jedno i drugie tak samo.

Pierwszy czytelnik odróżnia źródło od zrzutu

Agent — nie. Dla maszyny różnica między strukturą a blobem jest różnicą między zapytaniem a interpretacją. Strukturę można odpytać: tanio, deterministycznie, z pewnością. Blob trzeba zinterpretować: kosztownie, z budżetem tokenów, z ryzykiem błędu — a niepewność obniża priorytet w rekomendacji. Fundament ujmuje to w warstwie danych strukturalnych jednym zdaniem: bez nich agent zgaduje, a zgadywanie obniża pewność.

I tu manifest dopowiada fundamentowi rzecz kluczową. Fundament słusznie zauważa, że odpaść można w każdej z sześciu warstw z osobna. Ale w praktyce audytowej trzy środkowe warstwy — dane strukturalne, treść, sygnały — prawie nigdy nie zawodzą osobno. Zawodzą razem, bo są objawami jednej choroby: prawda firmy nie ma jednego miejsca zamieszkania. Schema pisana ręcznie przy okazji wdrożenia, fakty w treści poprawiane przy okazji kampanii, wizytówki aktualizowane przy okazji przeprowadzki — trzy okazje, trzy wersje prawdy. Kto naprawia warstwy pojedynczo, wraca za pół roku z tymi samymi rozjazdami. Kto naprawia model danych, temu trzy warstwy spójnieją naraz.

Architektura: źródło, głos, projekcje

Model, który proponujemy, ma trzy piętra.

Źródło. Kanoniczny, ustrukturyzowany zapis prawdy firmy — wersjonowany, w formacie czytelnym dla ludzi i maszyn (wystarczy katalog plików markdown z frontmatterem; nie potrzeba platformy enterprise). Co w nim mieszka: tożsamość marki (kim jesteśmy, jakim głosem mówimy, jakich twierdzeń wolno używać i czym je uzasadniamy), oferta (produkty, usługi, ceny, warunki), fakty operacyjne (lokalizacje, godziny, polityki zwrotów, dane kontaktowe). Zasada jest jedna i bezwzględna: fakt, który nie istnieje w źródle, nie istnieje.

Głos. Interfejs, przez który maszyny rozmawiają ze źródłem zamiast skrobać jego projekcje. Dziś tę rolę pełni MCP: serwer z narzędziami w rodzaju „podaj ofertę", „podaj politykę zwrotów", „przeszukaj produkty". W ramie fundamentu to warstwa protokołów — ale w tym modelu przestaje być „kolejną integracją do dorobienia", a staje się naturalnym finałem architektury: źródło, które dostało głos.

Projekcje. Wszystko, co powstaje ze źródła: strona internetowa, dane strukturalne schema.org (generowane, nie pisane), plik llms.txt (generowany, nie pisany), wizytówki i katalogi, materiały drukowane, kalendarz promocyjny. Także projekcja szczególna: profil marki jako kontekst dla agentów wytwórczych — pakiet, który agent generujący ulotkę czy wpis ładuje jako ograniczenie, nie sugestię. Bo ta architektura karmi dwa kierunki naraz: agentów zewnętrznych, którzy czytają firmę (widoczność), i agentów wewnętrznych, którzy pracują na jej danych (produkcja).

Dryf, czyli dlaczego samo źródło nie wystarczy

Tu manifest musi być uczciwy wobec własnej tezy. Jedno źródło prawdy nie likwiduje dryfu — czyni go wykrywalnym. To ogromna różnica względem stanu obecnego (bez kanonu nie wiadomo nawet, która wersja jest prawdziwa), ale to nie to samo co niemożliwość rozjazdu. Dryfują projekcje: cache, który nie został unieważniony; plik wygenerowany w marcu ze źródła zmienionego w maju; redaktor, który „na szybko" poprawił cenę w zrzucie zamiast w źródle. Dlatego do architektury należą trzy dyscypliny: zakaz ręcznych edycji projekcji (poprawka zawsze idzie do źródła i spływa w dół), generowanie zamiast przepisywania, i monitoring spójności — cykliczne asercje sprawdzające, czy wszystkie projekcje mówią o cenie, dostępności i warunkach to samo.

I jeszcze granica, której żadna architektura nie przekroczy, a którą trzeba znać. Kontrola właściciela kończy się na krawędzi jego serwera. Dalej stoi łańcuch pośredników z własnymi kopiami: cache infrastruktury, indeksy wyszukiwarek i — projekcja ostateczna — wagi modeli językowych, zamrożony zrzut Twoich danych z momentu treningu, którego nie unieważnisz żadnym przyciskiem. Od krawędzi serwera można już tylko sygnalizować świeżość i mierzyć, co łańcuch faktycznie serwuje. Wiemy to nie z teorii: podczas prac nad tym tekstem naprawiliśmy błąd we wpisie-fundamencie, a maszynowy czytelnik jeszcze przez pewien czas dostawał wersję sprzed naprawy — z kopii gdzieś w łańcuchu, na którą nie mieliśmy żadnego wpływu. Właściciel widział prawdę, maszyna projekcję, i oboje mieli rację — każde patrzyło na inny zrzut tego samego kanonu.

Czym ten manifest nie jest

Trzy zastrzeżenia, w duchu fundamentu.

Nie jest teorią wszystkiego. Dane są kanonem dla faktów, twierdzeń i tożsamości — nie dla prozy. Dobry tekst narracyjny nie jest zrzutem z bazy i nigdy nie będzie; to rzemiosło. Rola źródła wobec narracji jest inna: ogranicza ją i uzgadnia. Artykuł może być dowolnie piękny, ale cena, warunek i twierdzenie w nim zawarte muszą zgadzać się z kanonem.

Nie wymaga platformy enterprise. Wielcy dostawcy sprzedają dziś tę samą diagnozę pod hasłami w rodzaju „brand ground truth" — w pakiecie z systemem za enterprise'owe pieniądze. Diagnoza jest słuszna; recepta opcjonalna. Katalog plików, prosty serwer MCP i dyscyplina dają małej firmie to samo, co korporacji daje platforma: jedno miejsce zamieszkania prawdy.

Nie unieważnia sześciu warstw — tłumaczy je. Dostęp i governance pozostają decyzjami bramnymi i politycznymi, niezależnymi od modelu danych. Ale środek ramy — dane strukturalne, treść, sygnały — z perspektywy tego manifestu to trzy okna na jedno pytanie: czy prawda tej firmy ma jedno źródło. Diagnoza mówi, gdzie odpadasz. Architektura mówi, dlaczego wciąż na nowo.

Od czego zacząć

Nie od technologii — od inwentaryzacji. Krok pierwszy: spisz fakty, które o Twojej firmie muszą być zawsze prawdziwe (oferta, ceny, warunki, lokalizacje, dozwolone twierdzenia), i sprawdź, w ilu miejscach dziś mieszkają — strona, schema, wizytówki, PDF-y, głowa właściciela. Sama liczba miejsc jest diagnozą. Krok drugi: wybierz jedno miejsce zamieszkania i przenieś tam kanon; format jest drugorzędny, dyscyplina pierwszorzędna. Krok trzeci: generuj projekcje zamiast je pisać, zaczynając od najtańszych (schema, llms.txt). Krok czwarty: mierz — asercjami, nie oczami. A jeśli chcesz wiedzieć, ile wersji prawdy Twoja firma serwuje maszynom dzisiaj, dokładnie to pokazuje Audyt AI-ready: porównanie tego, co mówi strona, schema, katalogi i to, co o firmie odpowiadają asystenci AI.

FAQ

Czy to znaczy, że strona przestaje być ważna? Nie — przestaje być pierwotna. Strona pozostaje najważniejszą projekcją dla ludzi i dziś także głównym wejściem dla maszyn. Zmienia się jej status: z miejsca, gdzie prawda mieszka, na miejsce, gdzie prawda się pokazuje.

Mam WordPressa i WooCommerce — czy muszę migrować? Nie. Woo już trzyma dużą część prawdy strukturalnie; problem to fakty zatopione w treściach i rozproszone poza stroną. Zwykle wystarczy dobudować kanon obok (choćby jako pliki), podpiąć generowanie projekcji i wprowadzić zasadę „poprawki tylko w źródle".

Czym to się różni od headless CMS? Headless oddzielił treść od prezentacji, ale dał tylko interfejs publikacji — API do renderowania projekcji. Brakującym elementem był interfejs zapytań dla maszyn działających w imieniu klientów. To dokłada dopiero MCP: agent nie dostaje zrzutu, tylko rozmawia ze źródłem.

Od którego momentu opłaca się serwer MCP? Projekcje (payload, schema, llms.txt) są warstwą obowiązkową już dziś — to je czytają agenci publiczni. MCP to warstwa docelowa: dziś dla zaproszonych agentów i własnych narzędzi, jutro — w miarę dojrzewania mechanizmów odkrywania — dla wszystkich. Dwutorowo, nie zamiast.