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

Автор: Юлия Николаева | Опубликовано: 07.09.2026

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

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

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

Сценарий узнаётся быстро: в отчётах по страницам появляются URL вложений, у них почти пустой контент, а в индексе они конкурируют с основными страницами записи. Иногда это видно и без Search Console: если открыть медиафайл из библиотеки, WordPress ведёт не на сам файл, а на attachment page.

На практике это мешает в трёх случаях:

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

Как понять, что проблема именно в attachment-страницах

Проверьте несколько признаков вручную:

откройте URL вложения и посмотрите, есть ли там собственный текст, а не только изображение;
посмотрите исходный код страницы: часто у attachment page почти нет уникального контента;
в Search Console найдите URL с сегментами attachment, image, media или похожими паттернами;
проверьте, не создаёт ли тема отдельный шаблон для вложений.

Если у вас сайт на старой теме или с набором SEO-плагинов, дубли могут появляться не только из-за WordPress, но и из-за настроек каноникал, sitemap и редиректов. Поэтому сначала нужно понять, где именно генерируется проблема.

Диагностика: что смотреть до правки

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

Проверка в админке и на фронтенде

Откройте Медиафайлы → Библиотека.
Выберите несколько изображений и посмотрите, есть ли у них отдельная страница вложения.
Откройте такую страницу в браузере и проверьте, есть ли на ней полезный текст, хлебные крошки, блоки похожих материалов.
Посмотрите, какой canonical ставится на странице: на сам attachment URL или на родительскую запись.

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

Проверка через поиск по сайту и sitemap

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

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

Пошаговое решение: отключить индексацию и убрать дубли

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

Подход	Когда подходит	Компромисс
Редирект attachment на файл или родительскую запись	Если отдельные страницы вложений не нужны	Нужно аккуратно выбрать целевой URL
Закрыть от индексации через `noindex`	Если страницы нужны пользователям, но не поиску	URL останутся доступны для обхода
Отключить attachment archive на уровне кода	Если нужен контроль без лишних плагинов	Требует правки темы или mu-plugin

Вариант 1: редирект attachment-страниц

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

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

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

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

Логика простая: если у вложения есть родительская запись, отправляем туда; если родителя нет, уводим на сам файл. Такой подход уменьшает количество тонких страниц и не ломает доступ к медиа.

Вариант 2: закрыть attachment от индексации

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

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

Важно: noindex не убирает URL из обхода мгновенно. Он лишь подсказывает поисковику не держать страницу в индексе. Если нужно именно убрать дубли, лучше сочетать noindex с редиректом или исключением из sitemap.

Вариант 3: отключить attachment archive через код

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

Практически это означает: не трогать сам файл и не ломать загрузку изображений, а только убрать отдельную HTML-страницу вложения.

Что делать, если sitemap уже содержит мусорные URL

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

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

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

<?php
$args = array(
    'post_type'      => array( 'post', 'page' ),
    'post_status'    => 'publish',
    'posts_per_page' => 100,
    'fields'         => 'ids',
);

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

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

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

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

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

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

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

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

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

Это распространённая, но не лучшая практика. Для поисковика такой редирект выглядит как массовое сведение разных URL в нерелевантную точку. Лучше уводить вложение на родительскую запись или на сам файл, если родителя нет.

Оставили attachment page в sitemap

Даже если вы поставили noindex, карта сайта продолжает сигнализировать о важности URL. В результате поисковик дольше держит их в обходе. Исправление простое: исключить attachment из sitemap на уровне SEO-плагина или кастомного генератора.

Сломали медиа после агрессивного редиректа

Иногда редирект пишут так, что он срабатывает не только на HTML-страницу вложения, но и на прямой файл изображения. Это уже ошибка. Проверяйте условие через is_attachment() и не трогайте запросы к .jpg, .png, .webp и другим файлам в uploads.

Поставили noindex, но не убрали дубли

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

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

Любая правка, связанная с редиректами и мета-тегами, должна жить либо в дочерней теме, либо в небольшом mu-plugin. Не вносите такие изменения в файлы родительской темы, если она обновляется: после апдейта всё исчезнет.

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

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

Короткий чек-лист перед публикацией изменений

Проверены attachment URL в браузере и через curl -I.
Понятно, куда ведёт редирект: на родителя или на файл.
Attachment-страницы исключены из sitemap.
На страницах вложений стоит корректный noindex, если он нужен.
Внутренние ссылки на медиа не сломаны.
В Search Console отправлены URL на повторную проверку.

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

⭐⭐⭐⭐⭐