Коротко. Чаще всего причина — кэш работает сразу на нескольких уровнях (браузер, плагин, хостинг, CDN), а очищен только один из них: например, плагин кэша сбросил свою копию, но CDN ещё отдаёт старую версию по собственному сроку хранения (обычно от нескольких часов до суток). Второй частый случай — слишком длинный Cache-Control на HTML-страницах (годовой срок, скопированный по ошибке с настроек для картинок). Решение — чистить кэш на каждом уровне отдельно и держать короткий или нулевой срок кэша именно для HTML.
Почему это вообще происходит: кэш — это несколько независимых копий
Когда на сайте настроено кэширование, страница может физически существовать в нескольких местах одновременно: в памяти браузера конкретного посетителя, в кэше плагина на сервере, в кэше самого хостинга (например, LiteSpeed или Varnish), и в кэше CDN, если он подключён. Обновление контента на сайте меняет только исходный файл или запись в базе данных — все остальные копии продолжают отдаваться до истечения своего срока или до принудительной очистки. Проблема «посетитель видит старую версию» почти всегда означает, что обновилась не вся цепочка копий, а только часть.
Ошибка 1: слишком длинный кэш на HTML
Самая частая техническая причина — на HTML-страницы по ошибке распространяется тот же долгий срок кэша, что задуман для статики. Если картинкам и CSS правильно назначить max-age=31536000 (год), а конфигурация сервера или плагина применяет то же правило ко всем файлам без разбора типа, HTML-страница будет кэшироваться в браузере посетителя на год — и никакая очистка кэша на сервере эту локальную копию в браузере конкретного человека не тронет. Решение — явно разделить правила: длинный кэш только для файлов с расширениями изображений, шрифтов, версионированных CSS/JS, и короткий (минуты, а не месяцы) или вовсе no-cache — для HTML-документов.
Ошибка 2: очистили кэш плагина, но не CDN
Кэш-плагин на WordPress или другой CMS обычно чистит только собственную копию на сервере — при клике «Очистить кэш» изменения сразу видны при прямом обращении к серверу. Но если перед сервером стоит CDN (Cloudflare и аналоги), у него собственный, независимый кэш с собственным сроком хранения — как правило, от нескольких часов до суток в зависимости от типа файла и настроек. Посетитель, обращаясь к сайту, попадает не на сервер напрямую, а на ближайший узел CDN, который может продолжать отдавать старую версию, даже если плагин на сервере кэш уже сбросил. Решение — при каждом значимом обновлении контента чистить кэш и на уровне CDN отдельно; у большинства провайдеров для этого есть отдельная кнопка «Purge Cache» в панели управления.
Ошибка 3: разные версии для разных посетителей из-за кэша на уровне варианта страницы
Если на сайте есть элементы, зависящие от посетителя (город в шапке, персональная скидка, содержимое корзины, результат A/B-теста), а кэш настроен без учёта этих вариаций, разные посетители по очереди «перезаписывают» кэш друг другом: один зашёл из Москвы, увидел свою версию, она закэшировалась, следующий из другого города увидел кэш москвича вместо своей версии. Это не столько «старая» версия, сколько «чужая». Решение — либо полностью исключать такие страницы из кэша, либо настраивать кэш с учётом вариаций (по cookie, по заголовку или через версию страницы без персонализации, с персонализацией уже на стороне JavaScript после загрузки).
Ошибка 4: старая версия CSS/JS из-за отсутствия версионирования файлов
Если после правок в дизайне или коде имя файла style.css остаётся неизменным, а на файле стоит долгий Cache-Control, браузеры части посетителей продолжат использовать старую, закэшированную версию файла, даже если на сервере лежит новая — потому что с точки зрения браузера ничего не изменилось: тот же URL, тот же файл. Решение — версионирование через параметр в URL (style.css?v=4) или через хэш содержимого файла в имени, что автоматически меняет адрес файла при каждом изменении и заставляет браузер скачать актуальную версию, не трогая при этом остальной, не изменившийся кэш.
Ошибка 5: посетитель видит старую версию из-за собственного кэша браузера
Даже при идеально настроенном сервере часть жалоб «сайт не обновился» приходит от посетителей, у которых браузер агрессивно кэширует именно эту страницу локально — например, если раньше уже был установлен слишком долгий срок кэша, а изменить его задним числом для уже сохранённой у пользователя копии нельзя. Это не ошибка настройки в моменте, а последствие ошибки 1 из прошлого. Единственное решение для уже пострадавших посетителей — попросить обновить страницу с принудительной очисткой кэша (Ctrl+F5 или Cmd+Shift+R), для остальных — впредь не допускать слишком долгого кэша HTML.
Как быстро найти, на каком уровне застряла старая версия
Проверка по шагам: открыть страницу в режиме инкогнито (исключает кэш браузера) — если старая версия видна и там, проблема на сервере или CDN. Затем открыть заголовки ответа во вкладке Network — заголовок age показывает, сколько секунд назад копия была помещена в кэш CDN или прокси, а x-cache или аналогичный заголовок (зависит от провайдера) обычно прямо указывает HIT (отдано из кэша) или MISS (сгенерировано заново). Если age большой и x-cache показывает HIT — проблема в CDN или серверном кэше, и нужно чистить именно этот уровень, а не гадать.
Почему кэш очистили, а на сайте всё равно старая версия?
Скорее всего, очищен не весь кэш, а только один уровень — например, плагин на сервере, тогда как CDN или сам браузер посетителя продолжают отдавать сохранённую ранее копию. Нужно проверить заголовки ответа (age, x-cache) и почистить кэш на каждом уровне отдельно.
Сколько времени обычно занимает, чтобы новая версия страницы дошла до всех посетителей?
Зависит от настроенного срока кэша на каждом уровне: при коротком кэше HTML (минуты) — почти сразу после ручной очистки. При долгом кэше CDN без ручной очистки — до истечения установленного там срока, обычно от нескольких часов до суток.
Можно ли настроить сайт так, чтобы такая проблема вообще не повторялась?
Да: короткий или нулевой Cache-Control для HTML, версионирование файлов CSS/JS вместо кэша по неизменному имени, и автоматическая очистка кэша (включая CDN, если он подключён) при каждой публикации или правке контента — большинство плагинов и CDN-провайдеров это умеют, но не всегда включают по умолчанию.
Опасно ли для SEO, если поисковый робот увидит старую версию страницы из кэша?
Да, если старая версия кэшируется подолгу — робот может проиндексировать устаревший контент или не увидеть свежих правок (новые ссылки, обновлённые метатеги) до следующего обхода. Это одна из причин держать HTML некэшированным дольше нескольких минут, отдельно от статики.
Разные посетители видят разные версии сайта одновременно — это тоже ошибка кэширования?
Обычно да — типичная причина в кэшировании персонализированного контента (город, скидка, содержимое корзины) без учёта этой персонализации в правилах кэша, из-за чего один посетитель может увидеть закэшированную версию, предназначенную для другого.
Разобраться, почему сайт показывает устаревшую версию
Проверим все уровни кэша — от браузера до CDN — и найдём точку, где старая версия застряла.