Ludzie trafiają na stronę i nadal nic nie robią. Czasem między nimi a ofertą stoi już program: asystent szukający odpowiedzi albo agent próbujący wypełnić formularz. Ten przewodnik pokazuje, co takie systemy odczytują, gdzie mogą się zatrzymać i które podstawy są ważniejsze od dodatków dla AI.

Agent dociera przez indeks albo samą stronę

Nie każdy agent odwiedza stronę bezpośrednio. Agent Copilot Studio korzystający z publicznej witryny jako źródła wiedzy opiera się na Grounding with Bing Search. Odpowiedzi pochodzą więc z treści zaindeksowanej przez Bing, a strony wymagające logowania albo nieobecne w indeksie nie zadziałają jako takie źródło (publiczna witryna jako wiedza Copilot Studio, sprawdzone: 2026-10-05).

Google opisuje podobną podstawę dla własnych funkcji AI. Strona nie potrzebuje specjalnego znacznika, żeby pojawić się w AI Overviews albo AI Mode. Musi być zaindeksowana i kwalifikować się do pokazania fragmentu, a zwykłe mechanizmy noindex, nosnippet, data-nosnippet i max-snippet ograniczają widoczność treści (wskazówki Google dla funkcji AI, sprawdzone: 2026-10-05).

Agent przeglądarkowy może czytać inaczej. Google opisuje analizę zrzutu ekranu, DOM oraz drzewa dostępności, czyli semantycznego obrazu strony używanego też przez technologie asystujące (przewodnik Google o stronach dla AI, sprawdzone: 2026-10-05).

Widoczność nie ma więc jednego przełącznika. Asystent oparty na wyszukiwarce potrzebuje strony w indeksie. Agent przeglądarkowy potrzebuje zrozumiałych kontrolek. Człowiek nadal potrzebuje prawdziwej oferty i działającego formularza.

Najwięcej daje zwykły, porządny fundament

Strona z JavaScriptem nie jest automatycznie pusta dla AI. Google zwykle przetwarza treść generowaną przez JavaScript, o ile nie jest zablokowana. Jednocześnie wskazuje, że SEO takich stron jest trudniejsze, i zaleca semantyczny HTML (przewodnik Google o stronach dla AI, sprawdzone: 2026-10-05).

Węższe ryzyko dotyczy informacji pojawiającej się dopiero po interakcji, błędzie skryptu albo zalogowaniu. Cena zapisana w HTML jako zero i podmieniana animacją może pokazać prostemu czytnikowi zły stan. Opis zamknięty w pliku za formularzem może nie trafić do indeksu.

Takie podstawy tworzą stronę czytelną dla ludzi i maszyn: sensowny HTML, widoczny tekst, stabilne adresy, opisane kontrolki i prosta droga od oferty do zapytania. Nie gwarantują miejsca w odpowiedzi AI. Sprawiają, że właściwa strona jest zrozumiała.

Sprawdź drogę od pytania do działania

Przeczytaj stronę bez interakcji

Otwórz stronę główną, ofertę i kontakt bez JavaScriptu. Test ujawnia informacje bez użytecznego stanu początkowego, lecz nie przewiduje sposobu renderowania strony przez Googlebota.

Czy nadal widać nazwę usługi, zakres, cenę, jeśli jest publikowana, dane kontaktowe i cel każdego pola? Potem włącz JavaScript i porównaj wynik. Zapisz każdą informację dostępną dopiero po kliknięciu, przewinięciu albo zgodzie na opcjonalne śledzenie.

Sprawdź też, czy ważna odpowiedź nie mieszka wyłącznie w PDF za formularzem albo panelu klienta. Microsoft podaje, że strony wymagające logowania i niezaindeksowane nie działają jako publiczne źródło wiedzy Copilot Studio (publiczna witryna jako wiedza Copilot Studio, sprawdzone: 2026-10-05).

Obejrzyj kontrolki i etykiety

Przejdź formularz klawiaturą. Każdy element interaktywny powinien dostać focus w logicznej kolejności. Pole potrzebuje widocznej etykiety, a link i przycisk powinny używać właściwego elementu HTML.

Google na web.dev zaleca semantyczne <button> i <a>, poprawne połączenie <label> z polem oraz stabilny układ. Ciągłe przesunięcia utrudniają pracę agentom opartym na zrzutach, a przezroczysta warstwa może zasłonić element, którego agent chce użyć (wskazówki web.dev dla agentów, sprawdzone: 2026-10-05).

Te same poprawki pomagają osobom używającym klawiatury albo czytnika ekranu. Kontrolka ma nazwę i zachowuje się zgodnie z oczekiwaniem.

Sprawdź robots, sitemapę i kanał

Otwórz /robots.txt i wskazaną w nim mapę witryny. Robots Exclusion Protocol jest opisany w RFC 9309, ale specyfikacja mówi wprost, że reguły nie są mechanizmem autoryzacji. Prywatne treści potrzebują prawdziwego zabezpieczenia (RFC 9309, sprawdzone: 2026-10-05).

Sitemapa przekazuje robotom listę kanonicznych adresów. Wymagane elementy to urlset, url i loc, a lastmod, changefreq oraz priority są opcjonalne. Adres mapy można wpisać do robots.txt (protokół Sitemaps, sprawdzone: 2026-10-05).

Jeśli firma publikuje artykuły, znajdź kanał RSS. RSS 2.0 to format XML, którego kanał wymaga tytułu, linku i opisu (specyfikacja RSS 2.0, sprawdzone: 2026-10-05). Framewright ma kanały pod /blog/feed.xml i /pl/blog/feed.xml, a nie w katalogu głównym.

Zadaj pytania klienta

Zadaj te pytania dwóm asystentom AI: czym zajmuje się firma, dla kogo jest usługa i jak zacząć. Porównaj odpowiedzi ze stroną. To kontrola punktowa, nie test pozycji.

Jeśli odpowiedź jest błędna, szukaj źródła: brak strony, blokada, nieaktualna treść albo przekierowanie. Microsoft opisuje, że publiczne źródło wiedzy może nie zwrócić treści po przekierowaniu na inną domenę najwyższego poziomu, a skonfigurowana ścieżka może mieć najwyżej dwa poziomy (publiczna witryna jako wiedza Copilot Studio, sprawdzone: 2026-10-05).

Przypisz kontrolę osobie, która śledzi też zmiany dostawców. Taki sam model odpowiedzialności opisuje artykuł kto czyta zapowiedzi zmian.

Traktuj pliki dla AI jako dodatek

llms.txt jest propozycją Jeremy'ego Howarda, nie standardem sieciowym. Format zaczyna się od H1 i może zawierać streszczenie oraz sekcje linków. Google pisze, że Search nie używa llms.txt, a sam plik nie pomaga ani nie szkodzi widoczności w wyszukiwarce (propozycja llms.txt, sprawdzone: 2026-10-05; przewodnik Google o stronach dla AI, sprawdzone: 2026-10-05).

NLWeb idzie dalej. To otwarty projekt ogłoszony przez Microsoft w maju 2025, oparty na Schema.org i RSS. Implementacja referencyjna udostępnia /ask i /mcp, a każda instancja działa jako serwer Model Context Protocol (wprowadzenie Microsoft do NLWeb, sprawdzone: 2026-10-05; repozytorium NLWeb, sprawdzone: 2026-10-05).

Repozytorium nazywa kod demonstracją proof of concept i nie zawiera gotowego pipeline CI/CD do produkcji. To aktywny, eksperymentalny projekt, a nie skrót do widoczności w odpowiedziach AI (repozytorium NLWeb, sprawdzone: 2026-10-05).

Czego nie robić

Nie płać za obietnicę gwarantowanej obecności w odpowiedziach AI ani nie opieraj na niej planu. Google wskazuje zwykłą indeksację i możliwość pokazania fragmentu, a żadna opublikowana dokumentacja nie obiecuje włączenia.

Nie przebudowuj strony tylko dlatego, że używa JavaScriptu. Google zwykle go renderuje. Testuj stan początkowy i zależność od interakcji.

Nie blokuj robotów na zapas. Google-Extended dotyczy użycia pobranych treści do przyszłego treningu Gemini i groundingu w aplikacjach Gemini, lecz nie steruje Google Search ani rankingiem (dokumentacja robotów Google, sprawdzone: 2026-10-05).

Nie dodawaj llms.txt, schema ani NLWeb przed uzupełnieniem oferty i naprawą kontrolek. Google nie wymaga danych strukturalnych dla wyszukiwania generatywnego (przewodnik Google o stronach dla AI, sprawdzone: 2026-10-05).

Kiedy poradzisz sobie samodzielnie

Pierwszą kontrolę wykonasz wewnętrznie. Porównaj stronę z JavaScriptem i bez niego, sprawdź etykiety, otwórz robots.txt i sitemapę, znajdź RSS, a potem zadaj asystentowi trzy pytania klienta. Każdą rozbieżność przypisz do konkretnej strony.

Pomoc jest potrzebna, gdy treść powstaje dopiero po złożonych działaniach w przeglądarce, migracja domeny zostawiła przekierowania między domenami albo formularz nie ma semantycznych kontrolek. Endpointy NLWeb i MCP są projektem programistycznym z decyzjami wdrożeniowymi oraz bezpieczeństwa.

Praktyczny standard jest prosty: prawdziwe informacje pod stabilnymi adresami, zrozumiałe kontrolki i aktualne pliki odkrywania. Agent dostaje wtedy ten sam materiał, którego potrzebuje człowiek i wyszukiwarka.