WordPress и Yandex Cloud CDN: подключение, замена URL и частые ошибки

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, который уже упирается в отдачу статики.

Схема подключения: по шагам

1. Создать ресурс CDN в Yandex Cloud, origin — ваш домен/сервер (или бакет Object Storage, если статика там).
2. Настроить HTTPS и CNAME (например, cdn.example.ru) либо использовать выданный хост облака — для продакшена обычно свой CNAME.
3. Задать правила кэша для статики: расширения, TTL, поведение query string.
4. Проверить, что origin отдаёт корректный Cache-Control / Expires для файлов, которые должны кэшироваться.
5. На WordPress переписать URL статики на CDN-домен (плагин, фильтры или контент).
6. Проверить заголовки HIT / Age / Cache-Control на повторном запросе.
7. Прогреть ключевые 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 мешает отладке или ресурс больше не нужен.

1. Верните origin-URL в WordPress (отключите плагин/фильтр замены, уберите CDN-домен из настроек).
2. Очистите кэш WP (page cache + object cache при наличии) и CDN (purge).
3. Проверьте HTML: больше нет yandexcloud.net / вашего CNAME на статике.
4. Прогоните ключевые страницы, формы, корзину/запись, админку.
5. Только после этого остановите или удалите ресурс в кабинете облака.

Резкое отключение только в облаке при живых CDN-ссылках на сайте даёт битые картинки и стили — поэтому порядок важен. Если часть URL всё ещё в старых постах, сделайте точечную замену в контенте или временный редирект со старого CDN-хоста (если он ещё жив).

Типичные ошибки на WordPress

1. CDN включили, URL не переписали — эффекта нет.
2. Кэшируют HTML с Set-Cookie — «странное» поведение личного кабинета и корзины.
3. Два кэша (плагин + CDN) без понимания, кто что хранит.
4. Забыли purge после деплоя CSS — «у меня не обновились стили».
5. Тянут через CDN админку и preview.
6. Ожидают, что CDN ускорит медленный TTFB PHP.
7. Переписали только wp_get_attachment_url, забыли srcset / content.
8. Смешали 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 или массовой замены изображений:

1. задеплойте файлы на origin;
2. сделайте purge CDN по путям или полный (если объём небольшой);
3. очистите page cache WordPress;
4. откройте посадочную в режиме инкогнито и проверьте Network: новые хэши/версии файлов и HIT после второго запроса;
5. проверьте 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.