Как отключить attachment pages в WordPress и убрать дубли медиа-страниц из индекса

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

Ниже разберём, как понять, что именно у вас происходит, и как безопасно отключить attachment pages без поломки картинок, canonical и редиректов.

Когда attachment pages становятся проблемой

Не каждая медиастраница вредна одинаково. Если у attachment URL есть осмысленный контент, уникальный заголовок и реальная навигационная роль, их можно оставить. Но в типичном WordPress-сайте страницы вложений выглядят так:

• заголовок совпадает с именем файла или подписью изображения;
• контент почти пустой, кроме самого изображения;
• страница не имеет самостоятельной ценности для пользователя;
• в индексе накапливаются десятки или сотни URL вида /attachment/ или вложенных страниц медиафайлов.

Если у вас уже есть статьи про дубли title, description и canonical, то attachment pages — это следующий практический источник мусора. Они часто не ломают сайт напрямую, но создают шум в поиске и усложняют техническую поддержку.

Диагностика: как понять, что проблема именно в attachment pages

Проверка начинается не с кода, а с фактов. Откройте несколько URL вложений из админки или из поисковой выдачи и посмотрите, что реально отдаёт сайт.

Что смотреть вручную

• Есть ли на странице только изображение и минимум текста.
• Совпадает ли title с названием файла.
• Отдаётся ли 200 OK вместо редиректа или 404.
• Есть ли в исходном коде canonical на сам attachment URL.
• Появляются ли такие страницы в отчётах Search Console как проиндексированные или обнаруженные, но не проиндексированные.

Если у вас включён SEO-плагин, проверьте, не создаёт ли он отдельные мета-теги для attachment pages. Иногда проблема не в WordPress как таковом, а в настройках плагина, который оставляет медиастраницы доступными для индексации.

Быстрая проверка через поиск

В поиске по сайту или через оператор site: можно увидеть, индексируются ли вложения:

site:example.com inurl:attachment

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

Какой вариант отключения выбрать

Есть три рабочих подхода: редирект на файл, редирект на родительскую запись или отдача 404/410. Выбор зависит от того, как у вас устроены медиа и есть ли внешние ссылки на attachment URL.

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

Если вам нужен предсказуемый технический результат, проще всего обработать attachment pages на уровне темы или небольшого mu-plugin. Для большинства проектов безопаснее редиректить вложения, чем оставлять их открытыми.

Вариант 1: редирект attachment page на родительскую запись

Этот способ удобен, если у вложения есть post_parent. Добавьте код в functions.php дочерней темы или в отдельный плагин:

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

    $parent_id = wp_get_post_parent_id(get_queried_object_id());

    if ($parent_id) {
        wp_safe_redirect(get_permalink($parent_id), 301);
        exit;
    }

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

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

Вариант 2: отдавать 404 для attachment pages

Если вы хотите полностью убрать медиастраницы из индекса и не сохранять их как отдельные URL, можно принудительно отдавать 404:

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

    global $wp_query;
    $wp_query->set_404();
    status_header(404);
    nocache_headers();
    include get_query_template('404');
    exit;
});

Этот вариант жёстче. Он подходит, когда attachment pages никогда не использовались как часть контентной стратегии и вы не хотите оставлять даже редиректную цепочку. Но если на такие URL уже есть внешние ссылки, 301 обычно мягче для пользователей и логов.

Вариант 3: отключить attachment pages через фильтр и перенаправление

Иногда достаточно не трогать шаблоны, а просто направить все attachment URL в нужное место. Это удобно, если тема или плагин уже переопределяют поведение вложений.

add_action('template_redirect', function () {
    if (is_attachment()) {
        $attachment = get_queried_object();

        if ($attachment && !empty($attachment->post_parent)) {
            wp_redirect(get_permalink($attachment->post_parent), 301);
            exit;
        }

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

Здесь wp_redirect() тоже рабочий вариант, но для внутренних редиректов я обычно предпочитаю wp_safe_redirect(). Он чуть строже и лучше подходит для контролируемых переходов внутри сайта.

Если используете SEO-плагин или чистку сайта

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

Смысл не в том, чтобы переложить всё на плагин, а в том, чтобы не держать логику в трёх местах одновременно: в теме, в SEO-плагине и в functions.php.

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

После внедрения проверьте не только браузер, но и фактический HTTP-ответ.

• Откройте несколько attachment URL в браузере.
• Проверьте код ответа через DevTools или curl -I.
• Убедитесь, что старые URL либо редиректят на нужную страницу, либо отдают 404.
• Посмотрите исходный код: canonical не должен вести на мусорный attachment URL, если страница больше не используется.
• Через Search Console проверьте, уменьшается ли количество проиндексированных URL вложений со временем.

Пример проверки через консоль:

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

Если вы выбрали редирект, в ответе должен быть 301 и заголовок Location с целевым URL. Если выбрали 404, проверьте, что страница не отдаёт 200 из-за кэш-плагина или кастомного шаблона.

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

Редирект настроен, но attachment pages всё ещё индексируются

Обычно причина в кэше или в том, что поисковик ещё не переобходил старые URL. Проверьте заголовки ответа, очистите кэш страницы и серверный кэш, если он есть. Если редирект работает в браузере, но не в индексе, это вопрос времени и повторного обхода.

Редирект ведёт на главную, а не на родителя

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

Кэш-плагин продолжает отдавать старую страницу

Если у вас включён кэш на уровне плагина или сервера, он может сохранять старую версию attachment page. После изменения логики обязательно очистите кэш и проверьте ответ повторно. Иначе вы будете видеть старое поведение даже после правильного кода.

Сломались ссылки на изображения в старых материалах

Это уже не проблема attachment pages как таковых, а ошибка в том, что редирект сделали не на тот уровень. Сам файл изображения должен оставаться доступным по прямому URL. Не путайте страницу вложения и сам медиафайл.

Чек-лист перед выкладкой на прод

• Проверили, нужны ли attachment pages как отдельные страницы вообще.
• Выбрали один сценарий: 301 на родителя, 301 на файл или 404.
• Убедились, что медиафайлы по прямым ссылкам открываются.
• Очистили кэш плагина, сервера и CDN, если он есть.
• Проверили HTTP-ответ через curl -I или DevTools.
• Посмотрели, не создаёт ли SEO-плагин отдельные мета-теги для вложений.
• Отследили изменения в Search Console после переобхода страниц.

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

Сам по себе редирект attachment pages не даёт заметного прироста скорости, но он уменьшает количество бесполезных страниц, которые нужно обходить и хранить в индексе. Это полезно для больших сайтов с тысячами медиафайлов.

С точки зрения безопасности важно не использовать открытые редиректы на произвольные URL. Поэтому для внутренних переходов лучше wp_safe_redirect(), а не ручная сборка Location на основе пользовательского ввода. Если вы делаете 404, не забывайте о кэше: неправильно закэшированная 200-страница сведёт решение на нет.

Если проект уже оброс техническим мусором, имеет смысл не ограничиваться только attachment pages. Обычно рядом всплывают архивы, поиск, служебные URL и дубли мета-тегов. В таких случаях удобнее собрать чистку в один понятный набор правил, а не латать каждую проблему отдельно.