На небольших и средних сайтах WordPress чаще всего индексируются не те страницы, которые нужны: результаты внутреннего поиска, страницы с параметрами фильтрации, сортировки, пагинации в служебных разделах. В итоге в поиске появляются слабые или дублирующие URL, а краулинговый бюджет уходит на мусор.
Задача здесь не в том, чтобы «спрятать всё подряд», а в том, чтобы аккуратно закрыть от индексации именно технические страницы, не ломая навигацию и не мешая пользователю переходить по сайту.
Какие страницы обычно нужно закрывать
Сначала полезно разделить URL на две группы: те, что должны быть доступны пользователю, и те, что не должны попадать в индекс. Это разные задачи. Например, страница поиска нужна для посетителя, но почти никогда не должна ранжироваться как отдельная посадочная. То же касается URL с параметрами вроде ?s=, ?orderby=, ?filter=, ?sort=.
Типичные кандидаты на noindex
- результаты внутреннего поиска WordPress:
/?s=...; - страницы с параметрами фильтрации и сортировки;
- служебные архивы, которые дублируют основной контент;
- страницы пагинации в разделах, где они не несут самостоятельной ценности;
- страницы с пустой выдачей или очень узким набором результатов.
Если у вас уже есть каноникализация и редиректы, это не отменяет задачу закрытия от индексации. Canonical помогает подсказать предпочтительный URL, но не всегда решает проблему с попаданием служебных страниц в индекс.
Диагностика: как понять, что именно индексируется
Перед правками проверьте, какие URL уже попали в поиск. Самый быстрый путь — посмотреть отчёт по страницам в Google Search Console и поискать шаблоны URL с параметрами. Дополнительно полезно сделать ручную проверку через оператор site: и посмотреть, не всплывают ли результаты поиска сайта или фильтры.
Если у вас есть доступ к логам или аналитике, обратите внимание на страницы с высоким числом входов, но низким временем на странице и почти нулевой конверсией. Это часто служебные URL, которые поисковик тоже может считать «полезными», если их не ограничить.
Ещё один практичный тест — открыть проблемный URL и посмотреть исходный код. Если там уже стоит noindex, но страница всё равно индексируется, значит, либо правило добавлено не на все шаблоны, либо поисковик ещё не переобходил страницу.
Пошаговое решение без плагина
Если нужно закрыть от индексации только часть страниц, проще всего добавить условный noindex через wp_head. Это подходит для результатов поиска и URL с параметрами, которые вы можете определить на своей стороне.
<?php
add_action( 'wp_head', function () {
if ( is_search() ) {
echo '<meta name="robots" content="noindex,follow">' . "\n";
return;
}
if ( isset( $_GET['filter'] ) || isset( $_GET['sort'] ) || isset( $_GET['orderby'] ) ) {
echo '<meta name="robots" content="noindex,follow">' . "\n";
}
}, 1 );
Здесь важно использовать именно noindex,follow, а не noindex,nofollow. В большинстве случаев вы хотите, чтобы поисковик мог переходить по ссылкам на странице, даже если сам URL индексировать не нужно.
Если фильтры реализованы через красивые URL, а не через query string, условие придётся адаптировать под вашу структуру. Например, можно проверять текущий шаблон, таксономию или конкретный набор rewrite-правил.
Когда лучше использовать robots.txt
robots.txt подходит для грубого ограничения обхода, но не для тонкой настройки индексации. Если вы просто запретите обход, поисковик может продолжить хранить URL в индексе без содержимого. Поэтому для уже известных страниц с параметрами обычно надёжнее ставить noindex на саму страницу, а не только закрывать её в robots.
Пример правила для служебных параметров в robots.txt может быть полезен как дополнительная мера, но не как единственная:
User-agent: *
Disallow: /*?s=
Disallow: /*?filter=
Disallow: /*?sort=
Disallow: /*?orderby=
Такое правило не универсально для всех серверов и конфигураций, поэтому перед внедрением проверьте, как именно формируются URL на вашем сайте.
Если нужен более управляемый вариант: плагин или код
На проектах, где служебных URL много и они меняются, удобнее использовать SEO-плагин с настройками для архивов, таксономий и мета-роботов. Если же проблема локальная и касается только поиска или пары параметров, код в теме или мини-плагине часто надёжнее: меньше зависимостей, проще отладка.
| Подход | Когда подходит | Минус |
|---|---|---|
| Код в теме/мини-плагине | Нужно закрыть конкретные шаблоны и параметры | Требует поддержки при изменении структуры сайта |
| SEO-плагин | Много архивов, таксономий и шаблонных правил | Часть настроек может конфликтовать с темой или другими плагинами |
| robots.txt | Нужно ограничить обход служебных URL | Не решает проблему индексации само по себе |
Если у вас уже стоит Clearfy Pro, часть задач по чистке дублей и служебных страниц можно закрыть через его настройки, но всё равно стоит проверить, как именно он формирует мета-теги и не конфликтует ли с другими SEO-модулями. Для сайта с большим количеством технических страниц это часто удобнее, чем разносить правила по нескольким файлам темы. Ссылка на продукт: Clearfy Pro.
Проверка результата после внедрения
После правок не ограничивайтесь просмотром кода страницы. Проверьте три вещи: наличие meta robots в исходнике, корректность ответа сервера и то, как URL видит поисковик.
- Откройте проблемную страницу в браузере и посмотрите исходный код.
- Убедитесь, что на нужных URL действительно выводится
noindex,follow. - Проверьте, не добавился ли случайно
noindexна обычные страницы. - В Search Console отправьте URL на повторную проверку, если он уже был в индексе.
Если используете кэш, очистите его после правок. Иначе вы можете смотреть старую версию страницы и ошибочно думать, что правило не сработало.
Частые ошибки и как их исправить
Ставят noindex только в robots.txt
Это частая ошибка. Запрет обхода не равен запрету индексации. Если URL уже известен поисковику, он может остаться в выдаче как «страница без описания». Для служебных страниц лучше добавлять мета-тег или заголовок X-Robots-Tag.
Закрывают от индексации слишком много страниц
Иногда под раздачу попадают категории, архивы или полезные посадочные страницы. Это происходит, когда правило написано слишком широко, например по одному только наличию ? в URL. Проверяйте условия точечно.
Не учитывают кэш и CDN
После изменения шаблона страница может продолжать отдавать старую версию из кэша. Если у вас подключён серверный кэш, CDN или плагин кэширования, очищайте все уровни, иначе диагностика будет ложной.
Путают canonical и noindex
Canonical указывает предпочтительный адрес, но не закрывает страницу от индексации. Если цель — убрать служебный URL из поиска, одного canonical может быть недостаточно.
Практические советы по безопасности и производительности
Не используйте универсальные условия вида if ( ! empty( $_GET ) ) для всех страниц. Это может случайно закрыть от индексации полезные URL с UTM-метками или рабочими параметрами. Лучше перечислять конкретные ключи и проверять, где именно они допустимы.
Если вы добавляете правила в тему, держите их в дочерней теме или в небольшом mu-plugin. Так они не потеряются при обновлении шаблона. Для сайтов с частыми изменениями структуры это безопаснее, чем править functions.php основной темы.
Для больших проектов полезно вести короткий список технических URL, которые должны оставаться закрытыми: поиск, фильтры, сортировка, внутренние служебные страницы. Это экономит время при аудите и помогает не забыть про новые шаблоны после редизайна.
Короткий чек-лист перед публикацией
- проверены конкретные URL, которые нужно закрыть;
- добавлен
noindex,followтолько на нужные шаблоны; - robots.txt не используется как единственная мера;
- очищен кэш сайта и CDN;
- проверен исходный код страницы и отчёт в Search Console;
- не затронуты полезные категории, теги и посадочные страницы.
Если задача шире, чем закрытие пары URL, и у вас много дублей, параметров и служебных архивов, удобнее сначала навести порядок в технической индексации, а уже потом заниматься контентом. В таких сценариях обычно выигрывает не один «магический» переключатель, а аккуратный набор правил, проверенных на реальных URL.
