Страницы внутреннего поиска в WordPress часто попадают в индекс не потому, что кто-то специально их продвигает, а потому что поисковик находит ссылки вида ?s=..., обходит их и видит набор почти пустых или дублирующихся страниц. Для сайта это обычно лишний шум: в индексе появляются URL с мусорными запросами, в отчётах растёт количество «тонких» страниц, а в логах — лишние обходы.
Проблема не в самом поиске, а в том, как он отдаёт результат. Если страница поиска открыта для индексации, поисковая система может сохранить в базе десятки вариантов одного и того же шаблона: / ?s=seo, / ?s=seo+plugin, / ?s=wordpress. Для пользователя это нормальный функционал, для индекса — чаще всего мусор.
Когда это действительно проблема
Сначала стоит понять, нужно ли вообще закрывать поиск. На небольшом контентном сайте внутренний поиск редко даёт ценность как посадочная страница. На крупном каталоге статей или базе знаний ситуация сложнее: иногда поисковые страницы полезны, если у них есть стабильный контент, фильтры и понятная структура. Но в типичном WordPress-проекте внутренний поиск лучше не индексировать.
Признаки, что страницы поиска уже мешают
- в Google Search Console появляются URL с параметром
?s=; - в индексе есть страницы поиска с заголовками вроде «Результаты поиска для…»;
- в отчётах по покрытию много страниц с низкой ценностью;
- поисковые запросы приводят к пустым или почти пустым страницам;
- боты тратят обход на однотипные URL вместо важных страниц.
Диагностика: что именно индексируется
Перед правкой проверьте, как сайт сейчас отвечает на запрос поиска. Откройте несколько URL вручную и посмотрите HTML-код страницы. Важно понять, есть ли там noindex, каноникал и не закрыт ли поиск случайно через robots.txt вместо нормальной настройки.
Минимальный набор проверок:
- откройте
https://example.com/?s=test; - посмотрите исходный код страницы;
- проверьте, есть ли мета-тег
robotsсnoindex; - проверьте заголовок ответа и канонический URL;
- сравните поведение для пустого и непустого запроса.
Если у вас установлен SEO-плагин, он может уже добавлять noindex для страниц поиска. Но полагаться на это вслепую не стоит: после обновлений темы, плагина или шаблона поведение иногда меняется.
Пошаговое решение без лишних рисков
Есть три рабочих подхода: через SEO-плагин, через код темы или через комбинацию обоих. Для большинства сайтов достаточно одного корректного noindex и нормального канонического URL.
| Способ | Когда подходит | Плюс | Минус |
|---|---|---|---|
| SEO-плагин | Если уже используете плагин для мета-тегов | Быстро и без правки темы | Зависит от настроек и совместимости |
| Код в теме или mu-plugin | Если нужен точечный контроль | Предсказуемое поведение | Нужно следить за обновлениями |
| robots.txt | Только как дополнительная мера | Снижает обход | Не гарантирует удаление из индекса |
Вариант 1: закрыть поиск через код
Если хотите управлять этим без зависимости от интерфейса плагина, добавьте фильтр в functions.php дочерней темы или в отдельный mu-plugin. Для WordPress это штатный способ повлиять на robots-мета.
<?php
add_filter( 'wp_robots', function( array $robots ) {
if ( is_search() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );Здесь логика простая: поисковая страница остаётся доступной для перехода по ссылкам, но не должна попадать в индекс. Это лучше, чем блокировать её через Disallow в robots.txt, потому что поисковик всё равно может увидеть URL по внешним ссылкам и сохранить его без содержимого.
Вариант 2: добавить canonical на главную или на страницу поиска
Если шаблон темы выводит странный canonical или его нет вовсе, можно поправить поведение через фильтр wp_get_canonical_url не всегда удобно, поэтому чаще используют SEO-плагин. Но если нужен именно код, безопаснее не переизобретать генерацию каноникала, а ограничиться noindex. Для поисковых страниц этого обычно достаточно.
Вариант 3: отключить индексацию в SEO-плагине
Если у вас уже стоит Yoast SEO, Rank Math или похожий плагин, проверьте настройки архивов и специальных страниц. В большинстве случаев там есть отдельная опция для страниц поиска. Это хороший вариант, если вы не хотите хранить логику в теме.
Плюс такого подхода в том, что он понятен редактору и не ломается при смене шаблона. Минус — настройки легко забыть после миграции сайта или клонирования staging в production.
Что делать с robots.txt
Закрывать поиск через robots.txt можно только как дополнительную меру, если вы хотите уменьшить обход. Но это не замена noindex. Если URL уже известен поисковику, запрет на обход не гарантирует его исчезновение из индекса.
User-agent: *
Disallow: /*?s=
Disallow: /search/Такой вариант уместен, если на сайте есть и параметрический поиск, и человекочитаемый путь вроде /search/. Но перед этим проверьте, что у вас действительно используются такие URL. Нельзя слепо копировать правило на любой проект.
Проверка результата после внедрения
После правки не ограничивайтесь открытием страницы в браузере. Нужно проверить, что поисковая страница отдаёт правильные сигналы для робота.
- Откройте
?s=testв режиме инкогнито и посмотрите исходный код. - Убедитесь, что в HTML есть
noindex. - Проверьте, не осталось ли в шаблоне старого meta robots с
index,follow. - В Search Console отправьте URL на повторную проверку, если он уже был в индексе.
- Через несколько дней проверьте отчёт по страницам с параметром
s.
Если используете серверный кэш, очистите его после изменения. Иначе вы можете смотреть на старую версию страницы и решить, что правка не сработала.
Частые ошибки и как их исправить
Закрыли только в robots.txt
Это самая частая ошибка. Поисковик может знать URL по ссылкам и всё равно показать его в выдаче без содержимого. Если задача именно убрать страницу из индекса, нужен noindex.
Поставили noindex, но забыли про кэш
Если на сайте включён page cache, старая версия HTML может ещё отдаваться ботам и пользователям. После изменения настроек очистите кэш плагина, серверный кэш и CDN, если он есть.
Сломали поиск для пользователей
Иногда разработчики вместо индексации закрывают сам функционал поиска, например через редирект или жёсткий запрет в шаблоне. Это лишнее. Пользовательский поиск должен работать, просто не обязан быть индексируемой страницей.
Сделали noindex только для одной формы поиска
На некоторых сайтах есть несколько точек входа: стандартный поиск WordPress, поиск в шапке, поиск по кастомному типу записей. Проверьте, что правило срабатывает для всех поисковых страниц, а не только для одного шаблона.
Практические советы по безопасности и производительности
Если поиск на сайте часто используется ботами, это может создавать лишнюю нагрузку. Для тяжёлых проектов имеет смысл ограничить частоту запросов на уровне сервера, но это уже отдельная задача и требует аккуратности, чтобы не задеть обычных пользователей.
Ещё один полезный шаг — следить за тем, чтобы страницы поиска не генерировали бесконечные вариации URL из-за параметров сортировки, фильтров или UTM-меток. Если такие параметры не нужны для индекса, лучше заранее продумать каноникал и политику индексации, чем потом чистить мусор из выдачи.
Если вам нужен более широкий контроль над дублями, техническими мета-тегами и очисткой сайта, в экосистеме WPShop есть Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже с плагином важно понимать, какие именно страницы он закрывает и не полагаться на настройки по умолчанию без проверки.
Как понять, что решение сработало
Итоговая проверка должна быть практической, а не формальной. Страница поиска должна открываться для пользователя, но отдавать сигнал noindex для робота. В идеале через некоторое время она исчезнет из индекса или перестанет появляться как отдельная посадочная страница.
- страница
?s=открывается без ошибок; - в HTML есть
noindex; - в Search Console уменьшается число URL поиска;
- в индексе не растёт количество мусорных поисковых страниц;
- основные статьи и рубрики не пострадали.
Если после всех правок поисковые URL всё ещё индексируются, проверьте тему, SEO-плагин и кэш в таком порядке. Обычно проблема не в одном месте, а в конфликте настроек.
