CDN и SEO: ускорение без потери позиций
CDN продают как волшебную кнопку «сделать сайт быстрым»: подключил — и LCP в зелёной зоне, позиции растут, хостинг разгружен. На практике сеть доставки контента — это дополнительный слой между вашим сервером и роботом Яндекса, и этот слой умеет не только ускорять, но и ломать. Мы видели проекты, где после включения CDN сайт терял региональную привязку, отдавал роботу устаревший кэш неделями или начинал показывать капчу поисковому боту. В этой статье разбираем механику: как CDN реально влияет на Core Web Vitals, где прячутся риски для индексации и геотаргетинга, как настроить сеть правильно и какого провайдера брать под рунет. Если хотите, чтобы SEO-продвижение опиралось на скорость, а не спотыкалось о неё, — читайте до конца.
Коротко
- CDN ускоряет доставку статики и сокращает TTFB за счёт географической близости узла к пользователю — это напрямую улучшает LCP, косвенно CLS и почти не влияет на INP.
- Главный выигрыш — не «средняя скорость по больнице», а сокращение разрыва между Москвой и удалёнными регионами: Владивосток перестаёт ждать ответа на 120–180 мс дольше столицы.
- Основные риски: потеря или подмена региона в Яндексе, отдача роботу устаревшего или чужого кэша, блокировка бота системой защиты, разъезд IP-адреса и данных в Вебмастере.
- Робот Яндекса не должен получать капчу, JS-челлендж или ответ 403 — это самая частая и самая дорогая ошибка настройки.
- Кэшировать нужно статику агрессивно (год с версионированием имён), HTML — осторожно и с коротким TTL либо через stale-while-revalidate.
- Для рунета берите провайдера с узлами внутри России и понятной политикой в отношении поисковых роботов; глобальные сети без российского присутствия часто дают обратный эффект.
- CDN не лечит медленный бэкенд: если сервер думает над HTML 900 мс, сеть доставки просто быстро привезёт вам эту задержку.
Что такое CDN и что именно она ускоряет
Сеть доставки контента (Content Delivery Network) — это распределённая инфраструктура из точек присутствия (PoP, points of presence), расположенных в разных городах и странах. Каждая точка хранит копии файлов вашего сайта и отдаёт их пользователю, который географически ближе всего. Ваш основной сервер в этой схеме называется origin — источник; он остаётся единственным местом, где живёт «правда», а узлы CDN работают как кэширующие прокси перед ним.
Механика простая: пользователь из Новосибирска запрашивает картинку. Без CDN запрос идёт до вашего сервера в московском дата-центре — это примерно 3000 километров по оптике, около 50–60 мс в одну сторону, плюс установка TCP-соединения и TLS-рукопожатия, каждое из которых требует своих раундтрипов. С CDN запрос обрывается на узле в самом Новосибирске: 5–10 мс до узла, соединение устанавливается локально, файл отдаётся из памяти или SSD узла. Пользователь получает контент в разы быстрее, а ваш сервер вообще не узнаёт об этом запросе.
Отсюда первое важное уточнение: CDN ускоряет не «сайт», а доставку. Она сокращает сетевую задержку и разгружает канал, но не делает быстрее генерацию HTML на вашем бэкенде, не оптимизирует SQL-запросы и не чинит тяжёлый JavaScript. Если PHP-приложение собирает страницу 800 мс, то с CDN пользователь получит эту же страницу через 800 мс плюс минус пару десятков миллисекунд на сеть. Поэтому CDN — это надстройка над нормально работающим сервером, а не замена работе над скоростью загрузки сайта.
Три уровня работы современной CDN
Провайдеры давно ушли от простой раздачи файлов. Сегодня в типовой сети есть три слоя, и каждый по-разному касается SEO.
Первый уровень — кэширование статики. Изображения, CSS, JavaScript, шрифты, PDF, видео. Это базовый и самый безопасный сценарий: файлы неизменны, кэшируются надолго, риски минимальны. Именно с него стоит начинать любое внедрение.
Второй уровень — проксирование и кэширование HTML. Через CDN проходит уже весь трафик сайта, включая динамические страницы. Здесь появляются реальные выигрыши по TTFB, но и все интересные риски: устаревший кэш, склейка страниц разных пользователей, проблемы с персонализацией.
Третий уровень — обработка на границе (edge). Сжатие Brotli, конвертация изображений в WebP и AVIF на лету, HTTP/3, автоматическая минификация, вычисления в edge-функциях, WAF и защита от ботов. Это самый мощный и одновременно самый опасный слой: именно тут CDN начинает принимать решения о том, кому что показывать, — и может по ошибке принять робота Яндекса за атакующего.
ГЛАВНЫЙ ПРИНЦИП
CDN — это ускоритель, а не лекарство. Она уменьшает физическое расстояние и снимает нагрузку с канала, но не исправляет медленный бэкенд, раздутый бандл и неоптимизированные картинки. Сначала приводите в порядок origin и код, потом ставьте сеть доставки — иначе вы просто быстро доставите пользователю ту же самую медленную страницу.
Как CDN влияет на Core Web Vitals
Разберём по метрикам, потому что «сайт стал быстрее» — это не аргумент ни для Яндекса, ни для Google. Значение имеют конкретные показатели Core Web Vitals, и CDN влияет на них очень неравномерно.
LCP — здесь выигрыш максимальный
Largest Contentful Paint измеряет момент отрисовки самого крупного элемента первого экрана. В подавляющем большинстве случаев это либо баннер, либо главное изображение товара, либо крупный текстовый блок. Порог зелёной зоны — 2,5 секунды по 75-му перцентилю реальных пользователей.
LCP раскладывается на четыре части: время до первого байта документа (TTFB), задержка до начала загрузки ресурса, время самой загрузки ресурса и время отрисовки. CDN бьёт по первым трём. TTFB сокращается за счёт близости узла и уже установленных соединений между узлом и origin (keep-alive пул, который вы сами бы не построили). Загрузка LCP-изображения ускоряется кратно: файл едет из соседнего города, а не через полстраны, и часто уже сконвертирован в AVIF или WebP на границе.
На практике для удалённых от origin регионов подключение CDN уменьшает LCP на 20–40% без единой строчки изменений в коде. Для пользователей, которые физически находятся рядом с вашим дата-центром, эффект куда скромнее — иногда близок к нулю. Это ключ к пониманию, кому CDN нужна, а кому нет.
CLS — влияние косвенное, но реальное
Cumulative Layout Shift штрафует за прыжки вёрстки; зелёная зона — до 0,1. Напрямую CDN на смещения не влияет: они возникают из-за изображений без размеров, поздно подгруженных шрифтов и рекламных вставок. Но косвенная связь есть. Когда шрифт приезжает за 40 мс, а не за 400, окно между отрисовкой резервного шрифта и подменой на основной сокращается — и вызванный этим сдвиг либо не успевает произойти, либо становится незаметным. То же с изображениями: быстрый ответ узла означает, что картинка встаёт в свой слот до того, как пользователь начал читать. Впрочем, полагаться на это нельзя: атрибуты width и height, font-display: optional и зарезервированные места под баннеры — обязательны в любом случае.
INP — здесь CDN почти бессилен
Interaction to Next Paint измеряет отзывчивость на действия пользователя; зелёная зона — до 200 мс. Это метрика главного потока браузера: длинные задачи JavaScript, тяжёлая гидрация, неоптимальные обработчики событий. Сеть доставки быстрее привезёт вам ваш мегабайтный бандл, но исполнять его всё равно будет процессор телефона пользователя. Единственный вклад CDN в INP — косвенный: раньше приехавший скрипт раньше отработает и раньше освободит поток. Если у вас INP в красной зоне, ищите проблему в коде, а не в доставке; особенно это касается проектов на фреймворках — механику разбирали в материале про JavaScript-SEO.
| Метрика / показатель | Влияние CDN | За счёт чего | Что нужно делать помимо CDN |
|---|---|---|---|
| TTFB | Сильное (для статики), среднее (для HTML) | Близость узла, готовые соединения, кэш на границе | Ускорять генерацию страницы, кэш на бэкенде, быстрый хостинг |
| LCP | Сильное, особенно в регионах | Быстрая доставка главного изображения, короткий TTFB, WebP/AVIF на лету | Приоритет загрузки (fetchpriority), preload, отказ от lazy-load для первого экрана |
| CLS | Слабое, косвенное | Шрифты и картинки успевают до первого взгляда | width/height, font-display, слоты под динамику |
| INP | Почти нулевое | Скрипт приезжает раньше и раньше исполняется | Дробить длинные задачи, урезать бандл, убирать лишние обработчики |
| Нагрузка на origin | Сильное | 80–95% запросов не доходят до сервера | Правильные заголовки кэширования, иначе доля попаданий будет низкой |
CDN и региональное ранжирование: где начинаются риски
Это тот раздел, ради которого стоит читать статью целиком. Скорость — фактор понятный и линейный: быстрее лучше. А вот география в связке с CDN устроена контринтуитивно, и здесь теряют позиции.
Как Яндекс определяет регион сайта
Региональная привязка в Яндексе — это не одно поле, а совокупность сигналов: указанный регион в Яндекс Вебмастере, привязка организации в Яндекс Бизнесе, контактные данные и адрес на страницах, доменная зона, содержание текстов, ссылочное окружение. IP-адрес сервера в этом списке присутствует, но давно не является определяющим — Яндекс прекрасно ранжирует московские сайты, физически стоящие в Германии, если все остальные сигналы на месте.
Тем не менее IP-адрес — сигнал ненулевого веса, особенно для новых доменов без истории, без организации в Бизнесе и с неопределённой региональностью. И вот здесь CDN вносит путаницу: после подключения ваш домен резолвится не в IP московского дата-центра, а в anycast-адрес сети, который может принадлежать зарубежной автономной системе. Для сайта с уже устоявшейся привязкой и организацией в Бизнесе это почти всегда безобидно. Для молодого проекта, который только строит региональные сигналы, — дополнительный шум, и лучше его не создавать. Подробнее логика привязки разобрана в материале про региональное SEO.
Обратный эффект: CDN без узлов в России
Самая частая практическая беда. Подключается глобальная сеть, у которой ближайшая к российской аудитории точка присутствия стоит во Франкфурте, Амстердаме или Хельсинки. Пользователь из Екатеринбурга шёл до вашего московского сервера напрямую — теперь он идёт до Франкфурта, а Франкфурт при промахе кэша идёт обратно в Москву. Вместо ускорения вы получаете лишний крюк в несколько тысяч километров и рост TTFB.
Добавьте сюда сетевую нестабильность на трансграничных маршрутах, и картина становится грустной: часть запросов отдаётся быстро из кэша, часть — с задержкой в сотни миллисекунд, а 75-й перцентиль в Core Web Vitals считается именно по хвосту распределения, а не по среднему. То есть страдает ровно та метрика, которую видят поисковики.
ПРАВИЛО ГЕОГРАФИИ
CDN имеет смысл ровно тогда, когда её узлы ближе к вашей аудитории, чем ваш origin. Если сайт стоит в Москве, вся аудитория — Москва и область, а точки присутствия сети находятся в Европе, вы не ускоряете сайт, а замедляете его и добавляете точку отказа. Проверяйте карту PoP провайдера до подписания договора, а не после.
Мультирегиональные сайты и подмена контента на границе
Если у вас поддомены или папки под города, следите за тем, чтобы CDN не начала кэшировать региональные версии по общему ключу. Классический сценарий провала: сайт определяет город по IP и подставляет телефон и адрес филиала, а CDN кэширует первую отданную версию страницы и раздаёт её всем. В итоге пользователь из Казани видит екатеринбургский телефон, а робот — тот вариант, который случайно попал в кэш узла, откуда он пришёл. Дальше — расхождение контента между обходами, скачки релевантности и просадка по региональным запросам.
Решений два. Либо полностью отказаться от геоподмены на лету и делать честные отдельные URL под каждый регион (правильный путь с точки зрения SEO), либо добавить регион в ключ кэша через заголовок Vary или собственный edge-параметр. Второе сложнее в поддержке и требует, чтобы провайдер умел определять регион на границе.
Риски для индексации: чем CDN ломает SEO
Капча и JS-челлендж для бота
Система защиты от ботов принимает YandexBot за парсер и отдаёт ему проверку. Робот видит вместо страницы заглушку и либо не индексирует её, либо индексирует текст капчи. Массовые выпадения из индекса начинаются в течение недели.
Устаревший HTML в индексе
Вы обновили цены и тексты, узел продолжает отдавать вчерашнюю версию. Робот фиксирует старый контент, дата последнего изменения не меняется, переиндексация буксует. Особенно больно для каталогов с наличием и ценами.
Подмена статусов
CDN кэширует 404 и 5xx или, наоборот, отдаёт 200 на несуществующих URL. Кэшированная пятисотка на важной странице живёт столько, сколько указано в TTL, и всё это время робот считает страницу сломанной.
Закэшированный запрет
Файл robots.txt тоже статика, и его тоже кэшируют. Выкатили на час запрещающую версию во время работ — узлы отдают её роботу ещё сутки. Обратный случай не менее опасен.
Потеря canonical и hreflang
Если canonical или hreflang отдаются HTTP-заголовками, а не в HTML, edge-обработка может их вырезать или не пробросить. Результат — дубли и расползание релевантности между версиями.
Разрыв цепочки сертификатов
Смешанная схема, когда CDN работает по HTTPS с пользователем и по HTTP с origin, порождает mixed content и редирект-петли. Робот получает бесконечный цикл и бросает обход.
Робот и защита от ботов — риск номер один
Разберём подробнее, потому что это самая дорогая ошибка. Современные CDN идут в комплекте с WAF и антибот-модулями. Логика этих модулей проста: подозрительный агент получает JavaScript-челлендж или капчу. А теперь посмотрим на поведение YandexBot глазами такой системы: заходит с не самого известного пула IP, десятками запросов в секунду, не грузит картинки и CSS, не исполняет JS, не имеет cookie, ходит по всему сайту подряд. Идеальный портрет парсера.
Что происходит дальше: робот получает ответ 403 или страницу с проверкой. Google-бот в такой ситуации обычно отмечает страницу как недоступную. Яндекс делает то же самое, и через несколько неудачных обходов страницы начинают выпадать из индекса. Хуже всего то, что вы этого не заметите: в браузере сайт работает идеально, аналитика показывает нормальный трафик, а органика тихо утекает.
Обязательные действия: внести YandexBot, Googlebot и роботов Mail.ru в белый список провайдера по обратному DNS-резолвингу (не по User-Agent — его подделывает кто угодно), отключить для них rate limiting и челленджи, регулярно проверять доступность страниц через инструмент «Проверка ответа сервера» в Яндекс Вебмастере. И заведите отдельный мониторинг на код ответа для запросов с User-Agent робота — это пятиминутная настройка, которая спасает от катастрофы.
Если поисковый робот получает от вашей CDN капчу или 403 — у вас нет никакого SEO. Всё остальное — тексты, ссылки, структура — не имеет значения, пока робот не может физически прочитать страницу.
Кэш HTML и свежесть контента
Со статикой всё просто: файл с хешем в имени неизменен по определению, кэшируйте его на год. С HTML сложнее. Здесь конфликтуют два желания: отдать роботу страницу мгновенно из кэша и отдать ему актуальную версию.
Рабочая схема — короткий TTL плюс механизм фоновой ревалидации. Заголовок вида Cache-Control: public, max-age=0, s-maxage=60, stale-while-revalidate=600 означает: браузер не кэширует, узел CDN держит копию 60 секунд как свежую, а следующие 10 минут может отдавать устаревшую копию, параллельно обновляя её из origin в фоне. Пользователь и робот всегда получают мгновенный ответ, origin получает один запрос в минуту вместо тысячи, а расхождение с реальностью не превышает нескольких минут.
Второе обязательное условие — инвалидация по событию. Изменили цену, опубликовали статью, обновили описание товара — админка должна дёргать API провайдера и сбрасывать кэш конкретного URL. Без этого вы обречены балансировать между «слишком свежо, но медленно» и «быстро, но с ценами прошлого месяца». Особенно критично для e-commerce: как это встраивается в общую техническую базу магазина, разбирали в гиде по SEO для интернет-магазина.
Правильная настройка: пошагово
Последовательность, которую мы применяем при внедрении CDN на проектах с органическим трафиком. Порядок шагов не случаен — он минимизирует риск потерять позиции в переходный период.
Снимите базовые метрики до внедрения
Зафиксируйте TTFB и LCP по ключевым регионам, долю страниц в зелёной зоне, среднее время ответа сервера из Вебмастера, количество проиндексированных страниц. Без этой точки отсчёта вы не докажете ни себе, ни клиенту, что стало лучше, и не заметите, что стало хуже.
Выберите провайдера по карте узлов, а не по цене
Смотрите на количество точек присутствия внутри России и в вашей целевой географии. Одна точка в Москве и одна в Петербурге при аудитории от Калининграда до Хабаровска — это не CDN, это ещё один прокси.
Начните только со статики
Первым этапом уводите под CDN изображения, CSS, JS, шрифты. HTML пока идёт напрямую с origin. Это даёт 60–70% эффекта при близком к нулю риске и позволяет проверить провайдера в бою.
Настройте заголовки кэширования осмысленно
Статика с версионированием в имени файла — Cache-Control: public, max-age=31536000, immutable. Статика без версионирования — не больше суток. HTML — s-maxage 60–300 плюс stale-while-revalidate. robots.txt и sitemap.xml — максимум 5 минут.
Внесите поисковых роботов в белый список
YandexBot, Googlebot, Mail.Ru bot — по обратному DNS-резолвингу. Отключите для них капчу, JS-челленджи и rate limiting. Это обязательный шаг, а не рекомендация.
Проверьте коды ответа и редиректы
Убедитесь, что 301, 404 и 410 проходят через CDN без искажений, а 5xx не кэшируются вовсе. Проверьте, что нет двойного редиректа: origin редиректит на HTTPS, CDN редиректит ещё раз — робот получает цепочку.
Настройте инвалидацию из админки
Публикация или правка контента должна автоматически сбрасывать кэш соответствующего URL через API провайдера. Ручной сброс «всего кэша» кнопкой — это не процесс, а костыль, который однажды забудут нажать.
Переводите HTML и наблюдайте две недели
После перевода динамики следите за долей попаданий в кэш, кодами ответа для роботов, скоростью обхода в Вебмастере и количеством страниц в индексе. Аномалии проявляются на 3–10 день, не раньше.
Что важно не забыть на этапе настройки
Несколько технических деталей, которые регулярно упускают.
- Единственный canonical. Если статика доступна и по вашему домену, и по техническому домену провайдера вида cdn12345.provider.net, у вас появится вторая копия сайта. Закройте технический домен от индексации и работайте только через CNAME на свой поддомен.
- Реальный IP пользователя. Origin должен получать адрес посетителя из заголовка X-Forwarded-For или CF-Connecting-IP, иначе все ваши логи, антифрод и геологика увидят один и тот же IP узла CDN.
- Vary: Accept-Encoding. Без него узел может отдать сжатый Brotli-ответ клиенту, который его не понимает, — получите битую страницу у части аудитории.
- Полный HTTPS. Только режим full/strict, где CDN общается с origin тоже по HTTPS с проверкой сертификата. Схема «flexible» с HTTP до origin создаёт mixed content и уязвимость. Детали перехода — в статье про HTTPS и SEO.
- Sitemap и robots.txt отдаются с origin. Или кэшируются на минуты. Эти два файла — управляющие, и залипший кэш здесь стоит дороже всего.
- HTTP/2 и HTTP/3. Включайте, если провайдер умеет: мультиплексирование и QUIC дают заметный выигрыш на мобильных сетях с потерями пакетов, что важно для мобильной оптимизации.
Выбор CDN для рунета: на что смотреть
Рынок разделился. Есть российские провайдеры с плотной сетью узлов внутри страны и понятной юрисдикцией. Есть глобальные сети с огромной инфраструктурой, но неопределённым присутствием в России и риском внезапных ограничений. Есть CDN внутри облачных экосистем, удобные, если вы уже там живёте. И есть решения при хостинге — простые, но обычно с тремя узлами.
| Критерий | Почему важен для SEO | Как проверить |
|---|---|---|
| Узлы внутри России | Без них CDN замедляет российскую аудиторию вместо ускорения | Карта PoP на сайте провайдера; замеры TTFB из Новосибирска, Екатеринбурга, Ростова |
| Политика в отношении роботов | Блокировка YandexBot = выпадение из индекса | Спросите в поддержке прямо: есть ли whitelist поисковых ботов и как он работает |
| Гибкость кэша | Нужны stale-while-revalidate, ключ кэша по URL и Vary, разные правила для разделов | Документация; тест на стенде до боевого переключения |
| API инвалидации | Без неё контент в индексе будет отставать от реальности | Наличие метода purge по конкретному URL и по тегу, лимиты на количество вызовов |
| Обработка изображений | WebP/AVIF на лету экономят 25–50% веса LCP-картинки | Поддержка формата по Accept, ресайз по параметрам URL |
| Прозрачность логов | Нужно видеть коды ответа и hit ratio по User-Agent роботов | Наличие выгрузки логов или аналитики с фильтром по агенту |
| Юрисдикция и стабильность | Отключение сервиса = недоступность сайта = потеря позиций | Юрлицо, договор, оплата в рублях, история работы в РФ |
Отдельно про кэш изображений. Если провайдер умеет конвертировать в WebP и AVIF на границе по заголовку Accept, вы получаете экономию 25–50% веса главной картинки первого экрана без единого изменения в CMS. Это самый дешёвый выигрыш в LCP из существующих. Что делать с картинками помимо этого, подробно разобрано в материале про оптимизацию изображений.
Когда CDN не нужна
Честный ответ, который редко услышишь от продавцов трафика. Сеть доставки — это расход и усложнение архитектуры, и она оправдана не всегда.
Локальный бизнес с одним городом. Стоматология в Самаре, сайт на сервере в Москве, вся аудитория — Самара и область. Разница в 15 мс сетевой задержки не изменит ни LCP, ни позиции. Деньги и время лучше вложить в скорость бэкенда и в Яндекс.Карты.
Малопосещаемый сайт. При 200 визитах в сутки кэш на узлах не успевает прогреться: каждый второй запрос — промах, узел идёт до origin, пользователь получает задержку больше, чем без CDN. CDN любит трафик; на низкой посещаемости она работает против вас.
Сайт, у которого болит бэкенд. Если TTFB 1,2 секунды из-за неоптимизированных запросов к базе, CDN этого не вылечит — она вообще не участвует в генерации HTML. Сначала кэш на стороне приложения, индексы в базе, нормальный тариф хостинга.
Проект без ресурса на сопровождение. CDN добавляет слой, который надо мониторить и понимать. Если некому разбираться, почему после релиза узлы отдают старый CSS, вы получите не ускорение, а регулярные инциденты и падение поведенческих факторов.
Как проверить, что CDN помогает, а не вредит
Внедрение без измерения — это вера, а не инженерия. Что смотреть после переключения.
Поле, а не лаборатория. Синтетические тесты вроде PageSpeed Insights дают лабораторные значения с фиксированной точки. Реальную картину показывают полевые данные: отчёты Метрики по времени загрузки в разрезе регионов и раздел скорости в Вебмастере. Именно они отражают то, что видит поисковик.
Разрез по регионам. Главный маркер пользы — сокращение разрыва между столицей и удалёнными городами. Если Москва грузится за 1,4 с, а Владивосток за 3,1 с, то после правильного внедрения второй показатель должен упасть до 1,8–2,0 с. Если не упал — узлов в нужной географии нет, и вы платите за воздух.
Доля попаданий в кэш (hit ratio). Для статики норма — выше 90%. Ниже 70% означает ошибку в заголовках: скорее всего, где-то стоит Cache-Control: no-cache или Set-Cookie на статических ответах, что автоматически запрещает кэширование.
Коды ответа для роботов. Отдельный отчёт: сколько 200, 403, 429 и 5xx получили YandexBot и Googlebot за сутки. Любая доля 403 и 429 выше нуля — инцидент, который надо разбирать сегодня.
Скорость обхода и индексация. В Вебмастере смотрите динамику загруженных страниц и время ответа сервера. Правильно внедрённая CDN обычно увеличивает интенсивность обхода: роботу становится дешевле качать ваш сайт, и он качает больше. Это, кстати, прямой способ расширить краулинговый бюджет на крупных каталогах и ускорить индексацию сайта.
Если внутри команды некому вести эту диагностику, разумнее отдать её на аутсорс вместе с технической частью продвижения: примеры проектов, где мы разбирали связку «сервер — CDN — Core Web Vitals», собраны в портфолио, а состав работ и стоимость сопровождения — в разделе цен. Отдельно отметим: если сайт только проектируется, слой доставки и стратегию кэширования стоит заложить сразу на этапе создания сайта — переделывать заголовки кэширования и схему инвалидации на живом проекте с трафиком всегда дороже и рискованнее.
КОНТРОЛЬНАЯ ТОЧКА ЧЕРЕЗ 14 ДНЕЙ
Через две недели после перевода HTML под CDN сверьте пять цифр: LCP по регионам, hit ratio, доля не-200 ответов для роботов, количество страниц в поиске, время ответа сервера в Вебмастере. Если хотя бы один показатель ухудшился — не ждите «пока устаканится». Аномалии в этой связке сами не проходят, они накапливаются.
Частые вопросы
Нет, отдельного фактора «использует CDN» не существует. Есть факторы скорости: время ответа сервера, скорость загрузки страницы, поведенческие метрики, которые от скорости зависят. CDN влияет на них опосредованно. Поисковику всё равно, каким способом вы добились быстрой отдачи, — важен результат. Поэтому «подключить CDN ради SEO» — неправильная постановка; правильная — «улучшить LCP и TTFB в регионах, и CDN один из инструментов для этого».
Если у сайта уже есть устойчивые региональные сигналы — регион в Вебмастере, организация в Яндекс Бизнесе, адреса и телефоны на страницах, релевантные тексты — практически нет. IP-адрес давно не главный сигнал геопривязки. Риск реален для молодых сайтов без истории и без организации: там любая неопределённость работает против вас. Совет простой — сначала закрепите регион всеми доступными способами, потом подключайте CDN, а не наоборот.
Три самые частые причины. Первая — узлы провайдера дальше от вашей аудитории, чем ваш origin: запрос делает крюк через Европу. Вторая — низкий hit ratio: кэш не работает из-за неверных заголовков или Set-Cookie на статике, и каждый запрос ходит до сервера через лишнее звено. Третья — слишком мало трафика, чтобы кэш прогревался. Начните с замера TTFB из разных городов и с проверки доли попаданий в кэш — обычно диагноз становится очевиден за полчаса.
В Яндекс Вебмастере откройте «Проверку ответа сервера» и посмотрите, что робот получает на ключевых URL: должен быть 200 и полный HTML, а не 403, 429 или страница с проверкой. Параллельно смотрите на статистику обхода — резкое падение количества загруженных страниц при неизменном сайте почти всегда означает, что роботу закрыли дверь. И запросите у провайдера логи с фильтром по User-Agent роботов: любые не-200 ответы там — это диагноз.
Да, если статика доступна по техническому адресу провайдера. Иначе вы рискуете получить в индексе вторую копию ресурсов, а иногда и страниц. Правильная схема — CNAME на ваш поддомен вида static.вашсайт.ru и запрет индексации технического домена. Если через CDN проходит HTML, то тем более: все canonical должны указывать на основной домен, а не на адрес узла. Механику дублей подробно разбирали в статье про canonical и дубли.
Регулярно и вручную — никогда. Кэш должен инвалидироваться автоматически по событию: изменили страницу — CMS дёрнула API провайдера и сбросила конкретный URL. Статику с хешем в имени файла сбрасывать не нужно вообще: при релизе меняется имя, и это новый объект. Тотальный сброс всего кэша кнопкой — аварийная процедура, после которой origin получает залповую нагрузку и может лечь. Если вы делаете это еженедельно, значит, настройка кэширования неправильная.
Да, положительно — при корректной настройке. Робот распределяет ресурсы с оглядкой на скорость ответа сервера: чем быстрее сайт отвечает, тем интенсивнее обход. Правильно внедрённая CDN снижает время ответа и позволяет роботу загружать больше страниц за тот же интервал. На крупном каталоге с сотнями тысяч URL это заметно ускоряет попадание новых страниц в индекс. Но при неверной настройке эффект обратный: таймауты и 429 заставляют робота сбавлять темп.
Это решает диагностика, а не бюджет. Если TTFB высокий по всей стране одинаково — проблема в бэкенде, и нужен сервер, кэш приложения и оптимизация базы; CDN тут не поможет. Если TTFB в Москве нормальный, а в Сибири и на Дальнем Востоке в два-три раза выше — проблема в расстоянии, и нужна именно CDN. Часто требуется и то, и другое, но порядок важен: сначала лечим origin, потом ускоряем доставку. Подробнее про роль сервера — в материале про хостинг и SEO.
Ускорим сайт и выведем в ТОП без потери позиций
Проведём технический аудит, подберём и настроим CDN под вашу географию, выведем Core Web Vitals в зелёную зону и проследим, чтобы робот видел сайт правильно. Прозрачный договор, отчёты каждую неделю.
- Пакет «Старт» от 55 000 ₽/мес
- Пакет «Стандарт» 75 000 ₽/мес
- Пакет «Премиум» 95 000 ₽/мес
- Бесплатный аудит и прогноз
- Договор с гарантией результата
- Отчёты каждую неделю
Комментарии (14)
Александр
Раздел про то, что CDN почти не влияет на INP, стоит распечатать и повесить перед разработчиками. У нас полгода объясняли клиенту, что мегабайтный бандл быстрее не исполнится оттого, что он приехал из соседнего города.
Марина_К
Подключили сеть с узлами только в Европе, потому что тариф был дешевле. TTFB в Екатеринбурге вырос почти вдвое, разбирались месяц. В статье это ровно тот пункт про крюк через Франкфурт — жаль, что прочитала уже после.
AdminSEO Мастер
Марина, очень частая история. Прежде чем менять провайдера, снимите TTFB из трёх-четырёх целевых городов до и после — так вы сразу увидите, есть ли реальные узлы рядом с аудиторией или только красивая карта на сайте. Карта PoP и замеры почти всегда расходятся.
Дмитрий
Про stale-while-revalidate отдельное спасибо. Схема с s-maxage=60 и окном ревалидации на 10 минут решила наш спор с бэкендерами, которые вообще не хотели кэшировать HTML.
Ольга П.
А если у нас поддомены под города и на каждом свой телефон — можно вообще спокойно ставить CDN? Боюсь той самой истории, когда Казань увидит екатеринбургский номер.
AdminSEO Мастер
Ольга, если у каждого города свой отдельный URL, то риска почти нет: ключ кэша строится по адресу, и версии не перемешаются. Опасна именно подмена контента по IP на одном URL — вот там нужен Vary или edge-параметр. У вас как раз правильная схема, можно ставить.
Сергей_бизнес
Раздел «Когда CDN не нужна» — самая честная часть. У меня автосервис в одном городе, мне полгода продавали сеть доставки как обязательную вещь.
vladimir77
Не соглашусь с тезисом, что робота надо белить по обратному DNS. У нормальных провайдеров это делается парой галочек, зачем усложнять.
AdminSEO Мастер
Владимир, галочка в интерфейсе — это и есть whitelist, вопрос в том, по чему он проверяет. Если по User-Agent, то любой парсер представится YandexBot и пройдёт мимо защиты. Обратный резолвинг — не усложнение, а единственный способ отличить настоящего робота от подделки, поэтому стоит уточнить у поддержки, как именно работает их галочка.
Ирина
Пункт про закэшированный robots.txt попал в больное. Выкатили запрещающую версию на время работ, сняли через час, а узлы отдавали её ещё сутки.
Максим
Вопрос по hit ratio: у нас на статике всего около 60%. Куда копать в первую очередь?
AdminSEO Мастер
Максим, в девяти случаях из десяти это Set-Cookie, который прилетает на статические ответы, — он автоматически отключает кэширование на узле. Второй подозреваемый — no-cache в Cache-Control от самого сервера. Посмотрите заголовки любой картинки через curl, диагноз обычно виден сразу.
Анна Т.
Спасибо за пошаговый порядок внедрения. Особенно за мысль начинать со статики и держать HTML на origin — так хотя бы понятно, кто виноват, если что-то поедет.
Костя_devops
Добавлю к списку деталей: X-Forwarded-For реально забывают. Пока не прокинули реальный IP, вся геологика на сайте считала, что все посетители сидят в одном дата-центре.
Наталья_В
У нас блог с небольшой посещаемостью, и после CDN стало ощутимо медленнее. Теперь понятно почему — кэш просто не успевал прогреваться. Отключили, вернулись к нормальным цифрам.
Егор
А что если сайт молодой, региональность ещё не устоялась, но аудитория по всей стране? Ждать полгода с CDN или всё-таки ставить?
AdminSEO Мастер
Егор, компромисс простой: уводите под CDN только статику, а HTML пока оставьте на origin с российским IP. Скорость картинок и шрифтов вы получите, а геосигналы не размоете. Параллельно закрепляйте регион в Вебмастере и Бизнесе, и через пару месяцев переводите HTML спокойно. Если сомневаетесь в раскладе — приходите на аудит, посмотрим вашу конкретную географию.
Тимур
Конвертация в AVIF на границе по заголовку Accept — это правда самый дешёвый выигрыш в LCP. Ничего не трогали в CMS, а главная картинка похудела заметно.
Лиля
Контрольная точка через 14 дней и пять цифр к сверке — забрала себе в чек-лист. Раньше просто включали и надеялись.