WordPress и внешний поиск: как настроить его правильно

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

Что нужно подготовить до начала

Ниже описана схема для WordPress 6.x. Она подходит для сайта со статьями, документацией или каталогом, где поиск должен выполняться не в базе WordPress, а во внешнем поисковом сервисе.

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

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

Выберите схему интеграции

У WordPress нет единственного «внешнего поиска». Под этим названием могут скрываться разные решения: от поисковой формы Google до отдельного индекса, который обновляется после каждого изменения записи.

Для первого запуска чаще всего разумен облачный сервис с готовой интеграцией или REST API. Собственный кластер не стоит поднимать ради нескольких тысяч страниц: операционные расходы быстро превысят пользу.

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

Пошаговая настройка

1. Зафиксируйте состав индекса

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

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

2. Создайте отдельный индекс

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

Задайте поля, по которым разрешён поиск, и поля для фильтров. Например, заголовок и текст могут участвовать в полнотекстовом поиске, а тип записи и рубрика — фильтровать результаты.

Проверка: тестовый документ появляется в staging-индексе и возвращается по точному слову из заголовка.

3. Настройте экспорт только публичных записей

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

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

Проверка: опубликованный материал находится в индексе, а черновик и удалённая запись — нет.

4. Определите способ синхронизации

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

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

Проверка: после изменения заголовка результат обновляется, а после снятия публикации ссылка исчезает из поиска.

5. Соберите страницу результатов

Форма поиска должна передавать запрос без лишней HTML-разметки и отображать понятное состояние: загрузка, пустой результат, ошибка сервиса и следующая страница. URL результата берите из индекса, но не позволяйте внешнему сервису подменять домен сайта.

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

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

6. Разделите публичные и секретные ключи

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

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

Проверка: просмотр исходного кода страницы не раскрывает ключ управления индексом, а отключение поискового ключа не ломает синхронизацию.

7. Проверьте индексацию и откат

Перед публикацией очистите тестовый индекс и загрузите в него ограниченный набор записей. Проверьте кириллицу, регистр, дефисы, номера товаров, опечатки, фильтры и переходы по страницам. Затем сравните несколько результатов с обычным поиском WordPress.

Заранее сохраните настройки подключения и порядок повторной индексации. При ошибке обновления должен оставаться последний корректный индекс, а не пустая выдача.

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

Что чаще всего ломается

• В выдаче остаются удалённые записи. Обычно удаление из WordPress не дошло до внешнего индекса. Проверьте журнал синхронизации и отправьте удаление повторно.
• Результаты ведут на staging. В индекс попали абсолютные URL тестового сайта. Перед production-переиндексацией проверьте домен каждого документа.
• Поиск показывает черновики. Фильтрация выполняется по типу записи, но не по статусу публикации. Добавьте проверку статуса на этапе экспорта.
• Кириллица ищется хуже латиницы. Проверьте настройки языка, анализатор текста и нормализацию символов у конкретного провайдера. Не пытайтесь исправить это только изменением CSS.
• Секретный ключ оказался в браузере. Немедленно отзовите его в панели сервиса, создайте новый и проверьте историю запросов. Маскировка ключа в JavaScript не делает его секретным.

Что проверить после запуска

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

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

Что делать дальше

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

Индекс¹ — отдельное хранилище документов, подготовленных для быстрого поиска. В нём могут быть не все данные исходной записи WordPress, а только поля, нужные для выдачи.

¹ Внешний индекс не заменяет базу WordPress и не должен быть единственным местом хранения контента.