Как исключить страницы из внутреннего поиска WordPress

Автор: Георгий Панин | Опубликовано: 02.10.2026

На WordPress часто нужно убрать из внутреннего поиска не весь контент, а только конкретные страницы: служебные разделы, личный кабинет, корзину, результаты фильтров, страницы благодарности, архивы с дублями или материалы, которые не должны всплывать в поиске по сайту. Если этого не сделать, пользователь получает мусорные результаты, а редакция — лишние жалобы.

Ниже — рабочие способы для темы и плагина, без выдуманных хуков и без ломания основного поиска. Сначала разберём, как понять, где именно возникает проблема, потом — как закрыть страницы точечно и как проверить, что всё сработало.

Когда проблема действительно в поиске WordPress

Сначала важно отличить внутренний поиск от индексации в Google. Это разные задачи. Страница может быть закрыта от поисковых систем, но всё равно показываться в поиске по сайту. И наоборот: можно убрать её из внутреннего поиска, но оставить доступной по прямой ссылке и для индексации.

Признаки, что нужно именно исключение из внутреннего поиска

в результатах поиска по сайту показываются страницы «Спасибо за заявку», «Личный кабинет», «Корзина»;
в выдаче всплывают служебные записи, которые не должны помогать пользователю;
поиск возвращает дубли: страницы категорий, архивы, технические страницы;
после настройки noindex в поиске по сайту ничего не изменилось.

Если проблема только в поисковых системах, нужен другой подход: noindex, canonical, robots.txt или настройка плагина SEO. Если же речь о локальном поиске WordPress, править нужно сам запрос поиска или исключения в шаблоне.

Диагностика: где именно формируется поиск

В WordPress поиск может строиться разными способами. В классической теме это обычно запрос через WP_Query или основной запрос архива поиска. В некоторых темах и конструкторах поиск переопределён через AJAX, REST API или отдельный шаблон. Поэтому сначала проверьте, какой механизм у вас используется.

Откройте страницу поиска и посмотрите URL: обычно это ?s=....
Проверьте, не подключён ли отдельный AJAX-поиск в теме или плагине.
Посмотрите, какие типы записей участвуют в выдаче: записи, страницы, кастомные типы.
Определите, по какому признаку нужно исключать контент: ID, тип записи, шаблон, категория, метка, slug.

Если поиск работает через стандартный WordPress, проще всего использовать фильтр pre_get_posts. Если же тема уже перехватывает запросы, иногда нужно править именно её код или отключать лишний плагин поиска.

Пошаговое решение через `pre_get_posts`

Самый надёжный вариант — изменить основной поисковый запрос и убрать из него нужные страницы. Это не требует правки ядра и нормально переживает обновления. Код можно добавить в functions.php дочерней темы или в собственный мини-плагин.

add_action('pre_get_posts', function ($query) {
    if (is_admin() || ! $query->is_main_query() || ! $query->is_search()) {
        return;
    }

    // Исключаем конкретные страницы по ID.
    $excluded_ids = array(12, 34, 56);

    $query->set('post__not_in', $excluded_ids);
});

Этот вариант подходит, если нужно убрать несколько страниц вручную. Например, страницу благодарности после формы, страницу входа или внутренние инструкции для сотрудников.

Как исключить по типу записи

Иногда проще убрать целый тип контента. Например, не показывать в поиске служебные записи кастомного типа docs или faq, если они не предназначены для посетителей сайта.

add_action('pre_get_posts', function ($query) {
    if (is_admin() || ! $query->is_main_query() || ! $query->is_search()) {
        return;
    }

    $query->set('post_type', array('post', 'page'));
});

Здесь поиск будет искать только по записям и страницам. Если у вас есть отдельные типы записей, их нужно добавить вручную. Иначе они исчезнут из результатов, даже если это полезный контент.

Как исключить по slug или шаблону

По slug исключать можно, но на практике надёжнее использовать ID. Slug меняется, а ID — нет. Если всё же нужен slug, сначала получите ID страницы по нему и уже потом исключайте по ID.

$page = get_page_by_path('thank-you');
if ($page) {
    $excluded_ids[] = $page->ID;
}

Такой подход удобен, когда страница создаётся один раз и её нужно убрать из поиска навсегда, но без жёсткой привязки к ручному номеру.

Если поиск делает плагин или AJAX-виджет

У некоторых тем поиск на главной или в шапке работает не через стандартный шаблон WordPress, а через AJAX. В этом случае pre_get_posts может не помочь, потому что запрос идёт отдельным обработчиком. Тогда нужно смотреть документацию плагина или искать его фильтры.

Практически это выглядит так: вы открываете DevTools, смотрите сетевые запросы и находите, куда уходит поиск. Если запрос идёт на admin-ajax.php или REST endpoint, значит, исключение нужно делать на стороне этого обработчика.

Подход	Когда подходит	Минус
`pre_get_posts`	Стандартный поиск WordPress	Не влияет на кастомный AJAX-поиск
Фильтр плагина поиска	SearchWP, Relevanssi и похожие решения	Нужно знать конкретный плагин
Правка шаблона AJAX	Тема сама строит выдачу	Сложнее поддерживать при обновлении темы

Если у вас установлен плагин расширенного поиска, проверьте его настройки исключений. Многие такие плагины умеют исключать страницы, категории и типы записей без кода. Но если задача точечная, код обычно надёжнее и прозрачнее.

Как проверить, что исключение работает

После изменения кода не ограничивайтесь визуальной проверкой на одном запросе. Нужна короткая проверка по нескольким сценариям.

введите в поиск точное название исключённой страницы;
проверьте, что она не появляется в результатах;
введите запрос, по которому должны находиться обычные записи;
убедитесь, что основной контент по-прежнему ищется;
если используется кэш, очистите его и повторите тест.

Для быстрой диагностики можно временно вывести параметры запроса в лог или использовать плагин для просмотра SQL-запросов. Но на боевом сайте лучше ограничиться тестовой средой или короткой отладкой через error_log.

add_action('pre_get_posts', function ($query) {
    if (is_admin() || ! $query->is_main_query() || ! $query->is_search()) {
        return;
    }

    error_log('Search query: ' . print_r($query->query_vars, true));
});

После проверки этот код нужно убрать. Постоянный лог на каждом поиске быстро засорит файл и может замедлить сайт.

Частые ошибки и как их исправить

Исключили не тот запрос

Самая частая ошибка — фильтр срабатывает не только на поиске, а вообще на всех запросах. Это происходит, если забыли проверку $query->is_main_query() или $query->is_search(). В результате ломаются архивы, главная или виджеты.

Исправление простое: всегда ограничивайте код только основным поисковым запросом.

Использовали ID из другой среды

На staging и production ID страниц часто отличаются. Если вы перенесли код с тестового сайта, проверьте, что ID действительно совпадают. Иначе исключится не та страница или исключение не сработает вообще.

Забыли про кэш

Если на сайте есть page cache, object cache или кэш плагина поиска, изменения могут не проявиться сразу. Сначала очистите кэш, потом тестируйте. Иначе легко решить, что код не работает, хотя проблема только в устаревшем HTML.

Пытались скрыть страницу только через robots.txt

robots.txt не убирает страницу из внутреннего поиска. Он влияет на обход поисковыми роботами, но не на логику WordPress. Для локального поиска нужен именно фильтр запроса или настройка плагина.

Что делать, если нужно не исключить, а понизить приоритет

Иногда страницу не нужно полностью убирать из поиска. Например, служебная страница может быть полезна для части пользователей, но не должна всплывать первой. Тогда лучше не исключать её, а изменить релевантность. Это уже зависит от конкретного поискового решения: стандартный WordPress почти не умеет тонкую настройку релевантности, а плагины вроде Relevanssi или SearchWP дают больше контроля.

Если задача регулярно повторяется — например, нужно управлять дублями, служебными страницами и SEO-исключениями в одном месте — удобнее вынести это в отдельный инструмент. В экосистеме WPShop для таких задач есть Clearfy Pro: он помогает с технической чисткой сайта и управлением дублями, когда нужно не только скрыть контент из поиска, но и привести в порядок SEO-настройки. Ссылка: Clearfy Pro.

Практические советы по безопасности и производительности

Если вы вносите изменения через functions.php, делайте это в дочерней теме или в небольшом плагине. Так вы не потеряете правки после обновления темы. Для production-сайта это не рекомендация «на будущее», а нормальная практика поддержки.

не редактируйте файлы родительской темы напрямую;
не оставляйте отладочный error_log в постоянной версии;
не исключайте слишком много страниц без проверки сценариев поиска;
если используется плагин поиска, сначала проверьте его встроенные исключения;
после изменений прогоните поиск по нескольким ключевым словам.

Если сайт большой и поиск нагружен, имеет смысл отдельно посмотреть на кэширование и на то, как часто выполняются поисковые запросы. Иногда проблема не в исключениях, а в том, что поиск слишком тяжёлый сам по себе и требует оптимизации индексов или перехода на специализированный плагин.

В итоге логика простая: сначала определите, какой именно поиск у вас работает, потом исключите страницы точечно и обязательно проверьте результат на реальных запросах. В WordPress это решается без сложной архитектуры, если не пытаться закрыть всё одним общим фильтром.