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

Автор: Игорь Ершов | Опубликовано: 21.09.2026

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

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

Когда страницы вложений действительно мешают

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

Типичные признаки проблемы

в Search Console появляются URL вида /attachment/ или вложения с названием файла;
в выдаче находятся страницы изображений вместо материалов;
в отчётах по индексации растёт число «Просканировано — не проиндексировано» или похожих статусов для медиа-URL;
на сайте есть старые ссылки на attachment-страницы, и они ведут в пустой шаблон.

Диагностика: что именно индексируется

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

Проверьте несколько вещей вручную:

Откройте страницу вложения из медиа-библиотеки и посмотрите, есть ли на ней контент.
Проверьте исходный код: есть ли <link rel="canonical"> на файл, на родительскую запись или на саму attachment-страницу.
Посмотрите, не ведут ли на эти URL внутренние ссылки из старых материалов, sitemap или хлебных крошек.

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

Подход	Что делает	Плюс	Минус
Плагин SEO	Добавляет `noindex` или редирект	Быстро и без кода	Зависит от настроек и логики плагина
Код в теме/плагине	Меняет canonical и редиректит attachment	Контроль над поведением	Нужно аккуратно тестировать
Удаление шаблона	Ломает страницу вложения целиком	Просто	Часто даёт 404 и побочные эффекты

Рабочее решение: редиректить attachment-страницы на файл или родительскую запись

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

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

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

    $attachment_id = get_queried_object_id();
    $file_url = wp_get_attachment_url( $attachment_id );

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

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

    wp_safe_redirect( home_url( '/' ), 301 );
    exit;
} );

Этот вариант хорош тем, что:

не оставляет пустую attachment-страницу в индексе;
не ломает доступ к самому файлу;
снижает риск накопления дублей.

Если нужен именно noindex, а не редирект

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

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

    return $robots;
} );

Такой вариант не удаляет страницу из обхода, но просит поисковик не включать её в индекс. На практике это полезно, если вы хотите сохранить переходы по ссылкам, но убрать мусорные URL из выдачи.

Пошаговая настройка без сюрпризов

Определите, есть ли у attachment-страниц полезный контент. Если нет — редирект лучше, чем noindex.
Проверьте, не использует ли тема отдельный шаблон для вложений. Иногда там уже есть логика canonical или хлебных крошек.
Добавьте редирект или noindex в дочернюю тему, mu-plugin или собственный мини-плагин, а не в файл темы, который может затереться при обновлении.
Очистите кэш сайта и CDN, если они есть.
Переобойдите несколько URL вручную и проверьте код ответа.

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

Проверка должна быть не только визуальной. Откройте несколько attachment-URL и убедитесь, что поведение соответствует выбранной схеме.

если выбран редирект — страница должна отдавать 301 и вести на файл или родительскую запись;
если выбран noindex — в HTML должен быть корректный robots-мета или заголовок;
в Search Console URL должен постепенно исчезать из индекса или переходить в статус, соответствующий закрытию;
внутренние ссылки не должны вести на пустые attachment-страницы, если это не задумано специально.

Для быстрой проверки ответа сервера удобно использовать:

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

Если видите 301 и правильный Location, редирект работает. Если используете noindex, проверьте исходный код страницы или заголовки ответа через инструменты браузера.

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

Редирект на главную без разбора структуры

Это частая «заглушка», но она плохо работает на больших сайтах. Пользователь теряет контекст, а поисковик получает слишком общий сигнал. Лучше редиректить на файл или на родительскую запись, если она есть.

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

Иногда путают URL медиафайла и страницу вложения. В результате ломаются картинки, PDF и другие ресурсы. Проверяйте, что редирект или noindex применяется только к is_attachment(), а не ко всем URL из медиабиблиотеки.

Оставили старые внутренние ссылки

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

Сделали noindex, но canonical остался на саму страницу

Это не всегда ошибка, но часто приводит к путанице в сигналах. Если страница должна быть закрыта, проверьте, не конфликтует ли canonical с вашей логикой. Иногда проще выбрать один понятный сценарий: либо редирект, либо noindex.

Что учесть для безопасности и производительности

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

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

Если нужен более широкий контроль над дублями, canonical и технической чисткой сайта, можно посмотреть в сторону инструментов уровня Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже с плагином полезно понимать, что именно он меняет в шаблоне и ответах сервера.

В итоге задача сводится к простому выбору: если attachment-страницы не несут пользы, закрывайте их аккуратно через редирект или noindex, не трогая сами файлы. Если на них есть смысловой контент, не убирайте их механически — сначала проверьте, не проще ли улучшить шаблон и canonical, чем вычищать URL из индекса.