Cloudflare Radar показва силна асиметрия между това колко страници обхождат (crawl-ват) AI ботовете и колко реферален трафик връщат на сайтовете.
В Cloudflare това се нарича crawl-to-refer ratio: колко HTML страници изисква ботът в сравнение с броя посещения, които платформата след това изпраща обратно към сайта.
При класическото търсене този обмен беше по-ясен: търсещият бот обхожда сайта, индексира съдържанието и връща потребителите чрез SERP. По данни на Cloudflare, при Google това съотношение може да бъде близо до 5:1.
Но при AI ботовете ситуацията е различна. В отделни извадки Cloudflare показва за Anthropic десетки хиляди обхождания за един referral, а за OpenAI — над хиляда обхождания за един referral.
И тук у много брандове се появява логична реакция: да блокират всички AI ботове.
В краткосрочен план това изглежда рационално:
- по-малко натоварване на сървъра;
- по-малко безплатно изтегляне на съдържание;
- по-малко неконтролирано използване на материали;
- по-лесно обяснение на решението пред юридическия или контент екипа.
Но проблемът е, че това невинаги е най-добрата стратегия за visibility (видимост).
LLM системите могат да използват web crawling за различни цели: training, AI search, user-triggered browsing, citations, answer generation. Ако блокирате всички еднакво, може случайно да отрежете не само training ботовете, но и онези crawler-и, които потенциално биха могли да доведат бранда в AI отговорите или да осигурят downstream visibility.
Затова решението не трябва да бъде „allow all“ (разреши всичко) или „block all“ (блокирай всичко). По-правилният подход е ботовете да се класифицират по предназначение и да се взема решение отделно за всеки тип.
Какво трябва да направи SEO специалистът:
1. Да анализира server logs или CDN logs
Вижте кои AI user-agents реално посещават сайта:
- GPTBot;
- ChatGPT-User;
- OAI-SearchBot;
- ClaudeBot;
- Claude-User;
- PerplexityBot;
- Google-Extended;
- GoogleOther;
- Meta-ExternalAgent;
- Bytespider;
- CCBot;
- други AI / scraper user-agents.
2. Да раздели ботовете по роли
Условно те могат да бъдат разделени на няколко групи:
- training bots — събират данни за обучение на модели;
- AI search bots — могат да се използват за търсене и цитиране;
- user-triggered agents — действат в отговор на заявка от конкретен потребител;
- classic search bots — Googlebot, Bingbot и други търсещи crawler-и;
- suspicious scrapers — неизвестни или агресивни ботове без ясна полза.
3. Да оцени ползата и риска за всяка група
За всеки бот трябва да се разбере:
- колко страници обхожда;
- кои раздели на сайта засяга;
- дали създава натоварване;
- дали носи referral traffic;
- може ли да влияе на AI visibility;
- съответства ли поведението му на вашата content strategy.
4. Да не разчита само на robots.txt
robots.txt е директива за crawler-ите, а не сигурна ключалка. Добросъвестните ботове може да я спазват, но технически тя не пречи на никого да направи заявка към страницата.
Ако трябва реално да ограничите достъпа, по-добре е да използвате правила на ниво сървър (server-side) или на ниво CDN: WAF, rate limiting, user-agent rules, IP intelligence, bot management.
5. Да взема решения според сценария, а не глобално
Например:
- разрешаване на classic search bots;
- разрешаване на user-triggered AI agents, ако те могат да водят потребители;
- ограничаване на training bots за скъпо или лицензирано съдържание;
- блокиране на агресивните scraper-и;
- отделно настройване на правилата за paywalled или premium content;
- отваряне на публичните информационни страници, ако са необходими за AI visibility.
Практически чек-лист:
- Извличане на логовете за последните 30–90 дни.
- Групиране на трафика по user-agent.
- Отделяне на AI ботовете от класическите търсещи ботове.
- Изчисляване на requests, HTML hits, status codes, crawl depth и top crawled URLs.
- Проверка дали има referral traffic от съответните AI платформи.
- Отделна оценка на стойността на съдържанието, което се обхожда.
- Подготовка на allow / block / rate-limit политика.
- Документиране на решението за SEO, legal и контент екипите.