Как закрыть от индексации старые версии CSS и JS файлов в WordPress без поломки кэша

Старые версии CSS и JS-файлов в WordPress обычно всплывают не сами по себе: их оставляет тема, плагин оптимизации, CDN или ручная сборка ассетов. Проблема в том, что такие URL часто выглядят как полноценные страницы для робота, а на деле ведут на устаревшие ресурсы с параметрами версионирования, хешами или копиями после деплоя. В результате в индексе копятся мусорные адреса, а в отчетах по сканированию растет количество бесполезных запросов.

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

Не каждый URL с .css или .js нужно трогать. Если файл отдается как статический ресурс и не попадает в индекс, вмешиваться не надо. Но если в Google Search Console или логах вы видите запросы к старым версиям ассетов, а в выдаче встречаются URL с параметрами вроде ?ver=1.2.3, ?v=20240901 или хешами сборки, это уже сигнал.

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

Диагностика: откуда берутся дубли

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

Проверьте, как именно формируется URL

Откройте исходный код страницы и найдите подключения стилей и скриптов. Если видите что-то вроде /wp-content/themes/site/assets/app.css?ver=1.4.8, это нормальная схема версионирования. Если же в индексе есть отдельные URL на старые файлы, значит они доступны напрямую и поисковик их нашел.

<link rel='stylesheet' id='theme-app-css' href='https://example.com/wp-content/themes/site/assets/app.css?ver=1.4.8' media='all' />
<script src='https://example.com/wp-content/themes/site/assets/app.js?ver=1.4.8' id='theme-app-js'></script>

Дальше проверьте серверную отдачу. Если старый файл возвращает 200 OK, он потенциально индексируемый. Если отдает 404 или 410, это уже лучше: робот быстрее выкинет его из обхода.

Посмотрите логи и отчет по страницам

В логах веб-сервера часто видно, что бот ходит по старым ассетам после релиза. Если у вас подключен CDN, проверьте и его логи: иногда файл удалили на origin, но кэш CDN продолжает отдавать старую копию.

• проверьте ответы 200/301/404/410 для старых URL;
• сравните URL в индексе и в текущем HTML страницы;
• посмотрите, не генерирует ли плагин оптимизации отдельные файлы с хешами;
• убедитесь, что старые ассеты не лежат в открытой папке без ограничений.

Что делать: рабочая схема без лишнего риска

Задача не в том, чтобы закрыть все CSS и JS от роботов. Нужно убрать из индекса именно устаревшие версии и при этом не сломать загрузку сайта. Для этого есть три подхода: удалить источник дублей, отдать правильный статус и, если нужно, добавить технический запрет на обход.

Шаг 1. Удалите старые версии, если они больше не нужны

Если файл остался после обновления темы или сборки, лучше удалить его физически. Для неиспользуемых ассетов это самый чистый вариант. После удаления проверьте, что сервер отдает 404 Not Found или, если вы намеренно убираете ресурс навсегда, 410 Gone.

# пример для Nginx: отдать 410 для конкретного старого файла
location = /wp-content/themes/site/assets/old-app.css {
    return 410;
}

location = /wp-content/themes/site/assets/old-app.js {
    return 410;
}

Если у вас Apache, аналогичное поведение можно сделать через Redirect gone в .htaccess, но точечно и без массовых правил, которые заденут рабочие файлы.

Шаг 2. Закройте каталог с архивом версий, если он реально мусорный

Иногда старые сборки лежат в отдельной папке вроде /assets/builds/ или /cache/. Если эта директория не нужна для публичного доступа, ее можно запретить для обхода в robots.txt. Это не замена удалению файлов, но полезный дополнительный барьер.

User-agent: *
Disallow: /wp-content/themes/site/assets/builds/
Disallow: /wp-content/plugins/some-plugin/cache/

Важно: не закрывайте в robots.txt папку, из которой реально грузятся активные стили и скрипты. Иначе робот не увидит ресурсы, а в отчете по мобильной пригодности или рендерингу могут появиться странные проблемы.

Шаг 3. Исправьте генерацию версий в теме или плагине

Если проблема в том, что тема постоянно создает новые URL с параметром версии, проверьте, не подключаются ли файлы вручную без нормального wp_enqueue_style() и wp_enqueue_script(). В WordPress лучше использовать штатную регистрацию ассетов, а версию брать из номера темы или из времени изменения файла только на этапе разработки.

add_action('wp_enqueue_scripts', function () {
    $theme = wp_get_theme();
    $version = $theme->get('Version');

    wp_enqueue_style(
        'site-main',
        get_stylesheet_directory_uri() . '/assets/css/main.css',
        array(),
        $version
    );

    wp_enqueue_script(
        'site-main',
        get_stylesheet_directory_uri() . '/assets/js/main.js',
        array(),
        $version,
        true
    );
});

Такой подход не решает индексацию сам по себе, но делает поведение предсказуемым: у вас один источник версии, а не набор случайных параметров, которые потом трудно чистить.

Если старые URL уже в индексе

Когда мусорные адреса уже попали в индекс, одного robots.txt мало. Если робот не может снова обойти URL, он дольше держит его в базе. Для старых ассетов лучше сначала отдать 410 или 404, а затем дождаться переобхода. Если URL массовые и однотипные, можно дополнительно отправить их на удаление через инструменты для вебмастеров, но это уже вспомогательный шаг, а не основа решения.

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

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

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

• старый URL возвращает 404 или 410, а не 200;
• в исходном коде страницы больше нет ссылок на устаревшие версии;
• в логах уменьшается число запросов к старым ассетам;
• в Search Console снижается количество найденных, но не проиндексированных технических URL;
• новые CSS и JS подключаются с ожидаемой версией и без дублирующих путей.

Проверить ответ сервера можно через curl:

curl -I https://example.com/wp-content/themes/site/assets/old-app.css
curl -I https://example.com/wp-content/themes/site/assets/old-app.js

Если видите 410 Gone, значит старый адрес закрыт корректно. Если 200 OK — файл все еще доступен и может продолжать попадать в обход.

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

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

Закрыли весь каталог с активными файлами

Это самая неприятная ошибка. В robots.txt запретили папку, из которой реально грузится фронтенд, и получили проблемы с рендерингом. Исправление простое: оставьте открытыми рабочие ассеты, а закрывайте только архивы, бэкапы и папки сборок.

Удалили файл, но не убрали ссылку из темы

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

Поставили редирект на главную

Это плохая практика для устаревших ассетов. Поисковик получает неочевидный сигнал, а пользователь — лишний HTML вместо ожидаемого CSS или JS. Для неактуального файла лучше 404 или 410, а не редирект на страницу сайта.

Оставили кэш CDN с прежней версией

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

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

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

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

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

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