Как убрать attachment-страницы WordPress из поиска и карт сайта

На небольших и средних сайтах attachment-страницы часто всплывают в индексе сами по себе: у изображения есть отдельный URL, тема выводит на него ссылки, а поисковик видит в этом ещё одну страницу. Проблема не в самих медиафайлах, а в том, что такие страницы обычно пустые или почти пустые и создают мусор в индексации.

Ниже разберём, как аккуратно убрать attachment-страницы из поиска и XML-карт сайта, не ломая загрузку изображений в контенте и не трогая сами файлы в /uploads/.

Когда это действительно проблема

Сначала стоит проверить, что именно у вас происходит. Не на каждом сайте attachment-страницы вредят SEO, но в типовой редакционной установке они почти всегда лишние.

Признаки, что attachment-URL лучше закрыть

• в результатах поиска есть URL вида /attachment/ или страницы с названием изображения;
• в Google Search Console растёт число «Просканировано, но не проиндексировано» для медиа-страниц;
• в sitemap попадают URL вложений, хотя на сайте нет смысла их индексировать;
• тема или плагин создают ссылки на страницу вложения вместо прямого файла;
• на сайте много изображений, загруженных в записи, и у каждого есть отдельная attachment-страница.

Проверка простая: откройте несколько изображений в медиатеке и посмотрите, ведёт ли клик по ним на отдельную страницу вложения. Если да, а эта страница не несёт самостоятельной ценности, её лучше убрать из индексации.

Что именно нужно изменить

Задача состоит из трёх частей:

1. отключить публичный вывод attachment-страниц;
2. убрать их из XML sitemap;
3. при необходимости перенаправить старые URL на сам файл или на родительскую запись.

Самый безопасный вариант — не удалять медиа, а изменить поведение URL. Тогда изображения останутся доступны в контенте, а поисковик перестанет считать attachment-страницы полезными посадочными.

Пошаговое решение через код

Если у вас есть дочерняя тема или небольшой mu-plugin, можно решить задачу без сторонних плагинов. Ниже рабочий вариант: он переводит attachment-страницы на 301-редирект к родительской записи, а если родителя нет — к самому файлу.

<?php
add_action('template_redirect', function () {
    if (!is_attachment()) {
        return;
    }

    $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;
    }

    wp_safe_redirect(home_url('/'), 301);
    exit;
});

Этот подход удобен тем, что старые ссылки не дают 404 и не висят в индексе как отдельные страницы. Но если вам нужно именно оставить attachment-страницы доступными, а из поиска убрать только их индексирование, можно использовать более мягкий вариант с noindex.

<?php
add_filter('wp_robots', function (array $robots) {
    if (is_attachment()) {
        $robots['noindex'] = true;
        $robots['follow'] = true;
    }

    return $robots;
});

Такой вариант не закрывает страницу от обхода, но подсказывает поисковику не добавлять её в индекс. Для большинства контентных сайтов этого достаточно, если нет жёсткого требования полностью убрать URL из выдачи.

Как убрать attachment-страницы из XML sitemap

Если sitemap генерируется через стандартные механизмы WordPress или SEO-плагин, нужно проверить, не попадают ли туда вложения. В WordPress 5.5+ есть встроенные XML-карты сайта, и для них можно отключить тип attachment.

<?php
add_filter('wp_sitemaps_post_types', function (array $post_types) {
    unset($post_types['attachment']);
    return $post_types;
});

Если sitemap формирует SEO-плагин, логика будет другой: у каждого решения свои настройки. Но принцип тот же — attachment не должен попадать в карту, если вы не хотите его индексировать.

Когда лучше использовать плагин, а когда код

Если у вас уже стоит плагин для SEO и он умеет отключать медиа-архивы, это допустимый путь. Но если нужна точечная и проверяемая настройка, код обычно надёжнее.

Диагностика после внедрения

После изменений важно не ограничиться визуальной проверкой. Нужно убедиться, что старые URL действительно ведут себя так, как задумано.

Что проверить вручную

• откройте несколько attachment-URL в браузере и проверьте редирект;
• посмотрите исходный код страницы и убедитесь, что на attachment стоит noindex, если вы выбрали этот вариант;
• проверьте XML sitemap и убедитесь, что там нет attachment;
• в Search Console отправьте на повторную проверку несколько старых URL;
• сделайте запрос в поиске по сайту: site:example.com attachment и отслеживайте динамику.

Если редирект не срабатывает, чаще всего проблема в том, что код добавлен не туда: например, в файл, который не загружается на фронтенде, или в плагин, отключённый на продакшене.

Частые ошибки и как их исправить

Редирект на главную вместо родительской записи

Такое случается, если у вложения нет родителя. Это не ошибка кода, а особенность данных. Для одиночных изображений без привязки лучше редиректить на сам файл или на главную только как запасной вариант.

Случайно закрыли сами файлы изображений

Важно не путать attachment-страницу и URL файла в /uploads/. Поисковику не нужен HTML-URL вложения, но сами изображения должны оставаться доступными для загрузки в контенте и превью.

В sitemap всё ещё есть attachment

Это значит, что карту генерирует не встроенный механизм WordPress, а SEO-плагин или тема. Тогда нужно искать отдельную настройку в плагине, а не ждать, что код для wp_sitemaps_post_types повлияет на внешний генератор.

На сайте остались внутренние ссылки на attachment-страницы

Даже после редиректа лучше убрать такие ссылки из шаблонов и контента, если они не нужны. Иначе пользователь будет лишний раз проходить через переадресацию, а это ухудшает поведение на сайте и усложняет аналитику.

Практические советы по безопасности и производительности

Если на сайте много медиа, attachment-страницы могут создавать лишнюю нагрузку на обход и индексацию. Это не критично само по себе, но на больших архивах заметно.

• не удаляйте вложения массово без проверки связей с контентом;
• не закрывайте изображения в robots.txt, если они используются в статьях и должны индексироваться как медиа;
• если используете кэширование, после правок очистите кэш страниц и CDN;
• для массовых изменений сначала проверьте на staging-копии;
• если attachment-страницы уже в индексе, редирект обычно безопаснее, чем резкое удаление без замены.

Если нужен более широкий аудит дублей, мусорных URL и технических настроек, в некоторых проектах удобно сочетать ручную настройку с инструментами вроде Clearfy Pro, но только если вам реально нужен набор для чистки сайта и SEO-опций, а не ещё один тяжёлый слой поверх темы.

Как понять, что решение сработало

Через несколько дней после внедрения проверьте три вещи: старые attachment-URL должны отдавать 301 или noindex, в sitemap их быть не должно, а в Search Console постепенно должно снижаться число страниц этого типа в отчётах по индексации. Если этого не происходит, значит где-то остался второй источник генерации URL — тема, SEO-плагин или кастомный шаблон медиатеки.

Для быстрой локальной проверки можно открыть attachment URL через curl -I и посмотреть код ответа:

curl -I https://example.com/sample-image/

В ответе вы должны увидеть либо 301 Moved Permanently с корректным Location, либо HTML-страницу с noindex в robots meta, если вы выбрали мягкий вариант.