Кэш в WordPress: почему после правок вы видите старую страницу, а робот — новую

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

Между браузером и файлом шаблона стоит от трёх до шести независимых хранилищ, и каждое имеет право отдать копию вместо того, чтобы спросить исходник. Ниже — из чего состоит эта цепочка, как за пять минут определить, какое звено держит старое, почему проверка адреса с вопросительным знаком врёт и что сбрасывать после каждого типа правок. В SEO с 2005 года, и жалоба «правки не применяются» стабильно входит в тройку самых частых после переделки сайта.

Пять слоёв кэша, и правка теряется в любом из них

Запрос к странице проходит длинную дорогу, и на каждом отрезке кто-то может подсунуть сохранённую копию. Порядок от вас к серверу такой.

• Кэш браузера. Хранит CSS, скрипты, картинки и иногда сам HTML. Управляется заголовками Cache-Control, Expires, ETag и Last-Modified. Если статике выставлен год жизни, браузер даже не пойдёт на сервер спрашивать — просто возьмёт файл с диска.
• Кэш CDN или прокси. Если сайт подключён к сети доставки контента, копия страницы лежит в узле ближайшего к посетителю города. Узлов десятки, и обновляются они не одновременно.
• Кэш веб-сервера. На связке nginx + Apache это чаще всего fastcgi_cache или proxy_cache. Он отдаёт готовый HTML, вообще не запуская PHP. Самый быстрый и самый коварный слой: плагин внутри WordPress о нём не знает и очистить его кнопкой из админки не может.
• Кэш плагина. WP Super Cache, W3 Total Cache, LiteSpeed Cache, WP Rocket и подобные складывают готовые HTML-файлы в wp-content/cache и отдают их вместо генерации страницы. Сюда же относится склейка и минификация CSS и JS, которая живёт своей жизнью и сбрасывается отдельной кнопкой.
• Объектный кэш и кэш байт-кода. Redis или Memcached хранят результаты запросов к базе, а OPcache на уровне PHP держит скомпилированный код файлов темы. Второй — типичная причина того, что правка в functions.php не действует до перезапуска процессов PHP.

Важная деталь: слои не согласованы между собой. Кнопка «Очистить кэш» в плагине очищает только то, что создал плагин. Она не трогает ни nginx, ни CDN, ни браузер посетителя, ни OPcache. Отсюда и берётся ощущение, что сайт живёт своей жизнью.

Почему адрес с параметром создаёт иллюзию, что правка приехала

Стандартный приём при проверке: открыть страницу с добавкой вида ?123 или ?test=1. Страница действительно показывает свежую версию, все выдыхают и закрывают вопрос. Проблема в том, что этой проверкой вы не проверили ничего.

Полностраничный кэш почти всегда настроен на точное совпадение адреса. Ключом хранения служит строка запроса целиком. Адрес /uslugi/ и адрес /uslugi/?123 — для кэша два разных объекта. Первого в хранилище нет, значит, страница собирается заново из PHP и базы, и вы видите правку. Второй лежит в хранилище со вчерашнего дня, и обычный посетитель, пришедший из поиска по чистому адресу, продолжает получать старьё.

То же самое делает вход в админку. Плагины кэширования по умолчанию не кэшируют страницы для авторизованных пользователей — они смотрят на куку wordpress_logged_in_ и отдают им живую генерацию. Владелец сайта почти всегда залогинен, поэтому он видит актуальную версию всегда, а посетитель — версию недельной давности. Ситуация зеркальна той, с которой начинается статья, и встречается ничуть не реже.

Правило простое: проверять только по чистому адресу, без параметров, в приватном окне браузера или в браузере, где вы не авторизованы. Всё остальное — самообман. Я на этом обжигался лично: правишь PHP, проверяешь с параметром, радуешься, а через сутки выясняется, что посетители полторы недели видели прежний текст.

Как определить, какой именно слой отдаёт старое

Диагностика занимает пять минут и не требует доступа к серверу. Смотреть надо на заголовки ответа — их показывает вкладка «Сеть» в инструментах разработчика браузера или консольная команда с ключом для вывода только заголовков.

Слой	Признак в заголовках или поведении	Чем сбрасывается
Браузер	Запрос вообще не уходит на сервер, во вкладке «Сеть» стоит пометка о взятии из памяти или диска; либо ответ 304	Жёсткая перезагрузка, приватное окно, смена версии файла в адресе статики
CDN или прокси	Заголовки вида CF-Cache-Status: HIT, X-Cache: HIT, ненулевой Age	Сброс кэша в панели сервиса, точечно по адресу или целиком
Веб-сервер	Собственный заголовок статуса кэша от nginx; страница обновляется только после перезапуска или очистки каталога кэша	Очистка каталога кэша на сервере, перезагрузка nginx
Плагин кэширования	В конце исходного кода страницы комментарий с отметкой о выдаче из кэша и временем создания копии	Кнопка полной очистки в плагине плюс очистка склеенных CSS и JS
Объектный кэш	HTML свежий, но старые данные в меню, счётчиках, выборках записей	Сброс Redis или Memcached, отключение постоянного объектного кэша на время правок
OPcache	Правка в файле темы или плагина не действует вообще, даже при отключённых плагинах кэша	Перезапуск процессов PHP или сброс OPcache в панели хостинга

Что в это время видит робот

Робот поисковой системы не имеет вашего браузерного кэша, не залогинен в админке и приходит по чистому адресу. Значит, ему достаётся ровно то, что лежит в кэше плагина, сервера и CDN. Из этого следуют два практических вывода.

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

Второй: обратная ситуация. Кэш сбросили, робот пришёл, забрал новое, а вы этого не видите из-за своего браузера и продолжаете считать, что правка не применилась. Проверять надо не глазами, а инструментом: в Яндекс.Вебмастере есть раздел проверки ответа сервера, который показывает код ответа и полученный HTML именно так, как его видит робот. Это единственная честная проверка — она обходит и ваш браузер, и вашу авторизацию.

Ускорить попадание правки в индекс помогает переобход по запросу и протокол мгновенного уведомления. Как подключить второй, я разбирал в материале Как установить indexnow на WordPress. Тонкость, о которой забывают: уведомление отправляется по факту изменения даты правки записи. Если вы поменяли содержимое напрямую в базе, не тронув дату, никакого уведомления не уйдёт и робот придёт в свой обычный срок. Если новые материалы вообще плохо доходят до индекса, причина обычно глубже кэша — об этом отдельный разбор Почему Яндекс не индексирует новые статьи на WordPress — и что с этим делать за один вечер.

Как проверять изменения честно

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

1. Сбросить кэш плагина полностью, а не только для одной записи. Отдельно нажать очистку склеенных CSS и JS, если минификация включена.
2. Сбросить кэш CDN, если он есть. Точечная очистка по адресу дешевле полной, но при правке шаблона нужна именно полная — шаблон затрагивает все страницы.
3. Открыть страницу по чистому адресу без параметров в приватном окне. Не в том браузере, где вы авторизованы.
4. Если старое — открыть тот же адрес через мобильный интернет с телефона. Это отсекает кэш вашего провайдера и локальной сети.
5. Если и там старое — смотреть заголовки ответа по таблице выше и определять слой.
6. Проверить страницу инструментом Вебмастера: код ответа 200, в теле HTML есть новый фрагмент.
7. Только после этого отправлять страницу на переобход. Отправка страницы, которая отдаёт старое из кэша, закрепит старое в индексе.

Отдельный пункт для правок в PHP: если файл изменён, а поведение прежнее при полностью выключенных плагинах кэша, дело в OPcache. Сброс делается перезапуском обработчика PHP из панели хостинга. Само по себе это не поломка, а штатное поведение: OPcache хранит скомпилированный код и по умолчанию проверяет дату файла не при каждом запросе.

Когда полностраничный кэш ломает формы и корзину

Полностраничный кэш отдаёт всем один и тот же готовый HTML. Пока страница статична, это идеально. Как только на ней появляется что-то персональное, начинаются поломки, причём тихие: ошибка не выводится, просто перестаёт работать.

• Формы обратной связи. WordPress защищает отправку одноразовым ключом, который живёт ограниченное время и привязан к сессии. Ключ попадает в HTML. Если HTML пролежал в кэше дольше срока жизни ключа, форма при отправке получает отказ проверки. Внешне это выглядит как «кнопка не работает» или вечный индикатор загрузки. На одном из моих проектов включение полностраничного кэша разом убило все заявки, и заметили это только по провалу в статистике обращений.
• Корзина интернет-магазина. Кэш запоминает страницу с пустой корзиной и показывает её всем. Товар добавляется, счётчик не меняется. В WooCommerce часть данных подгружается отдельным запросом, и корректные плагины кэширования это учитывают, но только если включён соответствующий режим.
• Всё, что зависит от куки. Выбранный город, валюта, режим отображения, согласие на обработку данных, включённый режим повышенной доступности. Если кэш не различает посетителей по куке, один посетитель увидит выбор другого.

Решение не в отказе от кэша, а в правильных исключениях. Три уровня: исключить адреса динамических разделов, исключить посетителей с определёнными куками, исключить конкретные страницы через служебную константу отключения кэша. Настройки называются в каждом плагине по-своему, но идея одинаковая. Проверка после настройки обязательна и делается руками: отправить заявку с чистого браузера, положить товар в корзину, дойти до оформления. Автоматически это не тестируется.

Что сбрасывать после правок шаблона

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

Что поправили	Что обязательно сбросить	Что можно не трогать
Текст или картинку в одной записи	Кэш этой записи, кэш главной и раздела, если там выводится анонс	CSS и JS, CDN, объектный кэш
Файл стилей темы	Склеенные CSS, версию файла в адресе, кэш CDN для статики	Кэш HTML отдельных записей, если версия файла изменилась
Шаблон шапки, подвала или сайдбара	Весь кэш HTML целиком, CDN целиком	OPcache, если правился только HTML в шаблоне
Код в functions.php или плагине	OPcache через перезапуск PHP, затем весь кэш HTML	Кэш статики
Меню, виджеты, настройки темы	Объектный кэш и кэш HTML целиком	CDN для статики
Логотип, иконку, шрифт	Кэш CDN по адресу файла, версию в адресе	Кэш HTML, если имя файла изменилось

Отдельно про версию статики. Надёжный способ доставить новый CSS всем посетителям — изменить адрес файла, а не просить браузер забыть старый. В WordPress это делается через параметр версии при подключении файла: если подставлять туда время последнего изменения файла, адрес меняется при каждой правке сам. Общая логика ускорения через кэширование разобрана в материале Кэширование сайта: как ускорить загрузку и улучшить пользовательский опыт, а набор рабочих приёмов для WordPress — в статье Как увеличить скорость загрузки сайта Wordress.

Когда кэш лучше не включать

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

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

В этих случаях выигрыш дают другие меры: сжатие, современный формат картинок, отложенная загрузка неглавных скриптов, объектный кэш, актуальная версия PHP. Они не трогают HTML и не ломают динамику. И главное: кэш не лечит медленный сайт, он его прячет. Первый же посетитель, попавший на непрогретый адрес, получает исходную скорость. Робот, обходящий тысячи адресов подряд, попадает на непрогретые страницы постоянно — именно поэтому в отчётах о скорости в Вебмастере цифры хуже, чем в вашем браузере. Что реально измеряется и что из этого влияет на ранжирование, я разбирал в статье Медленный сайт = низкие позиции: как скорость загрузки влияет на ранжирование в Яндексе.

Частые вопросы

Почему после сброса кэша сайт стал медленнее? Так и должно быть первые часы. Хранилище пустое, каждая страница собирается заново из базы. Скорость возвращается по мере того, как посетители и робот обходят адреса. На большом сайте помогает предварительный прогрев по карте сайта — такая функция есть в большинстве плагинов кэширования.

Сколько хранить кэш страницы? Для сайта услуг разумный срок жизни — сутки и больше, для блога с ежедневными публикациями — несколько часов. Точное число менее важно, чем корректный сброс при публикации: почти все плагины умеют чистить главную и связанные разделы автоматически при сохранении записи.

Обязательно ли сбрасывать кэш браузера посетителям? Вы физически не можете это сделать. Единственный работающий подход — менять адрес файла при изменении содержимого. Поэтому для CSS и JS ставится версия по времени правки, а картинки при замене загружаются под новым именем, а не поверх старого файла.

Может ли кэш стать причиной дублей в индексе? Косвенно да. Если кэш сохраняет отдельные копии для адресов с рекламными метками и эти адреса открыты для обхода, робот получает набор одинаковых страниц по разным адресам. Сам кэш дублей не создаёт, но помогает им закрепиться. Механика подробно разобрана в материале Дубли, которые вы не видите: пагинация, фильтры, UTM и сессионные параметры.

Сколько плагинов кэширования можно ставить? Ровно один. Два плагина складывают копии в разные каталоги и перехватывают вывод по очереди, из-за чего сброс одного не влияет на второй, а страница может отдаваться из хранилища, о котором вы забыли. Симптом узнаваемый: чистите всё подряд, а старое возвращается.

Если правки на сайте регулярно теряются, а причину каждый раз ищете вслепую, разбор технической части снимает вопрос целиком: видно, какие слои кэша включены, что и когда сбрасывается, где исключения настроены неверно. Это входит в доработку сайта вместе с настройкой скорости. Общий подход к работе и условия — на странице SEO-продвижение сайтов под Яндекс: продвижение веду лично, вы общаетесь со мной напрямую, а не с менеджером.

Коротко

• Между вашим браузером и файлом шаблона стоит до шести независимых хранилищ, и кнопка очистки в плагине сбрасывает только одно из них.
• Адрес с вопросительным знаком и вход в админку обходят полностраничный кэш — проверка через них показывает картину, которой не видит ни один посетитель.
• Честная проверка: чистый адрес, приватное окно, затем инструмент проверки ответа сервера в Вебмастере.
• Робот видит то, что лежит в кэше сервера и CDN, поэтому отправлять на переобход страницу до сброса кэша бессмысленно и вредно.
• Полностраничный кэш ломает формы, корзину и всё, что зависит от куки; лечится списком исключений, а не отказом от кэша.
• Правка PHP, не дающая эффекта при выключенных плагинах кэша, почти всегда упирается в OPcache и лечится перезапуском обработчика PHP.