Как настроить WAF и CDN для поисковых роботов

WAF и CDN защищают сайт от атак, сглаживают нагрузку и ускоряют доставку, но любое правило на пограничном слое способно незаметно изменить то, что получает поисковый робот. Посетитель открывает страницу из кеша с кодом 200, а Googlebot попадает под rate limit. Владелец видит зелёный мониторинг из своего региона, а YandexBot получает капчу на другом edge. Такой дефект выглядит как проблема индексации, хотя возник до приложения.

Безопасная конфигурация не сводится к кнопке «разрешить известных ботов». User-Agent легко подделать, провайдерские списки имеют границы применимости, а у поисковых компаний есть разные crawler и fetcher. Нужно подтвердить источник, ограничить исключение конкретными публичными методами, сохранить защиту закрытых областей и проверить фактический HTTP-ответ из нескольких точек.

Статья описывает рабочий процесс для владельца сайта, SEO-специалиста и инженера инфраструктуры: как нарисовать путь запроса, разделить правила, настроить кеш и лимиты, протестировать IPv4/IPv6 и организовать наблюдение. Конкретные названия полей отличаются у поставщиков, поэтому решения формулируются как проверяемый контракт, а не как магический набор переключателей.

Как выглядит блокировка робота

Самый очевидный симптом — 403, 429 или 5xx в логах для подтверждённых crawler. Но встречаются более тихие варианты: 200 с межстраничной проверкой, пустым HTML, сообщением «включите JavaScript», формой согласия или заглушкой чужого региона. Код формально успешен, поэтому мониторинг доступности молчит, а поисковик не получает основной контент и ссылки.

Другой признак — расхождение между браузером и инструментами поисковых систем. В Search Console отрендеренная страница теряет ресурсы, в Яндекс Вебмастере проверка ответа показывает блокировку, а обычный запрос сотрудника проходит. Не делайте вывод по одному инструменту: диагностический fetcher и основной crawler могут использовать разные адреса и назначение. Подтверждение ищут в журналах реального edge.

На графиках проблема проявляется ростом кодов ошибок, падением полученных байтов, сокращением числа обходившихся URL или внезапным увеличением времени ответа конкретному классу клиентов. Падение показов появляется позже и не указывает на правило WAF напрямую. Сначала сопоставьте точное время изменения конфигурации, hostname, edge location и затронутые шаблоны.

Иногда блокировка маскируется кешем. Популярные страницы продолжают отдаваться, а новые и обновлённые URL, для которых нет объекта на edge, уходят к origin и получают challenge. В результате старый контент обходится, новый не обнаруживается. Поэтому тестовая выборка обязана включать cache hit, cache miss, HTML, robots.txt, Sitemap и ресурсы.

Не каждая редкая запись 404 означает аварию: робот регулярно проверяет старые адреса. Инцидентом становится системное отклонение от ожидаемого контракта. Значения и поисковый смысл ответов разобраны в руководстве по HTTP-кодам, а мягкие заглушки — в материале про soft 404.

Где именно меняется ответ

Нарисуйте фактический маршрут: DNS → CDN edge → bot management → WAF → rate limiter → load balancer → reverse proxy → приложение → хранилище. У каждого слоя есть собственные редиректы, кеш, тайм-ауты и страницы ошибок. Если смотреть только application log, заблокированный на edge запрос вообще не появится, а команда ошибочно решит, что робот не приходил.

Для каждого слоя зафиксируйте владельца и доказательство: request ID, action, rule ID, cache status, upstream status, адрес origin и длительность. Один идентификатор должен проходить через доступные журналы. Тогда ответ 403 можно привязать к конкретному managed rule, а 503 — к origin, а не обсуждать абстрактное «CDN что-то режет».

Особое внимание уделите реальному IP клиента. Origin обычно видит адрес прокси; исходный IP передаётся в провайдерском заголовке. Приложение принимает его только от доверенных сетей CDN. Если origin открыт напрямую или доверяет заголовку от любого клиента, атакующий подставит адрес поисковика и обойдёт политику. Закройте прямой доступ к origin сетевыми правилами и аутентификацией между слоями.

Проверка закрытого origin должна входить в приёмку, а не оставаться предположением. Попытка соединиться с его публичным адресом вне CDN отклоняется; соединение от edge подтверждается сетевым списком, взаимным TLS либо другим механизмом провайдера. Секретный заголовок сам по себе слаб, если его значение попало в клиентский ответ или общий журнал. После смены адресов CDN правила firewall обновляются атомарно: сначала добавляются новые доверенные сети, затем проверяется трафик и только потом удаляются старые. Иначе во время миграции настоящий запрос может обойти часть edge или, наоборот, получить отказ на исправном origin.

Соберите таблицу ожидаемых ответов по пути и методу. Публичная статья на GET и HEAD доступна, POST комментария проходит отдельную защиту, личный кабинет требует авторизацию, служебный preview закрыт независимо от робота. Исключение для crawler не должно превращаться в глобальный bypass всех правил. Основы серверного контроля разобраны в статье о заголовках безопасности.

Учитывайте отдельные hostname: с www и без, мобильный домен, статика, изображения, API рендеринга. Политика на главном hostname не гарантирует доступ к CSS и JavaScript с другого домена. Карта зависимостей помогает не лечить только HTML, когда содержимое формируется после запроса к заблокированному API.

Как подтверждать поискового робота

Не доверяйте одному User-Agent. Он годится для первичного отбора, но подделывается одной строкой. Google рекомендует проверять адрес по официальным CIDR-файлам соответствующего класса либо через обратный DNS с последующим прямым подтверждением. Яндекс рекомендует PTR, допустимый суффикс yandex.ru, yandex.net или yandex.com и обязательное совпадение исходного IP в A/AAAA.

С марта 2026 года диапазоны Google публикуются в каталоге /crawling/ipranges/. Разделяйте common crawler, special crawler и user-triggered fetcher: это не взаимозаменяемые списки. Разрешение обычному Googlebot не означает, что каждый адрес Google Cloud или любой продукт компании должен обходить WAF. Полная последовательность проверки изложена в статье о подлинности Googlebot и YandexBot.

Если CDN предлагает категорию verified bot, выясните метод подтверждения, частоту обновления и доступность функции на вашем тарифе. Такая категория удобна как управляемый сигнал, но политика всё равно ограничивает методы и маршруты. Провайдер может включать мониторинг, превью ссылок и другие прозрачные агенты, которые не являются поисковыми индексаторами.

Кешируйте результат проверки ограниченное время и сохраняйте версию источника. При сбое загрузки JSON не очищайте активный список автоматически; при сбое DNS не выдавайте безусловный allow. Состояние «не удалось подтвердить» отличается от «точно вредный» и обрабатывается обычными безопасными лимитами с оповещением.

Идентичность не заменяет авторизацию. Проверенному Googlebot не нужны административные страницы, корзина, данные клиента или POST к API. Закрытый стенд остаётся за HTTP-аутентификацией, VPN или сетевым барьером; практическая схема есть в руководстве по защите staging.

Как построить политику WAF

Начинайте с явных классов ресурсов и методов, а не с исключения «skip everything». Для публичного HTML подтверждённому common crawler обычно нужны GET и HEAD. Статические ресурсы получают отдельный безопасный профиль. Формы, поиск, регистрация и API записи сохраняют ограничения для всех неавторизованных клиентов. Административные и preview-пути не открываются поисковику ни при каком User-Agent.

Порядок правил критичен. Сначала вычисляется доверенный исходный IP, затем подтверждается тип crawler, после чего применяется узкое исключение из интерактивного challenge. Остальные проверки — допустимость метода, длина URL, известные атаки, доступ к приватному пути — продолжают работать. Если глобальный managed rule стоит раньше исключения, робот всё равно блокируется; если bypass слишком ранний, исчезает полезная защита.

Разделите действия: log, managed challenge, block, rate limit и allow. Новое условие сначала работает в режиме журнала, чтобы команда увидела реальный охват и ложные совпадения. Затем его включают на малой доле или одном hostname. Немедленный block по непроверенному шаблону пути создаёт риск массовой ошибки и затрудняет расследование.

Храните описание намерения рядом с правилом: «не показывать интерактивную капчу подтверждённым common crawler на публичных GET/HEAD», а не «SEO fix». Добавьте владельца, источник диапазонов, дату ревью, тестовые URL и откат. При смене провайдера намерение переносится, даже если названия полей другие.

Не пытайтесь управлять безопасностью через robots.txt. Файл выражает предпочтения обхода для соблюдающих стандарт роботов, но не останавливает злоумышленника и не заменяет WAF. Одновременно WAF не должен превращать разрешённый в robots.txt документ в недоступный. Правильная роль файла описана в статье про robots.txt.

Заранее определите поведение при отказе каждого сигнала. Недоступность сервиса классификации не должна означать «разрешить всех»: публичный GET остаётся под обычным неинтерактивным лимитом, опасные методы и закрытые пути блокируются штатно. Устаревшая, но ещё допустимая проверенная база может работать ограниченное время с алертом; повреждённая новая версия не заменяет её. Если origin перегружен, подтверждённый crawler также получает управляемое ограничение, а не привилегию, способную окончательно положить сервер. Матрица fail-safe фиксирует условие, временное действие, максимальную длительность, владельца и критерий восстановления. Тогда дежурный не придумывает глобальный bypass посреди инцидента.

Для каждой временной меры задайте автоматическое истечение. Исключение без срока переживает инцидент, смену команды и следующую архитектуру. Перед продлением владелец повторяет положительные и отрицательные тесты, объясняет необходимость и фиксирует новую дату. Отдельный отчёт показывает все активные bypass, их охват по hostname и методы, чтобы узкая аварийная настройка не стала постоянным невидимым каналом обхода защиты.

Rate limiting, challenge и капча

Общий лимит «60 запросов в минуту на IP» плохо подходит crawler: один адрес может последовательно обойти много страниц, а посетители за NAT — делить адрес. Сначала определите ресурсный предел origin и стоимость маршрутов. Статическая статья, поиск по каталогу и генерация отчёта нагружают систему по-разному, поэтому одинаковый порог создаёт либо лишние блокировки, либо слабую защиту.

Для подтверждённых поисковых crawler используйте отдельную корзину лимита на публичные GET/HEAD или контролируемую очередь, но не бесконечный доступ. При перегрузке сайт должен честно замедлять обход и сохранять доступ людям. Google указывает, что значительное число 429, 500 или 503 снижает скорость crawl всего hostname; длительная отдача таких кодов способна повлиять на присутствие URL.

Интерактивная капча и JavaScript challenge непригодны для обычного crawler: он не обязан решать задачу или хранить cookie как браузер человека. Если запрос подтверждён и соответствует публичному пути, исключите именно challenge. Для неизвестных автоматических клиентов можно оставить managed challenge, но тестируйте, какой HTTP-код и тело фактически возвращаются.

Не отдавайте challenge с кодом 200 и canonical исходной страницы. Такой ответ выглядит успешным, хотя основного содержания нет. Если инфраструктура перегружена, временный 429 или 503 честнее, но это аварийная мера, а не постоянная стратегия. Заголовок Retry-After может подсказать время, однако не гарантирует точный повторный обход.

При неожиданно высокой активности не блокируйте адрес до проверки. Сопоставьте Sitemap, выпуск новых URL, cache miss и тип crawler. Возможно, робот обнаружил бесконечный календарь или параметры фильтра. Тогда исправляется пространство URL и внутренняя навигация; материал о краулинговом бюджете помогает отделить полезный обход от ловушки.

Кеш, HTML и ресурсы страницы

Кеш должен различать только те признаки, которые действительно меняют представление. Если User-Agent случайно входит в cache key, робот и человек получают разные объекты, а ошибка проявляется не на всех edge. Если заголовок согласия или cookie попадает в ключ без необходимости, crawler всегда уходит в редкий вариант. Документируйте ключ и проверяйте его на реальных запросах.

Не создавайте специальный SEO-кеш с улучшенным текстом. Поисковый робот должен видеть содержательно то же публичное представление, что человек без авторизации. Допустимы технические различия адаптивной доставки, но скрытая подмена контента создаёт риск клоакинга и мешает диагностике. Один источник HTML проще тестировать и обновлять.

Cache hit не должен скрывать неисправность origin бесконечно. Включите наблюдение за свежестью, Age, ETag и Last-Modified, а после публикации проверяйте purge на нескольких точках. Иначе робот продолжает получать старый noindex или canonical, хотя приложение уже исправлено. Основы браузерного и пограничного кеширования связаны с материалом про Cache-Control.

CSS, JavaScript и изображения нуждаются в доступе, если участвуют в рендеринге и понимании страницы. Отдельный hostname статики может иметь другой WAF и забытый deny для IPv6. Проверьте ключевые ресурсы и итоговый DOM. Для SPA полезно сравнивать первоначальный HTML и результат рендеринга; подробности есть в статье про JavaScript-сайты.

Страницы ошибок и challenge делайте маленькими, но никогда не кешируйте их как успешный документ надолго. Учитывайте stale-if-error: функция полезна посетителям, однако способна скрыть восстановление или раздать устаревшее состояние. В тесте фиксируйте код edge, upstream status, cache status и хеш смыслового фрагмента HTML.

Диагностируйте кеш попарными запросами, а не очисткой «на всякий случай». Один и тот же URL проверяют как cold miss и повторный hit, с обычным клиентом и подтверждённым crawler, на двух edge. Сравнивают статус, Age, Vary, Content-Encoding, canonical, robots meta и контрольный абзац. Если тело различается, сначала объясняют каждое измерение cache key: устройство, язык, cookie, заголовок эксперимента. User-Agent не должен незаметно создавать SEO-версию. После purge убедитесь, что удалён именно нужный объект во всех вариантах и что первый miss больше не кеширует challenge или страницу ошибки под кодом 200.

HTTP-коды, robots.txt и обслуживание

Для доступного публичного документа нормален 200, для неизменившегося условного запроса — корректный 304. Постоянный перенос отражается 301 или 308, временный — подходящим временным кодом. Не превращайте блокировку в 200 с текстом ошибки. Поисковик передаст такой HTML на обработку и может распознать soft 404, но предсказать результат нельзя.

Ответ 403 означает отказ доступа, 429 — превышение частоты, 500/502/503/504 — ошибку сервера или цепочки. Массовая доля таких ответов важнее единичного случая. При 429 и 503 можно передать Retry-After, однако это подсказка, а не расписание. Причину и длительность устраняют, а не пытаются компенсировать далёкой датой.

Файл robots.txt должен оставаться доступным и не попадать под challenge. Для Яндекса корректный файл или конечная цель допустимого редиректа возвращает 200. Google при кратком полном обслуживании отдельно советует не отдавать 503 на robots.txt и не менять его на Disallow: /. Старая версия правил полезнее временной ошибки конфигурации.

Если сайт останавливается на короткое окно, исходные URL могут отвечать 503 с небольшим статическим телом. Не совмещайте этот режим с noindex, массовым редиректом на главную или заглушкой 200. Подробный рабочий сценарий есть в статье о технических работах и Retry-After.

После восстановления очистите ошибочный кеш и проверьте ответ снаружи. Приложение может уже отдавать 200, а edge продолжать раздавать сохранённый 503. Контроль включает главную, новый URL, редкий шаблон, robots.txt, Sitemap и один несуществующий адрес, который обязан сохранить честный 404.

Регионы, IPv6 и несколько origin

CDN применяет правила в разных точках присутствия, и конфигурация может распространяться не мгновенно. Ошибка проявляется только в отдельной стране или сети, тогда домашняя проверка не воспроизводит проблему. Сохраняйте код edge location и тестируйте минимум несколько независимых точек, особенно после изменения geo restriction, санкционного списка или маршрутизации.

Не блокируйте весь регион, исходя из предположения, где находится поисковик. Адреса и маршруты меняются, а crawler может приходить из нескольких сетей. Если бизнес обязан ограничивать доступ по территории, отделите юридическое ограничение контента от автоматического правила безопасности и проверьте официальными инструментами, какой ответ получает робот.

IPv6 часто забывают в allowlist и firewall. Список Google содержит IPv4- и IPv6-префиксы, а DNS способен вернуть AAAA. Библиотека должна корректно обрабатывать CIDR обеих версий. Нельзя переводить IPv6 в строку и сравнивать сокращённые формы вручную: одинаковый адрес имеет несколько текстовых представлений.

При нескольких origin сравните ответы каждого пула. Один кластер может иметь старый robots meta, другой — неправильный сертификат, третий — иной WAF на самом сервере. Healthcheck, который проверяет только строку «OK», этого не заметит. Нужен smoke-тест реальных URL через публичный hostname с фиксацией выбранного upstream.

DNS и TLS также входят в цепочку. Ошибка AAAA приводит IPv6-клиента на неподготовленный сервер, а несовпадающий SNI — к чужому сертификату. Основы записей собраны в статье про DNS, а HTTPS — в материале о TLS и HTTPS.

Как тестировать и наблюдать конфигурацию

До изменения соберите базовую выборку: наиболее посещаемые страницы, новые URL, шаблоны, robots.txt, Sitemap, CSS, JS, изображение и заведомый 404. Для каждого ожидайте код, Content-Type, минимальный размер, canonical и контрольный фрагмент текста. Не сравнивайте весь HTML побайтно: реклама и персонализация создают шум.

Набор содержит положительные и отрицательные сценарии. Подтверждённый common crawler получает публичную статью; поддельный User-Agent не получает привилегию; подтверждённый адрес не открывает админку; POST формы проходит обычную защиту; неизвестный бот при высокой частоте ограничивается. Без отрицательных тестов легко создать слишком широкое исключение.

После выпуска смотрите доли кодов по подтверждённому типу crawler, action WAF, cache status, hostname, edge и шаблону. Полезны размер ответа и время до первого байта: 200 длиной 2 КБ вместо обычных 80 КБ сигнализирует о заглушке. Метрики производительности сервера раскрыты в статье про TTFB.

Синтетическая проверка не заменяет реальные логи, а инструменты вебмастеров не заменяют синтетику. Первая видит подготовленный сценарий, вторые показывают взгляд сервиса, журналы подтверждают фактический трафик. Сведите три источника по времени и URL. Постоянный набор алертов можно встроить в процесс из руководства по SEO-мониторингу.

В отчёте не обещайте индексацию после снятия блока. Зафиксируйте только наблюдаемое: правило изменено, выбранные URL отвечают ожидаемо, ресурсы доступны, ошибки исчезли в логах. Обновление поисковых данных зависит от следующего обхода и обработки; сроки и показ не гарантируются.

Числовой пример исправления WAF

Каталог получает 12 600 000 запросов в сутки. Подтверждённые crawler Google и Яндекса создают 420 000 запросов, то есть 420 000 ÷ 12 600 000 × 100 = 3,33% трафика. После включения нового managed rule 31 500 запросов crawler получили 403 или 429. Доля ошибок внутри подтверждённой группы: 31 500 ÷ 420 000 × 100 = 7,5%.

Разбиение показало 24 000 блокировок HTML, 4 500 Sitemap/robots.txt и 3 000 ресурсов; 24 000 + 4 500 + 3 000 = 31 500. При этом 88% проблем возникло на cache miss. Это указало не на общий запрет домена, а на challenge перед origin. Правило было настроено раньше проверки типа crawler и требовало cookie от всех клиентов без кешированного объекта.

Команда не сделала глобальный allow. Она подтвердила источники, исключила common crawler из интерактивного challenge только для GET/HEAD публичных путей, сохранила managed WAF и отдельный лимит. Административные URL, поиск и POST остались под прежними правилами. На 240 тестах до изменения было 222 ожидаемых ответа и 18 ошибок; 18 ÷ 240 = 7,5%.

После canary на 10% edge повторили 240 тестов: 228 страниц дали 200, 8 условных запросов — 304, 4 отсутствующих адреса — 404. Сумма 228 + 8 + 4 = 240, неожиданных ответов нет. Затем правило распространили на остальные точки. За следующие сутки подтверждённые crawler сделали 438 000 запросов, из них 438 получили временные 5xx origin.

Доля 5xx составила 438 ÷ 438 000 × 100 = 0,1%. Команда оставила технический алерт на пороге 0,5% и расследовала один нестабильный upstream отдельно. Исправление подтвердило доступность и безопасность выбранной политики, но не считалось обещанием роста показов или позиций.

Как выпускать правила без риска

Начните с review намерения и матрицы доступа. В обсуждении участвуют инфраструктура, безопасность, разработка и SEO: первая знает маршрут, вторая оценивает обход защиты, третья — поведение приложения, четвёртая — критичные URL и сигналы. Один владелец принимает решение и отвечает за откат, чтобы инцидент не завис между командами.

Новое правило проходит режим log, тестовую среду, canary и полный выпуск. На каждом этапе известны длительность наблюдения и стоп-условия: рост неожиданных 4xx/5xx, изменение размера HTML, недоступность robots.txt, появление доступа к закрытому пути. Автоматический откат полезен, но команда должна уметь выполнить его вручную без панели приложения.

Проверьте аварийный сценарий до реального сбоя поставщика. Если сервис verified bots временно не отвечает, система не должна объявлять всех клиентов подтверждёнными или удалять последнюю рабочую базу. Если недоступна панель CDN, у дежурного остаются API, версия конфигурации и короткая процедура возврата. Откат восстанавливает порядок правил, лимиты и cache behavior целиком, а не только выключает последнее условие. После него снова выполняются отрицательные тесты: поддельный User-Agent не получает доступ, подтверждённый адрес не открывает POST и админку. Это отличает безопасное восстановление от поспешного глобального bypass, который лишь меняет SEO-инцидент на инцидент безопасности.

Конфигурацию храните в системе версий вместе с тестами и источниками диапазонов. Экспорт из интерфейса провайдера не всегда отражает порядок выполнения и скрытые managed rules, поэтому сохраняйте доступное машинное представление и снимок активных настроек. После обновления поставщиком повторяйте отрицательные сценарии.

Раз в месяц проверяйте срок исключений, статистику ложных блокировок, свежесть источников и открытые приватные маршруты. Удаляйте правила, которые заменены новой архитектурой. Старый временный bypass опасен именно потому, что никто уже не помнит причину. Плановая ревизия дешевле расследования незаметной уязвимости или месячной блокировки crawler.

Итог фиксируйте наблюдаемыми фактами: какие типы запросов разрешены, какие проверки остались, какие URL протестированы, как изменились коды и где лежит откат. Не связывайте успешный технический тест с гарантией поискового результата. Он доказывает лишь то, что заданные клиенты получают корректный публичный ответ и не обходят лишнюю защиту.

Протокол выпуска приложите к заявке: версия правил, время каждого этапа, доля canary, контрольные URL, снимок метрик и имя ответственного. Через сутки повторите выборку на непрогретых страницах и другом edge. Это ловит отложенное распространение конфигурации и ошибку, скрытую первым кешем.

Если результат отличается, остановите расширение правила, сохраните запросы и верните последнюю проверенную конфигурацию до нового разбора.

Главный вывод

Хорошая настройка WAF и CDN не выбирает между безопасностью и доступностью для поиска. Она подтверждает источник независимым способом, учитывает тип crawler, разрешает только нужные публичные методы и снимает лишь несовместимый интерактивный challenge. Все остальные проверки продолжают работать. Кеш, IPv6, ресурсы и каждый edge входят в тест, а реальные логи подтверждают результат. Такой контракт уменьшает ложные блокировки и не превращает известный User-Agent в универсальный ключ от сайта.