Как закрыть старые изображения в WordPress и убрать их из индекса без поломки сайта

Автор: Степан Захаров | Опубликовано: 16.09.2026

На WordPress старые изображения часто живут дольше самих записей: файл удалили из медиатеки, а URL уже успел попасть в индекс, в sitemap, в архивы вложений или в внешние ссылки. В итоге в поиске всплывают пустые страницы вложений, дубли картинок и мусорные URL, которые не дают трафика, но создают шум в отчётах.

Задача здесь не в том, чтобы «всё запретить», а в том, чтобы аккуратно разделить три сценария: что нужно оставить доступным, что закрыть от индексации, а что действительно удалить и отдать 410/404. Ниже — рабочая схема без лишней магии.

Когда проблема уже есть: как понять, что в индексе мусорные медиа-страницы

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

Признаки, что нужно разбираться с медиа-URL

в Google Search Console появляются страницы вида /wp-content/uploads/... или /attachment/...;
в индексе есть пустые страницы вложений без текста;
в sitemap попадают URL, которые не нужны пользователю;
после удаления изображения из записи оно всё равно открывается по прямой ссылке;
поиск показывает старые файлы, хотя на сайте они уже не используются.

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

Что закрывать, а что удалять: короткое сравнение подходов

Не все медиа-URL нужно обрабатывать одинаково. Если изображение используется в статье, но сама attachment-страница не нужна, обычно достаточно закрыть именно страницу вложения. Если файл удалён полностью и больше нигде не нужен, тогда уже имеет смысл отдавать 410 или хотя бы 404.

Подход	Когда подходит	Плюс	Минус
noindex для attachment-страниц	Файл нужен в контенте, но отдельная страница вложения не нужна	Безопасно, не ломает картинки	URL может ещё какое-то время обходиться роботом
410 Gone для удалённых файлов	Файл удалён окончательно	Быстрее убирается из индекса	Нельзя применять к рабочим изображениям
Редирект на родительскую запись	Есть смысл отправить пользователя на статью	Сохраняет часть пользовательского пути	Не всегда уместно для массовых старых вложений

Диагностика: где именно WordPress создаёт лишние URL

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

Проверка в браузере и в Search Console

Откройте любой URL вложения. Если видите отдельную страницу без полезного текста — это кандидат на закрытие.
Посмотрите исходный код страницы: есть ли noindex в meta robots.
Проверьте sitemap: нет ли там attachment-URL.
В Search Console откройте отчёт по страницам и посмотрите, какие медиа-адреса уже проиндексированы.

Если у вас есть доступ к серверу, полезно проверить заголовки ответа:

curl -I https://example.com/wp-content/uploads/2024/01/photo.jpg

Для изображения должен быть корректный Content-Type, а для attachment-страницы — понятная политика индексации. Если вместо этого отдаются странные редиректы или цепочки редиректов, сначала исправьте их, а уже потом отправляйте URL на переобход.

Пошаговое решение: закрываем attachment-страницы и чистим индекс

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

Шаг 1. Закрыть attachment-страницы от индексации

Если вы не хотите ставить отдельный SEO-плагин только ради этой задачи, можно добавить фильтр в functions.php дочерней темы или в собственный мини-плагин:

<?php
add_action('template_redirect', function () {
    if (is_attachment()) {
        wp_redirect(get_permalink(get_post()->post_parent), 301);
        exit;
    }
});

Этот вариант переводит пользователя на родительскую запись. Он подходит не всегда: если у вложения нет родителя или запись удалена, редиректить будет некуда. В таком случае лучше вернуть 404 или 410, а не отправлять на главную.

Более аккуратный вариант — не редиректить, а запретить индексацию через robots meta. Для этого можно использовать фильтр, если тема и SEO-стек его поддерживают, но на практике надёжнее управлять этим через SEO-плагин. Например, в Clearfy Pro есть инструменты для удаления дублей и чистки сайта; если вы уже используете его, проверьте, не дублируется ли логика с вашей темой или другим SEO-плагином. Ставить два решения для одной и той же задачи — частая причина конфликтов.

Шаг 2. Убрать attachment-URL из sitemap

Если sitemap генерируется SEO-плагином, проверьте, не попадают ли туда страницы вложений. Их обычно не нужно отдавать поисковику как посадочные страницы. Если sitemap создаётся кодом, исключите attachment-посты из выборки.

<?php
add_filter('wp_sitemaps_post_types', function ($post_types) {
    if (isset($post_types['attachment'])) {
        unset($post_types['attachment']);
    }
    return $post_types;
});

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

Шаг 3. Для удалённых файлов отдавать 410, а не молчаливую пустоту

Если файл удалён окончательно и на него есть внешние ссылки или он уже в индексе, код ответа 410 Gone обычно понятнее для поисковика, чем бесконечный 200 с пустой страницей. Это не «ускоритель магического удаления», но нормальный сигнал, что ресурс больше не существует.

<?php
add_action('template_redirect', function () {
    if (is_attachment()) {
        $post = get_post();
        if (!$post) {
            return;
        }

        $file = get_attached_file($post->ID);
        if (!$file || !file_exists($file)) {
            status_header(410);
            nocache_headers();
            exit;
        }
    }
});

Этот код нужно использовать осторожно: он проверяет наличие физического файла. Если у вас нестандартное хранилище медиа, CDN или offload-плагин, file_exists() может дать ложный результат. В таком случае ориентируйтесь на логику конкретного решения хранения файлов, а не на локальный диск.

Как проверить, что решение сработало

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

Откройте несколько attachment-URL вручную: они должны редиректить, отдавать 404/410 или иметь noindex в зависимости от выбранной схемы.
Проверьте sitemap: лишние медиа-страницы не должны там присутствовать.
Посмотрите заголовки ответа через curl -I или DevTools.
В Search Console отправьте страницу на проверку после переобхода и посмотрите, сменился ли статус.
Если использовали редирект, убедитесь, что нет цепочки из нескольких переходов.

Хороший признак — когда старые attachment-URL перестают возвращать полноценную индексируемую страницу, а в отчётах постепенно уменьшается число мусорных адресов. Не ждите мгновенного исчезновения: поисковику нужно время на повторный обход.

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

Редирект всех вложений на главную

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

Закрыли файлы изображений вместо attachment-страниц

Иногда путают URL файла и URL страницы вложения. Файл изображения должен оставаться доступным, если он используется в контенте. Закрывать нужно именно HTML-страницу attachment, а не сам .jpg или .png, если они нужны на сайте.

Оставили дубли в sitemap

Даже если страницы закрыты, их наличие в sitemap создаёт лишний шум. Поисковик сначала видит URL в карте сайта, а уже потом получает сигнал о запрете. Уберите их из sitemap на уровне генерации.

Поставили два SEO-плагина с одинаковой функцией

Если один плагин закрывает attachment-страницы, а второй пытается их индексировать или переписывать canonical, результат будет непредсказуемым. Проверьте, кто именно отвечает за robots meta, canonical и sitemap. Должен быть один источник правды.

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

Любые правки, которые влияют на индексацию и редиректы, лучше сначала тестировать на staging-копии. Ошибка в логике attachment-страниц легко превращает нормальные медиа-URL в массовые 404 или циклы редиректов.

Сделайте резервную копию перед изменениями в functions.php или MU-плагине.
Не используйте тяжёлые проверки на каждом запросе, если можно решить задачу через готовый механизм SEO-плагина.
Если медиа раздаётся через CDN, проверьте, не кэширует ли он старые заголовки ответа.
После массового удаления файлов очистите кэш страницы, объектный кэш и CDN, иначе поисковик и пользователь будут видеть разное состояние.

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

В рабочем процессе это обычно выглядит так: находите тип мусорного URL, определяете, нужен ли файл или только страница вложения, выбираете редирект/410/noindex, убираете URL из sitemap и затем проверяете ответ сервера и Search Console. Такой порядок даёт предсказуемый результат и не ломает медиа на сайте.