Audyt dostępności AI dla gotowości agentowej

Systemy AI nie mogą cytować, rekomendować ani działać na podstawie treści, których nie są w stanie wiarygodnie pobrać. Ta faza testuje ten fundament, zanim zespół zmierzy widoczność lub zleci treści przeznaczone dla silników odpowiedzi.

Faza: P4, Etap A — Zrozumienie. Ram czasowy: 3–5 dni roboczych dla typowej witryny marketingowej; 5–10 dla dużej witryny e-commerce, marketplace lub aplikacji w dużym stopniu renderowanej po stronie klienta. Właściciel: osoba odpowiedzialna za techniczne SEO jest rozliczana, inżynierowie przeprowadzają testy pobierania i renderowania, lider treści sprawdza możliwość ekstrakcji, a osoba biznesowa lub prawna podejmuje decyzje dotyczące polityki crawlerów.

Dlaczego ta faza pojawia się tutaj

Konwencjonalny audyt techniczny pyta, czy wyszukiwarki mogą przeszukiwać, renderować, indeksować i pozycjonować witrynę. Ta faza pyta, czy crawler AI, systemy wyszukiwania i agenci zadaniowi mogą dotrzeć do tych samych użytecznych informacji i je zinterpretować. Mogą używać innych agentów użytkownika (user agent), ścieżek pobierania, możliwości renderowania, limitów czasu i metod ekstrakcji. Strona, która jest indeksowalna, może wciąż zwracać pustą skorupę, ścianę zgody, bot challenge lub niepołączone fragmenty do klienta AI.

Audyt dostępności AI należy zatem do tego samego miejsca co audyt bazowy techniczny , a nie na końcu produkcji treści. Renderowanie po stronie klienta oznacza, że JavaScript buduje ważną treść po dostarczeniu początkowego HTML. Systemy wyszukiwania mogą nie wykonać tego kodu, mogą przerwać przed jego zakończeniem lub mogą wyodrębnić tylko początkową odpowiedź. Jeśli nazwa produktu, odpowiedź, cena, dostępność lub dowód istnieją dopiero po uruchomieniu JavaScriptu, późniejsza optymalizacja treści nie naprawi błędu dostępu.

Ta faza korzysta ze zweryfikowanych kont, analityki, logów crawlerów, źródeł map witryny, zestawu krytycznych URL-i i mapy własności z fazy dostępu, śledzenia i źródeł danych . Przeprowadzenie jej wcześniej uniemożliwia zespołowi odróżnienie prawdziwego braku od braku dostępu. Przeprowadzenie jej po pomiarze bazowym zanieczyszcza bazę: zerowa liczba cytowań może odzwierciedlać niedostępną witrynę, a nie słabą treść lub popyt.

Pominięcie tej fazy marnuje pracę: autorzy ulepszają fragmenty, których crawler nigdy nie otrzymuje, programiści dodają schemat za wyzwaniem, lub zespół myli prawidłowy plik llms.txt z pełną gotowością witryny. Dostęp, ekstrakcja, zrozumienie i działanie to osobne możliwości.

Wejścia i wyjścia

Wejścia sprawiają, że testy są powtarzalne. Wyjścia tworzą kontrakt z P5: pomiar rozpoczyna się dopiero po naprawieniu lub wyraźnym zaakceptowaniu znanych błędów dostępu.

Lista kontrolna

Przetestuj reprezentatywny zestaw URL-i, nie tylko stronę główną, i zachowaj powtarzalne dowody.

1. Podejmij świadomą decyzję o dostępie crawlerów

Co robić: zinwentaryzuj reguły dla crawlerów AI w robots.txt , kontrolach botów w CDN, zaporach aplikacji webowych, warstwach zgód i konfiguracji origin. Dlaczego to ważne: zezwolenie w robots.txt to tylko preferencja; usługa brzegowa może nadal zablokować żądanie, podczas gdy przypadkowa blokada za pomocą wildcarda nie jest polityką. Jak to zrobić: porównaj reguły na żywo z macierzą polityki, pobierz reprezentatywne URL-e z odpowiednimi agentami użytkownika i zapisz kompromis. Narzędzie: AmICited Robots.txt i mapy witryny, zatwierdzony klient żądań oraz logi CDN/origin. Gotowe, gdy: każda rodzina crawlerów ma zatwierdzoną decyzję (zezwolenie, blokada lub warunkowa), a zachowanie na żywo jest z nią zgodne.

2. Porównaj odpowiedź bez JavaScriptu z użyteczną stroną

Co robić: porównaj początkowy HTML z normalną stroną w przeglądarce. Dlaczego to ważne: klient wyszukiwania może nie uruchomić skryptów, które wstawiają odpowiedzi, oferty, linki lub dane produktów. Jak to zrobić: przetestuj każdy ważny szablon przed hydratacją — procesem, który dodaje zachowanie aplikacji do HTML-a z serwera. Narzędzie: przeglądarka bez JavaScriptu lub klient HTTP oraz wyrenderowana strona. Gotowe, gdy: początkowa odpowiedź zawiera tytuł, H1, główną treść, podstawowe fakty i linki do odkrywania; każdy wyjątek ma dowody i właściciela.

3. Przetestuj możliwość ekstrakcji z wyrenderowanego DOM

Co robić: wyodrębnij główną treść z wyrenderowanego modelu DOM (Document Object Model), czyli strukturalnej reprezentacji strony w przeglądarce, bez nawigacji, tekstu zgód lub ukrytych wariantów. Dlaczego to ważne: otrzymanie tekstu to nie to samo co zidentyfikowanie właściwego tekstu; szum z szablonu może zniekształcić wyszukiwanie. Jak to zrobić: porównaj wyodrębniony tytuł, odpowiedź, wydawcę, daty, fakty i linki z widocznym źródłem na długich, krótkich i komercyjnych stronach. Narzędzie: inspekcja przeglądarki, ekstrakcja tekstu i kod źródłowy strony. Gotowe, gdy: zapis zachowuje główne znaczenie i fakty bez pozycji wizualnych i nieudokumentowanych selektorów.

4. Sprawdź drzewo dostępności (accessibility tree)

Co robić: przejrzyj drzewo dostępności: role, nazwy, stany, nagłówki, punkty orientacyjne (landmarks) i elementy sterujące. Dlaczego to ważne: semantyka odróżnia nagłówki od dekoracji, przyciski od ikon oraz główną treść od nawigacji. Jak to zrobić: przetestuj krytyczne szablony pod kątem jednego H1, uporządkowanych nagłówków, nazwanych elementów sterujących, punktów orientacyjnych, opisowych linków i znaczących alternatyw obrazów. Narzędzie: narzędzie do sprawdzania drzewa dostępności AmICited oraz inspekcja przeglądarki. Gotowe, gdy: wynik spełnia próg, żaden krytyczny element sterujący nie jest bez nazwy, a główny region i następna czynność są identyfikowalne.

5. Zweryfikuj pokrycie i prawdziwość danych strukturalnych

Co robić: porównaj widoczne fakty z danymi strukturalnymi , czyli ustandaryzowanymi znacznikami, takimi jak Schema.org JSON-LD. Dlaczego to ważne: znaczniki wyjaśniają encje, oferty, autorstwo i daty, ale niedokładne znaczniki przekazują błędne fakty. Jak to zrobić: zweryfikuj odpowiednie schematy i uzgodnij nazwy, URL-e, ceny, waluty, dostępność, daty, oceny i identyfikatory z systemami źródłowymi. Narzędzie: walidator, wyrenderowany HTML i źródłowe rekordy. Gotowe, gdy: krytyczne szablony mają prawidłowe odpowiednie znaczniki, wartości są zgodne z widocznymi faktami, a każde istotne ostrzeżenie jest rozwiązane lub wyjaśnione.

6. Przejrzyj plik llms.txt jako wskazówkę, nie bramę

Co robić: sprawdź, czy plik /llms.txt dokładnie podsumowuje organizację i linkuje do kanonicznych publicznych zasobów. Jest to proponowany tekstowy przewodnik, a nie kontrola dostępu ani gwarantowany sygnał rankingowy. Dlaczego to ważne: zwięzła mapa zmniejsza niejednoznaczność; nieaktualna mapa wprowadza agentów w błąd. Jak to zrobić: zweryfikuj status, strukturę Markdown, opis, miejsca docelowe, kanoniczne URL-e i właściciela. Narzędzie: przegląd llms.txt w AmICited i bezpośrednie pobranie. Gotowe, gdy: plik, jeśli jest używany, nie zawiera uszkodzonych/prywatnych linków i ma właściciela ds. utrzymania; brak pliku to uwaga dotycząca ulepszenia, nie dowód niewidoczności.

7. Sprawdź samodzielne fragmenty tekstu

Co robić: przejrzyj niezależnie pobrane definicje, odpowiedzi, fakty, porównania, kroki i ograniczenia. Dlaczego to ważne: wyszukiwanie może oddzielić akapit od jego nagłówka; „działa to dla nich lepiej” traci wtedy podmiot i porównanie. Jak to zrobić: przeczytaj co najmniej 20 fragmentów bez ich tytułu lub poprzedniego akapitu. Narzędzie: wyniki ekstrakcji i przegląd redakcyjny. Gotowe, gdy: każdy fragment określa swój podmiot, odpowiada na identyfikowalne pytanie, zachowuje warunki lub jednostki i unika nierozwiązanych odniesień.

8. Potwierdź jasność encji kanonicznej

Co robić: zweryfikuj, czy strona jasno określa, kim jest organizacja, co oferuje oraz jak powiązane są jej marki, produkty, osoby, lokalizacje i profile. Encja kanoniczna to podstawowa, rzeczywista rzecz, do której odnosi się nazwa. Dlaczego to ważne: niespójne nazwy, stare logo, sprzeczne opisy i niepołączone profile URL ułatwiają połączenie dwóch encji w jedną lub podział jednej encji na kilka. Jak to zrobić: porównaj stronę główną, stronę O nas, dane kontaktowe, dane strukturalne, profile społecznościowe, strony autorów, nazwę prawną i ważne profile zewnętrzne. Narzędzie: arkusz faktów encji, wyrenderowane strony i wyniki danych strukturalnych. Gotowe, gdy: jeden zatwierdzony arkusz faktów określa oficjalną nazwę, aliasy, kanoniczny URL, logo, opis, własność, główne oferty i profile tej samej encji, a konflikty są zapisane do korekty.

9. Przetestuj czas odpowiedzi i niezawodność pobierania

Co robić: zmierz status, czas do pierwszego bajtu (TTFB), przekierowania, limity czasu i spójność odpowiedzi przy normalnych i odpowiednich agentach użytkownika crawlerów. TTFB to odstęp od rozpoczęcia żądania do nadejścia pierwszego bajtu odpowiedzi. Dlaczego to ważne: sporadyczne błędy 403, 429, 5xx, długie łańcuchy przekierowań lub wolne originy sprawiają, że treść jest zawodna, nawet jeśli pojedyncza wizyta w przeglądarce się powiedzie. Jak to zrobić: uruchom powtarzalną próbkę zdefiniowaną w tabeli progów z więcej niż jednej lokalizacji sieciowej, gdy geografia ma znaczenie, a następnie uzgodnij błędy z logami i podstawowymi wskaźnikami internetowymi (Core Web Vitals). Narzędzie: monitor żądań, logi CDN/origin oraz AmICited Web Vitals. Gotowe, gdy: krytyczne URL-e spełniają progi niezawodności i opóźnień lub mają przypisaną dotkliwość, przyczynę, właściciela i datę ponownego testu.

10. Oceń WebMCP i protokoły handlowe tam, gdzie tworzą wartość

Co robić: testuj gotowość WebMCP i handlową tylko tam, gdzie model biznesowy wspiera działania agentów. WebMCP to powstający sposób, w jaki witryna może udostępniać wywoływalne narzędzia, takie jak wyszukiwanie, rezerwacja lub dodawanie przedmiotu do koszyka. Handel agentowy (agentic commerce) obejmuje odkrywanie produktów i transakcje wspomagane przez agentów, w tym protokoły takie jak ACP lub UCP. Dlaczego to ważne: czytelna treść wspiera odpowiedzi; jawne narzędzia i dane handlowe wspierają niezawodne działanie bez ekranowego skrobania (screen scraping). Jak to zrobić: zmapuj wartościowe zadania użytkowników, sprawdź zadeklarowane narzędzia lub protokoły, zweryfikuj opisy wejść i wyjść oraz potwierdź zachowanie przy potwierdzaniu, uwierzytelnianiu, uprawnieniach, cenie, stanie magazynowym i błędach. Narzędzie: kontrole WebMCP i Handlu Agentowego w AmICited oraz kontrolowane środowisko testowe. Gotowe, gdy: odpowiednie możliwości są wykryte i bezpiecznie testowalne, lub kontrola jest oznaczona jako nie dotyczy z zatwierdzonym uzasadnieniem biznesowym i wyzwalaczem przeglądu.

Narzędzia w AmICited

Otwórz https://app.amicited.com/accessibility, aby uzyskać skonsolidowany audyt oraz opis funkcji Dostępność AI i gotowość agentowa . Produkt raportuje niezależne odczyty, zamiast ukrywać różne typy błędów w jednym mieszanym wyniku.

1. Użyj podsumowania, aby sprawdzić Wynik Dostępności Agentowej i zapisać każdy komponent, nie tylko ogólny stan.
2. Użyj Robots.txt i map witryny, aby sprawdzić pokrycie robots.txt i map witryny , a następnie porównać zadeklarowaną regułę z rzeczywistym pobraniem naśladującym crawlera.
3. Użyj przeglądu pliku, aby przejrzeć llms.txt i otworzyć każdy wymieniony cel podróży.
4. Użyj narzędzia do sprawdzania strony, aby sprawdzić drzewo dostępności strony dla każdego krytycznego szablonu.
5. Użyj kontroli gotowości, aby sprawdzić gotowość WebMCP i sprawdzić gotowość handlu agentowego , gdy te możliwości mają zastosowanie.
6. Otwórz https://app.amicited.com/audit/web-vitals, aby sprawdzić podstawowe wskaźniki internetowe (Core Web Vitals) i połączyć wydajność terenową z testami żądań w warunkach crawlera.

Zasady decyzyjne

Poniższe wartości to operacyjne progi akceptacji, a nie twierdzenia o algorytmach rankingowych. Zaostrz je dla ścieżek krytycznych dla przychodu lub treści regulowanych, a każdą alternatywę zapisz przed testowaniem, aby wynik nie był korygowany po fakcie.

Wyniki nigdy nie zastępują konkretnych dowodów. Wynik dostępności 85 nie usprawiedliwia nieoznaczonego przycisku realizacji zakupu, a zezwolenie w robots.txt nie przeważa nad stroną z wyzwaniem zwróconą rzeczywistemu żądaniu. „Nie sprawdzono” to stan nieznany, a nie zaliczenie ani zero.

Efekt końcowy: rejestr ustaleń dotyczących gotowości agentowej

Przekaż jeden rejestr ustaleń, a nie prezentację i osobny backlog AI. Dodaj każde ustalenie do listy priorytetów P2 z następującymi polami:

ID i tytuł:
Dotknięte URL-e/szablony:
Kontrola i zaobserwowany stan:
Oczekiwany stan/próg:
Dowody: znacznik czasu, agent użytkownika, status, odniesienie do przechwyconego materiału lub logu
Konsekwencja biznesowa:
Dotkliwość: Krytyczny | Poważny | Zalecenie
Zalecane działanie:
Właściciel i osoba zatwierdzająca:
Nakład pracy i zależność:
Termin i data ponownego testu:
Decyzja polityczna, jeśli dotyczy:
Wpływ na pomiar P5:
Status: Otwarte | Zaakceptowane ryzyko | Naprawione | Zweryfikowane

Krytyczny oznacza, że błąd uniemożliwia niezawodny dostęp, istotnie zmienia wyodrębnione znaczenie lub pozwala na niebezpieczne działanie. Poważny oznacza, że dostęp lub zrozumienie jest ograniczone, ale reprezentatywny klient może nadal odzyskać główną treść. Zalecenie oznacza użyteczne ulepszenie, które nie ma dowodów na obecną awarię. Zaakceptowane ryzyko wymaga nazwanego właściciela biznesowego, uzasadnienia, zakresu, daty wygaśnięcia lub przeglądu oraz sposobu wykrywania zmienionych warunków.

Deduplikuj według przyczyny źródłowej: jedno wyzwanie CDN dotykające konwencjonalnych crawlerów i crawlerów AI to jedna pozycja z wieloma dowodami.

Co może pójść nie tak

Traktowanie fazy jako opcjonalnej. Śledzenie promptów i przepisywanie treści nie może zrekompensować nieudanego wyszukiwania. Uczyń P4 warunkiem wejścia do interpretowalnego pomiaru bazowego.

Blokowanie domyślnie i nazywanie tego polityką z mocą wsteczną. Reguła bez właściciela decyzji, uzasadnienia ani daty przeglądu to konfiguracja, a nie polityka. Przedstaw kompromis między odkrywalnością a kontrolą i uzyskaj wyraźną decyzję.

Dodanie pliku llms.txt i uznanie zadania za zakończone. Plik nie może nadpisać reguł robots.txt, blokad CDN, pustego początkowego HTML-a, mylących znaczników, słabych fragmentów ani limitów czasu. Traktuj go jako jeden z przewodników w szerszym zestawie dowodów.

Testowanie tylko przyjaznego agenta użytkownika lub tylko strony głównej. Kontrole brzegowe różnią się w zależności od ścieżki, lokalizacji geograficznej, szybkości i tożsamości. Przetestuj każdy wysokowartościowy szablon i agenta użytkownika z macierzy polityki.

Mylenie wyglądu z możliwością ekstrakcji. Dopracowana strona może ukrywać zduplikowane treści, bezsensowne nazwy elementów sterujących lub pustą odpowiedź bez JavaScriptu. Zachowaj osobno dowody źródłowe, DOM, drzewo dostępności i wyodrębniony tekst.

Traktowanie nieznanego jako porażki lub sukcesu. Ponownie testuj przekroczenia czasu i niesprawdzone crawler; nigdy nie zamieniaj brakujących dowodów na wygodny wynik.

Instalowanie eksperymentalnych możliwości agentowych bez przypadku użycia. Protokoły WebMCP lub handlowe powinny udostępniać wartościowe, uprawnione działania. Wdrożenie niebezpiecznego lub niedokładnego działania jest gorsze niż oznaczenie możliwości jako nie dotyczy.

Przekazanie do pomiaru bazowego

Faza pomiaru bazowego otrzymuje połączoną listę priorytetów, pakiet dowodów testowych, rejestr polityki crawlerów, reprezentatywny zestaw URL-i i notatkę gotowości. Właściciel P4 musi zidentyfikować wszelkie ograniczenia, które zmieniają interpretację: zablokowane rodziny crawlerów, niedostępne szablony, sporadyczne regiony, brakujące fragmenty lub niedawną poprawkę, której efekt jeszcze się nie rozprzestrzenił.

P5 może rozpocząć, gdy krytyczne URL-e są celowo dostępne dla rodzin crawlerów uwzględnionych w pomiarze, prawidłowa główna treść jest ekstrahowalna, a żadne nierozwiązane ustalenie Krytyczne nie sprawiłoby, że zerowy lub niski wynik byłby nieinterpretowalny. Może rozpocząć z adnotacjami, gdy celowa blokada wyklucza znanego crawlera lub problem Poważny dotyka ograniczonego szablonu. Powinien poczekać, gdy zamiar dostępu jest nieznany, krytyczne strony nie przechodzą pobierania lub wyodrębniona treść istotnie zaprzecza widocznemu źródłu.

Przekazanie jest zakończone, gdy właściciel P5 może odpowiedzieć na trzy pytania bez ponownego otwierania audytu: którzy agenci mieli mieć dostęp, które strony i fakty mogli niezawodnie pobrać oraz które znane ograniczenia muszą pojawić się obok wartości bazowej.

FAQ

Często zadawane pytania