Как сделать поиск по статическому сайту без сервера

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

В проектах на Astro, Eleventy и других статических генераторах в Exceltic.dev регулярно видим один и тот же момент: сайт растёт, разделов и статей становится больше сотни, а обычной навигации по меню уже не хватает - читателю нужен поиск. Команда открывает панель хостинга и упирается в вопрос: сервера, который выполнит запрос, в архитектуре просто нет.

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

Проблема встаёт в полный рост у контентных сайтов - документации, блогов, каталогов, - где счёт статей идёт на сотни. У такого сайта нет сервера, который на лету выполнит запрос по тексту: страница отдаётся как готовый HTML-файл с хостинга или CDN. Без отдельного механизма поиск на сайте просто отсутствует, а читатель ищет нужную статью через Ctrl+F в браузере или уходит искать ответ в Google.

Статический поисковый индекс: заранее собранный файл или набор файлов с данными для поиска по сайту, который создаётся один раз при сборке и после этого отдаётся браузеру как обычный статический ресурс.

Почему у статического сайта нет “обычного” поиска

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

Статический сайт устроен иначе. Astro, Eleventy, Hugo и другие генераторы превращают контент в готовые HTML-файлы ещё на этапе сборки, а не на каждый запрос пользователя. Хостинг или CDN просто отдают эти файлы браузеру без каких-либо вычислений на своей стороне - в этом и заключается их скорость и простота.

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

Клиентский поиск: поиск, при котором сопоставление запроса пользователя с содержимым сайта происходит в браузере, а не на сервере. Именно он и закрывает эту нехватку - вычисления переносятся туда, где сайт уже физически находится: в браузер пользователя.

Варианты решения - обзор подходов

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

• Предварительно построенный индекс в браузере. На этапе сборки сайта генерируется поисковый индекс, который загружается в браузер и обрабатывает запросы прямо на клиенте. Пример такого инструмента - Pagefind, open-source библиотека для полнотекстового поиска по статическим сайтам без хостинга собственной инфраструктуры.
• Сторонний поисковый сервис или API. Индекс строится и хранится не в браузере, а на серверах внешнего провайдера (например, Algolia или Meilisearch Cloud). Сайт отправляет запрос по сети и получает готовый список результатов - фактически это возврат к серверной модели, только сервер чужой.
• Встроенный поиск CMS или платформы. Если контент хранится в headless CMS с собственным API поиска, эту функцию можно использовать напрямую, не добавляя отдельный инструмент - актуально для сайтов на архитектуре вроде Astro и Sanity, где контент и так живёт в управляемом хранилище.

Все три варианта решают одну задачу - найти нужную страницу по тексту запроса, - но по-разному распределяют нагрузку между браузером, сборкой сайта и сторонним сервером.

Когда какой вариант подходит

Выбор зависит не от предпочтений разработчика, а от объёма контента и требований к качеству поиска.

• Небольшой сайт или документация (до нескольких тысяч страниц). Предварительно построенного индекса в браузере достаточно: он не требует ни оплаты стороннего сервиса, ни отдельной инфраструктуры, а результат появляется мгновенно после ввода запроса.
• Крупный каталог или e-commerce. Здесь клиентский поиск обычно перестаёт справляться - нужны фасетные фильтры, персонализация выдачи и аналитика по несостоявшимся запросам, которые есть у сторонних поисковых сервисов, но плохо ложатся на статический индекс.
• Нужен fuzzy-поиск и синонимы. Базовые библиотеки для клиентского поиска умеют прощать опечатки и частичные совпадения, но продвинутая работа с синонимами, ошибками распознавания языка и весами полей обычно лучше реализована у специализированных сервисов.
• Нужна персонализация выдачи. Показ разных результатов разным пользователям требует сервера, который знает контекст запроса - клиентский индекс такой возможности не даёт в принципе.

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

Как работает клиентский поиск на практике

Разберём механизм на примере подхода с предварительно построенным индексом - самого распространённого сценария для статических сайтов.

1. Генерация индекса при сборке

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

# сначала обычная сборка статического сайта
astro build

# затем отдельный шаг индексации по готовым HTML-файлам
npx pagefind --site dist

2. Загрузка индекса частями по мере набора запроса

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

3. Ранжирование результатов

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

4. Работа офлайн и на медленном интернете

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

На сайте документации из 300-500 страниц собранный поисковый индекс обычно занимает от одного до нескольких мегабайт суммарно, но благодаря разбивке на части браузер при первом запросе подгружает лишь десятки-сотни килобайт - основная масса файла остаётся невостребованной, пока запрос не станет достаточно специфичным. По данным документации Pagefind, библиотека способна индексировать сайты из 10 000 страниц с суммарной сетевой нагрузкой на поисковый интерфейс в пределах нескольких сотен килобайт - точные цифры зависят от объёма текста на странице и настроек индексации. По состоянию на середину 2026 года Pagefind остаётся одним из наиболее используемых инструментов такого рода в экосистеме статических генераторов.

Что теряется по сравнению с серверным поиском

Клиентский поиск закрывает базовый сценарий, но не заменяет полноценный серверный поиск во всех задачах.

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

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

Рост индекса вместе с объёмом контента. Чем больше страниц и текста на сайте, тем тяжелее становится индекс. Для сайта с десятками тысяч статей объём данных, которые нужно поддерживать актуальными при каждой сборке, становится заметной статьёй расходов по времени сборки.

Типичные ошибки

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

• Индекс собирается не на финальных файлах сборки. Если шаг индексации запускается раньше, чем готов итоговый HTML, в индекс попадает неполный или устаревший контент.
• Забытая пересборка индекса при автопубликации. Если контент обновляется отдельным процессом (например, через CMS-вебхук), а шаг индексации не встроен в этот же пайплайн, поиск начинает выдавать устаревшие результаты.
• Поиск не протестирован на медленном соединении. Индекс, который отлично работает на офисном Wi-Fi, может ощутимо тормозить на мобильном интернете - это стоит проверять отдельно.
• Ожидание фасетных фильтров и персонализации от базового решения. Клиентский индекс не заменяет полноценный поисковый сервис для каталога с десятками атрибутов фильтрации.
• Отсутствие резервного сценария при недоступности JavaScript. Поиск полностью зависит от выполнения скрипта в браузере - без запасного варианта (например, обычной навигации) пользователь с отключённым JS останется без поиска вовсе.

Для кого актуально

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

Часто задаваемые вопросы

Работает ли клиентский поиск на сайте с десятками тысяч страниц?

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

Нужен ли для клиентского поиска отдельный сервер или хостинг индекса?

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

Умеет ли клиентский поиск прощать опечатки и искать по частичным совпадениям?

Базовые библиотеки для клиентского поиска, включая Pagefind, поддерживают простой fuzzy-поиск и частичные совпадения слов. Однако продвинутая обработка синонимов, языковых форм и весов по полям обычно реализована лучше у специализированных сторонних сервисов - это стоит учитывать для сайтов, где точность поиска критична для конверсии. Для документации и блога базовой точности обычно достаточно, а более тонкую настройку выдачи добавляют уже по мере роста жалоб пользователей на нерелевантные результаты.

Как обновляется индекс, если контент на сайте меняется?

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

Сколько времени занимает добавление поиска на уже готовый сайт?

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

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

Если у вас статический сайт растёт контентом, а поиска по нему всё ещё нет - опишите задачу команде Exceltic.dev. Разберём объём контента и предложим архитектуру поиска под ваш сайт.