Attachment-страницы в WordPress часто всплывают неожиданно: у изображения есть отдельный URL, он попадает в индекс, а саму страницу почти никто не использует. В результате появляются пустые или слабые страницы, которые конкурируют с основным контентом. Если задача не в том, чтобы показывать медиа как отдельные материалы, attachment-страницы лучше отключить и отправлять пользователя на родительскую запись или сразу на файл.
Когда attachment-страницы становятся проблемой
Сценарий обычно один и тот же: в медиабиблиотеке много изображений, посты активно публикуются, а в поиске начинают появляться URL вида /attachment/ или страницы вложений с названием файла. Для SEO это не всегда критично, но на небольших и средних сайтах такие страницы почти никогда не несут пользы. Они размывают структуру индекса и добавляют лишние адреса, которые нужно контролировать.
Что именно стоит проверить
- есть ли в индексе URL вложений через поиск по сайту или в Google Search Console;
- открываются ли attachment-страницы как отдельные страницы с шаблоном темы;
- ведут ли они на пустую страницу без полезного текста;
- есть ли на сайте внутренние ссылки на attachment URL из старых материалов или плагинов.
Диагностика: как понять, что проблема именно в attachment-страницах
Сначала откройте несколько изображений из медиабиблиотеки в новой вкладке. Если URL выглядит как отдельная страница вложения, а не как прямой файл в /uploads/, значит WordPress отдаёт attachment template. Дополнительно проверьте исходный код страницы: если там нет полезного контента, а только заголовок и изображение, это типичный кандидат на отключение.
Ещё один практический способ — посмотреть, какие URL отдают код ответа 200. Если attachment-страницы доступны без редиректа, поисковик может продолжать их обходить. Если на сайте уже есть SEO-плагин, проверьте, не добавляет ли он noindex, но не рассчитывайте только на это: сам URL всё равно остаётся доступным и может появляться в отчётах как отдельная страница.
Как отключить attachment-страницы без плагина
Самый надёжный вариант — добавить редирект в functions.php дочерней темы или в небольшой mu-plugin. Логика простая: если запрос идёт на attachment, отправляем пользователя на родительскую запись, а если родителя нет — на главную или на сам файл, в зависимости от сценария сайта.
<?php
add_action('template_redirect', function () {
if (!is_attachment()) {
return;
}
global $post;
if ($post instanceof WP_Post && !empty($post->post_parent)) {
$parent_url = get_permalink($post->post_parent);
if ($parent_url) {
wp_safe_redirect($parent_url, 301);
exit;
}
}
wp_safe_redirect(home_url('/'), 301);
exit;
});Этот вариант удобен тем, что не ломает загрузку файлов и не трогает сами медиафайлы. Он влияет только на просмотр attachment-страниц. Если у вас есть отдельный сценарий, где attachment должен вести на файл, а не на запись, логику можно изменить, но для большинства контентных сайтов редирект на родителя работает лучше.
Если нужно отправлять на сам файл
Иногда attachment-страница вообще не нужна, а пользователю логичнее сразу открыть изображение. Тогда вместо родителя можно редиректить на URL файла из метаданных вложения:
<?php
add_action('template_redirect', function () {
if (!is_attachment()) {
return;
}
global $post;
if ($post instanceof WP_Post) {
$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;
});Этот вариант стоит использовать осторожно: если файл большой или лежит на внешнем хранилище, редирект на сам файл может быть нормальным, но не всегда полезным для UX. Для SEO обычно важнее убрать отдельную attachment-страницу, чем сохранить её как промежуточный адрес.
Сравнение подходов: код, плагин, ручная настройка
| Подход | Что делает | Плюсы | Минусы |
|---|---|---|---|
| Код в теме или mu-plugin | 301-редирект с attachment на родителя или файл | Контроль, минимум лишней логики | Нужно аккуратно внедрить и протестировать |
| SEO-плагин | Часто ставит noindex или меняет поведение архивов | Быстро включить | Не всегда убирает сам URL из обхода |
| Ничего не делать | Attachment-страницы остаются как есть | Нет внедрения | Риск дублей и пустых страниц |
Если на сайте уже используется плагин для технической чистки, например Clearfy Pro, проверьте его настройки, но не смешивайте несколько решений без необходимости. Когда один плагин ставит noindex, другой делает редирект, а третий меняет canonical, отладка становится заметно сложнее.
Пошаговое внедрение без лишнего риска
- Сделайте резервную копию файла
functions.phpили подготовьте mu-plugin. - Добавьте один из вариантов редиректа.
- Очистите кэш сайта, если он есть.
- Проверьте несколько attachment-URL вручную.
- Посмотрите, не появились ли циклы редиректа.
- Через Search Console или лог сервера убедитесь, что старые URL больше не отдаются как 200.
Как проверить, что решение сработало
Проверка должна быть не только визуальной. Откройте attachment-страницу и убедитесь, что адрес меняется на родительскую запись или файл. Затем проверьте HTTP-статус. Для быстрой диагностики удобно использовать браузерные инструменты разработчика или команду curl:
curl -I https://example.com/attachment-page/В ответе должен быть 301 и заголовок Location с новым адресом. После этого проверьте, что:
- редирект не уводит на несуществующую страницу;
- нет цепочки из нескольких 301 подряд;
- родительская запись открывается нормально;
- внутренние ссылки на attachment-страницы больше не генерируются новыми материалами.
Частые ошибки и как их исправить
Редирект поставили не там
Если код добавлен в активную тему, при смене темы он пропадёт. Для технического правила лучше использовать mu-plugin или дочернюю тему. Это особенно важно на проектах, где шаблон обновляется отдельно от логики.
Получился редирект на саму себя
Так бывает, если attachment-страница и целевой URL совпадают по логике плагина или кастомного шаблона. Проверьте, что wp_get_attachment_url() не возвращает текущий адрес страницы вложения, и что редирект не срабатывает повторно на целевой URL.
Сломались старые ссылки из контента
Если в статьях вручную вставлялись ссылки именно на attachment-страницы, после редиректа они будут вести на родителя. Обычно это нормально, но если где-то использовались такие URL как часть пользовательского сценария, их нужно заменить в базе или через поиск по контенту.
Ожидали удаления из индекса сразу
Редирект не удаляет URL мгновенно из поиска. Он лишь показывает поисковику, что адрес переехал. Для переобхода нужно время, а в Search Console полезно отправить страницу на повторную проверку, если она уже была в отчётах.
Безопасность и производительность
Редирект через template_redirect почти не нагружает сайт, но код должен быть коротким и без лишних запросов к базе. Не стоит делать сложную логику с перебором метаданных или дополнительными WP_Query на каждом открытии attachment-страницы. Если сайт большой, лучше оставить только проверку is_attachment() и один целевой URL.
Если вы используете кэширование страниц, после внедрения правила обязательно очистите кэш. Иначе старые attachment-страницы могут продолжать отдаваться из кэша как обычные 200-страницы, хотя код уже изменён.
Когда attachment-страницы лучше не отключать
Есть редкие случаи, когда отдельные страницы вложений нужны: например, у фотопортфолио, каталога иллюстраций или медиаархива с собственными описаниями. Тогда редирект на родителя может быть лишним. В таком сценарии лучше не отключать attachment-страницы полностью, а доработать шаблон, добавить текст, хлебные крошки и понятную навигацию. Но для обычного блога, новостника или корпоративного сайта это скорее исключение, чем правило.
Если нужен более широкий технический аудит дублирующихся URL и служебных страниц, имеет смысл смотреть не только на attachment-страницы, но и на архивы, теги и параметры фильтрации. В таких проектах удобно сначала убрать самые слабые страницы, а уже потом разбирать остальную индексацию.