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

Автор: Артем Никитин | Опубликовано: 24.09.2026

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

Ниже — практический разбор: как понять, что именно попадает в поиск, чем лучше исключать контент в зависимости от задачи и как проверить, что после правки поиск действительно стал чище.

Когда внутренний поиск нужно править

Типичный сигнал — пользователь вводит запрос, а в результатах видит не статьи и страницы, а:

вложения изображений;
страницы автора, архивы, теги и категории;
служебные страницы вроде «Спасибо за заказ» или «Политика конфиденциальности»;
дубли контента из кастомных типов записей;
пустые или нерелевантные результаты из-за совпадения в заголовке, но не в содержимом.

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

Быстрая диагностика

Перед изменениями проверьте три вещи:

Какие типы записей участвуют в поиске.
Попадают ли в выдачу вложения и служебные страницы.
Не ломается ли поиск после установки SEO-плагина или темы.

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

Как исключить страницы из поиска: рабочие варианты

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

Подход	Когда подходит	Плюсы	Минусы
Код через хук	Нужно исключить 1–2 типа записей или конкретные ID	Точно, быстро, без лишних зависимостей	Нужно поддерживать код в теме или плагине
Плагин поиска	Нужны веса, фильтры, исключения и отдельная логика выдачи	Удобно для редакторов, меньше ручной работы	Дополнительная нагрузка и зависимость от плагина
Настройка темы	Тема уже переопределяет поиск	Можно быстро убрать очевидные ошибки	Часто решение временное и плохо переносится при смене темы

Вариант 1: исключить типы записей через `pre_get_posts`

Если нужно убрать из поиска, например, страницы и вложения, используйте хук pre_get_posts. Это самый предсказуемый способ, если вы контролируете тему или свой мини-плагин.

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

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

Этот пример оставляет в поиске только записи типа post. Если у вас есть отдельный контентный тип, добавьте его явно:

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

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

Такой подход хорош тем, что вы не пытаетесь «запретить всё лишнее», а задаёте список разрешённых типов. Для поиска это обычно надежнее.

Вариант 2: исключить конкретные страницы по ID

Если проблема в нескольких служебных страницах, можно исключить их точечно. Это полезно для страниц «Корзина», «Оформление», «Спасибо», «Политика» и похожих.

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

    $excluded_ids = array( 12, 34, 56 );
    $query->set( 'post__not_in', $excluded_ids );
} );

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

Вариант 3: исключить вложения и служебные записи через фильтр поиска

Иногда в поиск попадают attachment-страницы изображений. Если они не нужны, можно убрать их из результатов на уровне запроса:

<?php
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' ) );
    $query->set( 'post_status', 'publish' );
} );

Если у вас в теме уже есть отдельная логика для поиска, проверьте, не переопределяет ли она этот запрос позже. Частая ошибка — добавить код в functions.php, а потом удивляться, что тема формирует свой WP_Query и игнорирует главный запрос.

Если нужен более гибкий поиск

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

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

Что проверить в настройках плагина

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

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

Пошаговая настройка без лишнего риска

Сделайте резервную копию файлов и базы.
Определите, что именно нужно убрать из поиска: типы записей, отдельные страницы, вложения.
Добавьте код в дочернюю тему или мини-плагин, а не в родительскую тему.
Проверьте поиск в обычном режиме и в режиме инкогнито.
Сравните результаты до и после на 5–10 реальных запросах.

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

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

Проверка должна быть не «по ощущениям», а по конкретным запросам.

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

Если вы меняли запрос через pre_get_posts, полезно временно включить логирование и посмотреть, какой post_type реально уходит в запрос. Это помогает быстро поймать конфликт с темой или другим плагином.

Мини-проверка через WP-CLI

Если у вас есть доступ к WP-CLI, можно быстро проверить, что поиск не ломает базовую выборку контента. Это не заменяет ручную проверку, но помогает понять, жив ли сайт после правки.

wp option get blogname
wp post list --post_type=post --post_status=publish --fields=ID,post_title --format=table

WP-CLI не покажет результаты поиска напрямую, но поможет убедиться, что контент опубликован и доступен, а проблема именно в логике поиска, а не в статусах записей.

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

Код добавили не туда

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

Сломали админку или REST API

Иногда разработчики пишут условие слишком широко и не проверяют is_admin() или is_main_query(). В результате меняется не только фронтенд-поиск, но и запросы в админке или сторонних интеграциях.

Исключили слишком много

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

Конфликт с плагином поиска

Если установлен SearchWP, Relevanssi или похожий инструмент, стандартный pre_get_posts может не дать ожидаемого эффекта. В таком случае нужно настраивать исключения в самом плагине, а не бороться с ним на уровне темы.

Безопасность и производительность

Любая правка поиска должна быть простой и предсказуемой. Чем сложнее условие, тем выше шанс получить медленный запрос или конфликт с кэшем.

Не делайте поиск по всем типам записей без необходимости.
Не добавляйте тяжёлые SQL-условия в posts_where, если можно решить задачу через pre_get_posts.
Не храните список исключений в коде, если редакторы меняют его часто — лучше вынести в настройки.
Проверяйте изменения на копии сайта перед выкладкой на продакшен.

Если вам нужно одновременно убрать дубли, служебные страницы и лишние архивы, иногда удобнее собрать это в одном инструменте для технической чистки сайта. В таких сценариях полезны плагины уровня Clearfy Pro, но только если вы действительно используете их функции, а не ставите «на всякий случай».

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