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

Автор: Лев Васильев | Опубликовано: 04.09.2026

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

Когда проблема действительно в attachment-страницах

Сначала стоит убедиться, что речь не о другой причине дублей. Attachment-страницы выдают себя довольно типично: URL вида /sample-image/ или /2026/09/photo-name/, на странице почти нет текста, а в исходном коде часто стоит canonical на саму attachment-страницу или на файл вложения. Если сайт уже закрывает архивы, теги и поиск, а в индексе всё равно остаются странные одиночные страницы с картинками, именно вложения — первый кандидат на проверку.

Что проверить руками

Откройте несколько URL вложений из поиска или из отчёта индексации.
Посмотрите, есть ли на странице полноценный контент или только изображение и подпись.
Проверьте canonical в исходном коде.
Сравните URL вложения с URL исходной записи, где используется это изображение.

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

Какие есть варианты решения

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

Подход	Что делает	Когда уместен	Риск
Редирект 301	Уводит attachment URL на файл или запись	Если страницы вложений не нужны вообще	Можно потерять старые входящие ссылки на attachment URL
`noindex`	Оставляет страницу доступной, но убирает из индекса	Если нужно мягко очистить поиск	URL остаётся в обходе и может жить в кэше
Отключение архивов	Не даёт WordPress показывать attachment-страницы	Если медиа-страницы не используются как контент	Нужно проверить тему и плагины на зависимости

Пошаговое решение: закрываем вложения от индексации

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

Шаг 1. Добавить noindex только для attachment

Ниже пример для functions.php дочерней темы или небольшого mu-plugin. Он добавляет noindex, follow только на attachment-страницы и не трогает обычные записи, страницы и архивы.

<?php
add_filter('wp_robots', function (array $robots) {
    if (is_attachment()) {
        $robots['noindex'] = true;
        $robots['follow']   = true;
    }

    return $robots;
});

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

Шаг 2. При необходимости сделать редирект на родительскую запись

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

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

    $attachment_id = get_queried_object_id();
    $parent_id = wp_get_post_parent_id($attachment_id);

    if ($parent_id) {
        wp_safe_redirect(get_permalink($parent_id), 301);
        exit;
    }

    $file_url = wp_get_attachment_url($attachment_id);
    if ($file_url) {
        wp_safe_redirect($file_url, 301);
        exit;
    }
});

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

Шаг 3. Убедиться, что canonical не указывает на мусорный URL

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

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

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

Откройте attachment-URL и проверьте исходный код: должен появиться noindex или редирект.
Проверьте заголовки ответа, если используете редирект: статус должен быть 301, а не 302.
Убедитесь, что обычные записи и страницы не получили лишний noindex.
В Search Console отправьте проверку URL и посмотрите, меняется ли статус индексации.

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

curl -I https://example.com/sample-image/

В ответе вы должны увидеть либо редирект, либо страницу с корректными мета-данными. Если вместо этого attachment-страница отдаёт 200 и индексируемый canonical, значит правило не сработало или его перебивает другой плагин.

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

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

Это частая путаница. is_attachment() относится к странице вложения, а не к самому файлу в /uploads/. Если после правки перестали открываться изображения по прямым ссылкам, значит проблема уже в другом коде или в правилах сервера.

Поставили noindex, но canonical остался на attachment URL

В таком случае поисковик может продолжать считать страницу значимой. Проверьте SEO-плагин, тему и кастомные функции, которые формируют canonical. Иногда canonical задаёт не WordPress, а сторонний плагин для медиа или галерей.

Сделали 301 на главную для всех вложений

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

Забыли про кэш

После изменения robots meta или редиректов старые версии страниц могут ещё какое-то время отдаваться из кэша плагина, CDN или сервера. Очистите кэш сайта, объектный кэш, если он есть, и кэш на уровне CDN. Иначе вы будете проверять уже не тот ответ, который видит бот.

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

Если на сайте много медиа, не стоит решать проблему через тяжёлые плагины, которые меняют сразу всё поведение вложений без прозрачной логики. Для точечной задачи чаще достаточно небольшого кода в mu-plugin. Так проще контролировать изменения, а при необходимости быстро откатить их без влияния на остальной сайт.

Если вы используете SEO-плагин для управления индексированием, проверьте, не дублирует ли он ваши кастомные правила. Два источника правды для robots meta — частая причина странного поведения. Для очистки дублей и технических хвостов иногда удобнее использовать отдельные инструменты вроде Clearfy Pro, но только если вам нужен именно набор технических настроек, а не ещё один слой логики поверх уже настроенного SEO-стека.

Мини-чек-лист перед публикацией правки

Проверены реальные attachment-URL на тестовом и боевом сайте.
Понятно, нужен ли редирект или достаточно noindex.
Canonical не указывает на индексируемую attachment-страницу.
Кэш очищен на сайте и на CDN.
Обычные записи, страницы и медиа-файлы не сломаны.
В Search Console отправлена повторная проверка важных URL.

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