Как закрыть от индексации технические страницы WordPress и убрать мусор из поиска

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

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

Какие страницы обычно нужно закрывать

Сначала стоит понять, что именно у вас попало в индекс. На практике чаще всего всплывают такие URL:

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

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

Диагностика: что именно индексируется сейчас

Перед правками проверьте фактическую картину в поиске и на сайте. Иначе легко закрыть не то, что нужно, и потом долго искать причину просадки.

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

• отчёт по страницам в Google Search Console;
• поиск по сайту через запрос site:example.com с типовыми служебными URL;
• логи краулера, если используете Screaming Frog или аналог;
• наличие мета-тега robots на проблемных шаблонах;
• ответ сервера: 200, 301, 404 или 410.

Если страница уже в индексе, но вам не нужна, одного Disallow в robots.txt часто недостаточно. Поисковик может сохранить URL в индексе без контента. Для удаления из индекса обычно нужен noindex или корректный редирект/ответ сервера.

Пошаговое решение через код темы или мини-плагин

Если задача касается именно WordPress-шаблонов, удобнее сделать это кодом. Так вы контролируете поведение точечно и не зависите от лишних настроек плагина.

1. Закрыть страницы вложений и вложенные медиа-URL

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

<?php
add_action('template_redirect', function () {
    if (is_attachment()) {
        $parent = wp_get_post_parent_id(get_queried_object_id());

        if ($parent) {
            wp_redirect(get_permalink($parent), 301);
            exit;
        }

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

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

2. Добавить noindex для служебных страниц поиска и архивов

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

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

    if (is_paged() && (is_category() || is_tag() || is_tax() || is_archive())) {
        $robots['noindex'] = true;
        $robots['follow'] = true;
    }

    return $robots;
});

Здесь есть важная деталь: для пагинации обычно не нужен nofollow, потому что поисковику полезно пройти дальше по ссылкам. Поэтому в примере для пагинированных архивов оставлен follow.

3. Убрать feed-ленты, если они не используются

Если RSS и Atom вам не нужны, можно отключить их вывод и перенаправить запросы на главную или вернуть 404. Делать это стоит осторожно: некоторые интеграции и агрегаторы до сих пор используют feed.

<?php
add_action('do_feed', 'wpapi_disable_feeds', 1);
add_action('do_feed_rdf', 'wpapi_disable_feeds', 1);
add_action('do_feed_rss', 'wpapi_disable_feeds', 1);
add_action('do_feed_rss2', 'wpapi_disable_feeds', 1);
add_action('do_feed_atom', 'wpapi_disable_feeds', 1);

function wpapi_disable_feeds() {
    wp_die(
        esc_html__('Feed отключён на этом сайте.', 'textdomain'),
        esc_html__('Feed unavailable', 'textdomain'),
        array('response' => 404)
    );
}

Если вы не уверены, что feeds нигде не используются, сначала проверьте логи и внешние подписки. Иногда лучше оставить их доступными, но закрыть от индексации через noindex.

Сравнение подходов: плагин, код или robots.txt

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

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

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

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

• на проблемной странице в исходном коде есть <meta name="robots" content="noindex,follow"> или эквивалентный заголовок;
• страница вложения отдаёт редирект или noindex, а не обычный 200 OK;
• служебные feed-адреса не возвращают индексируемый контент;
• в Search Console URL помечен как исключённый или не подлежащий индексации;
• новые страницы не ломают каноникал и не получают случайный noindex.

Если используете командную строку, удобно проверить заголовки так:

curl -I https://example.com/sample-attachment/
curl -I https://example.com/?s=test

В ответе смотрите на статус-код и наличие X-Robots-Tag, если вы задаёте его через сервер или плагин. Для HTML-мета-тега проверяйте исходник страницы.

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

Закрыли в robots.txt, но URL остался в индексе

Это нормальная ситуация. Disallow не удаляет страницу из индекса сам по себе. Если URL уже известен поисковику, нужен noindex, редирект или 404/410 в зависимости от сценария.

Поставили noindex на всё подряд

Частая ошибка — закрыть архивы, таксономии и пагинацию одной общей проверкой. В итоге можно случайно выкинуть из индекса полезные страницы категорий или страницы пагинации, которые приводят трафик. Проверяйте условия is_*() отдельно.

Сломали медиа-страницы, которыми пользовались редакторы

Если в контенте есть ссылки на attachment-страницы, массовый редирект может повлиять на внутреннюю перелинковку. Перед внедрением посмотрите, используются ли эти URL в старых материалах.

Отключили feed без проверки интеграций

Некоторые сервисы мониторинга, агрегаторы и старые подписки всё ещё читают RSS. Если feed нужен хотя бы частично, не ломайте его полностью — лучше ограничить индексацию и оставить доступ.

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

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

• не ставьте несколько SEO-плагинов одновременно, если они управляют robots и canonical;
• проверяйте, не создаёт ли тема отдельные шаблоны для пустых архивов;
• если закрываете служебные URL кодом, вынесите его в мини-плагин, а не в functions.php активной темы;
• после изменений прогоните сайт через краулер и сравните список индексируемых URL;
• не используйте массовый noindex без списка страниц, которые реально должны остаться в поиске.

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