Strony internetowe przez lata były przygotowywane przede wszystkim dla dwóch odbiorców: użytkowników i wyszukiwarek. Treść miała być czytelna dla człowieka, a struktura serwisu zrozumiała dla Google.
Agenci AI dokładają kolejny sposób korzystania z internetu. Mogą znaleźć informacje o firmie i wykorzystać je w odpowiedzi, ale coraz częściej mogą też wykonywać działania w imieniu użytkownika. Sprawdzić dostępny termin, pobrać aktualną cenę, znaleźć produkt spełniający określone wymagania, przygotować wycenę albo sprawdzić status zamówienia.
To wymaga od strony czegoś więcej niż dobrej treści i poprawnego SEO. Publiczne informacje powinny być łatwe do odnalezienia i zrozumienia przez systemy AI, a procesy, które mają być obsługiwane przez agentów, potrzebują bezpiecznych i jednoznacznie opisanych interfejsów.
Pierwsze elementy takiej infrastruktury już istnieją. Powstają formaty takie jak llms.txt, rozwija się Model Context Protocol, a systemy CMS zaczynają opisywać swoje funkcje w sposób możliwy do wykorzystania przez agentów. Dobrym przykładem jest WordPress, który rozwija Abilities API.
Nie oznacza to jeszcze, że każdy asystent automatycznie wykona operację na dowolnej stronie. Warto jednak uwzględnić ten kierunek przy projektowaniu nowych serwisów, sklepów i aplikacji.
Agent AI może zrobić więcej niż przeczytać stronę
Najprostszy scenariusz jest już dobrze znany. System AI pobiera publicznie dostępną treść i próbuje ustalić, czym zajmuje się firma, jakie oferuje usługi, gdzie działa i jakie ma warunki współpracy. W takim przypadku największe znaczenie ma jakość, struktura i dostępność informacji znajdujących się na stronie.
Bardziej zaawansowany scenariusz zaczyna się wtedy, gdy użytkownik oczekuje wykonania konkretnego działania. Zamiast samodzielnie odwiedzać kilka stron hotelowych może poprosić agenta o znalezienie dostępnego pokoju spełniającego określone wymagania. Zamiast przechodzić przez konfigurator produktu może podać agentowi parametry i poprosić o sprawdzenie ceny.
Do wykonania takiego zadania nie wystarczy przeczytanie tekstu na stronie. Agent potrzebuje aktualnych danych albo dostępu do konkretnej operacji udostępnianej przez system znajdujący się za serwisem.
Treść strony nadal jest podstawą
Przygotowanie strony na agentów AI nie zaczyna się od instalowania dodatkowych narzędzi. Najpierw warto sprawdzić, czy informacje, których może szukać użytkownik, są w ogóle dostępne w czytelnej formie.
Opis usług, zakres działania, ceny, warunki współpracy, dane kontaktowe i odpowiedzi na typowe pytania powinny być normalną treścią strony. Istotne informacje nie powinny istnieć wyłącznie jako grafika, dokument PDF albo element wymagający wykonania skomplikowanej interakcji w przeglądarce.
Pomaga również poprawna struktura dokumentu, logiczne nagłówki, jednoznaczne nazwy usług i odpowiednie dane strukturalne. Duża część tego, co od lat było dobrą praktyką technicznego SEO i dostępności, pozostaje przydatna również wtedy, gdy odbiorcą treści jest system AI.
llms.txt może wskazać agentowi najważniejsze treści
Dodatkową warstwą może być llms.txt. Jest to rozwijana propozycja formatu przygotowanego z myślą o systemach wykorzystujących modele językowe.
Plik umieszczony pod adresem /llms.txt może zawierać krótki opis witryny oraz uporządkowane odnośniki do materiałów, które są najważniejsze z punktu widzenia zewnętrznego systemu. Dla strony firmowej mogą to być informacje o usługach, cennik, dokumentacja, FAQ, warunki współpracy czy dane kontaktowe.
Przykładowy plik może wyglądać tak:
# Example Company
> We design and develop e-commerce platforms and web applications.
## Services
- [E-commerce development](https://example.com/services/ecommerce.md): Custom online stores and e-commerce integrations.
- [Web applications](https://example.com/services/web-apps.md): Custom web applications and business systems.
## Company
- [About us](https://example.com/about.md): Information about the company and team.
- [Contact](https://example.com/contact.md): Contact information.
## Resources
- [FAQ](https://example.com/faq.md): Frequently asked questions.
- [Knowledge base](https://example.com/knowledge-base.md): Technical articles and guides.
llms.txt nie musi zawierać całej treści serwisu. Może działać jako niewielka mapa prowadząca do najważniejszych materiałów i ich wersji przygotowanych w prostym formacie Markdown.
W praktycznych implementacjach można spotkać również llms-full.txt, który zawiera większą część treści witryny w jednym dokumencie. Przy niewielkim serwisie może to być wygodne, ale wraz ze wzrostem liczby podstron jeden duży plik staje się mniej praktyczny. Rozdzielenie materiałów na osobne dokumenty pozwala agentowi pobrać tylko te informacje, których potrzebuje.
llms.txt nie zastępuje strony ani SEO
Dodanie llms.txt nie powinno być traktowane jako nowa wersja SEO ani sposób na automatyczne zwiększenie widoczności firmy w odpowiedziach generowanych przez AI.
Format nie zastępuje publicznej treści HTML, robots.txt, mapy witryny, danych strukturalnych ani poprawnej architektury informacji. Nie daje też agentowi możliwości wykonywania operacji w systemie.
Jego rola jest znacznie prostsza: może wskazać systemowi, gdzie znajdują się najważniejsze materiały i udostępnić je w formie wygodnej do dalszego przetwarzania.
Nie ma również podstaw, żeby traktować obecność llms.txt jako czynnik rankingowy Google. To dodatkowa warstwa przygotowana dla systemów, które zdecydują się korzystać z tego formatu.
Markdown może uprościć dostęp do treści
Agent nie zawsze potrzebuje całego kodu strony razem z nawigacją, stopką, skryptami, formularzami i elementami interfejsu. W wielu zastosowaniach wystarczy mu właściwa treść dokumentu.
Dlatego llms.txt może prowadzić do uproszczonych wersji podstron zapisanych jako Markdown. Pod adresem podobnym do:
https://example.com/services/ecommerce.md
można udostępnić tytuł, opis usługi, zakres prac, warunki współpracy i inne informacje bez pozostałych elementów strony.
Nie oznacza to konieczności ręcznego utrzymywania dwóch kopii każdej podstrony. W dobrze zaprojektowanym systemie HTML i Markdown mogą być generowane z tego samego źródła treści, dzięki czemu zmiana w CMS-ie aktualizuje obie reprezentacje.
Statyczna treść nie wystarczy do pobierania aktualnych danych
Opis usługi, regulamin czy informacje o firmie zmieniają się stosunkowo rzadko i mogą być publikowane jako zwykła treść. Inaczej wygląda dostępność terminu, stan magazynowy, aktualna cena albo status zamówienia.
Takie informacje zależą od bieżącego stanu systemu. Umieszczenie ich w llms.txt albo statycznym dokumencie Markdown nie rozwiązuje problemu, ponieważ dane mogą przestać być aktualne kilka sekund później.
W takich przypadkach potrzebne jest API. Agent może przekazać parametry zapytania, a system zwrócić aktualną odpowiedź bez konieczności odczytywania jej z interfejsu przeznaczonego dla człowieka.
Firma usługowa może w ten sposób udostępnić wolne terminy, sklep aktualny stan magazynowy, a konfigurator cenę produktu obliczoną na podstawie parametrów podanych przez użytkownika.
API przestaje być potrzebne tylko aplikacjom i integracjom
Do tej pory API strony lub sklepu było zwykle projektowane z myślą o konkretnym zastosowaniu: aplikacji mobilnej, systemie ERP, integracji magazynowej, panelu klienta albo połączeniu z partnerem.
Agenci AI mogą stać się kolejnym klientem takich interfejsów. Potrzebują jednak nie tylko adresu endpointu. Muszą również wiedzieć, jakie operacje są dostępne, jakie parametry należy przekazać, jaki będzie format odpowiedzi i jakie uprawnienia są wymagane.
Znaczenia nabiera więc możliwość opisywania funkcji systemu w sposób czytelny maszynowo. W tym miejscu pojawiają się rozwiązania takie jak MCP oraz mechanizmy rozwijane bezpośrednio w poszczególnych platformach.
MCP może połączyć agenta z systemem firmy
Model Context Protocol pozwala udostępniać agentom narzędzia, z których mogą korzystać w ustandaryzowany sposób. Narzędziem może być prosta operacja odczytująca dane albo funkcja wykonująca konkretne działanie w systemie.
Firma może przygotować agentowi ograniczony zestaw możliwości bez udostępniania całego panelu administracyjnego czy bezpośredniego dostępu do bazy danych.
Przykładowe operacje mogą wyglądać tak:
check_availability
get_product_price
calculate_quote
check_order_status
create_lead
Agent otrzymuje opis operacji oraz jej parametrów. Gdy użytkownik poprosi o przygotowanie wyceny, model może zebrać potrzebne informacje, przekazać je do odpowiedniego narzędzia i wykorzystać otrzymany wynik w dalszej rozmowie.
WordPress zaczyna budować podobną warstwę
Dobrym przykładem kierunku zmian jest WordPress. Od wersji 6.9 rozwija Abilities API, czyli centralny rejestr operacji dostępnych w systemie.
Każda ability może mieć nazwę, opis, schemat danych wejściowych i wyjściowych, funkcję wykonującą operację oraz zasady określające dostęp. Wtyczka rezerwacyjna może dzięki temu opisać sprawdzanie dostępnych terminów, a konfigurator produktu obliczanie ceny.
Przykładowe abilities mogłyby wyglądać tak:
booking/check-availability
products/calculate-price
orders/check-status
leads/create
Sam rdzeń WordPressa udostępnia na razie niewielki zestaw podstawowych operacji związanych między innymi z informacjami o witrynie, użytkowniku i środowisku. Największe znaczenie tego mechanizmu nie wynika więc z funkcji dostępnych dzisiaj, ale z możliwości dodawania kolejnych abilities przez wtyczki i własny kod.
WordPress jest tutaj tylko przykładem. Podobny model można zastosować w aplikacji napisanej w Laravelu, własnym systemie e-commerce, platformie SaaS albo istniejącym API firmy.
Treść, llms.txt, API i MCP mają inne zadania
Przygotowanie strony na agentów AI nie polega na wyborze jednego standardu. Poszczególne rozwiązania dotyczą różnych sposobów korzystania z serwisu i mogą działać razem.
| Warstwa |
Do czego służy |
Przykład |
| HTML |
Publiczna treść dla użytkowników, wyszukiwarek i systemów AI |
Opis usług, cennik, informacje o firmie |
llms.txt |
Wskazanie najważniejszych materiałów |
Lista usług, FAQ i dokumentacji |
| Markdown |
Uproszczona reprezentacja treści |
/services/ecommerce.md |
| API |
Pobieranie aktualnych danych i wykonywanie operacji |
Sprawdzenie ceny albo dostępności |
| MCP |
Udostępnianie operacji jako narzędzi dla agentów |
calculate_quote |
W praktyce agent może najpierw odnaleźć usługę dzięki publicznej treści albo llms.txt, przeczytać jej szczegóły w wersji Markdown, a następnie skorzystać z narzędzia pobierającego aktualną cenę lub dostępny termin.
Przygotowanie strony pod agentów nie oznacza przenoszenia całej zawartości do endpointów. Opis firmy, oferta, cennik czy warunki współpracy nadal powinny być normalną publiczną treścią.
API ma największy sens tam, gdzie wynik zależy od aktualnego stanu systemu albo wymaga wykonania logiki biznesowej. Dostępność terminu może zmieniać się w ciągu dnia, cena konfiguracji może zależeć od kilkunastu parametrów, a status zamówienia jest informacją dotyczącą konkretnego klienta.
Podobnie llms.txt nie powinien stawać się kopią całej strony tylko dlatego, że technicznie można tam umieścić dużo informacji. Lepiej wykorzystać go do wskazania najważniejszych źródeł i pozostawić właściwe dane w miejscu, które najlepiej odpowiada ich charakterowi.
Operacje wykonywane przez agentów wymagają uprawnień
Odczyt publicznego opisu usługi ma niewielkie konsekwencje. Utworzenie rezerwacji, zmiana zamówienia albo odczyt danych klienta wymagają już odpowiedniego zabezpieczenia.
Agent powinien otrzymywać tylko te uprawnienia, których potrzebuje do wykonania konkretnego zadania. Integracja nie powinna korzystać z konta administratora tylko dlatego, że jest to najprostszy sposób uzyskania dostępu do API.
W praktyce warto stosować osobne dane dostępowe dla poszczególnych integracji, minimalny zakres uprawnień, walidację parametrów oraz rejestrowanie wykonywanych operacji. Przy funkcjach zmieniających dane istotne jest również ustalenie, które działania wymagają dodatkowego potwierdzenia przez użytkownika.
Agent może na przykład samodzielnie sprawdzić dostępność terminu, ale finalne złożenie płatnego zamówienia może wymagać wyraźnej akceptacji użytkownika.
Jak może wyglądać strona przygotowana na agentów AI?
W większości przypadków nie wymaga to budowania serwisu od początku. Najważniejsze jest uporządkowanie warstw, które już istnieją.
Publiczna treść powinna być dostępna i jednoznaczna. Najważniejsze materiały można dodatkowo wskazać przez llms.txt i udostępnić w uproszczonej wersji Markdown. Dane zmieniające się w czasie rzeczywistym powinny pochodzić z API, a procesy biznesowe możliwe do wykonania przez agentów mogą zostać wystawione jako odpowiednio zabezpieczone narzędzia.
W zależności od rodzaju firmy mogą to być między innymi:
- sprawdzenie dostępności terminu,
- pobranie aktualnej ceny produktu,
- sprawdzenie stanu magazynowego,
- przygotowanie wyceny na podstawie parametrów,
- sprawdzenie statusu zamówienia lub zlecenia,
- utworzenie zapytania ofertowego,
- rezerwacja terminu po potwierdzeniu przez użytkownika.
Nie każda firma potrzebuje wszystkich tych możliwości. Najwięcej sensu ma udostępnianie procesów, które już dzisiaj są wykonywane przez klientów na stronie albo ręcznie przez pracowników firmy.
Co można zrobić już teraz?
Pierwszym krokiem jest przegląd publicznej treści. Warto sprawdzić, czy oferta, ceny, warunki współpracy, lokalizacje, dane kontaktowe i najczęściej poszukiwane informacje są dostępne jako normalny tekst i można je jednoznacznie zinterpretować.
Następnie można przygotować llms.txt wskazujący najważniejsze materiały i, tam gdzie ma to sens, udostępnić uproszczone wersje treści w Markdown.
Kolejnym etapem jest analiza procesów działających za stroną. Dobrzy kandydaci do integracji mają jasno określone dane wejściowe i wynik, na przykład sprawdzenie terminu, obliczenie ceny czy pobranie statusu.
Jeżeli takie procesy mają już API, część infrastruktury jest gotowa. Jeżeli logika znajduje się wyłącznie w formularzu, panelu albo kodzie aplikacji, można przygotować dla niej osobny interfejs. MCP lub rozwiązania takie jak WordPress Abilities API mogą następnie opisać te możliwości w sposób wygodniejszy dla agentów.
Strony będą projektowane nie tylko dla ludzi i wyszukiwarek
Nie wiadomo jeszcze, jak duża część ruchu, zapytań i transakcji będzie obsługiwana przez agentów AI ani które z rozwijanych obecnie standardów staną się powszechnie używane. Nie ma więc sensu przebudowywać całej strony tylko po to, żeby oznaczyć ją jako „AI ready”.
Warto natomiast przygotować fundamenty, które są użyteczne niezależnie od dalszego rozwoju agentów. Dobrze uporządkowana treść, czytelna struktura serwisu, aktualne API, ograniczone uprawnienia i rozdzielenie publicznych informacji od operacji wymagających autoryzacji poprawiają architekturę systemu również dzisiaj.
llms.txt, Markdown czy MCP można dokładać jako kolejne warstwy tam, gdzie przynoszą konkretną korzyść. Dzięki temu strona pozostaje użyteczna dla ludzi i wyszukiwarek, a jednocześnie jest przygotowana na sytuację, w której część użytkowników będzie korzystać z niej za pośrednictwem własnego agenta.
Przy projektowaniu stron internetowych, sklepów i aplikacji możemy przeanalizować zarówno publiczną treść, jak i procesy, które mają sens do udostępnienia agentom. Dotyczy to WordPressa i WooCommerce, ale również własnych aplikacji, platform SaaS i dedykowanych systemów e-commerce.
Jeżeli chcesz sprawdzić, jak obecna strona wygląda z tej perspektywy, napisz do nas. Możemy przeanalizować treść, API i procesy działające za serwisem oraz wskazać elementy, które warto przygotować pod dalszy rozwój agentów AI.
