Cloudflare: препоръки за SEO, AI търсене (GEO), AI асистиране (AEO) и скорост

Cloudflare стои зад повече от една пета от домейните в мрежата[20] и решава какво стига до сървъра. Заявките на Googlebot приключват при Cloudflare, а не при сайта. Затова един превключвател в таблото за управление може да спре обхождането на цял сайт, без нищо да изглежда счупено отвън: страниците се отварят нормално в браузър, Search Console продължава да отчита адресите като индексирани, а трафикът пада.

Материалът подрежда настройките по тежест – първо тези, които вредят, после тези, които помагат. Приоритетът на източниците е фиксиран: документацията на Google определя поведението на Google Търсене, документацията на Cloudflare определя поведението на продукта.

Където двете се разминават, разминаването е посочено. AI (или “ИИ”) търсене и асистиране тук означава видимост в генеративните резултати: AI Overviews и AI Mode при Google, отговорите на ChatGPT, Claude и Perplexity. Понятието се среща и като GEO, и като AEO. Позицията на Google е, че това си остава SEO[3].

Всяка промяна в Cloudflare е промяна в работеща среда. Преди прилагане настройките се съгласуват с конкретен отговорник.

Петте решения с най-голяма тежест

Останалата част от материала обяснява защо са точно тези и как се прилагат.

1. Никога Block за обучението на модели. След 15 септември 2026 г. тази настройка спира Googlebot, Bingbot и Applebot изцяло, включително за търсене[19], [20]. Правилният избор е Disallow AI Training за големи издатели и Allow AI Training за останалите сайтове.
2. Сървърна грешка върху /robots.txt може да спре обхождането на целия сайт за 12 часа. Документирано поведение на Google[7].
3. Bot Fight Mode на безплатния план не прави изключение за проверени роботи и връща страница за проверка, която носи noindex,nofollow[29], [41].
4. Новите правила за ограничаване на честотата не изключват автоматично търсачките. Старите го правеха[24], [25].
5. Отказът от обучение на модели не струва позиции в Google. Google-Extended не влияе на включването в Търсенето и не е сигнал за класиране[4].

Проверка преди всичко останало

Не всяка препоръка по-долу важи за всеки сайт. Зависи от това дали трафикът минава през Cloudflare и по какъв начин е свързан домейнът. Две команди изясняват картината за под минута.

# Минава ли трафикът през Cloudflare
curl -sI https://example.com | grep -i "server\|cf-ray\|cf-cache-status\|cf-mitigated"

# Пълна или частична настройка
dig +short example.com NS

Заглавка server: cloudflare заедно с cf-ray означава проксиран трафик, тоест Cloudflare наистина стои отпред. Ако сървърите за имена (NS) сочат към Cloudflare, настройката е пълна и целият набор функции е достъпен. При частична настройка през CNAME част от функциите, включително APO, остават недостъпни.

Появата на cf-mitigated: challenge е достатъчна сама по себе си. Означава, че Cloudflare е върнал страница за проверка вместо съдържание, тоест причината е в мрежовия слой, а не в приложението.

Какво Cloudflare променя в SEO и какво не

Около Cloudflare се въртят няколко упорити опасения, които струват на екипите време в излишни спорове. Официалната документация ги изброява поименно и ги отхвърля [22]:

Приносът на Cloudflare върви по три линии: скорост, шифрована връзка и достъп на роботите. Първите две са фактори за класиране според Google[11], [12]. Третата не е фактор, а условие – без достъп няма индексиране. Google формулира изискванията в три точки[1]: Googlebot не е блокиран, страницата връща код 200, съдържанието е индексируемо.

В документацията за ИИ функциите обхватът е разширен изрично до слоя пред сървъра. Обхождането трябва да е разрешено в robots.txt и от всяка мрежа за доставка на съдържание (CDN) или хостинг инфраструктура [2]. Това изречение е причината материалът да съществува.

Настройките, които спират индексирането

Шест защитни функции на Cloudflare могат да прекъснат достъпа на търсачките, без това да е било нечие намерение. Подредбата е по вероятност да засегне конкретен сайт, а не по реда в менюто.

robots.txt и сървърните грешки

Файлът robots.txt е първото, което всеки робот проверява, преди да обходи каквото и да било. Ако файлът върне грешка, последиците не остават локални. Реакцията на Google е описана подробно[7]:

Кодът 429 е изрично изваден от обработката на 4xx и се третира като сигнал за претоварен сървър, не като липсващ файл. Копието на robots.txt се пази до 24 часа. Всяка промяна – включително автоматично управляваният файл на Cloudflare – се отразява със закъснение. Практическото следствие е рязко. Ако страница за проверка, ограничаване на честотата или режимът Under Attack засегне /robots.txt, губи се не една страница, а обхождането на целия сайт. Google изрично препоръчва кодовете 401 и 403 да не се ползват за забавяне на робота[7]. Проверката отнема секунди:

curl -sI https://example.com/robots.txt | head -1

Очакван отговор: HTTP/2 200.

Bot Fight Mode

Bot Fight Mode е безплатната защита срещу автоматичен трафик и се включва с един превключвател, което я прави примамлива. Проблемът е в обхвата: за разлика от Super Bot Fight Mode на платените планове, тази функция не прави изключение за проверени роботи[29]. Механизмът на щетата е конкретен. Страницата за проверка на Cloudflare носи мета етикет noindex,nofollow.

Това личи както от шаблона в официалната документация за персонализирани страници за проверка[41], така и от заснети отговори на стандартната междинна страница „Just a moment…“. Роботът получава кратък документ без съдържание, без връзки и с изрична инструкция да не индексира и да не следва. Диагностиката подвежда, ако се гледа само Search Console. Индексирането и обхождането се провалят независимо едно от друго, тоест Google продължава да поднася вече индексираното копие.

Затова проверката на адрес отчита „Submitted and indexed“ дни наред след спирането. Сигналът, който издава проблема, е датата на последно обхождане. Тя спира да се движи. За сайт с органичен трафик на безплатен план заключението е еднозначно: Bot Fight Mode се изключва, а защитата се пренася към правила във WAF.

Проверените роботи вече не са автоматично разрешени

Cloudflare поддържа списък с проверени роботи – такива, които се представят честно и не злоупотребяват с достъпа. Дълги години етикетът означаваше автоматично разрешение. От 1 юли 2026 г. значението му е друго. Документацията вече описва старото поведение в минало време и добавя, че всеки клиент сам определя какво разрешава и какво блокира[23].

Етикетът вече не значи „разрешен“. Той значи „допустим в рамките на съответната категория“. Правило, което разчита единствено на cf.client.bot, вече не гарантира достъп. Официалната страница Improve SEO все още съветва да се провери дали правилата пропускат проверените роботи [22]. Датата на последната ѝ промяна е 20 април 2026 г., тоест преди промяната в определението. Съветът не е грешен, но вече е непълен.

Ограничаване на честотата

Правилата за ограничаване на честотата спират клиенти, които изпращат прекалено много заявки за кратко време. Търсачките обхождат бързо по природа, затова попадат в обхвата на такива правила по-често, отколкото се очаква. Двете версии на функцията се описват с различни думи (“disallow” и “block”), и разликата е съществена.

Прилагането на правила за ограничаване на честотата върху проверени роботи може да засегне SEO. Цената на пропуска е измерима. При значителен брой отговори 500, 503 или 429 Google намалява честотата на обхождане, и намалението обхваща целия хост – както адресите с грешки, така и тези, които връщат съдържание[9]. Googlebot повтаря около два дни. При задържане над този срок адресите отпадат от индекса[8].

Опашка за чакане, режим Under Attack и блокиране по държава

Трите функции пазят сайта при наплив или атака, но всяка от тях спира и роботите заедно с хората.

Waiting Room. Роботите на търсачките попадат в опашката при активно нареждане. Функцията SEO Crawler Bypassing гарантира, че проверените от Bot Management роботи не се нареждат [27]. 

Under Attack. Режимът пуска проверка срещу целия трафик. Използва се само по време на активна атака и се изключва веднага след нея.

Блокиране по държава. Google излиза предимно от адреси в Съединените щати. При установена блокировка на заявки оттам Google може да опита от други държави, но това не е обещание[5]. Роботът не изпраща и заглавка Accept-Language[15].

Оттук следва и правилото срещу автоматичните пренасочвания по адрес. Такова пренасочване поднася на робота от Съединените щати нещо различно от това, което вижда посетител от София. Google препоръчва отделни адреси за всеки език и пазар с анотации hreflang вместо динамично пренасочване[15]. Поднасянето на съществено различно съдържание на робот и на човек попада в определението за прикриване, тоест cloaking[16].

Правилото, което пази роботите

Правилата във WAF се изпълняват по ред отгоре надолу. Това позволява едно правило в началото на списъка да защити търсачките от всичко под него.

Обратното условие не върши работа като блокиращо. cf.client.bot eq false обхваща и клиентите, които Cloudflare не може да провери в нито една посока, а това е голяма част от нормалния трафик.

Към същия шаблон се добавят изрични изключения за инструментите за наблюдение и за собствените проверки при внедряване.

Още едно правило заслужава внимание при сайтове с персонализирани заглавки. Ако правило от тип Transform променя заглавките на отговора за целия сайт, то се намесва в страниците за проверка и ги чупи. Документацията дава точния израз за изключване [41]:

not cf.response.error_type in {"managed_challenge" "iuam" "legacy_challenge" "country_challenge"}

Шифроване, HSTS и пренасочвания

Четири настройки в раздела SSL/TLS определят дали сайтът се отваря по шифрована връзка и какво се случва при грешка в сертификата. Едната от тях не се връща лесно.

Видимост в ИИ търсенето

Появата в отговорите на ChatGPT, Claude, Perplexity и в AI Overviews зависи от това кои роботи имат достъп до сайта и какво намират, когато стигнат до него. Тук се събират най-новите промени в Cloudflare и най-често бърканите настройки при Google.

Три повърхности, три различни механизма

Google не поставя допълнителни технически изисквания за появяване в AI Overviews и AI Mode. Страницата трябва да е индексирана и допустима за откъс, тоест сниплет[2]. Всичко останало е обичайното SEO.

Управлението обаче минава през три различни механизма, и смесването им е честа грешка.

Два детайла се пропускат често:

nosnippet не е “скалпел”. Правилото важи за всички форми на резултати – уеб търсене, изображения, Discover, AI Overviews и AI Mode – и предотвратява използването на съдържанието като пряк вход за генеративните отговори[10]. Тоест премахва и обикновения откъс. Загубата на кликове в органиката е реална.

Google-Extended няма собствен потребителски агент. Това е само управляващо означение в robots.txt. Обхождането става със съществуващите агенти на Google [4].

Отчитането минава през Google Search Console. Сайтовете, които се появяват в ИИ функциите, влизат в общия трафик от търсене в отчета за резултатите, под тип „Уеб“[2].

Промяната от 15 септември 2026 г.

Дотогава Cloudflare предлагаше един превключвател с надпис „Block AI bots“. Той вече не съществува, а на негово място стоят три отделни категории според това какво прави роботът[20]:

Настройките се намират в Security → Settings. Изборът за Training е между Allow, Disallow AI Training, Block on pages with ads и Block. Достъпни са на всеки план, включително на безплатния[45], което е важно за проектите, качени на Cloudflare преди години и непипани оттогава.

От същата дата роботите с няколко предназначения се оценяват по всичките си поведения, по най-строгото приложимо правило. Cloudflare описва следствието без заобикалки: Googlebot, Applebot и Bingbot се блокират от клиентите, избрали да блокират Training[20].

Disallow AI Training срещу Block

Двете настройки стоят една до друга в едно и също меню и звучат близко. Разликата между тях е органичният трафик на сайта [19]. 

Disallow AI Training записва предпочитание за отказ от обучение в robots.txt чрез Bot Preference Sync – механизмът, който поддържа файла в съответствие с настройките в таблото. На практика в robots.txt се появяват два реда: забрана за Google-Extended и забрана за Applebot-Extended[42]. И двете означения се използват от операторите си само за обучение, затова забраната им не докосва търсенето. Резултатът се вижда с отваряне на /robots.txt, тоест настройката е проверима отвън.

Роботите с няколко предназначения, които Cloudflare определя като отговорни, продължават да обхождат за търсене. Обучаващите роботи на Amazon, Anthropic, Meta и OpenAI се спират, което не засяга търсенето, защото тези оператори ползват отделни роботи за двете задачи.

За категорията Agent няма опция за отказ, а само разрешаване или блокиране. Причината е, че утвърдена директива за предпочитания към агентите още не съществува[19].

Block спира всички, включително Googlebot, включително за търсене. Обхватът на тази загуба е по-широк от органичните резултати: блокирането на Googlebot засяга Google Търсене заедно с Discover и всички функции в него, а също Google Изображения, Google Видео и Google Новини[6].

Определението „отговорен оператор“ не е рекламно. То изисква четири неща: механизъм за отказ от обучение, механизъм за отказ от ИИ обобщения, видимост на ниво адрес и публично потвърждение, че отказът от обучение не влияе на класирането. Apple, Google и Microsoft отговарят на условията или са дали конкретен срок[19].

Сроковете са различни. Видимостта на ниво адрес при Google предстои в близките седмици, при Apple – догодина, а Microsoft изостава най-много[42]. Самият Cloudflare обявява, че контролите за ИИ обобщения са следващата стъпка, с планирано пускане догодина[19]. Дотогава отказът от обобщения минава единствено през Search Console.

Какво препоръчва Cloudflare?

Настройката по подразбиране се разминава според това дали сайтът печели от реклама. За сайтове с реклами препоръката е Disallow AI Training заедно с блокиране на агентите на рекламните страници. За сайтове без реклами стойността по подразбиране оставя Training на Allow[20], [42]. Логиката е, че приходът от реклама зависи от човек, който вижда страницата, а обучението заменя посещението с отговор.

Какво препоръчва този материал?

Search на Allow, Agent на Allow, Training на Disallow AI Training за големи издателски сайтове с реклами, сайтове без печалба от реклами, предлагащи с продукти и услуги – да се избере Allow AI Training. Разминаването с препоръката на Cloudflare е съзнателно.

Цената е загуба на обвързване с източници в Gemini като приложение и във Vertex AI. В Google Търсене, в AI Overviews и в AI Mode не се променя нищо. Ползата в обратната посока няма измерване: публикувано изследване за връзка между разрешеното обучение и броя цитирания няма нито при Google, нито при останалите оператори. Марка, която държи езиковите модели да я познават и споменават, има основание да остави Allow, но нито една компания за изкуствен интелект не е заявила колко тежи това.

Издател с уникално съдържание печели от отказа. Сайт за услуги с типово съдържание губи малко и в двете посоки, въпреки че в някои частни случаи то може и да е бизнес решение.

Какво показа измерването след промяната

Обявената промяна и наблюдаваната промяна не съвпадат. Това е единственото публикувано измерване по темата и заслужава внимание, защото резултатът върви в посока, обратна на очакваната. SeenSure проверява 1046 сайта на 14 септември и отново на 16 септември, с осем различни самоличности на роботи, с контролна група от 300 сайта без Cloudflare и с повторна заявка от обикновен браузър като контрол на самия инструмент[43]. При сайтовете зад Cloudflare отказите се движат в две посоки наведнъж:

Отказите към обучаващите роботи се качват с около три пункта, което съответства на обявеното. Отказите към търсещите и към агентните роботи падат с между 12,7 и 13,9 пункта – а това Cloudflare не е обявявал. Контролната група извън Cloudflare не помръдва, повторната заявка от браузър също.

Практическото следствие за българските сайтове: страници, които ChatGPT и Perplexity не са могли да прочетат преди 15 септември, вероятно са достъпни сега. Проверката на собствен сайт отнема една команда и е в списъка по-долу.

Три ограничения обаче стоят, и авторите на изследването ги посочват сами. Извадката е предимно от наскоро издадени сертификати, тоест млади домейни, а не напречен разрез на мрежата. Измерва се отказ, а не решение – заглавката cf-ray доказва, че Cloudflare е бил по пътя, но не и че отказът е негов, защото сървърът на сайта също може да върне 403 през Cloudflare. И едно измерване преди и след не отговаря на въпроса защо. Повторение е обявено за декември.

Останалите оператори

OpenAI, Anthropic и Apple разделят роботите си по задача. Това е добра новина, защото позволява отказ от обучение без загуба на видимост в отговорите им.

Anthropic предупреждава, че блокирането на Claude-SearchBot намалява видимостта и точността на сайта в отговорите [36].

Bing прави изключение. Единственият наличен днес механизъм за отказ от обучение е мета етикетът NOARCHIVE, а той изключва съдържанието и от Chat, и от Copilot. Тоест носи цена във видимост, каквато означенията на Google и Apple нямат. Поддръжка на предпочитание в robots.txt е в разработка [19].[бел. 1](#note1)

Изобразяването с JavaScript

Много съвременни сайтове доставят почти празен документ, който се запълва със съдържание чак след като браузърът изпълни JavaScript. Google се справя с това. Останалите – не.

Google изобразява страниците, тоест рендира ги, с актуална версия на Chromium, но това става в отделна опашка и изостава от обхождането[13]. Самата документация отбелязва, че не всички роботи изпълняват JavaScript.

Изследване на Vercel и MERJ от декември 2024 г. върху около 569 милиона заявки на GPTBot и 370 милиона на Claude установява, че никой от основните ИИ роботи не изпълнява JavaScript [34]. GPTBot изтегля файлове с JavaScript при 11,5% от заявките, ClaudeBot при 23,84%, но не ги изпълнява. Изключения са Google и Applebot. Следствието е неприятно и лесно за пропускане: страница може да е на първа позиция в Google и празна обвивка за ChatGPT, Claude и Perplexity. Проверката е една команда:

curl -sL -A "OAI-SearchBot/1.0" https://example.com/statiya | grep -c "изречение от основния текст"

Резултат 0 означава, че съдържанието не съществува за този робот.

Решението е изобразяване от страна на сървъра или статично генериране. Google понижи динамичното изобразяване до заобиколно решение и препоръчва сървърно изобразяване, статично генериране или хидратация[14]. Поднасянето на съществено различно съдържание само на роботи попада в определението за прикриване[14], [16].

llms.txt и версии на страниците в Markdown формат

Напоследък се препоръчва към сайта да се добави файл llms.txt или паралелни версии на страниците в обикновен текст, за да ги „разбират по-добре“ езиковите модели. За Google този съвет няма покритие.

Позицията в документацията не оставя място за тълкуване. За появяване в Google Търсене, включително в генеративните функции, не са нужни нови машинночетими файлове, ИИ текстови файлове, допълнително маркиране или Markdown, защото Google Търсене не ги ползва [3]. Създаването им нито помага, нито вреди на класирането там.

Приложимостта е извън Google. Perplexity е операторът, който заявява, че чете файла. Полза има при сайтове с документация и програмни интерфейси, където кодовите помощници са осезаем източник на посещения.

При решение за внедряване има един капан, който рядко се споменава. Паралелните адреси с разширение .md са индексируеми като всеки друг поддържан тип файл. Без заглавка noindex или забрана в robots.txt резултатът е дублиращ се набор адреси и пропилян бюджет за обхождане.

За магазин или корпоративен сайт съотношението между разход и доказана полза не оправдава работата.

Пренасочване на обучаващите роботи

Остарелите страници, които стоят онлайн заради стари връзки, са проблем и за търсачките, и за езиковите модели. Разликата е, че търсачките разбират сигналите за остарялост, а обучаващите роботи – не.

Cloudflare публикува измерване от собствения си сайт с документация: роботи от категорията за обучение са го посетили 4,8 милиона пъти за 30 дни и са поглъщали остаряло съдържание със същата честота като актуалното [21].

Причината е, че noindex, каноничните адреси и предупредителните ленти работят надеждно за търсачките, но не и за обучаващите роботи. Функцията Redirects for AI Training превръща съществуващите канонични адреси в пренасочвания 301 за проверените обучаващи роботи. Един превключвател, всички платени планове [21].

Смисъл има при сайтове с версии на документацията, с голям архив от стари публикации или след промяна на адресната структура.

Отчитане

За разлика от търсенето, тук няма Search Console. Отчитането се сглобява от два източника, и единият от тях подвежда, ако се чете буквално.

AI Crawl Control показва кои роботи идват, какво получават и кои адреси обхождат [32]. Данните за посещения от ИИ източници са достъпни на платените планове.

Броят на неуспешните заявки е показателят, който заблуждава. Той събира всички отговори със състояние 400 и нагоре, и може да идва от всяко правило или грешка, не само от блокиране[32]. Скокът обикновено се дължи на мъртви входящи връзки, а не на спрян достъп.

Отделен отчет за ИИ отговорите не съществува. Практичният подход е съчетание от записите на Cloudflare и ръчни проверки с подсказки в самите инструменти.

За сравнение със средните стойности в мрежата служи Cloudflare Radar, където разделът за ИИ показва какви отговори получават обучаващите и търсещите роботи в целия трафик на Cloudflare[40]. Полезен е при преценка дали дадено отклонение е особеност на проекта, или общо явление.

Скорост

Cloudflare предлага десетина настройки за ускоряване, от които част помагат, част нямат ефект и част вредят. Разграничаването им зависи от това по какви данни се съди за резултата.

Оценката минава през полеви данни

Основните показатели за уеб, известни като Core Web Vitals, измерват изживяването на реални хора, а не на изпитателен инструмент, и се ползват от системите за класиране[11]:

Отчита се стойността, под която попадат 75% от реалните посещения. INP замени FID през март 2024 г. [33] Ръководство, което още споменава FID, е остаряло и вероятно греши и другаде.

Google уточнява, че добрата оценка в Search Console или в чужди инструменти не гарантира челни позиции и че стремежът към идеален резултат само заради SEO невинаги е добро вложение на време [12].

Следствието за работата: промяната се оценява по полеви данни в прозорец от 28 дни, а не по оценка от Lighthouse на следващия ден.

Какво се включва

Шест настройки носят полза при почти всеки проект, с по едно условие към всяка.

Какво се изключва

Три настройки се срещат в стари ръководства и в стари конфигурации. Две от тях вече не съществуват, а третата вреди по-често, отколкото помага.

Кеширане

Кешът определя какво вижда посетителят и какво вижда роботът, затова грешката тук е едновременно техническа и правна.

Page Rules се прекратяват. Настройките мигрират към Cache Rules, Configuration Rules и Redirect Rules[31]. Част от старите настройки нямат заместник и отпадат при прехода, включително Disable Security и Disable Performance. Проектите, които разчитат на тях, се мигрират съзнателно, а не по инерция.

При кеширане на HTML изключението по бисквитка е задължително – за влезли потребители, за количка и за всяка персонализирана страница. Кеширана страница на влязъл потребител, поднесена на робот, е едновременно прикриване и изтичане на лични данни.

Google поддържа два механизма за проверка на свежестта: ETag заедно с If-None-Match и Last-Modified заедно с If-Modified-Since. Други директиви за кеширане не се поддържат. При налични и двете се ползва ETag, който документацията препоръчва заради липсата на проблеми с изписването на датата[5]. Отговор 304 без тяло при непроменено съдържание пести ресурс на сървъра и подобрява косвено ефективността на обхождането[8].

Платформи

Преди коя да е настройка стои друг въпрос: достъпен ли е изобщо мрежовият слой при тази платформа. При част от системите отговорът е не, и това променя целия план за работа.

Shopify заслужава отделен абзац

Помощният център посочва, че конфигурациите с прокси на Cloudflare, включително схемата Orange-to-Orange, не се поддържат. Двете причини са загуба на устойчивост, защото Shopify ползва няколко доставчика, и намалена точност при разпознаването на роботи, защото атрибутите на заявката се променят, преди да стигнат до платформата [37].

Документацията за темите добавя препоръка да се избягват прокси пред мрежата на Shopify [38]. За магазин на Shopify препоръките в този материал не са приложими на мрежово ниво. Работата се пренася върху темата, съдържанието и структурираните данни.

Откриване на причината

Когато трафикът падне без видима причина, първата задача е да се разграничи проблем в сайта от проблем в мрежовия слой. Шест стъпки дават отговора, подредени от най-бързата към най-бавната.

1. Заглавките. Наличието на cf-mitigated: challenge е достатъчно доказателство, че отговорът идва от Cloudflare, а не от сървъра.
2. Кодът на състоянието. 403 и вътрешен код 1020 сочат блокиране от правило. 1015 сочи ограничаване на честотата. 402 сочи плащане за обхождане.
3. Security Events. Колоната Service назовава източника поименно: Bot Fight Mode, Super Bot Fight Mode, WAF или Rate limiting.
4. Заявка с потребителски агент на робот. Сравнението между Googlebot, OAI-SearchBot, PerplexityBot и ClaudeBot показва различия по оператори.
5. Проверка на адрес в Search Console. Live Test и View crawled page показват какво получава Googlebot сега. Състоянието „Submitted and indexed“ отразява последното успешно обхождане, а не текущия достъп.
6. Отчетът Crawl Stats. Предупреждението Hostload exceeded означава, че Googlebot не успява да обходи толкова адреси, колкото е открил[8].

Списък за проверка след промяна

Осемте точки отнемат около двайсет минути и хващат почти всичко, което може да се счупи при смяна на настройка.

1. Пет заявки с curl -sSI към началната страница. Очаква се 200 без cf-mitigated.
2. Същата проверка с потребителски агент на Googlebot, OAI-SearchBot, PerplexityBot и ClaudeBot.
3. Изтегляне на /robots.txt и сверяване с намерението. Автоматично управляваното съдържание не бива да противоречи на собствените правила.
4. Сравнение между суровия и изобразения HTML. Основният текст, каноничният адрес и структурираните данни трябва да присъстват в суровия код.
5. Проверка на адрес в Search Console през Live Test и View crawled page.
6. Проверка на cf-cache-status и че персонализирано съдържание не попада в кеша.
7. Наблюдение на полевите показатели в прозорец от 28 дни.
8. Сверяване в AI Crawl Control дали разрешеното и блокираното съвпадат с решението.

Три важни препоръки

Ако времето стига само за три неща, това са те. Първите две отнемат по пет минути, третото – две.

1. Отваряне на Security → Settings и записване на изричен избор за Search, Agent и Training. Ако някъде стои Block за Training, смяна на Disallow AI Training.
2. Преглед на безплатните зони за включен Bot Fight Mode и замяна с правило (cf.client.bot) → Skip, поставено първо.
3. Изтегляне на началната страница с потребителски агент на Googlebot и на OAI-SearchBot и сравнение на двата резултата.

Бележки

1. Според Cloudflare Microsoft разработва поддръжка на предпочитание за отказ от обучение в robots.txt със срок началото на 2027 г.[19] Срокът е посочен от Cloudflare. До влизането му в сила изборът Disallow AI Training не предава предпочитание към Bing, което съвпада с поведението на предишната настройка за блокиране.

2. Обхватът на новите стойности по подразбиране заслужава уточнение, защото се предава различно на различни места. Публикацията на Cloudflare говори за новите домейни, които се добавят[20]. TechCrunch, позовавайки се на компанията в деня на обявяването, изброява три групи: нови клиенти, нови сайтове на съществуващи клиенти и всички съществуващи клиенти на безплатния план[44].

Cloudflare отделно посочва, че при съществуващите зони настройките се пренасят без нужда от действие[19]. Практиката е една и съща и в трите случая: изричен избор, записан в Security → Settings, премахва всяко съмнение. Зоните на безплатния план, които стоят непипани от години, заслужават приоритет при този преглед. 

3. Данните за производителност от продуктовите страници на Cloudflare са твърдения на доставчика. Проверяват се с полеви измервания по конкретния проект.

Източници