Страницы attachment в WordPress часто всплывают в индексе сами по себе: у изображения есть отдельный URL, на нём может быть тонкий контент, а поисковик воспринимает его как самостоятельную страницу. В итоге в отчётах появляются дубли, а трафик уходит на пустые или почти пустые URL. Удалять сами файлы обычно не нужно — достаточно правильно обработать attachment-страницы.
Ниже разберём рабочую схему: как понять, что проблема именно в attachment, какие есть варианты решения и как проверить, что после правки поисковик больше не индексирует эти URL.
Когда проблема действительно в attachment-страницах
Сначала стоит убедиться, что речь не о других дублях: архивы, теги, страницы пагинации или результаты поиска. Attachment-страница обычно выглядит как отдельный URL вида /sample-image/ или /photo-name/, при этом на ней почти нет полезного текста, а в исходном коде часто присутствует canonical на саму страницу или на вложение.
Что смотреть в первую очередь
- В Google Search Console в отчёте по страницам есть URL с типом страница-вложение или просто странные одиночные URL медиафайлов.
- При открытии attachment-страницы в браузере виден только заголовок, картинка и минимум текста.
- В sitemap или внутренних ссылках есть ссылки не на запись, а на attachment URL.
- На сайте включена тема или плагин, который автоматически создаёт ссылки на страницу вложения при вставке изображения.
Если attachment-страницы уже в индексе, простое удаление ссылки из контента не решит проблему сразу. Поисковику нужно явно показать, что эти URL не являются целевыми страницами.
Какие есть варианты решения
На практике есть три подхода: закрыть attachment-страницы от индексации через noindex, перенаправлять их на файл изображения или на родительскую запись, либо вообще отключить их вывод на уровне темы/плагина. Выбор зависит от структуры сайта.
| Подход | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Noindex | Нужно сохранить URL, но убрать из индекса | Безопасно, не ломает медиа | Страница ещё доступна по прямой ссылке |
| Редирект на файл | Attachment не нужен как страница | Убирает лишний URL из обхода | Нужно аккуратно исключить вложения без родителя |
| Редирект на запись | Картинки встроены в статьи и есть родительский пост | Пользователь попадает в контекст | Не подходит для медиа-библиотеки без привязки |
Если нужен быстрый и предсказуемый вариант, чаще всего достаточно noindex плюс редирект со страницы вложения. Это не мешает загрузке файлов и не создаёт лишних страниц в индексе.
Пошаговое решение через код
Ниже пример, который добавляет noindex,follow на attachment-страницы и при необходимости делает редирект на файл изображения или на родительскую запись. Код лучше разместить в дочерней теме или в небольшом кастомном плагине.
<?php
add_action('wp_head', function () {
if (is_attachment()) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
});
add_action('template_redirect', function () {
if (!is_attachment()) {
return;
}
$post = get_queried_object();
if (!$post || empty($post->ID)) {
return;
}
$parent_id = (int) $post->post_parent;
if ($parent_id > 0) {
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;
}
});Логика здесь простая: если у вложения есть родительская запись, пользователь уходит на неё. Если родителя нет, редирект идёт на сам файл. При этом noindex остаётся полезным дополнительным сигналом для поисковиков.
Когда редирект лучше не делать
Если на attachment-страницы уже ведут внешние ссылки или они используются в каком-то старом процессе, сначала проверьте, не сломает ли редирект аналитику и внутренние переходы. В таких случаях можно оставить только noindex и убрать ссылки на attachment из шаблонов.
Если нужно закрыть attachment без кода
Иногда проще использовать SEO-плагин или инструмент для технической чистки сайта. Например, в Clearfy Pro есть функции для отключения лишних страниц и дублей, если задача шире, чем только attachment. Это удобно, когда нужно одновременно убрать несколько типов технических URL, не правя тему вручную.
Но даже при использовании плагина всё равно стоит проверить, что он не конфликтует с уже существующими редиректами, canonical и настройками sitemap. Автоматическая настройка не отменяет ручную проверку результата.
Как проверить, что решение сработало
После внедрения не ограничивайтесь открытием страницы в браузере. Нужно проверить и HTML, и HTTP-ответ, и состояние индексации.
- Откройте attachment-URL и убедитесь, что он отдаёт редирект 301 или содержит
<meta name="robots" content="noindex,follow" />. - Проверьте заголовки ответа через DevTools или
curl -I https://example.com/attachment-url/. - Посмотрите исходный код страницы: canonical не должен вести на случайный URL, если вы делаете редирект.
- В Search Console отправьте повторную проверку URL, если страница уже была в индексе.
- Через несколько обходов проверьте, исчезает ли attachment из отчётов по страницам.
curl -I https://example.com/sample-image/Если видите 301 Moved Permanently, редирект работает. Если редиректа нет, но есть X-Robots-Tag: noindex или meta robots в HTML, поисковик всё равно должен исключить страницу из индекса со временем.
Частые ошибки и как их исправить
Редирект зацикливается
Так бывает, если attachment редиректит на URL, который сам снова обрабатывается как attachment или попадает под другое правило. Проверьте, что get_permalink($parent_id) возвращает обычную запись, а не вложение.
Закрыли не только attachment, но и медиафайлы
Ошибка возникает, когда в шаблоне или плагине путают страницу вложения и сам файл изображения. Файл по адресу /wp-content/uploads/... должен оставаться доступным, если он реально используется на сайте.
Canonical указывает не туда
Если canonical на attachment-странице ведёт на саму страницу, а не на родителя или запись, поисковик может дольше держать URL в индексе. При редиректе canonical обычно уже не нужен, потому что страница не должна отдаваться как HTML.
Сломались старые ссылки из контента
Если в статьях вручную вставлялись ссылки именно на attachment-страницы, после редиректа пользователь попадёт на родительскую запись или файл. Это нормально, но стоит проверить, не теряется ли контекст. Иногда лучше заменить такие ссылки массово через поиск по базе или редактором контента.
Практические советы по безопасности и производительности
Не стоит закрывать attachment-страницы через robots.txt, если они уже в индексе. Robots.txt не удаляет URL из индекса сам по себе и может помешать поисковику увидеть noindex. Для технической чистки лучше использовать редирект или meta robots.
Если на сайте много медиа и старых вложений, проверьте ещё два момента:
- не создаёт ли тема отдельные шаблоны для attachment, которые тянут лишние запросы к базе;
- не генерируются ли attachment-ссылки в XML-карте сайта, если плагин SEO это поддерживает.
Для сайтов с большим количеством контента полезно периодически проверять, какие типы URL реально индексируются. Это помогает не только с attachment, но и с дублями архивов, страницами автора и техническими страницами фильтрации.
Короткий чек-лист перед публикацией правки
- Проверить, есть ли attachment-страницы в индексе.
- Выбрать один сценарий:
noindex, редирект на родителя или редирект на файл. - Убедиться, что редирект не ломает медиа и не создаёт цикл.
- Проверить HTML и HTTP-ответ на тестовом URL.
- Отправить страницу на повторную проверку в Search Console.
- Через несколько дней посмотреть, как меняется статус URL в отчётах.
Если задача не ограничивается только attachment-страницами, а на сайте есть ещё дубли от архивов, пагинации и служебных URL, имеет смысл решать это в комплексе. В таких сценариях удобнее сначала собрать список всех технических страниц, а уже потом закрывать их по приоритету.