Как запретить индексацию attachment-страниц в WordPress без потери медиа в контенте

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

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

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

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

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

Что важно не перепутать

Закрывать нужно именно attachment-страницы, а не сами изображения. Файл .jpg, .png или .webp должен продолжать открываться в записи, в галерее, в блоке изображения и в Open Graph, если он используется. Речь идёт только о HTML-странице вложения, а не о медиафайле как таковом.

Диагностика: как понять, что индексируются именно attachment URL

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

1. Откройте Google и выполните запрос site:example.com attachment или site:example.com inurl:attachment.
2. Проверьте отчёт «Страницы» в Search Console на наличие URL с вложениями.
3. Откройте несколько таких страниц вручную: если там только заголовок, картинка и почти нет текста, это кандидат на закрытие от индексации.

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

Пошаговое решение: редирект или noindex

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

Вариант 1: редирект attachment-страниц в functions.php

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

<?php
add_action( 'template_redirect', function () {
    if ( is_attachment() ) {
        $parent_id = wp_get_post_parent_id( get_queried_object_id() );

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

        $file_url = wp_get_attachment_url( get_queried_object_id() );
        if ( $file_url ) {
            wp_redirect( $file_url, 301 );
            exit;
        }
    }
} );

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

Вариант 2: добавить noindex для attachment-страниц

Если вы хотите оставить URL доступным, но убрать его из индекса, добавьте meta robots через wp_head. Это не самый «красивый» способ, но он рабочий и не требует внешних зависимостей.

<?php
add_action( 'wp_head', function () {
    if ( is_attachment() ) {
        echo '<meta name="robots" content="noindex,follow" />' . "\n";
    }
} );

Здесь важно не ставить nofollow без необходимости. Для attachment-страниц обычно достаточно noindex,follow: страница не попадает в индекс, но обход ссылок не ломается.

Если используете SEO-плагин

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

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

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

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

• Откройте attachment-страницу в браузере и проверьте, есть ли редирект или meta robots.
• Посмотрите исходный код страницы: должен быть noindex,follow, если вы выбрали этот вариант.
• Проверьте ответ сервера через curl -I https://example.com/attachment-url/ и убедитесь, что редирект действительно 301, а не 302.
• В Search Console отправьте URL на повторную проверку, если страница уже была в индексе.

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

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

Редирект на несуществующий родительский URL

Такое бывает, когда вложение загружено отдельно, без привязки к записи. В этом случае wp_get_post_parent_id() вернёт ноль, и если не предусмотреть запасной сценарий, пользователь попадёт в пустоту. Решение — проверять наличие $file_url и использовать его как fallback.

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

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

Поставили noindex, но страница всё равно в индексе

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

Дублирующие правила в теме и SEO-плагине

Если тема добавляет один редирект, а плагин — другой, итоговое поведение становится непредсказуемым. Оставьте один источник истины: либо код в теме/му-плагине, либо настройка в SEO-плагине.

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

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

Ещё один полезный момент: не плодите отдельные attachment-страницы ради SEO-экспериментов. Для большинства сайтов они не дают ценности и только увеличивают объём технического мусора. Чем меньше лишних URL, тем проще поддерживать индексацию и отчёты в Search Console.

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

Что проверить после запуска на боевом сайте

• attachment-страницы отдают 301 или noindex в зависимости от выбранного сценария;
• сами изображения продолжают открываться в записи и в медиабиблиотеке;
• в Search Console нет роста ошибок 404 из-за неверного редиректа;
• в теме или плагинах нет второго правила, которое переопределяет ваше;
• новые вложения не создают индексируемые HTML-страницы по умолчанию.

Если всё это сходится, значит вы закрыли именно техническую проблему, а не просто «спрятали» её в интерфейсе. Для WordPress это обычно и есть правильный результат: меньше мусорных URL, чище индекс и без потерь для медиа-контента.