Переезд на CDN без потери индексации: правила Яндекса и Google для защиты краулинга и WAF

TL;DR: • При подключении CDN (Яндекс Cloud CDN, EdgeЦентр, Selectel, Cloudflare) падает время ответа сервера, и YandexBot с Googlebot резко увеличивают частоту обхода сайта. • На старте сеть доставки контента отдает Cache Miss, поэтому двойной поток запросов от краулеров бьет напрямую в ваш основной сервер (origin). • Администраторы видят аномальный трафик в логах, включают жесткие правила WAF, JS-челленджи или CAPTCHA и случайно блокируют роботов кодом 403, обрушивая индексацию.

Переезд на CDN (Content Delivery Network) — это стандартный способ ускорить загрузку страниц и масштабировать проект под рост аудитории, главная цель которого — разгрузить основной сервер за счет кэширования статики и контента на периферийных узлах. Свежие технические рекомендации Google Search и практика работы с российскими облачными провайдерами показывают, что миграция на CDN часто оборачивается падением бэкенда и потерей позиций в обоих поисковиках.

Механика сбоя: почему переезд на CDN вызывает двойной удар по серверу

В Рунете сайт одновременно сканируют два тяжелых поисковых краулера (YandexBot и Googlebot), к которым добавляются ИИ-боты (Яндекс Нейро, GPTBot, DeepSeekBot). Когда вебмастер переключает DNS на CDN, запускается цепная реакция:

1. Резкое снижение TTFB: Пограничные узлы CDN отвечают быстрее, чем одиночный origin-сервер.
2. Сигнал на рост краулингового бюджета: И алгоритмы Яндекса, и роботы Google воспринимают низкую задержку (latency) как признак высокой пропускной способности хостинга и автоматически повышают лимит сканирования (crawl rate).
3. Пробой холодного кэша (Cold Cache): CDN кэширует страницу только после первого обращения к ней. При массовом обходе тысяч карточек товаров или статей все первичные запросы проходят мимо кэша напрямую в базу данных вашего origin-сервера.
4. Ложное срабатывание WAF и анти-DDoS: Инженеры видят в access.log резкий скачок обращений с разных подсетей, принимают краулеров за парсинг или DDoS-атаку и включают агрессивную блокировку ботов.

Миграция с Cloudflare на отечественные CDN

На фоне ограничений работы западных сетей доставки контента в РФ российский бизнес массово переводит проекты на отечественные платформы (Яндекс Cloud CDN, EdgeЦентр, Selectel) или ставит перед сервером облачные прокси защиты (DDoS-Guard, Qrator, StormWall).

При смене провайдера кэш сбрасывается в ноль. Отечественные анти-DDoS фильтры по умолчанию настроены жестко: при резком всплеске обращений на холодный кэш они часто закрывают доступ поисковым роботам через JS-проверки или статус 403 Forbidden, если в правилах WAF не настроена верификация подсетей Яндекса и Google.

3 технических правила для безопасного переезда на CDN

Чтобы миграция на сеть доставки контента прошла без просадки позиций в Яндексе и Google, соблюдайте три базовых правила:

Закладывайте запас мощности origin-сервера под пик краулинга

Быстрый отклик пограничных серверов CDN гарантированно провоцирует рост скорости сканирования со стороны обоих поисковиков. Планируйте переезд с запасом по CPU и пропускной способности базы данных на основном сервере, так как в первые 48–72 часа после смены NS-записей частота заходов YandexBot и Googlebot вырастет в несколько раз.

Прогревайте кэш до открытия трафика (Cache Pre-warming)

На холодном кэше каждый первый запрос к уникальному URL вызывает Cache Miss и уходит на ваш бэкенд. По возможности запускайте предварительный прогрев кэша для ключевых категорий каталога, посадочных страниц и свежих публикаций до того, как DNS-изменения разойдутся по сети.

Не блокируйте верифицированных роботов через WAF и CAPTCHA

Самая критичная ошибка при скачке нагрузки — включение общих правил фильтрации, которые отдают краулерам код 403 Forbidden или страницу с капчей. Настройте исключения в WAF для подтвержденных роботов Яндекса и Google. Если основной сервер действительно перегружен, отдавайте краулерам временные статусы 429 Too Many Requests или 503 Service Unavailable — они сигнализируют системам о необходимости плавно снизить частоту обхода без исключения страниц из поиска.

Этап миграции на CDN	Что происходит в инфраструктуре	Типичная ошибка вебмастера	Правильное решение для Яндекса и Google
Переключение DNS и падение TTFB	YandexBot и Googlebot фиксируют быстрый отклик и повышают crawl rate	Запуск переезда на пределе ресурсов origin-сервера	Проверка запаса прочности CPU и базы данных до смены NS
Первичный обход на холодном кэше	Массовые Cache Miss пробивают CDN и идут напрямую в бэкенд	Отсутствие прогрева популярных и коммерческих URL	Предварительный прогрев кэша (Cache Pre-warming)
Реакция защиты на всплеск в логах	Активность поисковиков выглядит как парсинг или DDoS-атака	Включение общего WAF-бана (403) или JS-капчи для всех ботов	Белый список для верифицированных ботов и коды 429 / 503

Пошаговый чек-лист: как настроить CDN и защитить YandexBot и Googlebot

Перед переводом домена на CDN выполните следующий алгоритм проверки:

• Шаг 1. Проверьте подлинность IP-адресов в логах: Прежде чем банить подозрительные подсети при росте нагрузки, убедитесь, что это не поисковые роботы. Проверить принадлежность IP через обратный DNS-запрос (rDNS) можно в бесплатном инструменте Валидатор Googlebot и YandexBot.
• Шаг 2. Отделите поисковых роботов от ИИ-скрейперов: Нагрузка на холодный кэш часто усиливается из-за бесконтрольного парсинга со стороны LLM-краулеров. Загрузите файл access.log в Анализатор логов ИИ, чтобы отфильтровать полезный трафик Яндекса и Google от агрессивных парсеров.
• Шаг 3. Настройте правила Verified Bots в WAF: В панели управления CDN или анти-DDoS прокси активируйте разрешение для верифицированных роботов поисковых систем без показа капчи и JS-челленджей.
• Шаг 4. Настройте корректную отдачу кодов 429 и 503: Убедитесь, что при пиковой нагрузке веб-сервер возвращает краулерам именно 429 или 503 с заголовком Retry-After, а не сбрасывает соединение с ошибками 502 / 504 или запретом 403.