Если в поиске всплывают не статьи и товары, а страницы вложений и целые медиаархивы WordPress, это почти всегда лишний шум. Такие URL редко дают трафик, зато раздувают индекс, создают дубли и отвлекают поисковик от действительно важных страниц сайта. Решение зависит от того, что именно попало в индекс: отдельные attachment-страницы или архивы медиафайлов как тип записей.
Ниже разберём оба случая и покажем, как убрать их из индекса без лишних действий. Сразу оговорюсь: если у вас уже есть внешние ссылки на такие страницы, они не исчезнут мгновенно. Поисковику нужно время, чтобы переобойти сайт и обновить индекс.
Что именно нужно закрыть от индексации
В WordPress под «страницами вложений» обычно имеют в виду отдельные страницы медиафайлов. Они создаются для изображений, PDF, архивов и других файлов, когда у вложения есть собственный URL на сайте. У такой страницы часто почти нет полезного контента: заголовок, изображение и ссылка на файл. Для поиска это слабая посадочная страница.
Медиаархивы — это уже не отдельные attachment-страницы, а архивные страницы самого типа записей attachment. На некоторых сайтах они доступны как отдельные списки медиафайлов или как архивы по датам/авторам, если тема и настройки это позволяют. Именно такие URL чаще всего и нужно убрать из индекса целиком.
Перед изменениями полезно понять, что у вас реально индексируется. Откройте несколько проблемных URL из поиска и посмотрите, что это за страницы: одиночные вложения с адресом вида /sample-image/ или архивные страницы, где перечислены файлы. От этого зависит способ решения.
Самый надёжный способ: запретить индексирование в настройках SEO-плагина
Если на сайте уже стоит SEO-плагин, это обычно самый безопасный путь. Он позволяет закрыть от индексации именно архивы вложений, не трогая сами файлы и не ломая загрузку изображений в контенте.
В большинстве SEO-плагинов нужно найти настройки архивов или типов записей и отключить индексирование для attachment. Логика простая: если архивы вложений не нужны пользователям и не должны участвовать в поиске, им не место в индексе. При этом сами медиафайлы продолжат открываться по прямым ссылкам, если они используются на сайте.
Если плагин умеет отдельно управлять страницами вложений, проверьте и этот пункт. На практике полезно закрывать оба уровня: и архивы, и одиночные attachment-страницы. Иначе в индексе может остаться один из вариантов.
Когда этого достаточно
Такой способ подходит, если:
- у вас обычный сайт на WordPress без сложной кастомной логики;
- медиафайлы не должны получать поисковый трафик отдельно от основного контента;
- нужно быстро убрать из индекса лишние URL без правки темы и шаблонов.
После сохранения настроек проверьте исходный код проблемной страницы. На ней должен появиться meta-тег noindex или эквивалентная директива, которую добавляет ваш SEO-плагин. Это не мгновенно убирает URL из поиска, но даёт поисковику понятный сигнал.
Если SEO-плагина нет: закройте архивы вложений на уровне WordPress
Когда на сайте нет SEO-плагина или вы не хотите полагаться на его настройки, можно отключить саму выдачу attachment-страниц через код. Это уже более технический вариант, но он работает предсказуемо.
Самый практичный подход — перенаправлять одиночные страницы вложений на сам файл или на родительскую запись. Для этого обычно используют фильтр attachment_link или редирект через шаблон темы, но для массового закрытия индекса лучше не ограничиваться редиректом. Поисковик может какое-то время видеть старые URL, а редирект не всегда решает вопрос с архивами типа записи.
Если задача именно убрать из индекса архивы вложений, а не менять поведение ссылок в контенте, лучше дополнительно отключить архивы для типа записей attachment. В WordPress это можно сделать через фильтр register_post_type_args, но только если вы понимаете, как и где загружается код. Такой способ подходит для дочерней темы или небольшого плагина.
Пример кода ниже отключает публичные архивы для типа записей attachment. Его стоит использовать только если вы уверены, что вам не нужны архивные страницы медиафайлов как часть структуры сайта.
add_filter( 'register_post_type_args', function( $args, $post_type ) {
if ( 'attachment' === $post_type ) {
$args['has_archive'] = false;
$args['publicly_queryable'] = false;
}
return $args;
}, 10, 2 );Этот код не удаляет сами файлы и не мешает вставке изображений в записи. Он лишь убирает возможность открывать attachment-архивы как отдельные страницы. Но перед использованием сделайте резервную копию и проверьте, нет ли у вас кастомной логики, которая опирается на эти URL.
Что делать с уже проиндексированными URL
Если страницы вложений и медиаархивы уже попали в индекс, одной настройки мало. Нужно дать поисковику сигнал, что эти адреса больше не нужны.
Рабочая схема обычно такая:
- закрыть страницы от индексации через
noindexили отключение архивов; - убедиться, что в sitemap они не попадают;
- при необходимости настроить редирект с одиночных attachment-страниц на более полезный URL;
- дождаться переобхода сайта.
Если у вас есть доступ к панели вебмастера, можно ускорить процесс через удаление устаревших URL или запрос на переобход. Но это вспомогательный шаг, а не замена корректной настройки на сайте.
Редирект нужен не всегда. Если attachment-страницы не имеют ценности и на них нет внешних ссылок, достаточно noindex и исключения из карты сайта. Если же на них уже есть ссылки или они активно открываются пользователями, редирект на родительскую запись или на сам файл может быть полезнее.
Проверьте, не создаёт ли тема или плагин лишние медиаархивы
Иногда проблема не в WordPress как таковом, а в теме или плагине, который выводит отдельные архивы медиафайлов. Это бывает у кастомных тем, медиа-библиотек, галерей и некоторых конструкторов. В таком случае отключение только attachment-страниц не решит вопрос полностью.
Проверьте:
- есть ли в sitemap URL с типом
attachment; - открываются ли отдельные архивы медиафайлов по человекопонятным адресам;
- не создаёт ли плагин собственные страницы-обёртки для файлов;
- не добавляет ли тема ссылки на attachment-страницы в хлебные крошки или списки похожих материалов.
Если такие URL есть, их нужно закрывать именно там, где они создаются. Иначе вы уберёте один источник дублей, но оставите другой.
Как проверить, что страницы действительно убраны из индекса
После настройки не стоит ориентироваться только на визуальный вид сайта. Проверка должна быть технической.
Сначала откройте несколько проблемных URL в браузере и посмотрите исходный код страницы. Ищите noindex, отсутствие страницы в sitemap и, если вы настраивали редирект, корректный ответ сервера с переходом на нужный адрес.
Затем проверьте поисковую выдачу по точному адресу страницы или по уникальному фрагменту заголовка. Если URL ещё виден в индексе, это нормально в первые дни и даже недели после изменения. Главное — чтобы поисковик при обходе видел уже новую логику: не индексировать, не включать в карту сайта и не считать страницу важной.
Если URL продолжает возвращаться в индекс, обычно причина одна из трёх: страница всё ещё доступна без noindex, она попадает в sitemap, либо на неё ведут внутренние ссылки с сайта. В таком случае сначала уберите источник ссылки, а уже потом ждите переобхода.
Что не стоит делать
Не удаляйте медиафайлы из библиотеки только ради того, чтобы убрать URL из поиска. Это может сломать изображения в старых записях и не решит проблему, если страницы уже проиндексированы. Также не закрывайте от индексации сами файлы, если они используются на сайте: поисковику обычно не нужен именно HTML-архив вложения, а не изображение как ресурс.
Ещё одна частая ошибка — ставить редирект со всех attachment-страниц на главную. Для поисковика это выглядит как грубая подмена и не помогает понять, что делать с конкретным URL. Если уж делать редирект, то на релевантную страницу: родительскую запись, категорию или сам файл, если это оправдано.
Если вам нужен более чистый сайт без дублей и технического мусора в индексе, эту задачу можно решать и через SEO-плагины с управлением архивами и типами записей. Но в любом случае принцип один: сначала определить, что именно индексируется, затем закрыть источник дубля, а уже потом ждать обновления выдачи.