18.08.2026
51
WordPress и Yandex Cloud CDN: подключение, замена URL и частые ошибки
Yandex CDN — один из самых частых технических запросов к материалам GLM-DEV: люди ищут ускорение сайта через облачную сеть доставки. Отдельный пласт вопросов — именно WordPress: как заменить ссылки на...Yandex CDN — один из самых частых технических запросов к материалам GLM-DEV: люди ищут ускорение сайта через облачную сеть доставки. Отдельный пласт вопросов — именно WordPress: как заменить ссылки на CDN, почему картинки всё ещё с origin и как отключить *.yandexcloud.net, если что-то пошло не так. Ниже — практический слой поверх общего руководства по CDN: что сделать на WP, чтобы CDN реально работал, а не «был включён в кабинете». Полные правила кэша и примеры конфигов — в полном гайде по Yandex Cloud CDN. Зачем WordPress вообще CDN CDN кэширует статику ближе к пользователю: изображения, CSS, JS, шрифты, иногда видео-превью. Это бьёт в: LCP (особенно hero-картинки и крупные фото услуг); TTFB статики и стабильность при всплеске Директа; разгрузку origin-сервера, когда одновременно открывают много страниц с медиа. CDN не лечит медленный PHP, тяжёлую тему, неоптимизированные запросы к БД и «зоопарк» плагинов. Сначала кэш страниц и оптимизация изображений, потом CDN — иначе вы ускоряете доставку «кирпичей». Когда CDN особенно оправдан: аудитория из разных городов/регионов; много медиа (клиники, каталоги, портфолио); рекламный трафик с мобильных устройств; origin на одном VPS, который уже упирается в отдачу статики. Схема подключения: по шагам Создать ресурс CDN в Yandex Cloud, origin — ваш домен/сервер (или бакет Object Storage, если статика там). Настроить HTTPS и CNAME (например, cdn.example.ru) либо использовать выданный хост облака — для продакшена обычно свой CNAME. Задать правила кэша для статики: расширения, TTL, поведение query string. Проверить, что origin отдаёт корректный Cache-Control / Expires для файлов, которые должны кэшироваться. На WordPress переписать URL статики на CDN-домен (плагин, фильтры или контент). Проверить заголовки HIT / Age / Cache-Control на повторном запросе. Прогреть ключевые URL (главная, услуги, hero) и замерить PageSpeed / полевые метрики на мобилке. Не включайте CDN «на всё подряд», включая HTML личного кабинета и ответы с персональными cookie — получите странные сессии и устаревшие экраны. Как заменить ссылки на CDN в WordPress Есть три рабочих подхода. Часто комбинируют 2 и 3. 1. Плагин CDN / оптимизации (если уже в стеке: WP Rocket, LiteSpeed, отдельный CDN-плагин и т.п.). Плюс — быстро. Минус — ещё один слой абстракции и риск конфликта с page cache. 2. Константы и фильтры темы / mu-plugin. Типичная идея: для вложений, стилей и скриптов подменять origin на CDN-хост. Упрощённый пример (адаптируйте под свой CDN-домен и исключения): /** * Подмена URL медиа и ассетов на CDN. * Не копируйте в прод без staging и списка исключений. */ add_filter('wp_get_attachment_url', 'glm_cdn_rewrite_url'); add_filter('style_loader_src', 'glm_cdn_rewrite_url', 10, 1); add_filter('script_loader_src', 'glm_cdn_rewrite_url', 10, 1); function glm_cdn_rewrite_url($url) { if (is_admin() || empty($url)) { return $url; } $cdn = 'https://cdn.example.ru'; $host = home_url(); // Не трогаем preview и временные query if (strpos($url, 'preview=true') !== false) { return $url; } return str_replace($host, $cdn, $url); } На практике часто нужны исключения: админка, preview, некоторые плагины, signed URL, карты, виджеты с чужих доменов. Отдельно проверьте srcset и WebP-версии — иначе LCP-картинка останется на origin, а мелкие превью уйдут на CDN. 3. Замена только в контенте (фильтр the_content / the_excerpt или разовая миграция в БД). Помогает, если в постах захардкожены абсолютные URL на старый домен. add_filter('the_content', function ($content) { $cdn = 'https://cdn.example.ru'; $host = home_url(); return str_replace($host . '/wp-content/uploads', $cdn . '/wp-content/uploads', $content); }); Важно: после смены домена CDN сделайте purge и проверьте страницы услуг/блога, не только главную. Иначе редактор увидит «старое» из page cache, а пользователь — смесь origin и CDN. Что проверить после включения (HIT и заголовки) Картинка/CSS открываются с CDN-домена в HTML, не только «ресурс создан в облаке». В ответе есть признак HIT после повторного запроса (зависит от заголовков провайдера: статус кэша, Age и т.п.). Нет mixed content (http на https-странице). WebP / ресайзы WP / srcset тоже идут через CDN. Формы, AJAX, админка и preview не сломались. LCP главного экрана реально улучшился на мобилке (лаборатория + поле, если есть). После деплоя CSS/JS purge срабатывает: пользователи не видят «сломанную вёрстку». Если URL уже на CDN, а HIT нет — смотрите: Cache-Control: private/no-store на origin; cookies, которые делают ответ «персональным»; query string (?ver=...) и правила игнора/учёта параметров; неверный origin или редиректы origin → www/https; правило CDN не матчит путь /wp-content/ или нужное расширение. Как отключить Yandex Cloud CDN без боли Запрос «cloud cdn yandex.net как отключить» обычно значит: сайт отдаёт старые URL, CDN мешает отладке или ресурс больше не нужен. Верните origin-URL в WordPress (отключите плагин/фильтр замены, уберите CDN-домен из настроек). Очистите кэш WP (page cache + object cache при наличии) и CDN (purge). Проверьте HTML: больше нет yandexcloud.net / вашего CNAME на статике. Прогоните ключевые страницы, формы, корзину/запись, админку. Только после этого остановите или удалите ресурс в кабинете облака. Резкое отключение только в облаке при живых CDN-ссылках на сайте даёт битые картинки и стили — поэтому порядок важен. Если часть URL всё ещё в старых постах, сделайте точечную замену в контенте или временный редирект со старого CDN-хоста (если он ещё жив). Типичные ошибки на WordPress CDN включили, URL не переписали — эффекта нет. Кэшируют HTML с Set-Cookie — «странное» поведение личного кабинета и корзины. Два кэша (плагин + CDN) без понимания, кто что хранит. Забыли purge после деплоя CSS — «у меня не обновились стили». Тянут через CDN админку и preview. Ожидают, что CDN ускорит медленный TTFB PHP. Переписали только wp_get_attachment_url, забыли srcset / content. Смешали http и https, получили mixed content на рекламных посадочных. Связка с рекламой, SEO и Core Web Vitals CDN — часть подготовки к Директу и Core Web Vitals, а не отдельная «галочка для SEO». Имеет смысл: ускорить статику через CDN; сжать hero и отложить виджеты (чат, пиксели, тяжёлые карты); проверить посадочные URL из объявлений на мобилке; смотреть LCP/INP/CLS до и после, а не только «баллы PageSpeed». Если готовите запуск рекламы, CDN хорошо стыкуется с чеклистом готовности посадочных: скорость, стабильность вёрстки, рабочие формы. Полезный соседний материал — Core Web Vitals перед запуском Директа: CDN там не замена оптимизации, а один из рычагов. Для поискового продвижения статья закрывает частотный запрос yandex cdn и длинные хвосты про WordPress-замену ссылок и отключение — то, что уже даёт показы в Вебмастере. Помните: CDN усиливает хороший фронт. Если тема тащит 2 МБ скриптов до LCP, облако не сделает из этого быстрый сайт — только чуть быстрее доставит тяжёлые файлы. Object Storage vs origin-сайт: что выбрать Частый вопрос: отдавать медиа с сервера WordPress или вынести в Object Storage и повесить CDN поверх бакета. Origin = сайт — проще старт, WP продолжает писать в uploads, меньше инфраструктуры. Минус: origin всё ещё отдаёт файлы при MISS и при прогреве. Origin = бакет — удобно при большом объёме медиа и желании разгрузить VPS. Минус: нужна синхронизация загрузок (плагин/хук), аккуратная политика публичного доступа и отдельные правила кэша. Для большинства сайтов услуг на WordPress достаточно CDN поверх origin-сайта + перепись URL. Бакет имеет смысл, когда медиа действительно давят диск/трафик сервера или медиаконтур общий для нескольких приложений. Что делать при деплое и смене темы После обновления темы, критического CSS или массовой замены изображений: задеплойте файлы на origin; сделайте purge CDN по путям или полный (если объём небольшой); очистите page cache WordPress; откройте посадочную в режиме инкогнито и проверьте Network: новые хэши/версии файлов и HIT после второго запроса; проверьте LCP-элемент: это всё ещё то же изображение/блок, что вы оптимизировали. Без этой дисциплины команда «CDN тормозит обновления» появляется через неделю после запуска — хотя виноват не CDN, а отсутствие purge в процессе релиза. Практический мини-чеклист GLM-DEV Origin и HTTPS в CDN настроены, CNAME резолвится. Правила кэша покрывают /wp-content/uploads, CSS, JS, шрифты. На WP включена перепись URL (и проверена на staging). Повторный запрос статики даёт HIT / растущий Age. Админка и preview на origin. Есть понятный план rollback (как отключить без битых URL). После деплоя — процедура purge. Замер LCP на ключевых посадочных до/после. Краткий итог Связка WordPress + Yandex Cloud CDN работает, когда настроены origin, HTTPS, правила кэша и перепись URL статики. Проверяйте HIT, не ломайте админку и умейте безопасно отключить CDN. Ускорение статики усиливает, но не заменяет нормальный хостинг, кэш страниц и чистый фронт — особенно перед Директом и работой над Core Web Vitals. Нужна настройка CDN под ваш WP или аудит скорости — можно обратиться в GLM-DEV. Если нужен глубокий разбор правил кэша в облаке — начните с полного руководства по Yandex Cloud CDN.Yandex CDN — один из самых частых технических запросов к материалам GLM-DEV: люди ищут ускорение сайта через облачную сеть доставки. Отдельный пласт...
