Если после обновления темы или плагина на сайте «поехала» верстка, а в браузере продолжают грузиться старые стили и скрипты, проблема обычно не в самом обновлении. Чаще всего виноваты кеш браузера, серверный кеш, CDN или неверная версия подключаемых файлов. В WordPress это особенно заметно, когда CSS и JS подключаются без версии файла или с одинаковым параметром ?ver=.
Ниже — рабочая схема, как диагностировать источник старого кеша, быстро сбросить его и настроить подключение так, чтобы после следующего обновления не ловить ту же проблему снова.
Как понять, где именно застрял старый CSS или JS
Сначала нужно определить, кто отдает устаревший файл: сам WordPress, серверный кеш, CDN или браузер. Без этого легко «лечить» не тот слой и тратить время на очистку всего подряд.
Что проверить в DevTools
Откройте страницу в Chrome/Firefox, включите инструменты разработчика и посмотрите вкладку Network. Для CSS и JS важны три вещи:
- статус ответа:
200,304или что-то из кеша; - заголовки
cache-control,etag,last-modified; - реальный URL файла, особенно параметр версии
?ver=.
Если файл подключается как /wp-content/themes/your-theme/assets/app.css?ver=1.0.0, а вы изменили содержимое, но не поменяли версию, браузер и промежуточные кеши могут продолжать считать его актуальным.
Признаки серверного кеша
Если после жесткой перезагрузки страницы проблема остается, а в Network видно, что HTML или статические файлы отдаются очень быстро и без обращения к PHP, вероятно, срабатывает кеш на уровне плагина, nginx, LiteSpeed, Cloudflare или другого CDN. В этом случае чистка только в браузере не поможет.
Пошаговое решение: от быстрой очистки до правильной версии файлов
Начинайте с самого простого и двигайтесь к источнику проблемы. Такой порядок экономит время и помогает не сломать рабочий кеш без необходимости.
1. Очистите кеш в браузере и проверьте в приватном окне
Это базовая проверка. Иногда проблема видна только у вас из-за локального кеша. Откройте страницу в режиме инкогнито или в другом браузере. Если там все выглядит нормально, серверный кеш, скорее всего, ни при чем.
2. Сбросьте кеш плагина и сервера
Если используется плагин кеширования, очистите его кеш через админку. Если есть доступ к серверу, проверьте и серверный слой: nginx fastcgi cache, LiteSpeed cache, Varnish или кеш на стороне хостинга. У разных провайдеров это делается по-разному, но логика одна: удалить старые HTML- и asset-копии, чтобы сайт пересобрал их заново.
3. Обновите версию подключаемых CSS и JS
Самый надежный способ — не надеяться на ручную очистку, а менять версию файла при каждом изменении. В WordPress это делается через wp_enqueue_style() и wp_enqueue_script().
<?php
add_action('wp_enqueue_scripts', function () {
$theme_version = wp_get_theme()->get('Version');
wp_enqueue_style(
'theme-main',
get_stylesheet_directory_uri() . '/assets/css/main.css',
array(),
$theme_version
);
wp_enqueue_script(
'theme-main',
get_stylesheet_directory_uri() . '/assets/js/main.js',
array('jquery'),
$theme_version,
true
);
});Если вы меняете файлы в дочерней теме, версия темы — не всегда лучший маркер. В таком случае удобнее использовать версию файла или время его изменения на этапе разработки.
<?php
add_action('wp_enqueue_scripts', function () {
$css_file = get_stylesheet_directory() . '/assets/css/main.css';
$js_file = get_stylesheet_directory() . '/assets/js/main.js';
wp_enqueue_style(
'theme-main',
get_stylesheet_directory_uri() . '/assets/css/main.css',
array(),
file_exists($css_file) ? filemtime($css_file) : null
);
wp_enqueue_script(
'theme-main',
get_stylesheet_directory_uri() . '/assets/js/main.js',
array('jquery'),
file_exists($js_file) ? filemtime($js_file) : null,
true
);
});Для разработки это удобно: изменили файл — поменялась версия — браузер запросил свежую копию. В продакшене такой подход тоже работает, но на очень нагруженных сайтах может быть лишней нагрузкой на файловую систему, если проверка идет на каждом запросе. Тогда лучше собирать версию на этапе деплоя.
4. Проверьте CDN и правила кеширования
Если сайт подключен к CDN, убедитесь, что он не держит старую копию файла дольше, чем ваш сервер. Частая ошибка — очистить кеш WordPress, но забыть про CDN. В итоге HTML уже новый, а CSS и JS все еще старые.
Если CDN поддерживает purge по URL, очистите конкретные файлы, а не весь домен. Это быстрее и безопаснее для трафика.
Когда лучше менять подход к кешированию, а не просто чистить его
Если обновления темы или плагинов происходят часто, ручная очистка кеша превращается в постоянную рутину. В таком случае лучше настроить подключение файлов так, чтобы они сами «инвалидировались» при изменении.
| Подход | Когда подходит | Минус |
|---|---|---|
| Ручная очистка кеша | Редкие правки, небольшой сайт | Легко забыть CDN или серверный слой |
filemtime() для assets | Разработка и частые правки | Лишние обращения к файловой системе |
| Версия сборки при деплое | Продакшен, CI/CD, стабильные релизы | Нужен процесс сборки и контроля версий |
Если вы используете плагин оптимизации, проверьте, не объединяет ли он CSS/JS в один файл с собственным кешем. После обновления темы такой плагин тоже нужно очистить. В некоторых случаях проще временно отключить объединение файлов и проверить, исчезла ли проблема.
Чек-лист проверки после внедрения
После очистки кеша и обновления версий файлов не ограничивайтесь визуальной проверкой главной страницы. Ошибка может проявляться только на отдельных шаблонах.
- Откройте проблемную страницу в приватном окне.
- Проверьте, что в URL CSS и JS изменился параметр версии или имя файла.
- Убедитесь, что в Network загружается новый файл, а не
304 Not Modifiedдля старой версии. - Сравните содержимое файла на сервере и то, что отдает браузер.
- Очистите кеш CDN, если он используется.
- Проверьте страницы с разными шаблонами: записи, страницы, архивы, мобильную версию.
Частые ошибки и как их исправить
Очищают только кеш плагина
Если сайт стоит за CDN или серверным кешем, очистка плагина ничего не даст. Нужно пройти весь путь: плагин, сервер, CDN, браузер.
Не меняют версию файла
Файл обновили, а URL остался прежним. Для браузера это тот же ресурс, и он может продолжать использовать старую копию. Решение — версионировать assets через wp_enqueue_style() и wp_enqueue_script().
Используют одинаковую версию для всех релизов
Если в коде жестко прописано 1.0.0 и его не меняют после деплоя, проблема будет возвращаться. Версия должна меняться вместе с изменением файла или сборки.
Смешивают минификацию и отладку
После обновления тема может ломаться не из-за кеша, а из-за старой минифицированной сборки. Для диагностики временно отключите минификацию и объединение файлов, чтобы понять, где именно ошибка.
Практические советы по безопасности и производительности
Не отключайте кеш полностью ради удобства отладки. На рабочем сайте это почти всегда ухудшает скорость загрузки. Лучше держать отдельный процесс для разработки и отдельный — для продакшена.
Если у вас есть доступ к деплою, добавьте шаг очистки кеша после выкладки новой версии темы или плагина. Это надежнее, чем надеяться на ручную память редактора или администратора.
Для сайтов, где часто меняются стили и скрипты, удобно использовать автоматическую версию файлов на этапе сборки. Это снижает риск того, что посетители увидят старую верстку после обновления.
Если нужна более широкая чистка технического мусора и дублей в WordPress, можно посмотреть в сторону инструментов вроде Clearfy Pro, но сам принцип остается тем же: сначала понять, какой слой кеширует, потом чистить именно его. Ссылка: Clearfy Pro.
Как проверить, что решение сработало
Финальная проверка должна быть технической, а не только визуальной. Откройте страницу в приватном окне, посмотрите Network и убедитесь, что:
- подключается актуальный CSS/JS;
- в URL есть новая версия или новое имя файла;
- старый файл не отдается из кеша CDN;
- верстка совпадает с ожидаемой после обновления;
- ошибка не повторяется на других шаблонах сайта.
Если после этого проблема исчезла, значит, вы нашли правильный слой кеширования. Если нет — проверьте, не генерирует ли тема инлайн-стили или динамический CSS отдельно от основных файлов. Именно там иногда и прячется старый код.