Страницы вложений в WordPress часто остаются в индексе как отдельные URL, хотя для сайта они не несут полезного контента. На практике это выглядит так: в поиске появляются тонкие страницы с одним изображением, а в отчётах по индексации растёт мусор. При этом сами файлы медиа должны продолжать открываться и использоваться в записях — отключать нужно именно attachment-страницы, а не загрузку изображений.
Когда это действительно проблема
Сначала стоит понять, что именно у вас индексируется. Если в поиске находятся URL вида /attachment/... или отдельные страницы вложений с заголовком файла, это типичный сигнал, что WordPress отдаёт attachment как полноценную страницу. Особенно часто это всплывает после миграции сайта, установки SEO-плагина или активной работы с изображениями в записях и галереях.
Проверить можно несколькими способами:
- в Google Search Console открыть отчёт по страницам и посмотреть URL с вложениями;
- в поиске выполнить запрос
site:example.com attachmentили поиск по названию файла; - открыть URL медиафайла в админке WordPress и посмотреть, есть ли у него отдельная страница вложения;
- проверить, не создаёт ли тема или плагин собственные шаблоны для attachment.
Что не стоит путать
Если у вас в индексе сам файл изображения, это не всегда ошибка: картинка может быть доступна по прямому URL и использоваться на сайте. Проблема именно в HTML-странице вложения, которая обычно почти пустая и дублирует контент записи или медиафайла. Её и нужно убрать из индексации или перенаправить.
Рабочие варианты решения
Есть три нормальных подхода: отключить attachment-страницы через SEO-плагин, сделать редирект на сам файл или на родительскую запись, либо изменить поведение WordPress кодом. Выбор зависит от того, как у вас устроен сайт и нужен ли вообще отдельный просмотр вложений.
| Подход | Когда подходит | Минус |
|---|---|---|
| SEO-плагин | Если нужен быстрый и безопасный способ без правки темы | Зависит от конкретного плагина и его настроек |
| Код в теме или mu-plugin | Если нужен предсказуемый контроль без лишних зависимостей | Нужно аккуратно тестировать после обновлений |
| Редирект на файл или запись | Если attachment-страницы уже в индексе и надо убрать их из поиска | Нужно не сломать старые ссылки и вложения |
Пошаговое решение через код
Самый надёжный вариант — перенаправить attachment-страницы на родительскую запись, если она есть, или на сам файл. Это не ломает медиа и убирает отдельную HTML-страницу из обхода поисковиками.
<?php
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;
}
wp_safe_redirect(home_url('/'), 301);
exit;
});Этот вариант удобен тем, что не требует менять шаблоны темы. Но его лучше размещать не в functions.php, а в небольшом mu-plugin, если сайт активно обновляется и тема может меняться.
Если нужен именно noindex
Иногда редирект нежелателен, например если у вас есть старые ссылки на attachment-страницы и вы хотите оставить их доступными, но закрыть от индексации. Тогда можно вывести noindex на attachment-архивы через wp_head.
<?php
add_action('wp_head', function () {
if (is_attachment()) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
});Это не удаляет страницу из поиска мгновенно, но даёт поисковику понятный сигнал. На практике редирект обычно эффективнее, если attachment-страницы не нужны вообще.
Как сделать это через SEO-плагин
Если на сайте уже используется SEO-плагин, сначала проверьте его настройки. Во многих случаях attachment-страницы можно закрыть от индексации без кода. Это проще для редакторов и безопаснее для тех, кто не хочет поддерживать собственный сниппет.
Но здесь важна проверка: не все плагины одинаково работают с attachment. После изменения настройки откройте несколько URL вложений вручную и убедитесь, что они либо редиректят, либо отдают noindex, либо закрыты от индексации в соответствии с вашей схемой.
Проверка результата после внедрения
После настройки не ограничивайтесь одной ручной проверкой. Нужно убедиться, что поисковик действительно видит нужный сигнал, а медиафайлы не сломались.
- откройте attachment URL в браузере и проверьте код ответа: 301 для редиректа или 200 с
noindex; - посмотрите исходный код страницы и найдите
meta name="robots"; - проверьте, что изображение по прямому URL открывается;
- в Search Console отправьте повторную проверку URL, если они уже были проиндексированы;
- через несколько дней проверьте, уменьшается ли количество attachment-страниц в отчётах.
Если используете командную строку, можно быстро проверить редирект так:
curl -I https://example.com/attachment/example-image/В ответе должен быть 301 и заголовок Location с целевым URL.
Частые ошибки и как их исправить
Редирект ведёт на главную без причины
Так бывает, если у вложения нет родительской записи и код сразу отправляет пользователя на главную. Это рабочий запасной вариант, но не лучший для SEO. Если attachment-страниц много, лучше отправлять на сам файл или на страницу, где изображение реально используется.
Сломались изображения в медиатеке
Обычно причина в том, что редирект сделали не на attachment-страницы, а на сами файлы в uploads. Проверяйте условие is_attachment() и не трогайте URL статических файлов.
Страница закрыта, но всё ещё в индексе
Это нормально на коротком промежутке. Поисковику нужно время, чтобы переобойти URL и убрать его из выдачи. Если страница уже давно закрыта, а в индексе остаётся, проверьте, нет ли внутренних ссылок на attachment и не возвращает ли сервер 200 вместо 301 или noindex.
Плагин SEO и код конфликтуют
Если один инструмент ставит редирект, а другой добавляет noindex или canonical на другой URL, поисковик получает противоречивые сигналы. В такой ситуации оставьте один способ управления: либо плагин, либо код.
Что проверить на сайте после изменений
- attachment-страницы больше не открываются как отдельные HTML-страницы;
- прямые ссылки на изображения работают;
- внутренние ссылки из записей не ведут на пустые страницы вложений;
- в Search Console не растёт число мусорных URL;
- шаблон темы не создаёт собственный контент для attachment.
Практические замечания по безопасности и производительности
Если вы решаете задачу кодом, лучше вынести его в отдельный mu-plugin, а не в активную тему. Тогда настройка не исчезнет после смены дизайна. Для сайтов с большим количеством медиа это ещё и удобнее при аудите: один маленький файл проще проверить, чем правки в теме.
Если нужен более широкий аудит дублей, архивов и технических страниц, стоит смотреть не только на attachment, но и на другие источники мусорной индексации: архивы, параметры URL, служебные страницы и пагинацию. На практике такие задачи часто решают вместе, а не по одной.
Когда нужно быстро закрыть несколько технических дублей без ручной правки кода, можно использовать инструменты уровня Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже в этом случае проверка через Search Console и ручной просмотр URL остаются обязательными.