Attachment-страницы в WordPress часто всплывают как отдельные URL с тонким или пустым содержимым. На небольшом сайте это выглядит безобидно, но в индексе такие страницы быстро превращаются в дубли: у изображения есть сам файл, у записи есть вложение, а у поисковика — ещё одна страница без полезной нагрузки. Если не контролировать этот слой, в отчётах Search Console появляются лишние URL, а краулинговый бюджет уходит на мусор.
Ниже — рабочий сценарий: как понять, что проблема именно в attachment-страницах, как отключить их без потери самих файлов и как проверить результат после внедрения.
Когда attachment-страницы становятся проблемой
В WordPress любое медиа может иметь собственную страницу вложения. Она открывается по отдельному URL и часто содержит только картинку, заголовок и минимальный шаблон темы. Для пользователя это редко полезно, а для поиска — типичный дубль или почти пустая страница.
Типичные симптомы
- в индексе есть URL вида
/image-name/или?attachment_id=123; - в Search Console растёт число «Просканировано, но не проиндексировано» или «Дубли, Google выбрал другой канонический URL»;
- по сайту находятся страницы вложений через внутренний поиск или sitemap;
- при клике на изображение в теме пользователь попадает на отдельную страницу вместо самого файла или записи.
Диагностика: как убедиться, что это именно дубли attachment-страниц
Сначала проверьте, как тема и плагины выводят медиа. Важно не путать attachment-страницы с самими файлами изображений. Файл лежит в /wp-content/uploads/, а attachment-страница — это обычный объект WordPress с собственным permalink.
Что проверить вручную
- Откройте несколько URL вложений из медиабиблиотеки.
- Посмотрите исходный код страницы: есть ли там канонический URL, заголовок, текст или только изображение.
- Проверьте, не попадают ли такие URL в XML-карту сайта.
- Сравните поведение на одиночной записи и в архиве: иногда тема ведёт на attachment-страницу только из галереи.
Быстрая проверка через WP-CLI
Если есть доступ к WP-CLI, можно посмотреть, сколько attachment-объектов вообще есть на сайте:
wp post list --post_type=attachment --fields=ID পোস্ট_title,post_status --format=tableКоманда покажет список вложений. Если их много, это не проблема само по себе. Проблемой становятся именно публичные страницы вложений, которые индексируются и не несут ценности.
Как решить задачу без удаления файлов
Самый безопасный путь — не удалять медиа, а отключить публичные attachment-страницы и перенаправить их на родительскую запись или сам файл. Так вы сохраняете изображения в медиабиблиотеке, но убираете лишние URL из индекса.
Вариант 1: редирект attachment-страниц на родительскую запись
Если у вложения есть родительский пост, логично отправлять пользователя туда. Это особенно полезно для изображений, вставленных в статьи.
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;
}
wp_safe_redirect( home_url( '/' ), 301 );
exit;
}
} );Этот код можно добавить в дочернюю тему или в небольшой mu-plugin. Он не удаляет вложения и не ломает медиабиблиотеку.
Вариант 2: редирект на сам файл изображения
Если attachment-страницы не нужны вообще, а логика сайта строится вокруг самих файлов, можно отправлять пользователя на URL медиафайла:
add_action( 'template_redirect', function () {
if ( is_attachment() ) {
$attachment_id = get_queried_object_id();
$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;
}
} );Этот вариант подходит не для всех проектов. Если изображение должно открываться в контексте статьи, лучше редиректить на родителя, а не на файл.
Вариант 3: отключить attachment-страницы на уровне темы или плагина
Если вы используете SEO-плагин или плагин для технической чистки сайта, проверьте, умеет ли он закрывать attachment-страницы без ручного кода. Например, в Clearfy Pro есть инструменты для технической оптимизации и удаления дублей, но перед включением любой опции нужно понимать, какой именно URL она меняет и как это влияет на уже проиндексированные страницы. Для таких задач важнее не «галочка», а предсказуемое поведение после деплоя.
| Подход | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
| Редирект на родителя | Сохраняет контекст статьи | Не подходит для медиа без родителя | Контентные сайты, блоги |
| Редирект на файл | Просто и прозрачно | Пользователь уходит на «голый» файл | Медиа-архивы, фотогалереи |
| Отключение через плагин | Меньше кода | Зависимость от настроек плагина | Если нужен быстрый управляемый вариант |
Пошаговая настройка: что делать на живом сайте
- Сделайте резервную копию базы и файлов.
- Проверьте, какие attachment-URL уже в индексе.
- Выберите целевое поведение: родительская запись или файл.
- Добавьте редирект в дочернюю тему или mu-plugin.
- Очистите кэш страницы, объектный кэш и CDN, если он есть.
- Переобойдите несколько attachment-URL вручную и проверьте код ответа.
- Обновите sitemap, если attachment-страницы туда попадали.
Как проверить, что решение сработало
Проверка должна быть не визуальной, а технической. Откройте несколько старых attachment-URL и убедитесь, что они отдают 301, а не 200.
Минимальный чек-лист
- attachment-URL открывается с редиректом;
- целевой URL соответствует вашей логике: запись или файл;
- в исходном коде старой страницы нет канонического URL на саму attachment-страницу;
- в XML-sitemap больше нет attachment-URL;
- в Search Console новые ошибки по этим URL не появляются;
- внутренние ссылки с изображений ведут туда, куда вы планировали.
Если есть доступ к командной строке, можно быстро проверить ответ сервера:
curl -I https://example.com/sample-image/В ответе должен быть статус 301 и заголовок Location с целевым адресом.
Частые ошибки и как их исправить
Редирект поставили, но страницы всё равно в индексе
Это нормально на коротком отрезке времени. Поисковику нужно переобойти старые URL. Ускорить процесс можно только через корректный 301, обновление sitemap и отсутствие внутренних ссылок на attachment-страницы.
Сломались галереи или lightbox
Такое бывает, если тема или плагин галереи ожидали именно attachment-страницу. Проверьте, не используется ли ссылка на вложение как целевой URL для клика по изображению. В этом случае редирект на файл или родителя нужно согласовать с логикой галереи.
Редирект ведёт на главную без причины
Это происходит, когда у вложения нет родительской записи. Для таких объектов лучше заранее определить правило: файл, главная или отдельная медиа-страница для конкретных типов вложений.
Появился цикл редиректов
Обычно причина в том, что тема уже делает собственный редирект для attachment-страниц, а вы добавили второй. Оставьте только один источник логики: либо тема, либо плагин, либо код в mu-plugin.
Безопасность и производительность
Attachment-страницы сами по себе не опасны, но они создают лишнюю поверхность для индексации и обхода. На больших сайтах это превращается в шум в логах и отчётах. Чем меньше бесполезных URL получает бот, тем проще контролировать техническое состояние проекта.
Если вы вносите изменения кодом, не правьте файл темы напрямую. Используйте дочернюю тему или mu-plugin, чтобы редирект не исчез после обновления. И не ставьте несколько SEO-плагинов, которые одновременно пытаются управлять каноникалами и редиректами: это частая причина конфликтов.
Когда лучше не трогать attachment-страницы вручную
Если сайт построен как фотокаталог, портфолио или медиаархив, attachment-страницы могут быть частью структуры. В таком случае не нужно бездумно закрывать всё подряд. Сначала проверьте, какие URL реально приносят трафик, и только потом решайте, что редиректить, а что оставить.
Для контентных сайтов и блогов чаще всего достаточно редиректа на родительскую запись. Для медиа-проектов — отдельной логики по типам вложений. Главное здесь не удалить изображения, а убрать лишние страницы, которые не несут самостоятельной ценности.