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

Сайтът се отваря нормално. Search Console отчита страниците като индексирани. Сървърът не показва грешки. А органичният трафик пада седмица след седмица.

В такива случаи причината често се крие на място, което рядко се проверява първо – между сайта и останалия свят. Cloudflare стои пред повече от една пета от домейните в мрежата[20]. За тези сайтове заявките на Googlebot, ChatGPT и Perplexity стигат първо до Cloudflare и едва след това, ако изобщо, до сървъра. Затова един превключвател в таблото за управление може да спре обхождането на цял сайт, без отвън нищо да изглежда счупено.

Материалът събира настройките, които имат значение за SEO, AI видимостта и скоростта, подредени по тежест: първо тези, които могат да навредят, после тези, които помагат. Когато документацията на Google и тази на Cloudflare казват различни неща, за поведението на Google Търсене решава Google, а за поведението на продукта – Cloudflare. Всяко такова разминаване е отбелязано.

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

Петте решения, които тежат най-много

Ако от целия материал има време само за една част, това е тя. Всичко след нея обяснява защо точно тези пет решения са толкова важни и как се прилагат на практика.

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

Първо: минава ли сайтът през Cloudflare

Не всяка препоръка важи за всеки сайт. Преди всичко друго е нужен отговор на по-простия въпрос – минава ли трафикът през 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 минава по три линии: скорост, шифрована връзка и достъп на роботите. Първите две са фактори за класиране[11], [12]. Третата не е фактор, а предпоставка. Без достъп няма индексиране, а без индексиране няма какво да се класира.

Google свежда изискванията до три точки[1]: Googlebot не е блокиран, страницата връща код 200, съдържанието е индексируемо. В документацията за AI функциите обаче има уточнение, което лесно остава незабелязано. Обхождането трябва да е разрешено не само в robots.txt, но и от всяка мрежа за доставка на съдържание (CDN) или хостинг инфраструктура[2].

Google изрично посочва слоя, в който работи Cloudflare. И точно там се крият най-сериозните рискове.

Настройките, които спират търсачките

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

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

Всеки робот започва от едно и също място – файла robots.txt. Преди да обходи и една страница, проверява какво му е позволено. Ако файлът върне грешка, последиците засягат целия сайт. Google описва реакцията си подробно[7]:

Кодът 429 е изрично изваден от правилото за 4xx. Google го третира като сигнал за претоварен сървър, а не като липсващ файл.

Към това се добавя и закъснението. Google пази копие на 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] и третира Googlebot като всеки друг бот.

Щетата има конкретен механизъм. Страницата за проверка на Cloudflare носи мета етикет noindex,nofollow. Това се вижда както в шаблона от официалната документация[41], така и в заснетите отговори на стандартната междинна страница „Just a moment…“. Роботът получава кратък документ без съдържание, без връзки и с изрична инструкция да не индексира и да не следва.

Най-коварното е, че Search Console не алармира веднага. Индексирането и обхождането се провалят поотделно: Google продължава да показва вече индексираното копие, а проверката на адрес дни наред отчита „Submitted and indexed“. Проблемът издава друг показател – датата на последно обхождане. Когато тя спре да се движи, нещо блокира робота.

За сайт с органичен трафик на безплатен план изводът е еднозначен: Bot Fight Mode се изключва, а защитата се пренася към правила във WAF. Как точно става това, е описано в раздела „Правилото, което пази роботите“.

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

Bot Fight Mode не е единствената изненада. Cloudflare поддържа списък с проверени роботи – такива, които се представят честно и не злоупотребяват с достъпа. Години наред този етикет означаваше автоматично разрешение. От 1 юли 2026 г. вече не е така.

Документацията описва старото поведение в минало време и уточнява, че всеки клиент сам решава какво разрешава и какво блокира[23]. Етикетът вече не означава „разрешен“, а „допустим в рамките на съответната категория“. Правило, което разчита само на cf.client.bot, вече не гарантира достъп.

Показателно е, че официалната страница Improve SEO все още съветва да се провери дали правилата пропускат проверените роботи[22]. Последната ѝ редакция е от 20 април 2026 г., тоест отпреди промяната. Съветът не е грешен, просто вече не е достатъчен.

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

Подобна, но по-тиха промяна засяга и ограничаването на честотата. Тези правила спират клиенти, които изпращат прекалено много заявки за кратко време. Търсачките обхождат бързо по природа и затова попадат под тях по-често, отколкото се очаква.

Разликата между старата и новата версия на функцията се свежда до една фраза. Старата документация гарантираше, че кешираните ресурси и познатите търсачки са изключени от правилата и не влияят на класирането, като уточняваше, че това важи само за предишната версия[25]. Новата предупреждава, че прилагането на правилата към проверени роботи може да засегне SEO[24].

Гаранцията се е превърнала в предупреждение. Автоматично изключение вече няма, затова то се задава ръчно чрез полето cf.verified_bot_category. Полето е достъпно в персонализираните правила на WAF, в Advanced Rate Limiting и в Late Transform rules[23].

Цената на пропуска се измерва лесно. При значителен брой отговори 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 определят дали сайтът се отваря по шифрована връзка и какво става при проблем със сертификата. Само една от тях не прощава грешки.

AI търсене: кой чете сайта и какво намира

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

Три цели, три различни механизма при Google

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

Трудността е другаде. Управлението минава през няколко отделни механизма и смесването им е една от най-честите грешки:

Два детайла заслужават отделно внимание:

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

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

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

Какво се промени на 15 септември 2026 г.

Докато Google разграничава целите с отделни механизми, Cloudflare направи същото с пренареждане на менюто. До средата на септември в таблото имаше един превключвател – „Block AI bots“. Сега на негово място стоят три категории според това какво прави роботът[20]:

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

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

Allow, Disallow AI Training или Block

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

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

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

Allow оставя достъпа отворен.

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

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

Препоръката: Allow по подразбиране

За целите на SEO и AI видимостта правилната настройка за огромното мнозинство сайтове е Allow и за трите категории – Search, Agent и Training. Това важи за онлайн магазини, фирми за услуги, корпоративни сайтове, SaaS продукти и всяка марка, която иска да бъде откривана и препоръчвана.

Аргументите са четири.

AI видимостта е самата цел. Всяка затворена категория стеснява пътищата, по които марката може да бъде позната, намерена и цитирана.

Отказът има цена и в Google. Забраната на Google-Extended изважда съдържанието от обвързването с източници (grounding) в Gemini като приложение и във Vertex AI[4]. Търсенето не се засяга, но една AI повърхност на Google се губи.

Моделите отговарят и от наученото. Когато AI асистент отговаря без търсене в реално време, разчита на данните от обучението си. Марка, която отсъства от тях, зависи изцяло от това дали търсещият робот ще я открие в конкретния момент. Колко точно тежи присъствието в данните, никоя AI компания не е заявила публично[42]. Отсъствието обаче затваря една от двете врати.

Cloudflare препоръчва същото. За сайтовете без реклами стойността по подразбиране оставя и трите категории на Allow[20], [42].

Изключението: големите новинарски издания

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

За такива издания Disallow AI Training е оправдан избор, и то безопасен за търсенето. Google изрично посочва, че Google-Extended не влияе на включването в Google Търсене и не е сигнал за класиране[4], а публичното потвърждение на това е едно от условията за отговорен оператор[19].

И при изключението важат две уточнения. Search и Agent остават на Allow, защото именно тези две категории носят видимостта и цитиранията в AI отговорите. Предварителната настройка на Cloudflare за сайтове с реклами обаче блокира агентите на рекламните страници[20], а това отрязва и заявките, които AI асистентите правят по поръчка на потребител. Затова изборът там е добре да бъде съзнателен, а не наследен по подразбиране.

Block не е вариант дори тук. За най-голямото издание той означава изчезване от Google.

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

Колко всъщност се промени достъпът на AI роботите след 15 септември? Засега има едно публикувано измерване и резултатът му е изненадващ.

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

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

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

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

Останалите AI компании

Извън Google картината е по-подредена, отколкото изглежда. OpenAI, Anthropic и Apple разделят роботите си по задачи, така че всяка категория може да се управлява поотделно:

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

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

JavaScript: невидимото съдържание

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

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

Изследване на Vercel и MERJ от декември 2024 г. върху около 569 милиона заявки на GPTBot и 370 милиона на Claude стига до еднозначен извод: никой от големите AI роботи не изпълнява 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 версии на страниците

Щом AI роботите предпочитат чист текст, не е ли логично да получат точно такъв? Оттук идва популярният съвет към сайта да се добави файл llms.txt или паралелни Markdown версии на страниците. За Google отговорът е категоричен.

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

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

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

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

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

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

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

Функцията Redirects for AI Training решава проблема, като превръща съществуващите канонични адреси в пренасочвания 301 за проверените обучаващи роботи. Включва се с един превключвател на всички платени планове[21]. Особено полезна е за сайтове с версии на документацията, с голям архив или след смяна на адресната структура. И е естествено допълнение към Allow: моделите учат, но от правилните страници.

Отчитане

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

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

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

Отделен отчет за AI отговорите не съществува. Практичният подход съчетава записите на Cloudflare с ръчни проверки в самите AI инструменти. За сравнение със средните стойности в мрежата служи Cloudflare Radar, където разделът за AI показва какви отговори получават обучаващите и търсещите роботи в целия трафик на 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. Други директиви за кеширане не се поддържат. Когато са налице и двата, Google използва 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. Отправната точка е Allow и за трите. Ако някъде стои Block, той се сменя веднага. 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 са твърдения на доставчика. Проверяват се с полеви измервания по конкретния проект.

Източници