Attachment-страницы в WordPress часто всплывают как технический мусор: у изображения есть отдельная страница вложения, она индексируется, попадает в sitemap и создаёт дубли без полезного контента. На небольшом сайте это выглядит как мелочь, но в Search Console такие URL быстро превращаются в лишние страницы с нулевой ценностью. Если задача — оставить сами файлы изображений, но убрать их страницы из поиска и карты сайта, это лучше решать точечно: сначала диагностировать, потом отключить вывод, затем проверить, что ничего важного не сломалось.
Когда attachment-страницы действительно мешают
Проблема обычно проявляется не в админке, а в индексации. В отчётах поисковика появляются URL вида /attachment/... или страницы вложений с тонким шаблоном, где кроме картинки и заголовка почти ничего нет. Такие страницы конкурируют с основными материалами, а иногда ещё и создают цепочки редиректов или дубли в sitemap, если тема или SEO-плагин добавляет их автоматически.
Особенно часто это заметно после массовой загрузки изображений, миграции сайта или смены темы. Если на сайте много медиа, attachment-страницы могут составлять заметную долю всех проиндексированных URL, хотя пользы от них нет.
Что проверить до изменений
- Откройте несколько attachment-URL вручную и посмотрите, что на них реально выводится.
- Проверьте XML sitemap: есть ли там вложения или медиа-страницы.
- Сравните canonical у attachment-страницы и у родительской записи, если она есть.
- Посмотрите, не используются ли attachment-страницы как целевые URL где-то в контенте или в старых ссылках.
Диагностика проблемы: где именно создаётся дубль
В WordPress attachment-страница может появиться по нескольким причинам. Сам WordPress создаёт запись типа attachment для каждого загруженного файла. Дальше тема или плагин решает, показывать ли отдельную страницу вложения, а SEO-плагин — включать ли её в sitemap. Поэтому лечить нужно не только индексацию, но и сам способ отдачи страницы.
Если вы видите, что URL вложений открываются как обычные страницы сайта, значит они доступны для обхода. Если они ещё и попадают в sitemap, поисковик получает прямой сигнал, что это важные URL. В реальности это не так.
Пошаговое решение без лишних побочных эффектов
Шаг 1. Перенаправить attachment-страницы на файл или родительскую запись
Самый практичный вариант — не оставлять отдельную страницу вложения вообще. Если у медиа есть родительская запись, можно отправлять пользователя туда. Если родителя нет, безопаснее вести на сам файл изображения или на главную страницу медиа не показывать как отдельный контент.
<?php
add_action('template_redirect', function () {
if (!is_attachment()) {
return;
}
$post = get_queried_object();
if (!$post || empty($post->ID)) {
wp_safe_redirect(home_url('/'), 301);
exit;
}
$parent_id = (int) $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;
}
wp_safe_redirect(home_url('/'), 301);
exit;
});
Этот вариант хорош тем, что не ломает сами файлы и не требует править шаблоны темы. Но если у вас уже есть SEO-плагин, который ставит canonical или noindex на attachment-страницы, проверьте, чтобы не получилось двойного редиректа или конфликта логики.
Шаг 2. Убрать attachment из XML sitemap
Если sitemap генерирует WordPress core или SEO-плагин, вложения нужно исключить на уровне источника. Для core sitemap можно убрать тип записи attachment через фильтр. Это не удаляет медиафайлы, а только исключает их страницы из карты сайта.
<?php
add_filter('wp_sitemaps_post_types', function ($post_types) {
if (isset($post_types['attachment'])) {
unset($post_types['attachment']);
}
return $post_types;
});
Если sitemap отдаёт SEO-плагин, логика зависит от конкретного плагина. У них обычно есть отдельная настройка для media/attachments. В таком случае лучше использовать штатное исключение в интерфейсе, а не пытаться перехватывать генерацию через код без необходимости.
Шаг 3. Закрыть индексацию для уже существующих URL
Если attachment-страницы уже успели попасть в индекс, одного редиректа может быть мало. Поисковику нужно дать понятный сигнал: страница больше не нужна. Редирект 301 обычно решает вопрос быстрее, чем просто noindex, но для старых URL полезно проверить, что они не возвращают 200 OK.
Если по каким-то причинам редирект сейчас не подходит, можно хотя бы добавить noindex, follow на attachment-страницы. Но это компромисс, а не финальное решение: такие URL всё равно останутся в обходе, просто без индексации.
Сравнение подходов
| Подход | Что делает | Плюс | Минус |
|---|---|---|---|
| Редирект на родителя | Уводит attachment-URL на связанную запись | Убирает дубль и сохраняет пользовательский путь | Не всегда есть родитель |
| Редирект на файл | Открывает сам медиафайл вместо страницы | Просто и предсказуемо | Файл не всегда удобен как целевая страница |
| Noindex | Запрещает индексацию, но оставляет URL доступным | Быстро внедряется | Не убирает дубль полностью |
Проверка результата после внедрения
После правок не ограничивайтесь открытием одной страницы в браузере. Нужно проверить три вещи: статус ответа, sitemap и поведение в поисковом обходе.
- Откройте несколько attachment-URL и убедитесь, что они возвращают 301, а не 200.
- Проверьте исходный код страницы назначения: нет ли там лишнего canonical на attachment.
- Откройте XML sitemap и убедитесь, что attachment-URL больше не присутствуют.
- В Search Console отправьте на повторную проверку несколько старых URL, если они уже были в индексе.
Для быстрой проверки статуса удобно использовать curl:
curl -I https://example.com/sample-attachment/
В ответе должен быть 301 Moved Permanently и корректный Location. Если видите 200 OK, значит редирект не сработал или его перебивает другой слой — плагин, тема, серверное правило.
Частые ошибки и как их исправить
Редирект поставили, но attachment всё равно индексируется
Чаще всего причина в том, что старые URL ещё не переобходились. Дайте поисковику время и проверьте, не остались ли ссылки на attachment-страницы внутри сайта, в старых постах или в XML sitemap.
Удалили attachment из sitemap, но страницы остались доступны
Это нормальная ситуация, если вы только исключили их из карты сайта. Для полного эффекта нужен редирект или noindex. Sitemap — это подсказка, а не блокировка.
После редиректа сломались ссылки на изображения
Так бывает, если вместо attachment-страницы редирект настроили на несуществующий родительский URL или перепутали страницу вложения с самим файлом. Проверьте, что wp_get_attachment_url() возвращает реальный путь к файлу, а не страницу вложения.
SEO-плагин снова добавляет вложения в sitemap
Тогда нужно отключать это в настройках плагина, а не только кодом. Иначе вы получите конфликт: один слой исключает URL, другой снова их публикует.
Практические советы по безопасности и производительности
Не правьте эту логику напрямую в теме, если сайт живёт на обновлениях. Лучше вынести код в небольшой mu-plugin или в собственный мини-плагин. Так вы не потеряете настройку при смене темы и не будете искать её после очередного деплоя.
Если на сайте много медиа, не пытайтесь массово удалять attachment-записи из базы без проверки. Это может затронуть связи с записями, галереями и блоками редактора. В большинстве случаев достаточно отключить страницы вложений от индексации и убрать их из sitemap.
Для сайтов, где техническая чистка и SEO-настройки часто идут вместе, удобнее держать такие правки в одном месте. Например, в Clearfy Pro есть набор инструментов для удаления дублей и технической чистки, но даже при использовании плагина полезно понимать, что именно он меняет в выводе сайта.
Что должно получиться в итоге
После внедрения attachment-страницы не должны быть отдельными индексируемыми URL. Пользователь либо попадает на родительскую запись, либо на сам файл, а sitemap больше не содержит технические дубли. Это не косметическая правка, а нормализация структуры сайта: меньше мусора в обходе, меньше лишних страниц в индексе и меньше шансов, что поисковик выберет не тот URL.