Настройка TTL для кеша страниц в WordPress: как не держать устаревший HTML слишком долго

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

Тема кажется простой, но в WordPress TTL может задаваться в нескольких местах: плагином кеширования, серверным reverse proxy, CDN и иногда даже заголовками браузерного кеша. Поэтому сначала нужно понять, какой именно слой отдаёт устаревшую страницу, а уже потом менять срок жизни кеша.

Когда проблема действительно в TTL, а не в WordPress

Сначала полезно отделить кеш от других причин. Если вы обновили запись, а на фронтенде изменения не появились сразу, это ещё не доказательство проблемы с TTL. Иногда виноваты:

• объектный кеш, который держит старые данные в wp_options или в запросах к термам;
• CDN, который отдает старую HTML-версию по краю сети;
• кеш плагина, но только для части URL;
• кеш браузера, если речь о CSS/JS, а не о самой странице.

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

Признаки, что TTL слишком длинный

• после публикации запись видна в админке, но на сайте старая версия держится часами;
• очистка кеша в плагине сразу решает проблему;
• на разных устройствах и в инкогнито открывается один и тот же устаревший HTML;
• в DevTools или через curl видны заголовки кеша с большим временем жизни;
• после правок в шаблоне изменения появляются только после ручной purge.

Диагностика: где смотреть TTL и кто его выставляет

Начните с ответа на простой вопрос: какой слой кеша отвечает за HTML. В WordPress это чаще всего плагин кеширования, а на хостинге — Nginx FastCGI cache, Varnish или CDN. Если изменить TTL только в одном месте, а второй слой оставить прежним, эффект будет неполным.

Проверить заголовки можно так:

curl -I https://example.com/

Ищите заголовки вроде Cache-Control, Expires, X-Cache, Age, CF-Cache-Status или фирменные заголовки вашего CDN/прокси. Если в ответе есть Age, это хороший индикатор того, что страница уже лежит в кеше и отдается не из PHP.

Если у вас установлен плагин кеширования, проверьте его настройки отдельно. У разных решений TTL называется по-разному: cache lifespan, cache timeout, expiry time, lifetime. Важно не путать TTL HTML и срок жизни браузерного кеша для статики.

Как настроить TTL для кеша страниц в WordPress

Ниже — рабочая схема, которая подходит для большинства сайтов: сначала определяем, какой слой кеширует HTML, потом уменьшаем TTL там, где это действительно нужно, и только после этого проверяем поведение на обновлении контента.

Шаг 1. Уменьшите TTL в плагине кеширования

Если HTML кеширует плагин, начните с его настроек. В большинстве случаев достаточно задать срок жизни в пределах, который соответствует частоте обновления сайта. Для новостного или контентного проекта это обычно короче, чем для корпоративного сайта с редкими правками.

Если плагин позволяет настроить автоматическую очистку, включите purge при:

• публикации новой записи;
• обновлении записи;
• изменении рубрик и меток;
• смене меню, если оно выводится в кешируемом шаблоне;
• обновлении виджетов, если они попадают в HTML-кеш.

Смысл не в том, чтобы сделать TTL минимальным. Слишком короткий срок жизни заставит сервер чаще генерировать HTML заново и может увеличить нагрузку. Лучше держать TTL достаточно коротким для актуальности и компенсировать это нормальной очисткой при изменениях.

Шаг 2. Проверьте серверный кеш и CDN

Если после настройки плагина старая версия всё равно держится, ищите второй слой. На хостинге часто включён FastCGI cache или reverse proxy, который живёт отдельно от WordPress. В этом случае очистка кеша в админке не всегда помогает, потому что WordPress не управляет серверным слоем напрямую.

Для CDN логика похожая: HTML может кешироваться на edge, а WordPress уже давно отдал новую версию. Тогда нужно либо уменьшить TTL для HTML на стороне CDN, либо настроить purge по событиям обновления контента. Если CDN используется только для статики, HTML лучше не кешировать там без необходимости.

Шаг 3. При необходимости задайте заголовки через код

Если вам нужно явно управлять кешированием HTML на уровне темы или плагина, можно отправлять заголовки через send_headers. Это не заменяет серверный кеш, но помогает задать поведение для браузеров и промежуточных прокси, если они уважают заголовки.

add_action('send_headers', function () {
    if (is_admin() || wp_doing_ajax() || is_feed() || is_preview()) {
        return;
    }

    if (is_singular()) {
        header('Cache-Control: public, max-age=300, s-maxage=600');
    } else {
        header('Cache-Control: public, max-age=600, s-maxage=1800');
    }
});

Здесь max-age влияет на браузерный кеш, а s-maxage — на shared cache, если он поддерживается. Но не стоит считать этот код универсальным решением: если у вас уже есть Nginx cache или CDN, они могут переопределять заголовки.

Шаг 4. Не кешируйте то, что должно быть свежим

Некоторые страницы и фрагменты лучше исключить из кеша или держать с очень коротким TTL:

• страницы с персональными данными пользователя;
• корзина, оформление заказа и личный кабинет, если речь о магазине;
• страницы с часто меняющимися счетчиками, рейтингами или лайв-данными;
• админка, REST API, AJAX-эндпоинты;
• страницы предпросмотра и результаты поиска.

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

Проверка результата после внедрения

После изменения TTL не ограничивайтесь визуальной проверкой в браузере. Нужны хотя бы три шага контроля.

1. Обновите запись или шаблон и очистите кеш только там, где это требуется.
2. Снова выполните curl -I и посмотрите, изменились ли заголовки Cache-Control, Age и признаки кеша от CDN или прокси.
3. Откройте страницу в обычном окне и в инкогнито, затем сравните HTML через просмотр исходника или DevTools.

Если у вас есть доступ к логам или панели CDN, проверьте, как часто происходит cache hit и как быстро страница обновляется после purge. Это особенно важно для главной страницы и архивов, где устаревший HTML заметнее всего.

Что считать нормальным результатом

• после обновления контента новая версия появляется без ручной очистки всего сайта;
• TTL соответствует частоте изменений на сайте;
• страницы, которые должны быть свежими, не держатся в кеше слишком долго;
• нагрузка на сервер не выросла заметно после сокращения TTL;
• заголовки кеша одинаково ведут себя на основных типах страниц.

Частые ошибки и как их исправить

Меняют TTL только в плагине, а CDN продолжает отдавать старую версию

Это самая частая ситуация. WordPress уже отдал новую страницу, но CDN держит старую копию. Решение — проверить TTL именно на edge и настроить purge для HTML, а не только для статики.

Ставят слишком короткий TTL и получают лишнюю нагрузку

Если TTL сделать слишком маленьким, кеш почти не работает, а PHP и база начинают чаще генерировать страницу заново. Исправление простое: увеличьте TTL для стабильных разделов и оставьте короткий срок только для динамических страниц.

Путают HTML-кеш и браузерный кеш

Если проблема только в CSS или JS, сокращение TTL для HTML не поможет. Для статики лучше использовать версионирование файлов и отдельные заголовки кеширования, а не трогать кеш страниц.

Не исключают служебные URL

Кеширование поиска, предпросмотра, личного кабинета и AJAX-ответов приводит к багам, которые сложно воспроизвести. Такие URL нужно исключать заранее, а не после жалоб пользователей.

Практические советы по безопасности и производительности

TTL — это не только про скорость. Нормально настроенный кеш снижает число запросов к базе и уменьшает поверхность для случайных ошибок, когда один и тот же тяжелый шаблон генерируется слишком часто. Но есть и обратная сторона: если кеш живёт слишком долго, вы дольше держите на сайте устаревший HTML, а иногда и старые ссылки на удалённые материалы.

Для сайтов с активным редактированием лучше:

• делать TTL короче на страницах, которые часто меняются;
• настраивать автоматический purge после публикации и обновления;
• не кешировать персонализированные страницы;
• проверять, не дублирует ли серверный кеш функции плагина;
• после каждого изменения конфигурации тестировать хотя бы главную, одну запись и архив рубрики.

Если вам нужен более широкий контроль над техническими дублями, очисткой и SEO-настройками, иногда удобнее вынести часть задач в специализированный плагин вроде Clearfy Pro, но только если он реально закрывает ваши сценарии и не конфликтует с уже настроенным серверным кешем.

Короткий чек-лист перед запуском

• Поняли, какой слой кеширует HTML.
• Проверили заголовки через curl -I.
• Сократили TTL там, где это действительно нужно.
• Настроили purge после обновления контента.
• Исключили служебные и персональные URL.
• Проверили результат в браузере, инкогнито и по заголовкам ответа.

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