Как исключить технические страницы WordPress из индексации без потери нужного трафика

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

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

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

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

Типичные кандидаты на исключение

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

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

Диагностика: где именно у вас лишняя индексация

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

1. В Google Search Console откройте отчет по страницам и посмотрите, какие типы URL индексируются.
2. Сравните список с картой сайта: если в sitemap попадают служебные URL, проблему нужно решать в генерации карты.
3. Проверьте исходный код проблемной страницы: есть ли <meta name="robots" content="index,follow"> или noindex.
4. Посмотрите, не открывается ли страница по нескольким адресам: с параметрами, со слешем и без, через архив и через поиск.

Для быстрой проверки можно использовать поиск по сайту в Google, но лучше смотреть именно в Search Console: там видно, как поисковик классифицирует URL и почему он их держит в индексе.

Пошаговое решение: закрываем технические страницы правильно

Оптимальная схема обычно состоит из трех уровней: robots.txt для обхода, noindex для индексации и canonical для указания основной версии страницы. Использовать только один из них — частая причина непредсказуемого результата.

1. Закрываем внутренний поиск и служебные архивы через noindex

Если у вас есть доступ к настройкам SEO-плагина, проще всего выставить noindex на архивы, которые не нужны в выдаче. Но если нужна точечная логика на уровне темы или мини-плагина, можно добавить мета-тег и заголовок X-Robots-Tag.

<?php
add_action('wp_head', function () {
    if (is_search() || is_attachment() || is_date()) {
        echo '<meta name="robots" content="noindex,follow">' . "\n";
    }
}, 1);

add_action('send_headers', function () {
    if (is_search() || is_attachment() || is_date()) {
        header('X-Robots-Tag: noindex, follow', true);
    }
});

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

2. Убираем мусор из sitemap

Если служебные URL попадают в XML-карту сайта, поисковик будет находить их быстрее. В этом случае сначала проверьте настройки SEO-плагина: часто архивы, вложения и таксономии можно исключить без кода. Если карта генерируется вручную или через кастомный плагин, исключайте ненужные типы записей на этапе формирования списка URL.

Пример для фильтрации массива URL перед выводом карты:

<?php
$urls = array_filter($urls, function ($url) {
    return strpos($url, '/search/') === false
        && strpos($url, '/attachment/') === false;
});

Логика здесь простая: если URL не должен индексироваться, он не должен и попадать в карту сайта. Иначе вы сами подсказываете поисковику, что страница важна.

3. Настраиваем robots.txt только там, где это уместно

robots.txt полезен для снижения лишнего обхода, но он не гарантирует удаление из индекса. Если страница уже известна поисковику, одного запрета в robots.txt может быть мало. Поэтому закрывать через robots.txt стоит только то, что не должно сканироваться, но при этом не требует обязательного noindex.

Пример аккуратного набора правил:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /?s=
Disallow: /search/
Disallow: /trackback/

Не стоит бездумно закрывать весь /wp-content/ или /wp-includes/: это старый и часто вредный совет. Поисковику нужны ресурсы для рендеринга страницы, а лишний запрет может ухудшить понимание контента.

Что выбрать: плагин, код или ручную настройку

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

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

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

• Откройте исходный код страницы и убедитесь, что есть noindex,follow там, где он нужен.
• Проверьте заголовки ответа через curl -I https://example.com/... и убедитесь, что X-Robots-Tag отдается корректно.
• Посмотрите, исчез ли URL из XML-карты сайта.
• В Search Console отправьте страницу на повторную проверку и отслеживайте статус индексации.
• Проверьте, не сломались ли внутренние ссылки и хлебные крошки после закрытия архивов.

Пример проверки заголовков:

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

В ответе вы должны увидеть либо X-Robots-Tag: noindex, follow, либо понять, что страница закрывается другим способом. Если заголовка нет, значит код не сработал или условие выбрано неверно.

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

Закрыли страницу в robots.txt, но она осталась в индексе

Это нормальная ситуация. Robots.txt запрещает обход, но не всегда удаляет уже известный URL из выдачи. Решение: добавить noindex и дождаться переобхода, либо убрать страницу из sitemap и дать поисковику сигнал на переоценку.

Поставили noindex на полезный архив

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

Закрыли URL, но он продолжает появляться в поиске

Причина обычно в том, что страница всё ещё доступна по ссылкам, есть в sitemap или на неё ведут старые внешние ссылки. В этом случае нужно не только закрыть индексацию, но и убрать источник обнаружения URL.

Поставили canonical на главную страницу вместо noindex

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

Безопасность и производительность: что не стоит делать

Не добавляйте правила закрытия наугад в functions.php активной темы, если сайт часто обновляется. Лучше вынести логику в небольшой mu-plugin или отдельный мини-плагин: так она не пропадет при смене темы.

Не закрывайте через Disallow страницы, которые должны отдавать noindex и при этом быть доступны для обхода до удаления из индекса. Для таких URL поисковику нужно увидеть сам ответ страницы.

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

Мини-чек-лист перед публикацией изменений

• Проверил, какие URL реально нужно закрыть.
• Убедился, что полезные архивы не попали под общий шаблон.
• Удалил служебные URL из sitemap.
• Добавил noindex там, где нужен запрет на индексацию.
• Использовал robots.txt только для снижения обхода, а не как единственный способ.
• Проверил заголовки ответа и исходный код страницы.
• Отправил проблемные URL на повторную проверку в Search Console.

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