Как закрыть от индексации старые версии файлов в WordPress

Старые версии файлов в WordPress обычно всплывают после обновления темы, смены сборки фронтенда или переноса сайта. В индексе остаются URL вида /wp-content/themes/..., /wp-content/uploads/... или файлы с суффиксами вроде .min.css, .js, -old, -v2. Для пользователя это незаметно, а для сайта — лишние URL в поиске, дубли и иногда утечки технических деталей.

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

Когда проблема уже есть

Обычно сигналов несколько:

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

Что проверить в первую очередь

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

grep -R "old-file.css\|v2.js\|/uploads/" wp-content/themes wp-content/plugins

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

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

Для старых версий файлов есть три нормальных сценария. Выбор зависит от того, файл еще нужен или уже нет.

1. Удалите реально лишние файлы

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

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

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

2. Для замененных файлов используйте 301 только там, где это имеет смысл

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

Redirect 301 /wp-content/themes/old-theme/style.css /wp-content/themes/new-theme/style.css

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

3. Закройте от индексации технические файлы через X-Robots-Tag

Когда файл должен оставаться доступным, но не нужен в поиске, используйте заголовок X-Robots-Tag. Это особенно удобно для PDF, архивов, старых медиа-версий и служебных файлов, которые нельзя просто удалить.

<FilesMatch "\.(pdf|zip|css|js)$">
  Header set X-Robots-Tag "noindex, nofollow"
</FilesMatch>

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

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

Удалить файл с сервера недостаточно, если URL уже попал в поиск. Тогда нужно дать поисковику понятный сигнал: либо 404/410, либо 301, либо noindex через заголовок. После этого URL должен исчезать постепенно, без ручной магии.

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

wp search-replace 'https://old-site.ru/wp-content/uploads' 'https://new-site.ru/wp-content/uploads' --all-tables

Команда выше безопасна только после бэкапа и на тестовой копии, если вы не уверены в объеме замены. Она не удаляет файлы, а исправляет ссылки в базе. Это часто решает проблему старых URL в контенте и настройках темы.

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

Проверять нужно не только в браузере. Важно увидеть, как отвечает сервер и как URL выглядит для робота.

• откройте старый URL через curl -I и проверьте код ответа;
• посмотрите, нет ли редиректа на нерелевантную страницу;
• проверьте заголовок X-Robots-Tag, если вы его настраивали;
• в Search Console отправьте URL на повторную проверку после удаления или редиректа;
• убедитесь, что старый адрес больше не попадает в sitemap и внутренние ссылки.

curl -I https://example.com/wp-content/uploads/2023/old-image.jpg

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

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

Закрывают все статические файлы в robots.txt

Это грубая ошибка. Если закрыть весь /wp-content/, можно сломать обход важных ресурсов. Поисковику нужны некоторые CSS и JS, чтобы корректно оценивать страницу. Закрывайте только конкретные проблемные пути, а не весь каталог.

Ставят noindex на файл, который уже отдается как attachment-страница

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

Оставляют старый файл на сервере и одновременно ставят редирект

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

Используют 302 вместо 301 без причины

Временный редирект для старого файла обычно не нужен. Если замена постоянная, используйте 301. Иначе поисковик может дольше держать старый URL в индексе и не передавать сигналы так, как вы ожидаете.

Чек-лист перед публикацией изменений

• старые файлы удалены или перенаправлены осознанно;
• нет жестких ссылок на старые пути в теме, плагинах и контенте;
• сервер отдает правильный код ответа для каждого URL;
• сайт не закрывает лишнее в robots.txt;
• старые адреса не попадают в sitemap;
• кэш и CDN очищены после правок;
• в Search Console отправлены на переобход только действительно проблемные URL.

Что можно автоматизировать в WordPress

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

add_action('admin_init', function () {
    if (!current_user_can('manage_options')) {
        return;
    }

    $old_path = 'https://old-site.ru/wp-content/uploads';
    $new_path = 'https://new-site.ru/wp-content/uploads';

    global $wpdb;
    $count = $wpdb->get_var($wpdb->prepare(
        "SELECT COUNT(*) FROM {$wpdb->posts} WHERE post_content LIKE %s",
        '%' . $wpdb->esc_like($old_path) . '%'
    ));

    if ((int) $count > 0) {
        error_log('Found old uploads URLs in post content: ' . $count);
    }
});

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

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

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

Если вы используете плагин для технической чистки сайта, проверьте, умеет ли он удалять дубли и служебный мусор без затрагивания нужных ресурсов. В экосистеме WPShop для таких задач уместно смотреть в сторону Clearfy Pro: он помогает с частью SEO- и технических настроек, но все равно не отменяет ручную проверку URL и ответов сервера.

Главный ориентир простой: если файл не нужен — удаляйте; если нужен, но не должен индексироваться — закрывайте точечно; если это замена старого ресурса — делайте понятный редирект. Любая другая схема обычно только откладывает проблему.