Страницы внутреннего поиска в WordPress часто создают лишний шум в индексе: у них мало уникального контента, они быстро плодят параметры в URL и нередко дублируют друг друга по разным запросам. При этом полностью ломать поиск не нужно — задача обычно в том, чтобы оставить его рабочим для пользователей и убрать из индекса технические страницы результатов.
Ниже — практический разбор: как понять, что именно индексируется, какие варианты закрытия подходят для обычного сайта и когда лучше не трогать robots.txt, а использовать noindex на уровне ответа страницы.
Когда это действительно проблема
Сначала стоит убедиться, что речь не о единичных URL, а о системной ситуации. В индекс попадают страницы вида /search/?s=..., /?s=... или другие варианты, зависящие от темы и плагинов. Если таких страниц немного и они не ранжируются, иногда достаточно наблюдения. Но если в Search Console растёт число URL с параметром s, а в выдаче видны пустые или слабые страницы, это уже техническая задача.
Что обычно видно в диагностике
- в индексе есть URL с параметром
sили отдельный шаблон страницы поиска; - страницы поиска получают заголовок, описание и сниппет, хотя не несут самостоятельной ценности;
- поисковики обходят много однотипных URL с разными запросами;
- внутренний поиск может создавать дубли из-за пагинации или сортировки результатов, если это добавлено темой или плагином.
Проверять лучше не на глаз, а по факту: откройте несколько URL поиска, посмотрите исходный код и заголовки ответа. Если страница отдаёт индексируемый статус и не содержит noindex, поисковик может её сохранить.
Какой способ закрытия выбрать
Для WordPress есть несколько рабочих подходов. Они не равнозначны, и выбор зависит от того, как устроен поиск на сайте.
| Подход | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
noindex в шаблоне | Если нужно оставить поиск доступным, но убрать результаты из индекса | Гибко, не ломает работу формы поиска | Нужно править тему или плагин |
| robots.txt | Если нужно ограничить обход, но не обязательно удалять уже известные URL | Быстро | Не гарантирует удаление из индекса, если URL уже известны поисковику |
| Редирект или каноникал | Если поиск заменён другой логикой и страницы не нужны вообще | Жёстко убирает лишние URL | Можно сломать полезный пользовательский сценарий |
На практике для обычного сайта чаще всего лучше noindex,follow на страницах результатов поиска. Это не мешает роботам переходить по ссылкам, но не просит индексировать саму страницу поиска.
Пошаговое решение через шаблон темы
Если у вас есть доступ к теме или дочерней теме, самый прямой путь — добавить мета-тег robots только на страницы поиска. В WordPress это можно сделать через хук wp_head.
<?php
add_action( 'wp_head', function () {
if ( is_search() ) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
} );
Этот вариант подходит, если страница поиска генерируется стандартным шаблоном WordPress. Он не требует сторонних плагинов и работает предсказуемо. Но важно не вставлять код в родительскую тему, если обновления её перезапишут. Лучше использовать дочернюю тему или мини-плагин.
Если нужен более строгий вариант
Иногда поисковый URL не должен индексироваться вообще, а сам поиск используется только как внутренняя функция. Тогда можно добавить ещё и nofollow, но делать это стоит осознанно: если на странице поиска есть полезные ссылки на контент, follow обычно безопаснее.
<?php
add_action( 'wp_head', function () {
if ( is_search() ) {
echo '<meta name="robots" content="noindex,nofollow" />' . "\n";
}
} );
Я бы не рекомендовал ставить nofollow по умолчанию без причины. Для большинства сайтов это лишнее ограничение.
Как закрыть поиск через robots.txt и почему это не всегда достаточно
Если задача — сократить обход мусорных URL, можно добавить правило в robots.txt. Для WordPress это делается либо вручную, либо через SEO-плагин, если он умеет редактировать файл.
User-agent: *
Disallow: /?s=
Disallow: /search/
Но тут есть важная оговорка: запрет в robots.txt не удаляет URL из индекса автоматически. Если страница уже известна поисковику, он может продолжать показывать её без содержимого или с фрагментом из внешних ссылок. Поэтому robots.txt полезен как дополнительная мера, но не как единственный способ.
Если поиск создаёт дубли из-за параметров
На некоторых сайтах проблема не только в s, но и в дополнительных параметрах, которые добавляет тема, фильтр или аналитика. Тогда нужно проверить, не появляются ли разные адреса с одинаковым результатом. Например, один и тот же поиск может открываться через несколько URL-форматов.
В такой ситуации полезно:
- оставить один канонический формат URL для поиска;
- убрать лишние параметры из ссылок внутри темы;
- не генерировать отдельные архивы под результаты поиска;
- проверить, не создаёт ли плагин SEO собственный canonical для search-страниц.
Если у вас стоит SEO-плагин, сначала проверьте его настройки. Иногда он уже умеет ставить noindex на поиск, и дополнительный код в теме будет просто дублировать логику.
Проверка результата после внедрения
После изменений не ограничивайтесь просмотром страницы в браузере. Нужно проверить именно то, что увидит поисковик.
- Откройте страницу поиска с любым запросом.
- Посмотрите исходный код и убедитесь, что есть
<meta name="robots" content="noindex,follow" />или нужный вам вариант. - Проверьте HTTP-ответ и убедитесь, что страница не отдаёт редирект на нерелевантный URL.
- В Search Console отправьте URL на проверку, если он уже был в индексе.
- Через несколько дней проверьте, уменьшилось ли число страниц поиска в отчётах по индексированию.
Если используете командную строку, можно быстро посмотреть заголовки ответа:
curl -I "https://example.com/?s=test"
Ищите не только статус 200, но и наличие нужных мета-указаний в HTML. Для страниц поиска это особенно важно, потому что поисковик может обойти URL даже при ограничениях в robots.txt.
Частые ошибки и как их исправить
Закрыли поиск только в robots.txt
Это самая частая ошибка. Если URL уже в индексе, запрет обхода не решает проблему полностью. Добавьте noindex на саму страницу поиска и оставьте robots.txt как дополнительный фильтр.
Поставили noindex на весь сайт
Иногда код вставляют без проверки условия is_search(). В результате мета-тег появляется на всех страницах. Исправление простое: код должен выполняться только на шаблонах поиска.
Сломали поиск редиректом
Если вместо закрытия от индексации сделать редирект на главную, пользовательский сценарий ухудшится, а поисковик может увидеть цепочку бесполезных переходов. Для внутреннего поиска это обычно плохой вариант.
Не проверили SEO-плагин
Если у вас уже есть Yoast SEO, Rank Math или другой SEO-плагин, он может сам управлять robots-мета. В этом случае ручной код в теме может конфликтовать с настройками. Сначала проверьте, нет ли уже готовой опции для search-страниц.
Что учитывать по безопасности и производительности
Сам по себе запрет индексации не ускоряет сайт, но уменьшает количество бесполезных обходов. Это особенно заметно на сайтах с большим количеством запросов поиска и слабой внутренней структурой. Если поиск активно используется, имеет смысл дополнительно проверить:
- не кешируются ли страницы поиска как обычные страницы;
- не создаёт ли тема тяжёлый шаблон результатов;
- не тянет ли поиск лишние запросы к базе данных;
- не индексируются ли параметры фильтров вместе с поиском.
Если вы не хотите поддерживать такой код вручную, можно использовать SEO-плагин или инструмент для технической чистки сайта. Например, в Clearfy Pro есть функции, связанные с удалением дублей и технической оптимизацией: https://wpshop.ru/plugins/clearfy. Но даже в этом случае важно проверить, как именно он работает в вашей конфигурации, а не полагаться на название опции.
Когда лучше не закрывать поиск полностью
Есть сайты, где страницы поиска реально полезны: каталоги документации, большие медиаархивы, базы знаний. Если поисковые страницы получают трафик и помогают находить контент, не стоит рубить их без анализа. В таких проектах лучше закрывать только технические варианты URL, а сам поиск оставить доступным и аккуратно оформленным.
Практический ориентир простой: если страница поиска не несёт самостоятельной ценности для внешней выдачи, её обычно стоит закрыть от индексации. Если же она выступает как навигационный слой по большому контентному массиву, решение нужно принимать по данным, а не по шаблону.