Как убрать страницы attachment из индекса WordPress

Автор: Ярослав Быков | Опубликовано: 08.09.2026

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

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

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

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

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

Что именно нужно проверить перед правкой

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

Диагностика: как понять, что проблема именно в attachment

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

Ещё один полезный тест — поиск по сайту через оператор site:. Если в выдаче есть URL с признаками attachment, а контент на них почти пустой, это кандидат на закрытие от индексации или редирект.

site:example.com inurl:attachment

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

SELECT COUNT(*) AS attachments_count
FROM wp_posts
WHERE post_type = 'attachment';

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

Что лучше: noindex, редирект или отключение страницы

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

Подход	Когда подходит	Плюсы	Минусы
Noindex	Нужно убрать URL из поиска, но оставить доступ по ссылке	Мягкое решение, меньше риска сломать старые ссылки	Страница остаётся доступной, поисковик может ещё какое-то время её обходить
301 на файл или родителя	Attachment-страницы не нужны вообще	Чистит структуру, убирает лишний слой	Нужно аккуратно выбрать цель редиректа
Отключение через код	Нужен предсказуемый технический контроль	Не зависит от плагина, легко версионировать	Требует доступа к коду и тестирования

Пошаговое решение через код

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

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

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

    $post = get_queried_object();
    if ( ! $post || empty( $post->ID ) ) {
        return;
    }

    $parent_id = (int) wp_get_post_parent_id( $post->ID );

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

    $file_url = wp_get_attachment_url( $post->ID );
    if ( $file_url ) {
        wp_safe_redirect( $file_url, 301 );
        exit;
    }
}, 1 );

Если вам нужно именно закрыть attachment-страницы от индексации без редиректа, можно добавить noindex в robots meta для этих URL. Это менее жёсткий вариант, но он не убирает саму страницу из обхода сразу.

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

    return $robots;
} );

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

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

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

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

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

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

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

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

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

Если всё настроено как редирект, в ответе должен быть статус 301 и заголовок Location с правильной целью.

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

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

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

Attachment-страницы закрыли, но ссылки в контенте остались

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

Noindex поставили, а URL всё ещё в индексе

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

Сломали галереи и lightbox

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

Безопасность и производительность: что учесть

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

Если у вас крупный сайт с большим архивом медиа, лучше сначала протестировать решение на staging-копии. Это особенно важно, если на сайте есть:

кастомные типы записей, связанные с медиа;
старые SEO-редиректы;
плагины галерей и слайдеров;
нестандартные шаблоны attachment.php.

Отдельно проверьте, не переопределяет ли тема шаблон attachment.php. Иногда проблема не в индексации, а в том, что шаблон отдаёт слишком бедную страницу, которую поисковик и так считает мусорной.

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

Проверен список attachment-URL в индексе.
Выбран один сценарий: редирект или noindex.
Проверены старые ссылки в контенте.
Тест пройден на нескольких реальных URL.
Проверен код ответа через curl -I или DevTools.
Убедились, что галереи и медиа-блоки не сломались.

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