Внутренний поиск WordPress часто попадает в индекс не потому, что сайт «плохой», а потому что поисковик видит множество URL с параметром ?s= и начинает обходить их как обычные страницы. Для небольших сайтов это почти всегда лишний мусор: дубли, пустые выдачи, слабые страницы с тонким контентом и лишняя нагрузка на сервер.
Если задача именно техническая — убрать страницы результатов поиска из индекса без плагина — это лучше решать на уровне robots.txt, мета-тегов и, при необходимости, заголовка X-Robots-Tag. Ниже разберём, что реально работает в WordPress, а что только создаёт видимость настройки.
Когда внутренний поиск нужно закрывать от индексации
Обычно это имеет смысл, если поиск на сайте используется только посетителями, а не как отдельный контентный раздел. Страницы вида / ?s=запрос почти всегда содержат мало уникального текста, а их заголовки и сниппеты генерируются шаблоном. В результате в индексе оказываются десятки или сотни почти одинаковых URL.
Признаки проблемы
- в поисковой выдаче видны URL с параметром
?s=; - в отчёте по индексации растёт число «Просканировано, но не проиндексировано»;
- поиск по сайту создаёт много пустых или слабых страниц;
- в логах заметно, что бот часто ходит по внутреннему поиску;
- в GSC появляются дубли с разными поисковыми запросами.
Диагностика: что именно индексируется
Сначала проверьте, действительно ли проблема в страницах поиска, а не в других дублях. Откройте несколько URL вручную и посмотрите, как они отдают ответ и какие мета-данные стоят в HTML.
<?php
// Пример URL внутреннего поиска WordPress
// https://example.com/?s=seo
// На странице результатов поиска в шаблоне обычно есть:
// - title с запросом
// - список записей или сообщение о пустой выдаче
// - пагинация, если результатов много
Если у вас есть доступ к консоли, проверьте заголовки ответа. Для страниц поиска полезно убедиться, что они не отдают случайно index,follow через тему или SEO-плагин.
curl -I 'https://example.com/?s=seo'Смотрите на три вещи: код ответа, наличие X-Robots-Tag и канонический URL. Если страница поиска уже закрыта, но всё равно индексируется, значит где-то конфликтуют шаблон, кэш или SEO-настройки.
Рабочая схема без плагина
Надёжнее всего сочетать два уровня: запрет обхода в robots.txt и явный noindex для HTML-страницы поиска. Один robots.txt без noindex не гарантирует удаление уже известных URL из индекса, а один noindex без запрета обхода может оставить лишнюю нагрузку на сервер.
1. Закройте поиск в robots.txt
Если у вас есть доступ к корню сайта, добавьте правило в robots.txt. Для WordPress это можно сделать вручную, если файл уже существует.
User-agent: *
Disallow: /?s=
Disallow: /search/
Но здесь есть нюанс: параметр ?s= не всегда корректно обрабатывается всеми роботами как обычный путь. Поэтому этот шаг полезен как дополнительный, но не как единственный.
2. Добавьте noindex для страниц поиска через functions.php
Самый практичный вариант — вывести мета-тег robots только на страницах результатов поиска. Это можно сделать в дочерней теме или через небольшой mu-plugin.
<?php
add_action('wp_head', function () {
if (is_search()) {
echo "<meta name=\"robots\" content=\"noindex,follow\" />\n";
}
}, 1);
Здесь важно использовать именно noindex,follow, если вы не хотите обрывать внутреннюю перелинковку. Для поисковой выдачи это обычно разумнее, чем noindex,nofollow.
3. При необходимости отдавайте X-Robots-Tag
Если тема или SEO-плагин вмешиваются в <head>, можно продублировать запрет через HTTP-заголовок. Это особенно полезно, когда HTML кешируется и вы не уверены, что мета-тег попадёт в ответ стабильно.
<?php
add_action('send_headers', function () {
if (is_search()) {
header('X-Robots-Tag: noindex, follow', true);
}
});
Этот вариант не заменяет нормальную настройку темы, но помогает, если поисковые страницы отдаются через кэш и в шаблоне сложно гарантировать корректный meta robots.
Что выбрать: robots.txt, meta noindex или заголовок
| Подход | Плюсы | Минусы | Когда использовать |
|---|---|---|---|
robots.txt | Снижает обход, просто внедряется | Не удаляет уже проиндексированные URL | Как дополнительный слой |
<meta name="robots"> | Понятно для поисковиков, работает на уровне страницы | Нужно, чтобы HTML реально отдавался без конфликтов | Основной способ для поиска WordPress |
X-Robots-Tag | Работает на уровне ответа сервера | Сложнее отлаживать при кэше и прокси | Когда нужен запасной канал |
Пошаговая настройка в WordPress
- Проверьте, какие URL внутреннего поиска уже есть в индексе через поиск по
site:example.com ?s=и отчёт в Google Search Console. - Добавьте запрет в
robots.txtдля параметрических и поисковых URL. - Вставьте в дочернюю тему или mu-plugin код с
is_search()иnoindex,follow. - Если используется кэш, очистите его после изменения.
- Проверьте исходный код страницы поиска и заголовки ответа.
- Отправьте URL на повторное сканирование в Search Console, если они уже были в индексе.
Как проверить, что решение сработало
Проверка должна быть не «страница открывается», а именно техническая.
- Откройте
https://example.com/?s=тести убедитесь, что в<head>естьnoindex,follow. - Проверьте заголовки через
curl -Iи найдитеX-Robots-Tag, если вы его добавляли. - Посмотрите исходный код страницы: мета-тег должен быть на месте, а не только в визуальном DOM после JS.
- В Search Console проверьте, не остались ли старые URL поиска в отчёте по страницам.
- Если сайт на кэше, сравните ответ до и после очистки кэша.
Если после внедрения в исходнике всё правильно, а в индексе изменения не видны, это нормально: поисковику нужно время на повторный обход. Не путайте задержку индексации с ошибкой настройки.
Частые ошибки и как их исправить
Закрыли только robots.txt
Это частая ошибка. Disallow уменьшает обход, но не гарантирует удаление уже известных URL. Если страницы поиска уже в индексе, нужен именно noindex.
Поставили noindex не на все поисковые URL
Иногда тема выводит поиск не только на ?s=, но и на отдельный шаблон /search/ или кастомный endpoint. Проверьте все варианты, которые реально генерирует сайт.
Сломали кэш
Если мета-тег добавлен условно, а кэш отдаёт старую версию страницы, поисковик увидит не то, что вы ожидаете. После изменения очистите page cache, object cache и CDN, если он есть.
Использовали noindex и nofollow без необходимости
Для внутренних поисковых страниц это обычно избыточно. nofollow может ухудшить передачу сигналов по внутренним ссылкам, если поиск всё же содержит полезные ссылки на записи.
Пытались закрыть поиск через canonical на главную
Это плохая замена noindex. Каноникал не всегда решает проблему для страниц с параметрами поиска и может запутать поисковик, если контент на странице явно отличается по запросу.
Безопасность и производительность
Если внутренний поиск активно используется, он может быть точкой лишней нагрузки. Боты любят перебирать запросы, а WordPress при каждом таком запросе строит обычный цикл и может обращаться к базе. Поэтому закрытие индексации — это не только про SEO, но и про снижение бесполезных обходов.
Если сайт большой, стоит ещё проверить:
- не создаёт ли поиск тяжёлые запросы к базе;
- нет ли в теме лишнего вывода на странице поиска;
- не кешируются ли пустые результаты как полноценные страницы;
- не дублируется ли поиск через AJAX и обычный шаблон одновременно.
Если нужен более широкий набор технических чисток — дубли, архивы, служебные страницы, лишние мета-теги — иногда удобнее закрывать это централизованно через Clearfy Pro, но для одной задачи с поиском код обычно быстрее и прозрачнее.
Когда код лучше плагина, а когда нет
Если у вас одна конкретная проблема — закрыть поиск от индексации — код проще сопровождать и легче проверить. Плагин оправдан, когда нужно одновременно управлять множеством SEO-правил, а в команде нет человека, который будет следить за шаблонами темы.
Для точечной задачи я бы оставил код в дочерней теме или mu-plugin: он не зависит от интерфейса админки, не ломается после обновления и не добавляет лишнюю логику в фронтенд.
Если вы всё же используете SEO-плагин, проверьте, не дублирует ли он noindex для поиска автоматически. Два разных источника правил иногда дают конфликт, и в итоге страница получает неожиданный набор мета-тегов.