Настройка TTL кэша в WordPress для отдельных страниц

Автор: Марина Тихонова | Опубликовано: 28.09.2026

Одна и та же политика кеша для всего сайта редко работает хорошо. Главная и архивы могут спокойно жить с длинным TTL, а страницы входа, корзины, личного кабинета, поиска или формы обратной связи должны обновляться сразу. Если не разделить эти сценарии, появляются жалобы на «старый контент», некорректные счетчики, устаревшие блоки и странные баги после публикации.

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

Когда проблема именно в TTL, а не в плагине

Сначала стоит понять, что вы лечите. Если страница обновляется только после ручной очистки кеша, это не всегда баг темы или плагина. Часто причина в слишком длинном TTL на уровне сервера, CDN или плагина кеширования.

Типичные симптомы

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

Если у вас уже есть отдельные правила в плагине кеша или на сервере, сначала проверьте их. Иногда TTL задается сразу в трех местах: в плагине, в Nginx/Apache и на CDN. Тогда вы меняете одно значение, а фактически срабатывает другое.

Какие страницы в WordPress обычно требуют разный TTL

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

Тип страницы	Обычно подходит	Комментарий
Главная, архивы, рубрики	Длинный TTL	Контент меняется не каждую минуту, кеш помогает разгрузить сервер
Записи и страницы с редкими правками	Средний TTL	Если часто правите текст, лучше уменьшить время жизни кеша
Поиск, корзина, личный кабинет, формы	Без кеша или короткий TTL	Там почти всегда есть пользовательский контекст
RSS, REST API, служебные endpoints	Отдельное правило	Нельзя бездумно кешировать все подряд

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

Диагностика: где именно задается кеш

Перед правками проверьте, кто реально управляет заголовками ответа. Это можно сделать через DevTools, curl или панель плагина кеша.

Проверка заголовков ответа

Для быстрой диагностики удобно посмотреть HTTP-заголовки:

curl -I https://example.com/

Ищите признаки кеширования: Cache-Control, Expires, Age, а также заголовки плагина или CDN. Если видите, что страница отдается с большим max-age, значит TTL задается на уровне сервера или внешнего кеша.

Если используете плагин кеширования, проверьте его настройки для:

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

Пошаговое решение: разный TTL для отдельных URL

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

Вариант 1. Настроить исключения в плагине кеша

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

Что нужно сделать:

Найти раздел с исключениями URL или правилами кеширования.
Добавить страницы, которые не должны кешироваться: /cart/, /checkout/, /my-account/, /search/ и аналогичные.
Для публичных страниц оставить кеш включенным, но проверить TTL.
Очистить кеш после изменения правил.

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

Вариант 2. Управлять TTL через `functions.php`

Когда нужно точечно менять заголовки для отдельных страниц, можно добавить фильтр в тему или в небольшой mu-plugin. Это полезно, если плагин кеша не дает нужной гибкости.

<?php
add_action('send_headers', function () {
    if (is_admin() || wp_doing_ajax()) {
        return;
    }

    // Страницы, которые не должны долго жить в кеше.
    if (is_page(array('cart', 'checkout', 'my-account')) || is_search()) {
        nocache_headers();
        header('Cache-Control: no-store, no-cache, must-revalidate, max-age=0');
        return;
    }

    // Публичные страницы можно кешировать дольше.
    if (is_front_page() || is_home() || is_category() || is_tag()) {
        header('Cache-Control: public, max-age=3600');
    }
});

Этот пример не заменяет серверный кеш, но помогает задать понятную политику для страниц, которые WordPress отдает сам. Если у вас уже есть заголовки от Nginx, Apache или CDN, они могут перекрыть этот код.

Вариант 3. Настроить правила на сервере

Если кешируется через Nginx или Apache, TTL лучше задавать там. Это надежнее и обычно быстрее, чем управлять всем из WordPress.

Пример для Nginx, где отдельные страницы не кешируются, а публичные получают длинный TTL:

location ~* ^/(cart|checkout|my-account)/ {
    add_header Cache-Control "no-store, no-cache, must-revalidate, max-age=0";
    expires off;
}

location / {
    expires 1h;
    add_header Cache-Control "public, max-age=3600";
}

Конфиг нужно адаптировать под вашу схему. Если у вас уже есть fastcgi_cache или proxy_cache, не дублируйте правила хаотично: сначала проверьте, где именно создается кеш, и только потом добавляйте исключения.

Как проверить, что TTL работает правильно

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

Откройте страницу в режиме инкогнито и проверьте заголовки ответа.
Сравните публичную страницу и исключенную страницу: у них должны быть разные Cache-Control.
Обновите запись и проверьте, что новая версия появляется без ручной очистки там, где это ожидается.
Проверьте, что страницы с пользовательским контекстом не отдают чужие данные.
Если есть CDN, проверьте заголовки и там, а не только на origin-сервере.

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

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

Один TTL для всех страниц

Это самая частая ошибка. В результате кешируются страницы, которые должны быть динамическими. Исправление простое: выделите исключения для пользовательских и служебных URL.

Правило в WordPress конфликтует с сервером

Если в коде вы ставите no-store, а Nginx отдает max-age=86400, побеждает серверная настройка. Нужно оставить один источник истины или хотя бы понять приоритеты.

Кеш не очищается после публикации

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

Слишком агрессивное кеширование AJAX и REST

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

Забыли про CDN

Даже если на сервере все настроено правильно, CDN может держать старую версию дольше. После изменения TTL проверьте настройки edge cache и purge-правила.

Безопасность и производительность: что не стоит делать

Не отключайте кеш целиком ради одной проблемной страницы. Это бьет по производительности сильнее, чем кажется. Лучше исключить конкретный URL или шаблон.

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

Если правите кодом, не вставляйте его в активную тему без необходимости. Для точечных правил удобнее mu-plugin: он не зависит от смены темы и проще контролируется при деплое.

<?php
/**
 * Plugin Name: Cache TTL Rules
 */
add_action('send_headers', function () {
    if (is_page('checkout')) {
        nocache_headers();
    }
});

Такой подход проще поддерживать, чем править functions.php после каждого обновления темы.

Если нужен быстрый путь без ручного кода

Когда задача сводится не к тонкой настройке серверных заголовков, а к чистке сайта и контролю дублей, иногда удобнее закрыть часть технических проблем через плагин. Например, Clearfy Pro помогает с SEO- и техническими настройками WordPress, когда нужно убрать лишнее и не собирать все правила вручную: https://wpshop.ru/plugins/clearfy.

Короткий чек-лист перед выкладкой

Поняли, где задается кеш: плагин, сервер или CDN.
Разделили публичные и динамические страницы.
Добавили исключения для корзины, поиска, кабинета и форм.
Проверили заголовки Cache-Control и Age.
Убедились, что после обновления контент не застревает в кеше.
Проверили, что CDN не переопределяет локальные правила.

Если после всех правок страница все еще живет слишком долго, ищите не в WordPress, а в цепочке кеширования выше: reverse proxy, CDN, хостинг-панель или отдельный модуль сервера. Именно там чаще всего и сидит причина, когда WordPress уже настроен правильно, а поведение не меняется.

⭐⭐⭐⭐⭐