Attachment-страницы в WordPress часто всплывают в индексе как тонкие страницы без полезного контента. Проблема обычно не в самих медиафайлах, а в том, что у вложений есть отдельные URL, которые поисковик может считать самостоятельными страницами. Если на сайте много изображений, это быстро превращается в мусорный индекс, дубли и лишние обходы роботом.
Ниже — рабочая схема: как найти такие URL, что именно закрывать, как не сломать медиа в контенте и как проверить, что после правки в индексе остались только нужные страницы.
Когда attachment-страницы становятся проблемой
Сценарий обычно одинаковый: в отчёте индексации появляются URL вида /image-name/ или ?attachment_id=123, а в поиске — страницы без текста, с одним изображением и кнопкой возврата. Для пользователя это бесполезно, для SEO — лишний дубль. Особенно заметно это на сайтах с галереями, новостями, рецептами, портфолио и большими архивами медиа.
Проверить наличие проблемы можно быстро:
- в Google Search Console открыть отчёт по страницам и посмотреть URL с типом Просканировано, но не проиндексировано или Дубли, выбран другой канонический URL;
- в поиске выполнить запрос
site:example.com inurl:attachmentилиsite:example.com inurl:/wp-content/uploads/; - открыть несколько attachment-URL вручную и посмотреть, есть ли там реальный контент, кроме изображения.
Что именно нужно закрывать
Важно не путать медиафайл и attachment-страницу. Сам файл в /wp-content/uploads/... может быть нужен и должен открываться, а вот страница-обёртка вокруг него чаще всего не нужна в индексе. Если на attachment-странице нет описания, заголовка, связанного контента и она не даёт ценности, её лучше либо редиректить на сам файл, либо на родительскую запись.
Подходы и компромиссы
| Способ | Что делает | Плюс | Минус |
|---|---|---|---|
| Плагин SEO/чистки | Ставит noindex или редирект для attachment | Быстро и без кода | Зависимость от плагина и его настроек |
| Код в теме или мини-плагине | Редиректит attachment-страницы программно | Контроль и предсказуемость | Нужно аккуратно тестировать |
| Оставить как есть | Ничего не менять | Нет риска сломать поведение | Дубли и мусорный индекс остаются |
Пошаговое решение через код
Если вам нужен стабильный вариант без лишних настроек в админке, проще всего сделать редирект attachment-страниц на родительскую запись, а если родителя нет — на главную или на сам файл. Код лучше класть в мини-плагин или в functions.php дочерней темы, но не в основную тему, которую потом легко обновить и потерять правку.
<?php
add_action( 'template_redirect', function () {
if ( is_attachment() ) {
$parent_id = wp_get_post_parent_id( get_queried_object_id() );
if ( $parent_id ) {
wp_safe_redirect( get_permalink( $parent_id ), 301 );
exit;
}
$file_url = wp_get_attachment_url( get_queried_object_id() );
if ( $file_url ) {
wp_safe_redirect( $file_url, 301 );
exit;
}
wp_safe_redirect( home_url( '/' ), 301 );
exit;
}
} );Логика здесь простая: если у вложения есть родительская запись, пользователь и робот попадают туда. Если родителя нет, можно отправить на сам файл, чтобы не ломать прямые ссылки на изображение. Такой вариант обычно безопаснее, чем редиректить всё подряд на главную.
Если нужен noindex вместо редиректа
Иногда attachment-страницы нужны для внутренних ссылок или старых материалов, и тогда редирект может быть слишком агрессивным. В этом случае можно оставить страницу доступной, но убрать её из индекса через мета-тег robots. Это не так чисто, как редирект, но иногда подходит лучше.
<?php
add_action( 'wp_head', function () {
if ( is_attachment() ) {
echo '<meta name="robots" content="noindex,follow">' . "\n";
}
}, 1 );Если используете SEO-плагин, проверьте, не ставит ли он уже собственный canonical или noindex. Два разных решения одновременно иногда дают странный результат: страница остаётся доступной, но поисковик получает противоречивые сигналы.
Диагностика перед внедрением
Перед изменениями стоит понять, как именно attachment-страницы сейчас формируются на сайте. На разных темах и плагинах поведение отличается: где-то attachment-URL открывается с шаблоном темы, где-то сразу редиректится, а где-то уже закрыт SEO-плагином. Если не проверить это заранее, легко получить цепочку редиректов или потерять нужные ссылки на изображения.
- Откройте 3–5 attachment-URL из разных разделов сайта.
- Проверьте HTTP-ответ через DevTools или
curl -I. - Посмотрите, есть ли canonical на саму attachment-страницу.
- Сравните поведение для вложений с родителем и без родителя.
curl -I https://example.com/sample-image/Если в ответе уже есть 301 или 302, не добавляйте второй редирект поверх существующего. Сначала найдите источник: тема, SEO-плагин, редирект-плагин или кастомный код.
Как проверить, что решение сработало
После внедрения важно проверить не только браузер, но и то, что видит поисковый робот. Иначе можно получить красивый редирект для пользователя и всё тот же мусорный URL в индексе.
- Откройте attachment-страницу в браузере и убедитесь, что она ведёт на нужный URL.
- Проверьте код ответа: для редиректа должен быть
301. - В Search Console отправьте проверку URL и посмотрите, как Google видит конечную страницу.
- Через несколько дней повторно проверьте запрос
site:example.com inurl:attachment.
Если вы выбрали вариант с noindex,follow, убедитесь, что страница действительно отдаёт мета-тег в <head>, а не только в визуальном шаблоне. Поисковик ориентируется на HTML-ответ, а не на то, что видно в редакторе темы.
Частые ошибки и как их исправить
Редирект на главную для всех вложений
Так делают часто, но это не всегда правильно. Если у изображения есть родительская запись, лучше вести туда. Массовый редирект на главную ухудшает поведение пользователя и может скрыть полезную связь между медиа и контентом.
Конфликт с SEO-плагином
Если плагин уже ставит canonical или noindex, а вы добавили ещё и редирект, можно получить нестабильное поведение. Решение одно: оставить один источник логики. Либо плагин, либо код.
Редирект ломает прямые ссылки
Если у вас есть внешние ссылки на attachment-страницы, резкий редирект на другой тип URL может быть нежелателен. В таком случае сначала проверьте статистику переходов и только потом меняйте схему.
Путают attachment-страницу и файл изображения
Это самая частая ошибка. Закрывать нужно не сами файлы в /uploads/, а именно страницы-обёртки. Иначе можно сломать отображение картинок в контенте, Open Graph-превью и загрузку медиа на сайте.
Практические советы по безопасности и производительности
Если сайт большой, не пытайтесь массово править attachment-URL вручную в базе. Это долго, рискованно и легко приводит к ошибкам в ссылках. Лучше использовать один предсказуемый механизм на уровне шаблона или SEO-плагина.
Для сайтов с большим количеством медиа полезно дополнительно проверить:
- не создаёт ли тема отдельные шаблоны для вложений;
- не генерируются ли лишние архивы изображений и страниц медиа;
- не дублируются ли изображения в sitemap;
- не открываются ли attachment-страницы через параметры и старые ссылки.
Если нужен более широкий контроль над дублями, техническими страницами и чисткой SEO-шума, иногда удобнее использовать специализированный набор настроек вроде Clearfy Pro, но только если он реально закрывает вашу задачу без лишних модулей. Смотрите на результат в HTML и в индексе, а не на количество включённых опций.
Главный критерий здесь простой: attachment-страницы не должны конкурировать с полезными страницами сайта. Если после правки в индексе остались только нужные URL, а медиа на сайте открываются без ошибок, значит схема работает.