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

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

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

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

В WordPress у каждого загруженного файла может быть собственная страница вложения. На практике это выглядит так: /sample-image/ ведёт не на сам файл, а на HTML-страницу с изображением и минимальным контентом. Для большинства сайтов это бесполезный URL, который создаёт дубли и раздувает индекс.

Проблема особенно заметна, если:

• в медиатеке много изображений, загруженных за годы работы сайта;
• тема или плагин автоматически ссылаются на attachment-страницы вместо файла;
• в поиске уже есть URL вида /image-name/ или ?attachment_id=123;
• на сайте есть архивы, пагинация и много контента с картинками, поэтому ботам есть что обходить.

Что именно нужно отключать

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

Диагностика проблемы перед изменениями

Сначала проверьте, есть ли attachment-URL в индексе и как они ведут себя сейчас. Это можно сделать без доступа к серверу.

• В поиске используйте запрос site:example.com inurl:attachment и site:example.com inurl:/wp-content/uploads/.
• Откройте несколько URL вложений вручную: если это отдельная HTML-страница, значит проблема есть.
• Посмотрите отчёт по страницам в Google Search Console: часто там видны малоценные URL с изображениями или странные страницы вложений.
• Проверьте, не ведут ли внутренние ссылки темы на attachment-страницы. Это бывает в галереях и блоках медиа.

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

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

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

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

    $attachment_id = get_queried_object_id();
    if ( ! $attachment_id ) {
        return;
    }

    $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;
    }

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

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

Если нужен не редирект, а жёсткое отключение

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

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

Варианты решения: код, плагин или ручная настройка

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

Как убрать дубли из медиатеки и не сломать изображения

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

• Откройте несколько старых постов и кликните по изображениям.
• Проверьте HTML в редакторе: ссылка у картинки должна вести либо на файл, либо быть пустой, если это декоративное изображение.
• Если используете галереи, убедитесь, что они не генерируют отдельные страницы вложений.
• Проверьте sitemap: attachment-URL не должны попадать в XML-карту сайта.

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

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

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

1. Откройте attachment-URL в режиме инкогнито.
2. Убедитесь, что ответ идёт с кодом 301, а не 200.
3. Проверьте, куда ведёт редирект: на родительскую запись или на файл.
4. Посмотрите исходный URL через инструменты разработчика или curl -I.

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

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

Что ещё проверить в Search Console

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

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

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

На практике проблемы возникают не в самом редиректе, а в деталях внедрения.

• Редирект на главную для всех вложений. Это выглядит безопасно, но ломает логику старых ссылок и может скрыть полезный контент. Лучше вести на родителя или файл.
• Код вставили в родительскую тему. После обновления он исчезнет. Используйте дочернюю тему или мини-плагин.
• Проверяли только в браузере. Браузер может показать страницу из кэша. Смотрите HTTP-статус.
• Не очистили кэш. После правки редирект может не примениться сразу из-за page cache или CDN.
• Отключили attachment-страницы, но оставили ссылки в контенте. Пользователь всё равно будет попадать на редирект. Лучше почистить старые ссылки отдельно.

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

Редирект attachment-страниц сам по себе почти не нагружает сайт, но есть несколько моментов, которые стоит учесть.

• Используйте wp_safe_redirect(), а не голый header().
• Не делайте цепочки редиректов: attachment → главная → другая страница. Это лишняя задержка и риск ошибок.
• Если у вас агрессивный кэш, проверьте, не кэшируется ли 301 неправильно для разных языков или доменов.
• Не закрывайте изображения в robots.txt, если они нужны для поиска по картинкам и для отображения контента.

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

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