В WordPress чаще всего проблема не в «плохой индексации», а в том, что в поиск попадают страницы, которые не должны там жить: результаты поиска по сайту, архивы с пустым контентом, страницы пагинации, служебные URL плагинов, теги без трафика. Если закрывать всё подряд через robots.txt, легко получить обратный эффект: URL останется в индексе, но без возможности переобхода, а поисковик не увидит мета-тег noindex. Поэтому здесь важно разделять задачи: что именно нужно убрать из индекса, а что — просто не сканировать.
Когда нужно закрывать страницу от индексации
Сначала полезно понять, какой у вас сценарий. Для WordPress это обычно один из трёх вариантов: служебная страница не несёт пользы пользователю, страница создаёт дубли, или URL нужен для работы сайта, но не должен попадать в поиск. Для каждого случая подход разный.
Типичные кандидаты на noindex
- внутренний поиск по сайту, если он доступен по отдельному URL;
- страницы тегов и архивов, которые не дают уникального контента;
- авторские архивы на сайтах с одним автором;
- страницы пагинации, если они не нужны в поиске;
- служебные страницы плагинов, корзины, личного кабинета, фильтров и сортировок;
- страницы с параметрами URL, которые создают мусорные дубли.
Если страница должна быть доступна пользователю, но не нужна в выдаче, обычно выбирают noindex, follow. Если URL вообще не должен сканироваться, тогда уже смотрят на robots.txt или на техническое закрытие через серверные правила.
Диагностика: где именно у вас появляется лишняя индексация
Перед правками не стоит гадать. Проще проверить, какие URL уже попали в индекс и откуда они взялись. Начните с отчёта поисковой системы и с обхода сайта краулером, если он у вас есть. В WordPress часто всплывают одинаковые страницы по разным адресам: с ?replytocom=, с тегами, с параметрами сортировки, с архивами автора и дат.
Полезно посмотреть исходный код проблемной страницы. Если там уже есть <meta name="robots" content="noindex, follow">, но URL всё равно в индексе, значит поисковик ещё не переобошёл страницу или где-то есть конфликтующий сигнал. Если мета-тега нет, а страница должна быть закрыта, значит решение нужно внедрять на уровне темы, плагина SEO или через код.
Что проверить в первую очередь
- есть ли у страницы канонический URL;
- не закрыта ли она только в
robots.txtбезnoindex; - не генерирует ли плагин SEO свой собственный мета-тег;
- не создаёт ли тема отдельный шаблон архива без управления robots;
- не дублируется ли контент через параметры URL.
Пошаговое решение через плагин SEO
Если у вас уже стоит SEO-плагин, это обычно самый безопасный путь. В большинстве случаев удобнее закрывать индексацию на уровне конкретного типа архива или записи, чем править шаблоны вручную. Логика простая: плагин формирует мета-тег в <head>, а поисковик получает явный сигнал, что страницу не нужно индексировать.
Например, для архивов тегов, авторов или дат обычно есть настройки в интерфейсе. Но если нужен точечный контроль, лучше использовать код. Это особенно полезно, когда нужно закрыть не весь тип страниц, а только часть условий.
Пример: добавить noindex для архивов тегов и авторов
<?php
add_filter( 'wp_robots', function( array $robots ) {
if ( is_tag() || is_author() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );
Этот вариант работает через стандартный фильтр WordPress wp_robots. Он не ломает разметку темы и не зависит от конкретного SEO-плагина. Но важно помнить: если ваш SEO-плагин тоже управляет robots, проверьте, не конфликтуют ли правила между собой.
Когда нужен robots.txt, а когда он не решает задачу
robots.txt полезен для экономии краулингового бюджета и запрета обхода технических разделов. Но он не гарантирует удаление URL из индекса. Если страница уже известна поисковику, одного запрета в robots.txt часто недостаточно. Для удаления из выдачи нужен именно noindex или корректный редирект/404/410 в зависимости от ситуации.
В robots.txt имеет смысл закрывать, например, служебные директории, страницы поиска по сайту, если они генерируют много мусорных URL, или параметры, которые создают бесконечные комбинации. Но не стоит закрывать там страницы, которые должны выпасть из индекса быстро и без двусмысленности.
Пример аккуратного robots.txt
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /?s=
Disallow: /search/
Disallow: /tag/
Этот пример нужно адаптировать под структуру сайта. Не копируйте его без проверки: если у вас важны страницы тегов, закрывать их целиком не надо. И не забывайте, что robots.txt не заменяет noindex для уже проиндексированных страниц.
Сравнение подходов: плагин, код, robots.txt
| Подход | Когда использовать | Плюсы | Минусы |
|---|---|---|---|
| Плагин SEO | Нужно быстро закрыть типы архивов и отдельные шаблоны | Удобно, меньше риска сломать шаблон | Зависимость от интерфейса и логики плагина |
Код через wp_robots | Нужна точечная логика без лишних плагинов | Гибко, работает на уровне WordPress | Требует проверки конфликтов и тестирования |
robots.txt | Нужно ограничить обход технических URL | Просто и быстро | Не удаляет URL из индекса само по себе |
Проверка результата после внедрения
После правок не ограничивайтесь визуальной проверкой. Откройте страницу в браузере и посмотрите исходный код: должен появиться нужный robots-мета-тег. Затем проверьте заголовки и статус ответа, если вы меняли серверные правила. Если страница закрыта через noindex, поисковик должен увидеть это при следующем обходе.
Практический чек-лист проверки:
- в исходном коде есть
noindexдля нужного URL; - канонический адрес указывает на правильную страницу;
- страница не закрыта случайно для пользователей;
- в
robots.txtнет противоречащих правил; - в панели вебмастера URL не получает новые ошибки обхода;
- через несколько обходов страница уходит из индекса или перестаёт появляться в новых результатах.
Если URL всё ещё показывается в выдаче, не делайте резких движений. Сначала проверьте, не осталась ли старая копия в кеше поисковика, и не мешает ли индексации другой сигнал: редирект, canonical, sitemap или внутренние ссылки.
Частые ошибки и как их исправить
Закрыли страницу только в robots.txt
Это частая ошибка. Если URL уже в индексе, поисковик может продолжать показывать его без возможности переобхода. Решение: добавьте noindex или уберите страницу из индекса через корректный статус ответа, если она больше не нужна.
Поставили noindex и одновременно запретили обход
Когда страница закрыта в robots.txt, поисковик может не увидеть мета-тег noindex. В итоге URL остаётся в индексе дольше, чем нужно. Если цель — именно удаление из выдачи, сначала дайте роботу увидеть noindex.
Случайно закрыли важные страницы
Иногда под раздачу попадают категории, товары, статьи или посадочные страницы. Это происходит, когда правила пишут слишком широко: например, закрывают весь тип архивов без проверки. Перед публикацией изменений обязательно пройдитесь по списку URL, которые должны остаться открытыми.
Конфликт плагина и ручного кода
Если SEO-плагин уже добавляет свои robots-правила, а вы сверху навешиваете ещё один фильтр, результат может быть непредсказуемым. В таком случае оставьте один источник правды: либо настройки плагина, либо код в теме/мини-плагине.
Практические советы по безопасности и производительности
Не редактируйте functions.php напрямую на рабочем сайте, если нет нормального процесса отката. Лучше вынести логику в мини-плагин или использовать дочернюю тему. Так проще отключить правку, если она заденет индексацию лишних страниц.
Если на сайте много мусорных URL из-за параметров, сначала решите причину их появления: фильтры, поиск, сортировки, бесконечные архивы, внутренние ссылки с параметрами. Иначе вы будете бесконечно закрывать симптомы, а не источник проблемы.
Для сайтов, где важна чистка дублей и техническая SEO-гигиена, иногда удобнее использовать специализированный плагин вроде Clearfy Pro: он помогает управлять частью служебных настроек, не разбрасывая их по теме и нескольким плагинам. Но даже в этом случае нужно отдельно проверять, какие именно URL закрываются и не конфликтуют ли правила между собой.
Если нужно, можно собрать логику в небольшой мини-плагин и хранить её в репозитории проекта. Тогда изменения по индексации будут версионироваться, а не теряться после обновления темы.