Attachment-страницы в WordPress часто всплывают как технический мусор: у изображения есть отдельная страница, но сама страница не несёт пользы пользователю и может создавать дубли в индексе. Проблема обычно проявляется после аудита: в поиске находятся URL вида /attachment/ или вложения с тонким контентом, а в отчётах по индексации растёт количество бесполезных страниц.
Отключать такие страницы нужно аккуратно. Если просто закрыть их без проверки, можно потерять внутренние ссылки, сломать старые URL из выдачи или получить цепочки редиректов. Ниже — рабочий сценарий: как диагностировать проблему, что именно отключать и как проверить, что сайт после правки ведёт себя нормально.
Когда attachment-страницы действительно мешают
Не каждая медиа-страница вредна одинаково. В одних проектах WordPress attachment-URL уже давно не используются и только засоряют индекс. В других на них завязаны старые ссылки из соцсетей, картинок или внешних материалов. Поэтому сначала смотрим не на сам факт наличия attachment, а на то, как они живут на сайте.
Признаки проблемы
- в поиске есть страницы вложений с пустым или почти пустым описанием;
- в отчётах Search Console появляются URL с низкой ценностью и без трафика;
- внутренние ссылки ведут не на файл изображения, а на attachment-страницу;
- при открытии вложения пользователь видит отдельную страницу вместо самого файла;
- на сайте есть старые материалы, где картинки вставлялись через ссылку на attachment.
Диагностика: что именно у вас открывается по URL вложения
Перед изменениями проверьте, как WordPress сейчас обрабатывает attachment-страницы. Важно понять, это обычная страница вложения, редирект на медиафайл или уже кастомная логика темы/плагина.
Самый простой тест — открыть несколько URL вложений вручную и посмотреть:
- какой код ответа возвращается;
- есть ли редирект на файл изображения;
- не подменяет ли тема шаблон attachment.php;
- не используются ли такие URL в меню, хлебных крошках или блоках.
Если нужен быстрый технический просмотр, можно проверить заголовки ответа через curl:
curl -I https://example.com/attachment/sample-image/Ищите 200, 301 или 404. Если страница отдаёт 200 и при этом не несёт пользы, это кандидат на отключение. Если уже есть редирект, не дублируйте его второй логикой в коде.
Что лучше: плагин, код или редирект
Для этой задачи обычно есть три подхода. Выбор зависит от того, хотите ли вы просто убрать страницы из индекса или полностью отключить их открытие.
| Подход | Когда подходит | Минус |
|---|---|---|
| Плагин для SEO/чистки сайта | Нужно быстро закрыть техстраницы без правки темы | Может добавить лишнюю зависимость и не всегда даёт точный контроль |
Код в functions.php или мини-плагине | Нужен предсказуемый результат и контроль над редиректом | Требует аккуратного тестирования после обновлений |
| Редирект через сервер или .htaccess | Нужно закрыть старые URL на уровне веб-сервера | Сложнее сопровождать, особенно если логика зависит от типа вложения |
Если у вас типовой сайт и не хочется собирать логику вручную, можно использовать инструменты для SEO-чистки вроде Clearfy Pro: в таких задачах полезно именно отключение технических дублей и лишних страниц, а не тяжёлый комбайн с десятком разрозненных настроек. Но если нужен точный контроль, код надёжнее.
Пошаговое решение через код
Самый безопасный вариант — не удалять attachment-страницы физически, а перенаправлять их на сам файл или на родительскую запись, если она есть. Это сохраняет старые URL и не оставляет пустых страниц в индексе.
Вариант 1: редирект attachment-страницы на файл
Если у вложения есть прямой файл, можно отправлять пользователя туда. Этот способ уместен, когда attachment-страницы не нужны вообще.
add_action('template_redirect', function () {
if (!is_attachment()) {
return;
}
$file = wp_get_attachment_url(get_queried_object_id());
if ($file) {
wp_redirect($file, 301);
exit;
}
wp_safe_redirect(home_url('/'), 301);
exit;
});Что делает код: если открыт attachment-URL, WordPress пытается получить прямой URL файла и отправляет туда 301-редирект. Если файл не найден, пользователь уходит на главную. Это лучше, чем отдавать пустую страницу.
Вариант 2: редирект на родительскую запись
Если вложения вставлены в статьи и у них есть родительский пост, логичнее вести пользователя туда. Такой вариант полезен для старых сайтов, где attachment-страницы уже попадали в индекс и на них могли быть внешние ссылки.
add_action('template_redirect', function () {
if (!is_attachment()) {
return;
}
$post_id = get_queried_object_id();
$parent_id = wp_get_post_parent_id($post_id);
if ($parent_id) {
wp_safe_redirect(get_permalink($parent_id), 301);
exit;
}
$file = wp_get_attachment_url($post_id);
if ($file) {
wp_redirect($file, 301);
exit;
}
wp_safe_redirect(home_url('/'), 301);
exit;
});Здесь сначала проверяется родительская запись, потом файл. Это снижает риск отправить пользователя в никуда, если вложение без привязки к статье.
Что делать с индексацией
Редирект — это не только про UX, но и про индексацию. Если attachment-страницы уже в поиске, после внедрения кода проверьте, что они отдают 301, а не 200. Тогда поисковик со временем переедет на целевой URL.
Если вы по какой-то причине не хотите редиректить, а хотите только закрыть страницы от индексации, этого недостаточно для старых URL в выдаче. Такие страницы могут ещё долго висеть в индексе, поэтому для технического мусора редирект обычно практичнее.
Проверка результата после внедрения
После правки не ограничивайтесь открытием одной страницы в браузере. Проверьте цепочку целиком.
- Откройте несколько attachment-URL в режиме инкогнито.
- Убедитесь, что они отдают
301, а не200. - Проверьте, что целевой URL открывается без второго редиректа.
- Посмотрите, не появились ли ошибки в логах сервера.
- Проверьте внутренние ссылки в постах: они должны вести на нужный файл или на страницу записи, а не на пустое вложение.
Для быстрой проверки можно использовать и браузер, и консоль:
curl -I https://example.com/sample-image/
curl -I https://example.com/wp-content/uploads/2026/01/sample-image.jpgЕсли первый URL отдаёт 301, а второй — 200, значит логика работает корректно: attachment-страница закрыта, сам файл доступен.
Частые ошибки и как их исправить
Редирект зацикливается
Такое бывает, если в коде редирект ведёт на тот же URL или на страницу, которая сама снова попадает под условие is_attachment(). Проверьте целевой адрес и не используйте общую логику редиректа без точной проверки типа страницы.
Сломались старые ссылки из контента
Причина обычно в том, что раньше изображения вставлялись через attachment-страницу, а не через файл. В этом случае лучше вести на родительскую запись или на сам файл, а не на главную. Иначе вы теряете контекст.
Появились 404 вместо редиректа
Это значит, что у вложения нет файла или он был удалён. Тогда нужно либо восстановить медиа, либо настроить fallback на родительскую запись. Не оставляйте такие URL без обработки, если они уже были в индексе.
Плагин SEO и код делают одно и то же
Если вы уже включили редирект или отключение attachment-страниц в плагине, не дублируйте это в теме. Двойная логика часто даёт неожиданные цепочки и усложняет отладку.
Практические советы по безопасности и производительности
Не редактируйте functions.php напрямую на боевом сайте без бэкапа. Для такой логики лучше использовать дочернюю тему или небольшой mu-plugin, чтобы не потерять изменения при обновлении темы.
Если сайт большой, после внедрения проверьте логи и карту обхода. Массовые редиректы на медиафайлы могут быть нормальными, но если у вас тысячи старых attachment-URL, лучше отслеживать, не создают ли они лишнюю нагрузку на сервер и не плодят ли цепочки.
И ещё один практический момент: если медиафайлы используются в email-рассылках, документации или внешних статьях, не удаляйте сами файлы только ради чистки attachment-страниц. Убирайте именно страницу вложения, а не активный файл.
Если нужен более широкий набор инструментов для технической чистки WordPress, имеет смысл смотреть не только на attachment-страницы, но и на дубли, архивы и служебные URL. В таких задачах удобно, когда один инструмент закрывает несколько типовых проблем без ручного набора разрозненных правок.