Как отключить attachment-страницы в WordPress и настроить 301-переадресацию

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

Ниже разберём рабочую схему: как понять, что проблема именно в attachment-URL, как отключить их без поломки медиафайлов, как настроить 301 и как проверить результат.

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

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

Симптомы обычно такие:

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

Как быстро диагностировать

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

• откройте URL вложения в браузере и посмотрите, есть ли там полезный контент;
• в поиске выполните запрос site:example.com inurl:attachment или site:example.com inurl:/image-name/;
• посмотрите исходный код страницы вложения: есть ли canonical на запись или на сам attachment;
• проверьте, не создаёт ли SEO-плагин отдельные мета-теги для attachment-страниц.

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

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

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

Ниже пример для functions.php дочерней темы или для собственного мини-плагина.

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

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

    $redirect_url = '';

    if ( ! empty( $post->post_parent ) ) {
        $redirect_url = get_permalink( $post->post_parent );
    }

    if ( ! $redirect_url ) {
        $redirect_url = home_url( '/' );
    }

    wp_safe_redirect( $redirect_url, 301 );
    exit;
}

Что делает этот код:

• срабатывает только на attachment-страницах;
• ищет родительскую запись у вложения;
• если родитель есть, отправляет на него;
• если родителя нет, отправляет на главную;
• использует 301, чтобы поисковики поняли, что URL переехал постоянно.

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

Если нужно отключить attachment-страницы без редиректа

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

Практически безопаснее всё же использовать 301, а не просто ломать маршрут.

Сравнение подходов: плагин, код, SEO-настройка

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

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

После добавления кода проверьте несколько сценариев вручную и через инструменты поисковика.

• Откройте attachment-URL в браузере: должен быть редирект 301 на родительскую запись или на выбранную страницу.
• Проверьте заголовки ответа через DevTools или curl -I https://example.com/image-name/.
• Убедитесь, что конечный URL отдаёт 200, а не ещё один редирект.
• Посмотрите, не остались ли внутренние ссылки на attachment-страницы в контенте.
• В Search Console отправьте на переобход несколько старых URL и проверьте, как меняется статус.

Пример проверки через консоль:

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

В ответе должен быть статус 301 Moved Permanently и заголовок Location с целевым URL. Если вместо этого вы видите 200 OK, значит редирект не сработал или код подключён не там, где нужно.

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

Редирект уводит на главную для всех вложений

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

Появилась цепочка редиректов

Частая причина — SEO-плагин уже делает свой редирект, а ваш код добавляет второй. Проверьте, не включена ли в плагине отдельная опция для медиа-страниц. Если есть дублирующая логика, оставьте только один источник редиректа.

Изображение перестало открываться

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

Attachment-страницы всё ещё в индексе

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

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

Если вы вносите код вручную, не правьте functions.php основной темы на боевом сайте. Используйте дочернюю тему или небольшой mu-plugin. Так вы не потеряете изменения при обновлении.

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

• не создаёт ли тема отдельные архивы или шаблоны для attachment;
• не добавляет ли плагин изображения в sitemap как отдельные страницы;
• не дублируются ли URL через HTTP/HTTPS и с www/без www;
• нет ли в кэше старых 200-ответов для attachment-страниц.

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

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

• редирект отдаёт именно 301, а не 302;
• целевой URL не закрыт от индексации;
• в sitemap нет старых вложений;
• каноникал на целевой странице указывает на саму запись, а не на attachment.

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