AI crawlers na stronie: jak odróżnić wartościowy ruch agentów od skanerów, spoofingu i marnowania zasobów? Praktyczny audyt B2B krok po kroku
SalesBot Playbook #02
Stan wiedzy: 17 sierpnia 2026 r.
Coraz więcej narzędzi analitycznych pokazuje ruch:
- AI crawlers,
- search bots,
- training bots,
- agents,
- automated traffic.
Łatwo więc dojść do wniosku:
„AI coraz częściej odwiedza naszą stronę — to dobrze.”
Problem polega na tym, że sam wzrost liczby requestów niczego jeszcze nie dowodzi.
Może oznaczać:
- wartościowe crawling Search,
- pobieranie treści do odpowiedzi,
- działanie agenta użytkownika,
- crawling treningowy,
- wielokrotne pobieranie tych samych URL-i,
- zwykły scraping,
- błędnie sklasyfikowanego bota,
- albo automatyczne skanowanie bezpieczeństwa podszywające się pod znanego crawlera.
Bardzo dobrym przykładem jest analiza opublikowana 14 sierpnia 2026 r. przez Slobodana Manica w Search Engine Journal. W ciągu 24 godzin jego dashboard Cloudflare przypisał około 1510 requestów do CCBot/Common Crawl. Po sprawdzeniu konkretnych URL-i okazało się jednak, że dominowały próby dostępu do plików konfiguracyjnych i sekretów, np. .env, SSH czy konfiguracji agentowej — a prawie nie było requestów do właściwych artykułów. Autor nie mógł z dostępnych danych jednoznacznie potwierdzić IP źródłowych, więc poprawnie opisuje to jako prawdopodobne podszywanie się/scanning, a nie jako udowodnione działanie Common Crawl. (Search Engine Journal)
Common Crawl sam ostrzega obecnie, że istnieją crawlery fałszywie identyfikujące się jako CCBot, i publikuje zarówno zakresy IP, jak i metodę weryfikacji przez reverse DNS. (commoncrawl.org)
Dla działu marketingu, SEO i osoby rozwijającej agentic commerce prowadzi to do bardzo ważnego wniosku:
Nie mierz AI crawler traffic. Najpierw ustal, jaki ruch maszynowy naprawdę otrzymujesz.
Najważniejszy wniosek w 60 sekund
W klasycznym SEO często wystarczało pytanie:
Czy Googlebot może odwiedzić stronę?
W agentic web pytania są szersze:
WHO?
Kto naprawdę wysyła request?
↓
WHY?
Po co przyszedł?
↓
WHERE?
Jakich zasobów szuka?
↓
WHAT HAPPENED?
Co otrzymał?
↓
VALUE?
Czy powstała z tego jakakolwiek wartość?
↓
GOVERNANCE?
Czy ten rodzaj dostępu jest zgodny z naszą polityką?
To proponuję potraktować jako:
Machine Traffic Audit
dla ery AI Search i Agentic Commerce.
Skąd w ogóle problem?
Cloudflare podaje, że w 2026 r. ruch niepochodzący od ludzi przekroczył 50% analizowanego przez firmę ruchu internetowego. Jednocześnie Cloudflare raportuje bardzo duży udział crawlerów treningowych i mixed-use oraz podkreśla, że coraz ważniejsze staje się rozróżnianie celu crawlera, a nie tylko faktu, że jest botem. (Cloudflare Blog)
To nie znaczy:
połowa klientów została zastąpiona przez agentów zakupowych.
„Machine traffic” obejmuje bardzo różne zjawiska.
Co więcej, CFO Cloudflare przedstawił scenariusz, w którym w ciągu kilku lat ruch maszynowy mógłby być nawet 1000 razy większy niż ludzki, ale sam zaznaczył dużą niepewność takiej projekcji. To scenariusz dotyczący wolumenu ruchu, nie prognoza, że 1000 razy wzrośnie wartościowy popyt agentowy. (Search Engine Journal)
To fundamentalne rozróżnienie:
Machine Traffic ≠ Machine Demand.
Machine Effort ≠ Business Value
Cloudflare zwrócił dodatkowo uwagę na miliardy powtarzających się fetchy dobrze zachowujących się botów pobierających treści, które od poprzedniej wizyty się nie zmieniły. Firma opisuje to jako dużą ilość pracy maszynowej bez odpowiadającego jej rezultatu. (Cloudflare Blog)
Czyli:
100 000 requestów
nie musi być lepsze niż:
100 requestów.
Jeżeli pierwsze:
- zużywają bandwidth,
- nie aktualizują niczego,
- nie generują referral,
- nie pomagają użytkownikowi,
- nie prowadzą do działania,
a drugie:
- są wykonane przez realnego agenta klienta,
- dotyczą konkretnego produktu,
- prowadzą do RFQ,
to biznesowo:
100 może być warte więcej niż 100 000.
Nowa zasada pomiaru
Nie:
REQUEST VOLUME.
Tylko:
REQUEST → PURPOSE → OUTCOME.
Najpierw rozdzielmy rodzaje ruchu maszynowego
W jednym dashboardzie mogą pojawiać się zupełnie różne klasy ruchu.
1. Search crawler
Cel:
odkrycie i wykorzystanie publicznej treści w Search.
Przykładem jest:
OAI-SearchBot.
OpenAI oficjalnie opisuje OAI-SearchBot jako crawler przeznaczony do surfacing stron w funkcjach Search w ChatGPT. OpenAI publikuje również zakresy IP tego bota. (OpenAI Developers)
To może być dla firmy:
desirable traffic.
2. Training crawler
Cel jest inny.
Przykład:
GPTBot.
OpenAI wyraźnie rozdziela GPTBot od OAI-SearchBot. GPTBot dotyczy treści, które mogą być wykorzystywane do ulepszania/treningu modeli, natomiast OAI-SearchBot odpowiada za Search. Oba ustawienia można kontrolować niezależnie. (OpenAI Developers)
Dlatego pytanie:
„Czy pozwalamy OpenAI?”
jest źle postawione.
Lepsze:
Na jaki rodzaj dostępu pozwalamy OpenAI?
3. User-triggered agent
Jeszcze czym innym jest:
ChatGPT-User.
OpenAI używa tego user agenta dla pewnych działań inicjowanych przez użytkowników ChatGPT i Custom GPTs. Nie jest on używany do automatycznego crawl całego webu ani do decydowania o obecności treści w Search. OpenAI zaznacza również, że ponieważ działanie jest inicjowane przez użytkownika, reguły robots.txt mogą nie mieć zastosowania w taki sam sposób jak dla automatycznego crawlera. (OpenAI Developers)
To niezwykle ważna kategoria.
Może oznaczać:
agent wykonuje zadanie dla realnego użytkownika.
Czyli potencjalnie:
machine request carrying human intent.
4. Archive / dataset crawler
Przykład:
CCBot.
Common Crawl buduje otwarte repozytorium danych webowych i prowadzi własny crawler. Prawdziwy CCBot posiada określony User-Agent, udokumentowane zakresy adresów oraz mechanizm reverse-DNS pozwalający potwierdzić jego pochodzenie. (commoncrawl.org)
5. Generic scraper
Może pobierać:
- ceny,
- opisy,
- dane,
- katalog produktów.
Nie musi:
- wysyłać referral,
- tworzyć leadów,
- respektować wszystkich preferencji.
6. Scanner / malicious automation
To już nie jest:
crawling contentu.
Może próbować odnaleźć:
- konfigurację,
- klucze,
- sekrety,
- przypadkowo wystawione pliki,
- niezabezpieczone endpointy.
I właśnie takie zachowanie znalazł autor SEJ pod etykietą przypisaną w dashboardzie do CCBot. (Search Engine Journal)
Kluczowy problem: User-Agent nie jest tożsamością
Request może powiedzieć:
CCBot
ale samo to jeszcze nie dowodzi:
to Common Crawl.
Common Crawl wprost ostrzega przed crawlerami podszywającymi się pod CCBot. (commoncrawl.org)
Podobna zasada powinna obowiązywać dla każdego ważnego crawlera:
claimed identity ≠ verified identity.
KROK 1. Zbuduj Machine Traffic Inventory
Nie zaczynaj od blokowania.
Najpierw:
OBSERVE.
Potrzebujesz danych z:
- Cloudflare / CDN,
- access logs,
- WAF,
- serwera,
- hostingu.
Minimalny eksport powinien zawierać:
| Pole | Po co |
|---|---|
| timestamp | kiedy |
| user agent | deklarowana tożsamość |
| IP / verified bot | weryfikacja |
| requested URL | czego chciał |
| HTTP status | co otrzymał |
| bytes | koszt transferu |
| referrer | kontekst |
| country/ASN | pomocniczo |
| request count | wolumen |
Nie potrzebujesz na początku skomplikowanej platformy.
CSV wystarczy.
KROK 2. Nie zaczynaj od nazwy bota — zacznij od URL-i
To najważniejsza lekcja z badania SEJ.
Autor najpierw zobaczył:
1510 requestów CCBot.
Dopiero analiza ścieżek pokazała, że dominują requesty do zasobów związanych z konfiguracją i sekretami, a nie do treści serwisu. (Search Engine Journal)
Dlatego nie pytaj:
„Ile razy odwiedził nas ChatGPT?”
Najpierw:
CO ODWIEDZIŁ?
Podziel request paths na kategorie
CONTENT
- artykuły,
- przewodniki,
- kategorie.
PRODUCT
- karty produktów,
- pricing,
- dokumentacja.
ACTION
- formularze,
- RFQ,
- konfiguratory,
- API.
ASSETS
- PDF,
- obrazy,
- video.
ADMIN
- logowanie,
- backend.
SENSITIVE / UNEXPECTED
- pliki konfiguracyjne,
- sekrety,
- ścieżki, których publiczny użytkownik nie powinien potrzebować.
Dopiero wtedy ruch zaczyna mieć znaczenie.
SalesBot Metric #1 — Useful Crawl Ratio
Możemy wprowadzić prostą wewnętrzną metrykę:
Useful Crawl Ratio
requesty do publicznych, wartościowych zasobów / wszystkie requesty danego bota
Przykład:
crawler:
10 000 requestów.
Do:
- content,
- products,
- docs
trafiło:
UCR:
8%.
Reszta to:
- duplikaty,
- błędy,
- zasoby bez znaczenia,
- anomalie.
To nie jest oficjalna metryka żadnego dostawcy.
To:
diagnostyczny KPI SalesBot.
KROK 3. Sprawdź status codes
Same request paths jeszcze nie wystarczą.
Porównaj:
200
crawler otrzymał zasób.
301 / 308
redirect.
404 / 410
zasób nie istnieje.
403
odmowa.
429
rate limit.
5xx
problem po stronie serwera.
OpenAI w swoich oficjalnych zaleceniach dotyczących crawlerów również rekomenduje przy diagnostyce analizę kodów odpowiedzi, w szczególności 403 i 429, oraz reguł WAF/CDN. (OpenAI Help Center)
Dlaczego 404 może być dobrą wiadomością?
Scanner pyta o:
potencjalny plik zawierający sekret.
Serwer odpowiada:
404.
To może być:
właściwy wynik.
Znacznie gorzej, gdy przypadkiem odpowiedź brzmi:
200.
Dlatego przy security-sensitive paths:
wysoki CTR nie jest KPI.
KROK 4. Zweryfikuj tożsamość ważnych crawlerów
Nie rób tego dla każdego przypadkowego User-Agenta.
Najpierw:
- Google,
- OpenAI,
- Common Crawl,
- inne boty mające znaczenie biznesowe.
OpenAI
OpenAI publikuje osobne zakresy IP dla:
- OAI-SearchBot,
- GPTBot,
- ChatGPT-User. (OpenAI Developers)
Dlatego przy większym serwisie warto weryfikować ruch nie tylko po:
User-Agent,
ale również względem:
oficjalnego zakresu źródłowego.
OpenAI samo rekomenduje, aby nie polegać wyłącznie na krótkoterminowej obserwacji IP i łączyć User-Agent, oficjalne ranges, mechanizmy provider-level verification oraz właściwe konfiguracje firewall/CDN. (OpenAI Help Center)
Common Crawl
CCBot można weryfikować:
- przez opublikowane zakresy,
- reverse DNS,
- ponowne rozwiązanie nazwy do tego samego IP.
Common Crawl publikuje własne instrukcje i JSON zawierający zakresy. (commoncrawl.org)
Dlaczego to ważne?
Bo:
User-Agent: CCBotmoże oznaczać:
prawdziwy CCBot
albo:
kogoś, kto napisał CCBot w nagłówku.
To dramatycznie różne rzeczy.
SalesBot Metric #2 — Verified Bot Rate
Verified Bot Rate
zweryfikowane requesty / requesty deklarujące danego bota
Przykład:
5000 requestów twierdzi:
KnownBot.
Po weryfikacji:
VBR:
64%.
Pozostałe:
wymagają oddzielnej analizy.
KROK 5. Nie używaj robots.txt jako zabezpieczenia sekretów
To chyba najważniejsza techniczna zasada całego przewodnika.
robots.txt mówi:
szanującym go crawlerom, czego nie powinny crawlować.
Nie mówi:
kto ma prawo uzyskać dostęp do pliku.
Google bardzo wyraźnie podkreśla, że robots.txt nie jest mechanizmem zabezpieczania prywatnej zawartości; crawler może go nie respektować, a poufne pliki powinny być chronione rzeczywistą kontrolą dostępu, np. uwierzytelnieniem. (Google for Developers)
Czyli:
robots.txt = crawl policy.
Nie:
security boundary.
Zła logika
„Dodaliśmy
/.secret/do robots.txt, więc dane są bezpieczne.”
Nie.
Jeżeli plik jest dostępny publicznie pod URL-em:
security problem już istnieje.
Właściwa logika
Sekret:
nie powinien być serwowany publicznie.
Koniec.
KROK 6. Sprawdź, czy secrets w ogóle znajdują się w web root
Badanie SEJ jest szczególnie ciekawe dlatego, że automatyczne listy wykorzystywane przez scannery zaczynają uwzględniać również konfiguracje związane z ekosystemem agentów — autor zauważył m.in. requesty do konfiguracji MCP. (Search Engine Journal)
To prowadzi do bardzo praktycznej kontroli:
czy wdrażając AI/agents przypadkiem nie stworzyliśmy nowych klas sekretów?
Przykładowe kategorie:
- API credentials,
- service tokens,
- cloud credentials,
- agent credentials,
- MCP authorization data.
Oficjalna dokumentacja MCP poświęca obecnie osobny, obszerny materiał zagrożeniom i mechanizmom autoryzacji, w tym problemom OAuth, token passthrough, SSRF, lokalnym serwerom MCP i minimalizacji zakresu uprawnień. (Model Context Protocol)
Agentic Commerce zwiększa powierzchnię bezpieczeństwa
Jeżeli strona była dotąd:
READ ONLY,
jej głównym zadaniem było:
udostępniać informacje.
Jeżeli dodamy:
- MCP,
- tools,
- APIs,
- konfiguratory,
- RFQ,
- agent actions,
powstaje:
ACTION LAYER.
A wtedy agent może potencjalnie:
- odczytać dane,
- uruchomić tool,
- przygotować działanie,
- przekazać dane,
- wykonać operację.
Dlatego nasze:
A2O Readiness
musi zawierać:
Governance.
A2O bez Governance jest niepełne
W naszym A2O Readiness Grid mamy:
Discoverability
Clarity
Comparability
Verifiability
Actionability
Governance.
Ten przykład świetnie pokazuje, dlaczego Governance nie jest dodatkiem.
Im bardziej strona staje się:
agent-actionable,
tym ważniejsze stają się:
- identity,
- permissions,
- authorization,
- audit,
- limits,
- ownership.
KROK 7. Zbuduj Bot Purpose Matrix
Nie stosowałbym zasady:
allow AI
ani:
block AI.
To zbyt prymitywne.
Stwórz tabelę.
| Klasa | Cel | Potencjalna wartość | Polityka |
|---|---|---|---|
| Search crawler | visibility | wysoka | allow |
| User agent | zadanie użytkownika | bardzo wysoka | allow/control |
| Training crawler | model training | zależna od strategii | decision |
| Archive | dataset/archive | zależna | decision |
| Commercial scraper | extraction | niska/ujemna | evaluate |
| Scanner | reconnaissance | ujemna | block |
To jest:
purpose-based crawler governance.
OpenAI jest dobrym przykładem
Możemy zdecydować:
OAI-SearchBot
ALLOW
bo chcemy Search visibility.
GPTBot
ALLOW albo DISALLOW
zależnie od polityki firmy wobec treningu.
ChatGPT-User
obsługiwać jako możliwy ruch związany z konkretnym działaniem użytkownika.
OpenAI celowo rozdziela te kategorie. (OpenAI Developers)
To znacznie dojrzalsze niż:
Disallow: wszystkie AI bots.
KROK 8. Oddziel Search Visibility od Training Access
To rozróżnienie powinno znaleźć się w każdym audycie AI Search.
Firma może chcieć:
być widoczna w ChatGPT Search
ale jednocześnie:
nie udostępniać treści GPTBotowi do treningu.
OpenAI dokumentuje, że te ustawienia są niezależne. (OpenAI Developers)
Czyli:
Search policy ≠ Training policy.
To ważne zarówno technicznie, jak i biznesowo.
KROK 9. Oddziel crawler od agenta klienta
To kolejny poziom.
Crawler:
indeksuje.
Agent:
może działać w imieniu człowieka.
Cloudflare w swojej wizji Agentic Internet opisuje przyszłość webu jako:
readable → discoverable → callable → payable,
czyli przejście od samego odczytu do wykonywania działań i transakcji. (Cloudflare Blog)
To bardzo dobrze pasuje do B2B.
Klasyczny crawler
Pobiera:
/owijarki-do-palet/
Agent potencjalnego klienta
Może potrzebować:
- przeczytać kategorię,
- porównać modele,
- znaleźć parametry,
- sprawdzić możliwość testu,
- przygotować RFQ.
To jest:
Machine Demand.
A nie:
Machine Traffic.
KROK 10. Sprawdź crawler-to-outcome
Dla każdego ważnego bota pytaj:
Ile requestów?
ale również:
Do czego?
Ile unikalnych wartościowych URL-i?
Ile transferu?
Ile błędów?
Czy generuje referral?
Czy prowadzi do użytkownika?
Czy wspiera Search visibility?
Czy wykonuje action?
SalesBot Metric #3 — Machine Traffic Value Map
Nie próbowałbym od razu zamykać tego w jednym score.
Lepszy dashboard:
OAI-SearchBot
Requests: 4 820
Content/Product: 82%
Verified: 99%
4xx: 3%
Referral/AI Search: YES
Business role: DISCOVERYUnknownBot claiming X
Requests: 7 300
Content/Product: 2%
Sensitive-path probes: 71%
Verified: 0%
Business role: NONE / SECURITYOd razu wiemy:
które „7300 AI requests” mają wartość.
KROK 11. Mierz Crawl-to-Referral Ratio — ale ostrożnie
Cloudflare coraz częściej analizuje relację:
crawl volume ↔ referral value.
Firma wskazuje, że właściciele treści zaczynają używać takich danych do oceny ekonomicznej wartości dostępu crawlerów. (Cloudflare Blog)
Przykład:
Bot A
100 000 crawl requests
500 referrals
↓
500:100 000
Bot B
5 000 requests
400 referrals
Bot B może mieć:
znacznie lepszą relację biznesową.
Ale dla B2B nie zatrzymywałbym się nawet na referral.
B2B powinno mierzyć dalej
Crawl
↓
AI Visibility
↓
Referral / Mention
↓
Product
↓
RFQ
↓
Pipeline.
To jest prawdziwy:
Machine-to-RFQ Funnel.
KROK 12. Sprawdź duplicate fetching
Jeżeli crawler pobiera:
ten sam niezmieniony URL 500 razy,
to nie oznacza:
ogromnego zainteresowania produktem.
Może oznaczać:
nieefektywność crawlingu.
Cloudflare wskazuje właśnie repeated fetching niezmienionych stron jako duże źródło machine traffic bez odpowiadającego rezultatu. (Cloudflare Blog)
Dlatego w logach warto badać:
URL × Bot × Time.
SalesBot Metric #4 — Re-fetch Waste Rate
ponowne pobrania niezmienionych zasobów / wszystkie requesty crawlera
To znów:
nasza metryka diagnostyczna,
nie standard branżowy.
Pomaga jednak odpowiedzieć:
ile machine traffic to realna aktywność, a ile powtarzanie tego samego?
KROK 13. Zidentyfikuj „crawler traps”
Bardzo duży ruch może być również skutkiem architektury strony.
Przykładowo:
- nieskończone filtry,
- parametry URL,
- kalendarze,
- paginacje,
- wyszukiwanie wewnętrzne,
- duplikaty,
- przypadkowe generowanie nowych kombinacji URL.
Wtedy:
bot wygląda agresywnie,
ale część problemu stworzyła:
strona.
Dlatego Machine Traffic Audit powinien być połączony z:
technical SEO.
KROK 14. Nie wrzucaj AI botów do jednego worka w Analytics
To powinno być jedno z najważniejszych usprawnień raportowych.
Nie:
AI Crawlers = 36 000 requests.
Tylko:
SEARCH
TRAINING
USER-TRIGGERED
ARCHIVE
SCRAPING
UNKNOWN
SECURITY.
Dopiero wtedy możemy podejmować decyzje.
KROK 15. Zbuduj Allow / Monitor / Rate-limit / Block Policy
Dla każdej klasy ruchu:
ALLOW
realna wartość.
MONITOR
niepewna wartość.
RATE LIMIT
wartość możliwa, ale koszt zbyt duży.
BLOCK
brak wartości / ryzyko.
Nie każda firma będzie miała tę samą politykę.
Firma przemysłowa ≠ publisher
Dla dużego wydawcy:
crawling treści
może mieć ogromny koszt ekonomiczny.
Dla producenta maszyn posiadającego 300 stron:
ważniejsze może być maksymalne udostępnienie publicznej wiedzy produktowej Search/agentom.
Dlatego nie kopiowałbym polityki:
New York Times
do:
polskiego producenta urządzeń.
Pytanie powinno brzmieć:
Jaki machine access pomaga realizować nasz model biznesowy?
KROK 16. Rozdziel public knowledge od private capability
To fundament Agentic Commerce.
PUBLIC
Agent może zobaczyć:
- produkt,
- parametry,
- dokumentację,
- use cases,
- cenę orientacyjną.
CONTROLLED
Może:
- sprawdzić dostępność,
- wygenerować konfigurację,
- przygotować RFQ.
PRIVATE
Nie powinien mieć publicznego dostępu do:
- credentials,
- wewnętrznych systemów,
- tokenów,
- danych klientów,
- konfiguracji infrastruktury.
To trzy różne warstwy.
Public ≠ callable
To, że agent może:
przeczytać cenę,
nie oznacza:
może ją zmienić.
To, że może:
przygotować RFQ,
nie oznacza:
może złożyć zamówienie.
Dlatego wracamy do naszego:
Agent Permission Ladder
READ
↓
COMPARE
↓
QUALIFY
↓
PREPARE
↓
SUBMIT
↓
COMMIT.
Im niżej:
tym mocniejsze:
Governance.
KROK 17. Audytuj MCP osobno
Jeżeli firma zaczyna eksperymentować z MCP, nie traktowałbym tego jako dodatku do SEO.
To nowa:
machine interface.
Oficjalna dokumentacja MCP posiada już rozbudowane Security Best Practices dotyczące m.in.:
- authorization,
- token handling,
- SSRF,
- privilege boundaries,
- scope minimization,
- lokalnych MCP servers. (Model Context Protocol)
Dlatego do każdego projektu MCP dodałbym checklistę:
Jakie resources udostępnia?
Jakie tools?
Dla kogo?
Jakie scopes?
Gdzie przechowywane są credentials?
Czy wymagane jest human approval?
Czy wszystkie calls są audytowalne?
KROK 18. Wprowadź Machine Surface Inventory
Tak samo jak wcześniej robiliśmy:
Content Inventory,
teraz potrzebujemy:
Machine Surface Inventory.
Przykład:
| Surface | Public | Machine accessible | Action | Risk |
|---|---|---|---|---|
| artykuły | tak | tak | read | low |
| produkty | tak | tak | read | low |
| calculator | tak | tak | calculate | low |
| availability | częściowo | API | check | medium |
| RFQ | tak | agent | submit | medium |
| CRM | nie | controlled | update | high |
| ERP | nie | controlled | order | very high |
To bardzo dobry most:
SEO → A2O.
KROK 19. Połącz Machine Surface z A2O Readiness Grid
Każdy machine-accessible element oceń według:
Discoverability
Czy właściwy agent może go odnaleźć?
Clarity
Czy wiadomo, co robi?
Comparability
Czy wyniki są jednoznaczne?
Verifiability
Czy wiadomo, skąd pochodzą dane?
Actionability
Czy agent potrafi wykonać właściwe działanie?
Governance
Czy działanie jest kontrolowane?
Tutaj AI crawler audit staje się:
A2O audit.
KROK 20. Zbuduj miesięczny Machine Traffic Dashboard
Dla firmy B2B proponuję raportować:
TOTAL MACHINE REQUESTS
ale tylko jako baseline.
Verified Search Crawlers
ile.
User-triggered Agents
ile.
Training Crawlers
ile.
Unknown/Suspicious
ile.
Useful Crawl Ratio
ile ruchu trafia do sensownych zasobów.
Top Machine URLs
jakie strony interesują maszyny.
Top Product URLs
jakie produkty.
Error Rate
4xx/5xx.
Suspicious Path Rate
jaki udział requestów wygląda jak scanning.
Crawl-to-Referral
jeśli możliwe.
Agent Actions
jeżeli już posiadamy actions.
Ale najważniejszy raport to nie Machine Traffic
Najważniejszy powinien być:
Machine Value.
Przykład:
AI / Machine Activity
↓
34 000 requests
↓
8 200 verified search/agent requests
↓
1 300 strategic product fetches
↓
96 AI/referral visits
↓
12 product interactions
↓
3 RFQsTo zaczyna mówić coś:
biznesowego.
KROK 21. Ustal alerty na zmianę zachowania
Nie tylko:
„crawler przekroczył 10 000 requestów”.
Lepsze anomalie:
nagły wzrost 404,
wzrost requestów do nietypowych ścieżek,
deklarowany znany bot spoza zweryfikowanych zakresów,
nagły skok transferu,
systematyczne pobieranie tego samego URL-a,
requesty do niepublicznych powierzchni.
To są:
behavior alerts.
KROK 22. Nie traktuj „AI crawler dashboard” jako security dashboard
To dokładnie jedna z lekcji eksperymentu SEJ.
Autor zauważył, że podejrzane requesty były widoczne w analizie AI crawler traffic, ale nie w security events, ponieważ nie uruchomiły żadnej reguły bezpieczeństwa. (Search Engine Journal)
Dlatego:
Analytics ≠ Security.
Potrzebujesz obu.
Analytics pyta
co odwiedza stronę?
Security pyta
co robi coś, czego nie powinno?
To różne pytania.
KROK 23. Zbuduj politykę przed agentic commerce
Zanim uruchomisz:
- MCP,
- WebMCP,
- agent tools,
- agentic checkout,
- Direct RFQ API,
ustal:
Machine Access Policy.
Powinna określać:
- jakie dane są publiczne,
- jakie dane są controlled,
- jakie actions są dozwolone,
- które wymagają identity,
- które wymagają authorization,
- które wymagają human approval,
- jak długo przechowujemy logs,
- kto odpowiada za incident.
To jest ważniejsze niż „czy mamy MCP”
Wiele firm zacznie od pytania:
Czy powinniśmy wdrożyć MCP?
Lepsza kolejność:
BUSINESS TASK
↓
DATA
↓
ACTION
↓
RISK
↓
PERMISSION
↓
GOVERNANCE
↓
PROTOCOL.
Dopiero na końcu:
MCP / A2A / WebMCP / API.
KROK 24. Wykorzystaj crawler logs także do Product Development
Tu zaczyna robić się szczególnie ciekawie.
Załóżmy, że verified crawlers i agents regularnie odwiedzają:
- specyfikacje,
- pricing,
- dokumentację,
- porównania,
- availability.
To może mówić nam:
jakich typów informacji machine users potrzebują przed decyzją.
Machine Content Demand
Jeżeli najczęściej pobierane są:
pricing pages
→ być może cena jest ważnym decision variable.
technical docs
→ specyfikacja jest kluczowa.
comparison pages
→ category wymaga qualification.
calculators
→ potrzebny jest model decyzyjny.
To może wpłynąć na:
Answer Architecture.
Ale najpierw verify identity
Nie wyciągaj wniosku:
„agenci interesują się naszymi cenami”
z ruchu niezweryfikowanego scrapera.
Najpierw:
WHO.
Dopiero potem:
WHY.
KROK 25. Zbuduj Agent Demand Map
Jeżeli mamy już zweryfikowane user-agent / agent interactions, możemy zacząć obserwować:
które capabilities są używane.
Przykład:
| Capability | Agent calls |
|---|---|
| find_product | 420 |
| compare | 210 |
| availability | 170 |
| calculate_roi | 95 |
| prepare_rfq | 26 |
To jest zupełnie nowy rodzaj danych:
Agent Demand.
I może bezpośrednio prowadzić do:
Product Development.
Czego nauczył nas eksperyment SEJ?
Nie tego, że:
Common Crawl kradnie credentials.
Tego autor nie udowodnił i sam zaznacza ograniczenie swoich danych. (Search Engine Journal)
Znacznie ważniejsza lekcja brzmi:
nie ufaj etykiecie w dashboardzie bez analizy zachowania i weryfikacji źródła.
Druga:
machine traffic może obejmować jednocześnie wartościowy crawling, bezwartościowe powtórzenia i zachowania wrogie.
Trzecia:
wraz z rozwojem ekosystemu agentów rośnie również nowa powierzchnia konfiguracji, credentials i capabilities wymagająca governance. Oficjalne MCP Security Best Practices pokazują, że ten problem jest już traktowany jako pełnoprawna domena bezpieczeństwa. (Model Context Protocol)
60-minutowy Machine Traffic Audit
Jeżeli masz dziś zrobić tylko jeden test:
1.
Otwórz Cloudflare / server logs.
2.
Wybierz:
ostatnie 24–72 godziny.
3.
Wyeksportuj machine/bot traffic.
4.
Zgrupuj:
User-Agent.
5.
Dla Top 10 botów sprawdź:
Top requested paths.
6.
Oznacz:
- CONTENT,
- PRODUCT,
- ACTION,
- ASSET,
- ERROR,
- SENSITIVE/UNEXPECTED.
7.
Sprawdź:
200 / 403 / 404 / 429 / 5xx.
8.
Zweryfikuj tożsamość 3 najważniejszych crawlerów na podstawie dokumentacji ich operatorów.
9.
Policz:
Useful Crawl Ratio.
10.
Odpowiedz:
który bot wnosi wartość, który zużywa zasoby, a który wygląda podejrzanie?
To wystarczy, aby przejść od:
„mamy 25 000 odwiedzin AI crawlerów”
do:
rzeczywistej diagnozy.
Checklista dla marketing managera
IDENTITY
- Jakie maszyny odwiedzają stronę?
- Czy ich tożsamość jest zweryfikowana?
- Czy User-Agent może być spoofed?
PURPOSE
- Search?
- Training?
- User-triggered agent?
- Archive?
- Scraping?
- Scanner?
CONTENT
- Jakie URL-e pobierają?
- Content?
- Product?
- PDF?
- Pricing?
SECURITY
- Czy pojawiają się nietypowe ścieżki?
- Czy sekrety są poza publicznym web root?
- Czy security log pokazuje anomalie?
TECHNICAL
- jakie HTTP status?
- ile 429?
- ile 5xx?
- duplicate fetching?
BUSINESS
- referral?
- product interaction?
- RFQ?
GOVERNANCE
- kogo allow?
- kogo monitor?
- kogo rate-limit?
- kogo block?
AGENTIC
- jakie resources?
- jakie tools?
- jakie permissions?
- human approval?
Czego NIE robić?
Nie blokuj automatycznie wszystkich AI botów
Możesz zablokować Search visibility albo działanie potencjalnego klienta.
Nie pozwalaj automatycznie wszystkim AI botom
„AI” nie jest kategorią zaufania.
Nie ufaj samemu User-Agent
Może być podszyty.
Nie używaj robots.txt do ochrony sekretów
To nie security mechanism. (Google for Developers)
Nie traktuj liczby requestów jako KPI widoczności AI
Request może być bezwartościowy albo wrogi.
Nie traktuj security logów jako kompletnego obrazu ruchu
Request może nie wyzwolić reguły, a nadal być istotnym sygnałem.
Nie wdrażaj agent actions bez governance
Najpierw permission architecture.
Najważniejsza zmiana dla SEO
Klasyczny model:
CRAWL → INDEX → RANK → CLICK.
AI Search dodaje:
CRAWL
↓
RETRIEVE
↓
ANSWER
↓
MAYBE CLICK.
Agentic commerce idzie dalej:
DISCOVER
↓
READ
↓
COMPARE
↓
CALL
↓
ACT.
Dlatego monitoring techniczny również musi ewoluować.
Nie możemy już analizować wszystkich automatów jako:
„bot traffic”.
Najważniejsza zmiana dla A2O
A2O nie powinno pytać tylko:
Czy agent może korzystać z naszej strony?
Powinno zadawać również:
Który agent?
W jakim celu?
Do jakich danych?
Z jakimi uprawnieniami?
Czy jego identity jest zweryfikowana?
Czy działanie pozostawia audit trail?
To jest przejście:
Agent Readiness
do:
Governed Agent Readiness.
Od SEO do Machine Governance
Pełny model zaczyna więc wyglądać:
HUMAN + MACHINE DEMAND
↓
SEARCH / AGENT DISCOVERY
↓
IDENTITY
↓
ACCESS POLICY
↓
ANSWER ARCHITECTURE
↓
PRODUCT DATA
↓
ACTION
↓
AUTHORIZATION
↓
DIRECT RFQ / COMMERCE
↓
AUDIT.
I właśnie dlatego bezpieczeństwo ruchu maszynowego przestaje być:
wyłącznie problemem administratora serwera.
Staje się również częścią:
strategii marketingowej i handlowej firmy.
Dlaczego marketing powinien zainteresować się logami?
Bo logi mogą odpowiedzieć na pytania, których GA4 nie pokaże:
które maszyny interesują się naszym produktem?
które dokumenty są pobierane?
które strony AI crawluje bardzo często?
czy agent trafia do kalkulatora?
czy Search crawler może dotrzeć do kategorii?
czy nasze WAF blokuje wartościowy ruch?
czy machine traffic jest w większości bezwartościowy?
To może być nowa warstwa:
Technical Demand Intelligence.
A potem łączymy ją z Search Console
Możemy mieć:
Google Search
impressions / clicks.
Google Generative AI
AI impressions.
ChatGPT
referrals / brand monitoring.
Machine Logs
crawler/agent interactions.
RFQ
realne zapytania.
Dopiero razem pokazują:
Digital Demand System.
FAQ
Czy duży ruch AI crawlerów jest dobrym sygnałem?
Nie sam w sobie. Trzeba ustalić tożsamość crawlera, cel requestów, odwiedzane zasoby i rezultat biznesowy.
Czy User-Agent wystarcza do identyfikacji crawlera?
Nie zawsze. Common Crawl ostrzega przed botami podszywającymi się pod CCBot i publikuje dodatkowe mechanizmy weryfikacji. (commoncrawl.org)
Czy OpenAI publikuje adresy swoich crawlerów?
Tak. OpenAI publikuje zakresy dla OAI-SearchBot, GPTBot i ChatGPT-User. (OpenAI Developers)
Czym różni się OAI-SearchBot od GPTBot?
OAI-SearchBot służy do Search. GPTBot dotyczy treści, które mogą być wykorzystane do ulepszania/treningu generatywnych modeli OpenAI. Ustawienia są niezależne. (OpenAI Developers)
Co to jest ChatGPT-User?
To User-Agent używany przy pewnych działaniach wykonywanych na prośbę użytkownika ChatGPT lub Custom GPT; nie jest crawlerem automatycznie indeksującym cały web. (OpenAI Developers)
Czy robots.txt zabezpiecza poufne pliki?
Nie. Robots.txt jest mechanizmem sterowania crawlingiem, a nie kontrolą dostępu. Prywatne zasoby należy zabezpieczać rzeczywistym mechanizmem autoryzacji. (Google for Developers)
Czy powinienem blokować GPTBot?
To decyzja dotycząca własnej polityki wobec treningu. Nie jest konieczne zezwalanie GPTBotowi, aby jednocześnie pozwalać OAI-SearchBot na Search. (OpenAI Developers)
Czy każdy bot powinien mieć dostęp do Product Cards?
Nie. Publiczne informacje produktowe mogą być szeroko dostępne, ale działania i dane niepubliczne powinny podlegać właściwym controls i governance.
Czy MCP zwiększa ryzyko?
MCP wprowadza dodatkową powierzchnię integracji i dlatego posiada własne Security Best Practices dotyczące m.in. authorization, token handling, SSRF i scope minimization. (Model Context Protocol)
Podsumowanie
Najbardziej użyteczne zdanie z całego eksperymentu nie brzmi:
„AI crawlers atakują strony.”
To byłoby zbyt szerokie i niepoprawne.
Brzmi:
Nie zakładaj, że wiesz, czym jest machine traffic, dopóki nie sprawdzisz jego zachowania.
Bo:
Search crawler
≠
training crawler
≠
user agent
≠
scraper
≠
scanner podszywający się pod crawlera.
Dlatego do klasycznego:
SEO CRAWL AUDIT
musimy dołożyć:
MACHINE TRAFFIC AUDIT.
A w firmach rozwijających agentic commerce:
MACHINE GOVERNANCE.
Wtedy dopiero możemy świadomie zdecydować:
które maszyny chcemy zapraszać, jakie informacje im udostępniać, jakie działania pozwolić wykonywać i w którym miejscu nadal musi być człowiek.
Zobaczmy, gdzie w Twoim ekosystemie tracą się wartościowe zapytania
Napisz, co sprzedajesz, do jakich firm chcesz docierać i jak obecnie powstają zapytania. Sprawdzimy, czy największy potencjał znajduje się w stronie produktowej, nowym klastrze tematycznym, widoczności w Google i AI, konwersji, analityce czy w połączeniu kilku elementów.
Sprawdź potencjał swojej firmy
Kontakt bezpośredni: kontakt@salesbot.pl