Cloudflare / SEO / AI Crawlers

Cloudflare вече позволява да спрете AI training, без да блокирате Googlebot

Cloudflare въведе Disallow AI Training и промени поведението на mixed-use crawlers. За сайтове зад Cloudflare разликата между Disallow и Block вече е критична за Googlebot, Bingbot и SEO.

Какво точно промени Cloudflare

На 15 септември 2026 г. Cloudflare обяви нова настройка Disallow AI Training и промени начина, по който Bot Management и AI Crawl Control работят с mixed-use crawlers. Това са crawler-и, които могат да участват едновременно в Search и AI-related use cases.

Cloudflare посочва Googlebot, Bingbot и Applebot като ключови mixed-use crawler-и. От тази промяна нататък настройките Block и Block on pages with ads могат да спрат тези crawler-и изцяло, което означава, че ефектът не се ограничава само до AI training.

Защо Block вече е SEO риск

Ако собственикът на сайт избере Training → Block с идеята просто да откаже AI training, той може да блокира и нормалния search crawler. При Google това означава Googlebot да не достига страниците, което може да засегне crawlability и впоследствие индексирането.

Cloudflare го описва директно: ако искате mixed-use crawler-ите да бъдат спрени напълно, изберете Block. Ако искате Search да остане достъпен, но да изразите отказ от AI training, използвайте Disallow AI Training.

Как работи Disallow AI Training

Новата настройка не блокира crawler-а на мрежово ниво. Вместо това Cloudflare синхронизира предпочитанията към подходящите robots.txt controls, така че crawler-ът да може да продължи search функцията си, но да получи отделен сигнал за training use case.

При Google това стъпва върху Google-Extended. Официалната документация на Google казва, че Google-Extended позволява на издателите да контролират дали crawled content може да се използва за обучение на бъдещи поколения Gemini модели и някои grounding сценарии. Google изрично посочва, че Google-Extended не влияе на включването на сайта в Search и не е ranking signal.

Фактът и нашият анализ

Фактът е, че Cloudflare вече разделя по-прецизно Search, Training и Agent като различни цели на автоматизирания трафик. Компанията казва, че Apple, Google и Microsoft са Accountable crawlers, които вече уважават или са поели конкретен ангажимент да уважават тези разделени предпочитания.

Нашият анализ е, че това е правилната посока за web инфраструктурата. Етикетът „AI bot“ вече е прекалено общ. Един crawler може да индексира, друг да обучава модел, трети да действа от името на потребител, а mixed-use crawler може да изпълнява повече от една функция. Затова policy-то трябва да бъде permission matrix, а не един глобален AI toggle.

Какво става със съществуващите Cloudflare настройки

Cloudflare казва, че в почти всички случаи съществуващите клиенти не трябва да правят нищо спешно. Предишните настройки се мигрират към новия модел така, че съществуващото намерение да бъде запазено без неочаквана загуба на Search visibility.

Това е важно уточнение: няма основание да се твърди, че Cloudflare внезапно е блокирал Google на всички сайтове. Реалният риск е най-вече при нова или ръчно променена конфигурация, когато администратор избере Block, мислейки, че спира само training.

Какво означава това за Google Search

Google-Extended не е отделен HTTP crawler user-agent. Crawling се извършва чрез съществуващата Google crawling infrastructure, а Google-Extended е control token в robots.txt. Това е една от причините грубото блокиране на Googlebot да е грешният инструмент, ако целта е само AI training opt-out.

За сайт, който разчита на органичен трафик, Search трябва да остане достъпен. Ако бизнесът не желае съдържанието му да участва в training за определени Gemini use cases, Google-Extended е официалният механизъм за това.

А как стои въпросът с Bing и Apple

Cloudflare описва Bingbot и Applebot като mixed-use crawler-и със собствени механизми или roadmap за отделяне на search и training preferences. Apple използва Applebot-Extended за training opt-out, а Microsoft предоставя отделни controls и работи по по-пълна site-level реализация.

Практическият извод е, че един и същ high-level policy може да се реализира по различен начин за различните crawler operators. Затова техническият SEO audit вече трябва да гледа не само robots.txt като файл, а реалния резултат от Cloudflare policy + crawler-specific controls.

Практически checklist за сайт зад Cloudflare

Отворете Security → AI bot policies и проверете отделно Search, Training и Agent. За сайт, който разчита на organic traffic, Search обикновено трябва да остане Allow. Ако искате да откажете AI training, проверете дали използвате Disallow AI Training, а не Block.

След промяната отворете robots.txt и потвърдете какви правила реално са публикувани. Проверете Google Search Console URL Inspection за стратегически страници, следете Crawl Stats и при възможност логовете за Googlebot/Bingbot. Ако имате custom WAF rules, уверете се, че не блокират crawler-а независимо от новата AI policy.

При eCommerce проверете категории, продукти и важните commercial landing pages. При publisher или content site проверете и секциите, които носят Discover и News трафик. След всяка промяна в bot/WAF слоя е разумно да се направи технически crawl и indexability проверка.

Кого засяга най-силно

Промяната е най-релевантна за сайтове зад Cloudflare, които използват AI bot controls: publishers, eCommerce, SaaS, B2B сайтове и компании с organic acquisition като важен канал. За сайт, който не използва Cloudflare, тази конкретна настройка няма директен ефект.

Но по-широкият принцип засяга всички: crawler access все по-често трябва да се управлява по purpose, а не само по user-agent. Search discovery, model training и agent activity са различни business и security use cases.

Какво не бихме правили прибързано

Не бихме натиснали Block само защото бизнесът „не иска AI“. Не бихме блокирали Googlebot през WAF, за да спрем Gemini training, след като Google предоставя Google-Extended за тази цел. Не бихме и копирали robots.txt шаблон без проверка на реалния crawler behavior.

Не бихме блокирали автоматично и всички AI agents. Част от agent traffic може да се превърне в реален acquisition или transaction channel. Правилният въпрос е кой automated actor има право на какво действие, а не дали всички AI системи трябва да бъдат позволени или забранени.

Нашият редакционен извод

Cloudflare вече дава по-добър отговор на реалния конфликт между Search discoverability и AI training control. Собствениците на сайтове могат да кажат: искам да бъда индексиран, но не искам съдържанието ми да се използва за training в определени AI use cases.

Но новата гъвкавост прави избора на policy по-важен. Block вече означава реално блокиране на mixed-use crawler-а, включително неговата Search функция. Затова AI bot policy вече трябва да присъства в техническия SEO audit редом с robots.txt, canonical, sitemap, WAF и status codes.

ПЪРВОИЗТОЧНИК
Cloudflare — Have it both ways: stay discoverable in search while disallowing AI training

Публикувано на 15.09.2026 г.. Използваме източника за фактите по новината; анализът и контекстът са на web-design.bg.

Отворете оригиналния източник
ИМАТЕ ВЪПРОС ЗА ВАШИЯ САЙТ?

Промените в търсачките имат значение само когато знаем как засягат конкретния бизнес.

Разкажете ни за проекта