На WordPress attachment-страницы часто появляются сами по себе: загрузили изображение, и у него есть отдельный URL-адрес со страницей вложения. Для сайта это не всегда проблема, но на проектах с активной публикацией контента такие страницы быстро превращаются в технический мусор: тонкий контент, дубли заголовков, пустые шаблоны и лишние URL в индексе.
Если задача именно в том, чтобы убрать attachment из поиска, но не сломать загрузку изображений и ссылки в контенте, лучше решать это на уровне шаблона и редиректов, а не просто «что-то закрыть в robots.txt». Ниже — рабочие варианты, их ограничения и проверка результата.
Когда attachment-страницы действительно мешают
Проблема обычно видна не сразу. В Search Console или в логике внутренней оптимизации всплывают страницы вида /attachment/, /имя-файла/ или отдельные URL медиафайлов, которые индексируются как самостоятельные страницы. У таких страниц почти всегда слабая ценность: один заголовок, одно изображение, иногда вообще пустой шаблон.
Типичные симптомы:
- в индексе есть десятки или сотни страниц вложений, хотя вы их не продвигали;
- поисковик показывает attachment-URL вместо основной статьи или изображения;
- в отчётах по дубликатам появляются страницы с одинаковыми title и H1;
- внутренние ссылки ведут на attachment, а не на оригинальный материал;
- после миграции или импорта медиа в индексе остались старые URL вложений.
Что важно проверить до изменений
Сначала посмотрите, как именно у вас устроены attachment-страницы. В разных темах и сборках WordPress поведение отличается: где-то attachment-URL отдаёт полноценную страницу, где-то сразу редиректит на файл, а где-то шаблон вообще пустой. От этого зависит, нужен ли вам редирект, noindex или оба механизма сразу.
- открывается ли attachment-страница в браузере;
- есть ли у неё отдельный title и meta description;
- не используется ли она в хлебных крошках или в sitemap;
- не ведут ли на неё внутренние ссылки из галерей и блоков изображений.
Какой способ выбрать: редирект, noindex или отключение шаблона
Для attachment-страниц обычно есть три рабочих подхода. Они не взаимозаменяемы полностью, поэтому выбирать нужно по задаче.
| Подход | Когда подходит | Минус |
|---|---|---|
| 301-редирект на файл или родительскую запись | Если attachment-страницы не нужны вообще | Нельзя сохранить отдельную страницу вложения |
| noindex, follow | Если страницы должны открываться, но не индексироваться | URL остаётся доступным и может попадать в обходные отчёты |
| Отключение шаблона attachment в теме | Если вы контролируете тему и хотите убрать страницу как сущность | Нужно аккуратно обработать редиректы и совместимость |
На практике чаще всего ставят 301-редирект с attachment на родительскую запись, если она есть, либо на сам файл изображения. Это самый чистый вариант, если отдельные страницы вложений вам не нужны.
Пошаговое решение через functions.php или мини-плагин
Если у вас есть доступ к коду, лучше сделать это в отдельном мини-плагине или в mu-plugin, а не в теме. Тогда правило не исчезнет после смены шаблона.
Вариант 1: редирект attachment-страниц на родительскую запись
Этот способ подходит, если у вложения есть post_parent и вы хотите отправлять пользователя и поисковик на основную статью.
<?php
/**
* Plugin Name: Attachment Redirect
*/
add_action('template_redirect', function () {
if (!is_attachment()) {
return;
}
$attachment_id = get_queried_object_id();
$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;
}
});Логика простая: если у вложения есть родитель, редиректим на него. Если родителя нет, отправляем на сам файл. Это лучше, чем оставлять пустую attachment-страницу в индексе.
Вариант 2: оставить страницу открытой, но поставить noindex
Если по какой-то причине attachment-страницы нужны пользователям, но не нужны в поиске, можно добавить noindex, follow. Это не удаляет URL из сайта, но даёт поисковику сигнал не включать его в индекс.
<?php
add_filter('wp_robots', function ($robots) {
if (is_attachment()) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
});Этот способ имеет смысл только если у вас корректно отрабатывает robots meta в теме и нет конфликтов с SEO-плагином. Если SEO-плагин уже управляет robots, проверьте, не перетирает ли он ваш фильтр.
Вариант 3: убрать attachment из sitemap и внутренних ссылок
Даже после редиректа полезно убедиться, что attachment-URL не попадают в карту сайта и не используются в шаблонах. Если sitemap генерирует SEO-плагин, проверьте его настройки на предмет медиа-страниц. Если ссылки на attachment появляются в галереях или блоках, лучше заменить их на ссылку на файл или на запись.
Для контентной части это особенно важно, если редакторы часто вставляют изображения через стандартную медиабиблиотеку и не следят, куда ведёт клик по картинке.
Диагностика после внедрения: что должно измениться
Проверка нужна не только в браузере. Сначала откройте несколько attachment-URL вручную и убедитесь, что они ведут туда, куда вы ожидаете. Потом проверьте заголовки ответа сервера и robots meta.
- attachment-страница отдаёт
301, если вы выбрали редирект; - нет цепочки из нескольких редиректов;
- в HTML отсутствует индексируемая страница вложения, если вы используете noindex;
- в Search Console новые attachment-URL не появляются как «страницы с перенаправлением» или «дубликаты»;
- внутренние ссылки в контенте не ведут на attachment вместо основной записи.
Проверить заголовки можно через браузерные инструменты разработчика или через curl:
curl -I https://example.com/sample-attachment/Если редирект настроен правильно, в ответе должен быть 301 и заголовок Location с целевым URL. Если вы ставили noindex, проверьте исходный код страницы и наличие <meta name="robots" content="noindex,follow"> или эквивалентного заголовка/мета-тега, который генерирует ваша связка.
Частые ошибки и как их исправить
Редирект на главную страницу для всех attachment
Это распространённая, но грубая схема. Она маскирует проблему, но не решает её аккуратно: поисковик получает нерелевантный редирект, а пользователь — страницу, не связанную с исходным объектом. Лучше редиректить на родительскую запись или на сам файл.
Закрытие только через robots.txt
Robots.txt не удаляет уже известные URL из индекса и не мешает поисковику хранить их как найденные страницы. Для attachment это слабое решение: URL может остаться в выдаче без контента. Если нужно убрать страницу из индекса, используйте редирект или noindex.
Конфликт с SEO-плагином
Если у вас уже стоит SEO-плагин, он может управлять robots meta, canonical и sitemap. В таком случае свой код нужно тестировать отдельно. Иначе вы получите ситуацию, когда тема или мини-плагин ставит noindex, а SEO-плагин тут же переписывает тег.
Редирект без проверки родителя
У части вложений родительская запись отсутствует, особенно после импорта, очистки медиатеки или переноса сайта. Если не проверять post_parent, можно отправить пользователя в никуда или получить лишнюю цепочку редиректов.
Практика безопасности и производительности
С точки зрения производительности attachment-редиректы почти не нагружают сайт, если код короткий и без лишних запросов. Но важно не вешать тяжёлую логику на каждый запрос и не проверять медиа через дополнительные SQL-запросы без необходимости.
Если вы используете мини-плагин, храните его отдельно от темы и не правьте ядро. Это снижает риск потерять настройку при обновлении. Для крупных сайтов полезно ещё и периодически проверять медиатеку на «осиротевшие» вложения — те, у которых нет родителя и которые не используются в контенте. Но удалять их нужно осторожно: сначала убедитесь, что файл не вставлен вручную в записи, виджеты или кастомные поля.
Если нужен более широкий технический аудит дублей, каноникалов и служебных страниц, иногда удобнее собрать это в одном наборе правил через SEO-плагин или отдельный инструмент для чистки сайта. Например, у Clearfy Pro есть блоки для управления дублями и служебными страницами: https://wpshop.ru/plugins/clearfy. Но даже в таком случае attachment-логику лучше проверить вручную, а не полагаться только на галочки в интерфейсе.
Как понять, что решение сработало
После внедрения не ограничивайтесь одной ручной проверкой. Смотрите на поведение URL в течение нескольких дней, особенно если сайт часто переобходит роботами.
- Откройте несколько attachment-URL и проверьте код ответа.
- Убедитесь, что редирект ведёт на релевантную страницу, а не на случайный адрес.
- Проверьте исходный код страницы, если используете noindex.
- Посмотрите отчёты Search Console по страницам с перенаправлением и исключённым URL.
- Сравните sitemap до и после: attachment не должны там появляться.
Если после всех правок attachment-страницы всё ещё индексируются, значит, где-то остался старый внутренний линк, кэш CDN отдаёт устаревший ответ или SEO-плагин генерирует собственные правила. В таком случае ищите источник по цепочке: шаблон темы, медиабиблиотека, sitemap, кэш и редиректы сервера.