Attachment-страницы в WordPress часто всплывают как технический мусор: у изображения есть отдельная страница вложения, но на ней почти нет полезного контента. В результате в индекс попадают тонкие страницы, которые не дают трафик, размазывают внутреннюю перелинковку и иногда создают дубли с медиафайлами или постами, где эти изображения используются.
Если у вас уже есть статьи про архивы автора, даты и поисковые страницы, следующий логичный шаг — разобрать именно attachment-страницы. Это отдельная зона риска: их нельзя просто массово удалить, если на них завязаны старые ссылки, превью в соцсетях или пользовательские переходы из медиатеки.
Когда attachment-страницы действительно мешают
Проблема обычно проявляется не в админке, а в поиске и аналитике. Типичные сигналы:
- в Google Search Console появляются URL вида
/attachment/или страницы с названием файла изображения; - в индексе есть страницы вложений без текста и с одним изображением;
- по сайту ходят внутренние ссылки на attachment-URL, хотя они не нужны пользователю;
- после миграции или импорта медиа старые attachment-страницы продолжают отдавать 200 OK;
- в sitemap попадают URL, которые не должны конкурировать с основными страницами.
Отдельно проверьте, не используются ли attachment-страницы как посадочные в старых темах или плагинах галерей. Если да, простое закрытие без редиректа может сломать переходы из старых материалов.
Что именно нужно найти перед изменениями
Сначала посмотрите, как у вас сейчас устроены ссылки на вложения. В WordPress attachment-страница — это не сам файл изображения, а отдельная запись типа attachment. Она может открываться по собственному permalink, даже если файл лежит в /uploads/.
Проверьте три вещи:
- есть ли у вложений отдельные URL в индексе;
- открываются ли они с кодом ответа 200;
- куда ведут ссылки из медиабиблиотеки и старых постов.
Как закрыть attachment-страницы: сравнение подходов
Есть три рабочих сценария. Выбор зависит от того, нужны ли вам эти страницы пользователю и есть ли уже трафик на них.
| Подход | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Редирект на файл или родительскую запись | Если attachment-страницы не нужны вообще | Сохраняет старые переходы, убирает тонкие страницы | Нужно аккуратно выбрать цель редиректа |
noindex для attachment | Если страницы должны открываться, но не индексироваться | Мягкий вариант без ломки URL | Страница остаётся доступной и может продолжать расходовать краулинг |
| Отключение attachment-страниц на уровне кода | Если нужен полный контроль | Предсказуемое поведение, можно учесть исключения | Требует правки темы или мини-плагина |
На практике чаще всего лучше редирект + запрет индексации. Это безопаснее, чем просто ставить noindex, потому что старые URL перестают быть конечной точкой для роботов и пользователей.
Пошаговое решение через код
Если вы контролируете тему или используете небольшой mu-plugin, можно закрыть attachment-страницы и отправить их на родительскую запись, а если родителя нет — на сам файл. Это рабочая схема для большинства сайтов.
<?php
add_action('template_redirect', function () {
if (!is_attachment()) {
return;
}
$post = get_queried_object();
if (!$post || empty($post->ID)) {
return;
}
$parent_id = wp_get_post_parent_id($post->ID);
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;
});Этот вариант делает две вещи: убирает отдельную attachment-страницу из пользовательского пути и сохраняет переход на полезный контент. Если у вложения есть родительская запись, пользователь попадает туда. Если нет — на сам файл изображения.
Как добавить noindex для вложений
Если вы не хотите редиректить attachment-URL, но хотите убрать их из индекса, добавьте мета-тег robots. Это не заменяет редирект, но помогает как дополнительный слой.
<?php
add_action('wp_head', function () {
if (is_attachment()) {
echo '<meta name="robots" content="noindex,follow">' . "\n";
}
});Важно: если вы уже используете SEO-плагин, проверьте, не ставит ли он свои правила для attachment-страниц. Дублирующие директивы обычно не критичны, но лучше оставить один источник истины.
Диагностика после внедрения
Проверять нужно не только визуально. Сначала откройте несколько старых attachment-URL вручную и посмотрите код ответа и конечный адрес. Затем проверьте индексацию и внутренние ссылки.
- Откройте attachment-URL в браузере: он должен вести на родительскую запись или на файл.
- Проверьте заголовки ответа через
curl -I https://example.com/attachment-url/. - Убедитесь, что в HTML страницы вложения больше нет отдельного контента для индексации.
- В Google Search Console проверьте, исчезают ли URL вложений из отчётов по страницам.
Пример проверки через консоль:
curl -I https://example.com/sample-image/
# ожидаемо:
# HTTP/2 301
# location: https://example.com/parent-post/Если у вас остался 200 OK, значит редирект не сработал: либо код не подключён, либо условие is_attachment() не выполняется в нужном месте.
Частые ошибки и как их исправить
Редирект ведёт на главную
Такое часто делают «на всякий случай», но это плохой вариант. Пользователь теряет контекст, а поисковый робот получает слабый сигнал о релевантности. Лучше отправлять на родительскую запись или на сам файл, если родителя нет.
Сломались старые ссылки из медиабиблиотеки
Если тема или плагин использовали attachment-страницы как часть галереи, массовый редирект может изменить поведение старых блоков. В этом случае сначала найдите такие места через поиск по контенту и шаблонам, а затем решите, нужен ли точечный исключающий список.
Страница всё ещё индексируется после noindex
Это нормально в краткосрочной перспективе: поисковику нужно время на повторный обход. Если URL продолжает появляться долго, проверьте, нет ли на него внутренних ссылок, sitemap-ссылок или каноникала, указывающего на сам attachment.
Редирект сделан через плагин, но конфликтует с кэшем
Иногда кэш отдает старую версию страницы без редиректа. После изменения правил очистите серверный и плагинный кэш, а затем проверьте ответ в режиме инкогнито и через curl.
Что проверить после очистки индекса
Когда редиректы и запреты уже работают, не останавливайтесь на одном URL. Проверьте всю группу вложений:
- страницы изображений в старых статьях;
- вложения PDF и документов;
- медиа, которые были загружены до смены темы;
- URL с разными форматами слэша и без него;
- страницы вложений, на которые ведут внешние ссылки.
Если у вас много старого контента, удобно сначала собрать список attachment-URL из логов или Search Console, а потом прогнать их пачкой через проверку ответов сервера.
Практические советы по безопасности и производительности
Не вносите такие правки прямо в файл темы, если тема обновляется. Для этого лучше использовать mu-plugin или небольшой кастомный плагин. Так вы не потеряете изменения после обновления и сможете быстро отключить логику, если что-то пойдёт не так.
Если на сайте уже есть SEO-плагин, проверьте его настройки перед добавлением кода. Иногда достаточно штатной опции, а ручной код нужен только для редиректа. Если вы используете Clearfy Pro, имеет смысл сначала посмотреть, не закрывает ли он attachment-страницы и другие технические дубли уже встроенными настройками; это уменьшает количество самописных правок и упрощает поддержку.
Для производительности полезно не оставлять attachment-страницы как отдельные точки входа. Чем меньше бесполезных URL отдает сайт, тем меньше лишней работы у краулера и кэша. Но не путайте это с удалением самих файлов: речь именно о страницах вложений, а не о медиафайлах в /uploads/.
Если нужно быстро проверить, не осталось ли у вас открытых attachment-страниц, используйте поиск по сайту и отчёты Search Console. На больших проектах это быстрее и надёжнее, чем вручную открывать десятки URL.