Cloudflare може да блокира Googlebot от 15 септември

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

Cloudflare разделя автоматизирания AI traffic на три поведения: Search, Agent и Training. Search обхваща crawlers, които събират и индексират съдържание за последващо откриване; Agent е автоматизирана активност в реално време от името на потребител; Training е използване на съдържание за обучение или fine-tuning на модели. За всяка категория Cloudflare позволява Block, Block on pages with ads или Allow.

От 15 септември 2026 г. новите defaults за нови домейни ще оставят Search разрешен, а Training и Agent ще бъдат блокирани на страници, на които Cloudflare открива реклами. По-важният SEO детайл е, че mixed-purpose crawlers, които комбинират Search и Training, ще бъдат блокирани от всички конфигурации, които блокират AI training — включително legacy настройката Block AI bots.

Фактът, който може да засегне Googlebot и Bingbot

Cloudflare изрично описва mixed-purpose crawlers като отделен случай. Ако един bot изпълнява едновременно Search и Training функция, по-рестриктивната активна политика може да спре целия request още на edge ниво. Това е различно от стандартно robots.txt правило, защото заявката може изобщо да не достигне origin сървъра.

Това не означава, че Cloudflare глобално блокира Google. Search остава разрешен по подразбиране. Рискът се появява при домейни, които са избрали да блокират Training или са оставили старата Block AI bots конфигурация, без да проверят как тя ще бъде интерпретирана след 15 септември.

Нашият анализ: AI crawler policy вече е част от техническото SEO

Преди няколко години crawler access се управляваше основно чрез robots.txt, sitemap и server responses. Днес CDN и bot-management слой може да спре crawler-а преди той да стигне до сайта. Това означава, че технически SEO audit, който не проверява Cloudflare Security и bot policies, вече може да пропусне критична причина за crawl проблем.

За бизнес, който разчита на Google Search, целта не е да разреши всички AI bots. Целта е да различи три бизнес решения: искаме ли Search discovery, искаме ли user-directed agents и искаме ли съдържанието да бъде използвано за Training. Тези отговори не са задължително еднакви.

Защо robots.txt и Google-Extended не са същото като Cloudflare Block

Google предоставя Google-Extended като control token за определени AI употреби на вече crawled content. Google изрично казва, че този token не е отделен HTTP crawler и че ограничаването му не влияе върху inclusion или ranking в Google Search. Това е content-usage preference, а не мрежова забрана за Googlebot.

Cloudflare работи по-рано в request chain-а. Ако edge policy върне block към Googlebot, crawler-ът няма как да прочете robots.txt или самата страница. Затова не е достатъчно да видите правилен robots.txt и да заключите, че search crawling е гарантирано.

Какъв SEO проблем бихме очаквали при продължителен block

Един блокиран request няма да изтрие сайт от Google. По-реалистичните ранни симптоми са спад в crawl activity, по-бавно откриване на нови URL-и, забавено обновяване на променени страници и stale информация в индекса. При eCommerce това може да означава по-бавно отразяване на продуктови промени, наличности или нови категории.

Ако block-ът остане дълго време, проблемът вече може да се превърне в indexing и visibility issue. Затова е по-разумно да се следят Cloudflare events и Search Console веднага след промяната, отколкото да се чака organic traffic графиката да покаже последствията седмици по-късно.

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

Първо бихме проверили всички сайтове зад Cloudflare с активен Block AI bots, Training = Block или неизяснени legacy настройки. По-висок приоритет имат publisher сайтове, онлайн магазини, големи WordPress инсталации, SaaS документация и сайтове, които публикуват често ново съдържание.

Ако сайтът не използва Cloudflare, тази конкретна промяна няма отношение към него. Ако Training не е блокиран или policy е конфигурирана така, че search crawlers да останат достъпни, няма причина автоматично да се очаква SEO проблем.

Практически checklist преди и след 15 септември

Проверете Cloudflare Security Settings → Configure AI bot policies и запишете текущите стойности за Search, Agent и Training. Ако има legacy Block AI bots настройка, прегледайте я отделно. Запазете screenshot като baseline, защото при бъдещ troubleshooting ще е важно да знаете какво е било активно преди rollout-а.

След промяната проверете Cloudflare Security Events за blocked verified crawlers, Google Search Console Crawl Stats и URL Inspection на няколко ключови URL-а. При eCommerce включете homepage, category, product page и нов продукт. Ако Bing носи трафик, направете аналогична проверка и в Bing Webmaster Tools.

Не разчитайте само на robots.txt. Проверете реален HTTP достъп и логове. При управление на множество клиентски Cloudflare zones направете audit per zone — тази настройка е инфраструктурна и може да е различна за всеки домейн.

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

Не бихме изключили Cloudflare заради тази промяна и не бихме разрешили всички bots само от страх за Google. CDN, WAF и DDoS защитата остават ценни; проблемът е конкретната policy, не самият Cloudflare.

Не бихме редактирали десетки robots.txt директиви, преди да разберем дали block-ът е на edge ниво. И не бихме чакали ranking спад, за да започнем проверка. При известна дата и известен failure mode превенцията е значително по-евтина от диагностика след загубена видимост.

Редакционният ни извод

Промяната на Cloudflare показва колко бързо се сливат SEO, security и AI governance. Решението дали да разрешаваме AI training е бизнес политика. Решението дали Googlebot може да достига сайта е инфраструктурна предпоставка за Search. Двете не трябва да бъдат смесвани случайно от един стар toggle.

Нашата препоръка е проста: ако organic traffic има значение и сайтът е зад Cloudflare, проверете AI bot policies преди или веднага след 15 септември 2026 г. Не защото Cloudflare „спира Google“, а защото неправилна конфигурация вече може да превърне AI training block в реален crawl проблем.