В WordPress у каждого загруженного файла может появляться отдельная attachment-страница. На небольшом сайте это часто незаметно, но на живом проекте такие URL начинают индексироваться, создавать дубли и собирать мусорный трафик. При этом сами изображения в записях и страницах должны продолжать открываться как обычно — задача не в том, чтобы сломать медиа, а в том, чтобы убрать из индекса пустые или бесполезные страницы вложений.
Ниже разберём, как понять, что проблема именно в attachment-страницах, какие есть рабочие способы закрыть их от индексации и как проверить, что после правки сайт не потерял изображения, превью и вложения в редакторе.
Как понять, что у вас индексируются attachment-страницы
Сначала стоит убедиться, что речь именно о страницах вложений, а не о других дублях. В поиске это обычно выглядит как URL с хвостом, похожим на /attachment/, /image-name/ или отдельную страницу медиафайла, где почти нет полезного текста. В отчётах краулинга такие страницы часто отмечаются как тонкие или дублирующие контент.
Признаки проблемы
- в поиске находятся страницы медиафайлов без содержимого;
- в Google Search Console растёт число проиндексированных URL, которых вы не планировали;
- на сайте есть много изображений, загруженных в разные записи, но у них создаются отдельные страницы;
- по внутренним ссылкам или из карты сайта появляются URL вложений, хотя они не нужны как посадочные страницы.
Проверка простая: откройте несколько URL вложений вручную и посмотрите, есть ли там уникальный контент. Если это почти пустая страница с картинкой и стандартным шаблоном, её обычно имеет смысл закрыть от индексации или перенаправить на сам файл/родительскую запись.
Что лучше: noindex, редирект или отключение attachment-страниц
Тут важно не смешивать разные задачи. Если вам нужно только убрать страницы вложений из индекса, достаточно noindex. Если attachment-страницы вообще не нужны как отдельные URL, можно сделать редирект на сам файл или на родительскую запись. А если тема и контентная модель сайта не используют attachment-страницы вовсе, иногда проще отключить их генерацию на уровне шаблона или плагина.
| Подход | Когда подходит | Плюс | Минус |
|---|---|---|---|
| noindex | Нужно убрать из поиска, но оставить URL доступным | Минимальный риск сломать медиа | Страница остаётся доступной по прямой ссылке |
| Редирект 301 | Attachment-страницы не нужны вообще | Чистая структура URL | Нужно аккуратно выбрать цель редиректа |
| Отключение через код/плагин | На сайте много мусорных вложений и нужен системный подход | Убирает проблему на уровне логики | Требует проверки темы и плагинов |
Если у вас уже есть SEO-плагин, сначала проверьте, не умеет ли он закрывать attachment-страницы без кода. Но если нужен предсказуемый результат и минимум лишней логики, кодовый вариант часто проще контролировать.
Диагностика: где именно создаются attachment-URL
Перед правкой полезно понять, откуда они вообще берутся. WordPress создаёт attachment как отдельный тип записи. В зависимости от темы и настроек медиафайлы могут открываться как отдельная страница, а не как прямой файл в /uploads/. Это нормальное поведение ядра, но не всегда нужное для SEO.
Если вы используете SEO-плагин, проверьте три места:
- метатеги robots на attachment-страницах;
- наличие этих URL в XML-карте сайта;
- редиректы или канонические URL, которые уже могли быть настроены раньше.
Если у вас есть доступ к серверным логам или аналитике, посмотрите, не получают ли attachment-страницы внутренние переходы. Иногда проблема не в индексации как таковой, а в том, что шаблон темы сам ведёт пользователя на страницу вложения вместо записи или файла.
Пошаговое решение через код
Если нужен надёжный способ без зависимости от конкретного SEO-плагина, можно закрыть attachment-страницы от индексации через wp_robots и при необходимости добавить редирект. Это рабочий вариант для темы или небольшого mu-plugin.
1. Добавить noindex для attachment-страниц
Этот код добавляет noindex, follow только для attachment-страниц. Он не меняет поведение самих изображений в контенте и не трогает обычные записи.
<?php
add_filter( 'wp_robots', function( array $robots ) {
if ( is_attachment() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );Если у вас уже есть SEO-плагин, проверьте, не конфликтует ли он с этим фильтром. Обычно WordPress просто соберёт итоговый набор robots-правил, но дублировать логику в двух местах не стоит.
2. При необходимости сделать редирект с attachment-страницы
Если attachment-страницы не нужны совсем, можно отправлять пользователя на родительскую запись, а если её нет — на сам файл. Это уже не про индексацию, а про удобство и чистоту структуры URL.
<?php
add_action( 'template_redirect', function() {
if ( ! is_attachment() ) {
return;
}
$post = get_post();
if ( ! $post ) {
return;
}
$parent_id = $post->post_parent;
if ( $parent_id ) {
wp_safe_redirect( get_permalink( $parent_id ), 301 );
exit;
}
$file_url = wp_get_attachment_url( $post->ID );
if ( $file_url ) {
wp_safe_redirect( $file_url, 301 );
exit;
}
} );Этот вариант стоит применять осторожно. Если у вас в теме или в редакторе есть ссылки именно на attachment-страницы, после редиректа пользователь будет попадать уже не туда, куда ожидал. Поэтому сначала проверьте, используются ли такие URL в меню, блоках, старых статьях и внешних ссылках.
3. Убрать attachment-страницы из карты сайта, если они туда попали
Если SEO-плагин включает вложения в sitemap, их лучше исключить. В большинстве случаев attachment-страницы не должны быть в XML-карте сайта, если вы не используете их как полноценные посадочные страницы. Конкретный способ зависит от плагина, но логика одна: медиафайл как объект нужен, а отдельная страница вложения — нет.
Если используете SEO-плагин
В популярных SEO-плагинах обычно есть настройка для attachment-страниц или медиа-архивов. Перед тем как писать код, откройте настройки индексации и проверьте, не включён ли у вас отдельный индекс для вложений. Если плагин умеет ставить noindex на такие URL, этого может быть достаточно.
Но даже в этом случае полезно проверить итоговый HTML страницы. Иногда настройка включена, а тема или другой плагин подменяет canonical, robots или редирект. В результате в интерфейсе всё выглядит правильно, а в коде страницы — нет.
Если вы используете Clearfy Pro, имеет смысл проверить его инструменты для чистки дублей и технической оптимизации: в таких задачах удобно централизованно закрывать лишние типы страниц, не размазывая логику по теме. Это не обязательное решение, но для сайтов с большим количеством технического мусора оно часто экономит время. Ссылка: Clearfy Pro.
Проверка результата после внедрения
После правки не ограничивайтесь визуальной проверкой в браузере. Нужно убедиться, что поисковик видит именно то, что вы задумали.
Что проверить вручную
- на attachment-странице в исходном коде есть
noindex; - если настроен редирект, URL вложения отдаёт
301на нужную цель; - изображения в записях продолжают открываться и не заменились на битые ссылки;
- медиафайлы по прямому URL из
/uploads/доступны, если это требуется вашему сайту; - attachment-страницы не попадают в XML-карту сайта.
Для быстрой проверки можно использовать curl:
curl -I https://example.com/sample-attachment/
curl -s https://example.com/sample-attachment/ | grep -i robotsЕсли стоит редирект, в ответе должен быть 301 и корректный Location. Если стоит только noindex, страница должна открываться, но в HTML должен быть robots-маркер или заголовок, который это подтверждает.
Частые ошибки и как их исправить
Закрыли не attachment, а все медиафайлы
Такое бывает, если фильтр написан слишком широко и проверяет не is_attachment(), а более общий контекст. В итоге ломаются страницы вложений, но иногда заодно задеваются и другие медиа-сценарии. Исправление простое: сузьте условие до attachment-страниц и отдельно проверьте, что обычные изображения в записях не меняют URL.
Поставили редирект на несуществующую цель
Если у вложения нет родителя, а код пытается редиректить только на запись, пользователь получит ошибку или пустую страницу. В коде выше это решается запасным переходом на сам файл. Если и файл не нужен, лучше вернуть 404 или 410, но только если вы понимаете последствия для старых ссылок.
Оставили attachment-страницы в sitemap
Это частая причина, почему поисковик продолжает их обходить даже после noindex. Карта сайта подсказывает роботу, что URL важен. Если вы закрываете вложения от индексации, их лучше убрать и из sitemap, и из внутренних ссылок.
Сломали ссылки в старых записях
Иногда в контенте вручную вставляли ссылку не на файл, а на attachment-страницу. После редиректа пользователь начинает попадать на другую страницу, и это выглядит как поломка. Перед массовой правкой стоит выгрузить несколько старых материалов и проверить, куда ведут ссылки на изображения.
Чек-лист перед публикацией правки
- Проверил, что проблема именно в attachment-страницах, а не в других дублях.
- Убедился, что изображения в записях не зависят от URL attachment-страницы.
- Выбрал один подход: noindex, редирект или отключение через плагин/код.
- Проверил robots, canonical и sitemap после изменения.
- Протестировал несколько старых записей с изображениями.
- Посмотрел ответ сервера через
curl -Iили аналогичный инструмент.
Когда лучше не трогать attachment-страницы вручную
Если сайт использует медиа как отдельный контентный слой — например, фотогалереи, портфолио или каталог изображений — attachment-страницы могут быть частью структуры. В таком случае не стоит бездумно ставить редирект на всё подряд. Сначала проверьте, не завязаны ли на них внутренние ссылки, хлебные крошки, навигация или фильтры.
Если же это обычный блог, корпоративный сайт или медиа-лендинг, где attachment-страницы не несут самостоятельной ценности, закрыть их от индексации — нормальная техническая чистка. Главное — делать это точечно и после проверки, а не по принципу «поставил плагин и забыл».