Если в индексе появились странные URL вида /sample-image/, /my-photo/ или страницы вложений с пустым контентом, источник часто один и тот же: attachment pages. WordPress создаёт отдельную страницу для каждого загруженного файла, и на небольших сайтах это незаметно, а на контентных проектах быстро превращается в пачку дублей и мусорных страниц.
Проблема не в самих изображениях, а в том, что у вложения есть собственный permalink, который может индексироваться, попадать в sitemap или конкурировать с основной страницей статьи. Ниже разберём, как проверить, что именно у вас происходит, и что лучше сделать: закрыть вложения от индексации, редиректить их на файл или полностью убрать из выдачи.
Как понять, что дубли создают именно страницы вложений
Сначала не трогайте код. Проверьте симптомы в поиске и в админке. На практике attachment pages выдают себя довольно одинаково:
- в поиске находятся URL с названием картинки или файла;
- страницы открываются без полезного контента, иногда только с изображением и заголовком;
- в sitemap есть URL, которые не должны быть посадочными страницами;
- в отчётах по индексации растёт количество «Просканировано, но не проиндексировано» или похожих статусов;
- одна и та же картинка доступна и как файл, и как HTML-страница вложения.
Быстрая диагностика в браузере и через поиск
Откройте несколько URL вложений вручную. Если адрес выглядит как обычная страница записи, но контент там пустой или почти пустой, это кандидат на удаление из индекса. Ещё полезно проверить, как WordPress формирует ссылку на attachment в теме или в плагине:
<?php
$attachment_id = 123;
echo get_permalink( $attachment_id );
Если функция возвращает HTML-страницу вложения, а вам нужен только файл, значит проблема не в медиа, а в логике вывода ссылок и индексации.
Что лучше сделать: сравнение вариантов
Для вложений есть три рабочих подхода. Выбор зависит от того, нужны ли вам отдельные страницы медиафайлов вообще.
| Подход | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Закрыть от индексации | Если страницы вложений не нужны в поиске, но ссылки могут остаться | Быстро, безопасно, минимум вмешательства | URL всё ещё существует, просто не индексируется |
| Редирект на файл или родительскую запись | Если attachment page не несёт ценности | Убирает мусорный HTML-URL из обхода | Нужно аккуратно настроить, чтобы не сломать вложения без родителя |
| Отключить генерацию attachment URL в теме/плагине | Если вы контролируете код и хотите убрать источник ссылок | Чистое решение на уровне шаблонов | Нужно проверить все места, где ссылка могла использоваться |
Пошаговое решение: редирект attachment pages на файл или запись
Самый практичный вариант для большинства сайтов — не оставлять вложения как отдельные страницы. Если у файла есть родительская запись, можно отправлять пользователя на неё. Если родителя нет, логичнее вести на сам файл.
Добавьте код в functions.php дочерней темы или в собственный небольшой плагин:
<?php
add_action( 'template_redirect', function () {
if ( is_attachment() ) {
$attachment_id = get_queried_object_id();
$parent_id = wp_get_post_parent_id( $attachment_id );
if ( $parent_id ) {
wp_safe_redirect( get_permalink( $parent_id ), 301 );
exit;
}
$file_url = wp_get_attachment_url( $attachment_id );
if ( $file_url ) {
wp_safe_redirect( $file_url, 301 );
exit;
}
}
} );
Что делает этот код:
- ловит любой запрос к attachment page;
- проверяет, есть ли родительская запись;
- если родитель есть — редиректит на неё;
- если родителя нет — отправляет на сам файл;
- использует
wp_safe_redirect(), а не голыйheader(), что безопаснее для WordPress-контекста.
Если нужно только закрыть от индексации
Иногда редирект нежелателен: например, если у вас есть отдельные страницы медиа в фотокаталоге или вы не хотите менять поведение старых ссылок. Тогда можно оставить URL доступным, но запретить индексацию. Для этого в SEO-плагине обычно есть настройка для attachment pages. Если плагина нет, можно добавить мета-тег вручную:
<?php
add_action( 'wp_head', function () {
if ( is_attachment() ) {
echo '<meta name="robots" content="noindex,follow">' . "\n";
}
} );
Это не убирает страницу из сайта, но даёт поисковику понятный сигнал. Для большинства технических задач этого достаточно, если редирект по каким-то причинам невозможен.
Как убрать сами ссылки на attachment pages из темы
Редирект решает индексацию, но не источник проблемы. Если тема или плагин выводят ссылку на страницу вложения вместо файла, лучше исправить генерацию URL. Часто это встречается в галереях, списках изображений и кастомных блоках.
Вместо get_permalink( $attachment_id ) используйте URL файла:
<?php
$attachment_id = 123;
$file_url = wp_get_attachment_url( $attachment_id );
if ( $file_url ) {
echo esc_url( $file_url );
}
Если нужен вывод изображения с правильной ссылкой, проверьте аргументы функций вроде wp_get_attachment_image() и шаблоны, где ссылка оборачивает картинку. Нередко проблема сидит не в WordPress, а в кастомной верстке, которая по умолчанию ведёт на attachment page.
Проверка результата после внедрения
После правки не ограничивайтесь открытием пары URL в браузере. Проверьте поведение на уровне ответа сервера и индексации.
- Откройте несколько attachment URL и убедитесь, что они редиректят с кодом 301.
- Проверьте, что редирект ведёт либо на родительскую запись, либо на файл.
- Посмотрите исходный код страницы вложения: если вы выбрали noindex, в
<head>должен бытьmeta robots. - Проверьте sitemap, если он генерируется SEO-плагином: attachment URL не должны попадать туда как обычные страницы.
- В Search Console отправьте на переобход несколько старых URL и посмотрите, как меняется статус.
Технически удобно проверить ответ через curl:
curl -I https://example.com/sample-image/
В ответе должен быть 301 и корректный Location. Если видите 200 OK, значит редирект не сработал или код подключён не там, где нужно.
Частые ошибки и как их исправить
Редирект зацикливается
Такое бывает, если attachment page и целевой URL совпадают по логике или если редирект отправляет на URL, который снова обрабатывается как вложение. Проверьте, что get_permalink( $parent_id ) действительно возвращает обычную запись, а не attachment.
Сломались изображения в медиатеке
Редирект attachment pages не должен ломать сами файлы. Если проблема появилась, значит вы случайно меняете URL вложения на уровне генерации ссылок, а не только на уровне шаблона. Отделяйте HTML-страницу вложения от прямого файла.
Страницы всё равно индексируются
Один noindex не всегда решает вопрос сразу. Если URL уже в индексе, поисковику нужно время на переобход. Ускорить процесс помогает 301-редирект и удаление URL из sitemap.
Код вставили в родительскую тему
После обновления темы правка исчезнет. Для таких задач используйте дочернюю тему или собственный мини-плагин. Это особенно важно, если сайт живёт на обновляемой коммерческой теме.
Безопасность и производительность: что учесть
Сам по себе редирект attachment pages почти не нагружает сайт, но есть нюансы. Не делайте тяжёлых запросов внутри template_redirect, не тяните лишние данные из базы и не вызывайте сторонние API. Здесь нужна простая и предсказуемая логика.
Если сайт большой, проверьте ещё два момента:
- не создаёт ли плагин SEO отдельные правила для attachment pages;
- не генерируются ли ссылки на вложения в блоках, которые массово выводят изображения из медиатеки.
Для сайтов с активной медиа-библиотекой полезно периодически просматривать, какие attachment URL реально существуют и не стали ли они мусорными после миграций, импорта контента или смены темы.
Когда лучше не трогать attachment pages вручную
Если у вас фотоблог, каталог изображений или проект, где страницы медиа действительно несут смысл, массовый редирект может быть лишним. В таком случае лучше ограничиться noindex, а ссылки в шаблонах оставить только там, где это действительно нужно. Для обычных корпоративных и контентных сайтов attachment pages почти всегда лишние, но универсального правила нет — сначала смотрите на структуру контента.
Если после правки дублей стало меньше, а в индексе остались только нужные страницы, значит решение сработало. Дальше уже имеет смысл проверить соседние источники мусора: архивы, теги без контента, служебные страницы и старые вложения, которые тянутся из старых импортов.