Возможно, вам не нужна Algolia™

Статическим сайтам, вероятно, не нужен поисковый сервис

Image by Dan Levy

Большинство решений о поиске по сайту принимаются слишком поздно.

К тому моменту, когда кто-то говорит «нам стоит использовать Algolia», команда обычно пропускает главный вопрос: какой именно контент мы ищем?

Если ответ — «HTML-страницы, которые мы уже генерируем», Pagefind должен стать первым, что вы попробуете. Не потому, что Algolia плох. Algolia очень хорош в решении множества сложных задач. Но если ваш поисковый индекс меняется одновременно с деплоем сайта, хостинговый поисковый сервис может оказаться инфраструктурным косплеем.

Используйте Pagefind, когда ваш поисковый контент генерируется на этапе сборки. Выбирайте Algolia, когда поиск должен принимать данные в реальном времени, применять бизнес-правила, учитывать пользовательское ранжирование или предоставлять гарантии, которые ваша статическая сборка обеспечить не может.

Это правило покрывает больше сайтов, чем люди ожидают: блоги, документация, маркетинговые сайты, внутренние справочники, руководства по продуктам, каталоги курсов и удивительное количество «приложений», которые по сути просто публикуют страницы.

Форма проблемы

Algolia даёт вам внешнюю поисковую систему. Вы создаёте записи, отправляете их в индекс, настраиваете ранжирование, подключаете интерфейс и поддерживаете синхронизацию с источником истины.

Pagefind смотрит на HTML, который вы уже опубликовали, и строит статический поисковый индекс рядом с ним.

Это различие звучит скучно, пока вы не начнёте поддерживать интеграцию.

С Algolia у вашего сайта появляется вторая копия контента. Теперь нужно отвечать на вопросы вроде:

• Деплой завершился, а обновление индекса не сработало?
• Какие поля являются каноническими: данные из CMS, отрендеренная страница или поисковая запись?
• Кто отвечает за корректировку ранжирования, когда результаты перестают соответствовать странице?
• Что происходит, когда бесплатный тариф оказывается не тем, что реально нужен вашему трафику?

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

Pagefind работает, потому что отказывается от лишней системы

Фишка Pagefind — не магия. Это здравый смысл.

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

Это делает возможные проблемы гораздо более понятными:

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

Именно поэтому мне нравится Pagefind для контентных сайтов. Индекс следует за артефактом.

Как на самом деле выглядит настройка

Для обычного статического сайта процесс приятно прост:

• CLI: Сканирует HTML-файлы вашего сайта, генерирует индекс и размещает его на глобальном CDN — всё за считанные минуты.
• Генераторы статических сайтов: Используйте плагины PageFind для Astro или Hugo, чтобы автоматизировать процесс индексации.
• Индивидуальные решения: Применяйте API PageFind для создания поисковых решений, адаптированных под ваши уникальные требования.

Руководства Getting Started достаточно, чтобы начать. Лучший тест — практический: можете ли вы пересобирать индекс в CI, публиковать результат и объяснять каждый промах поиска, проверяя отрендеренный HTML?

Где Algolia всё ещё выигрывает

Pagefind — это не маленькая Algolia в тренчкоте. Это другой ответ.

Используйте Algolia, OpenSearch, поиск Postgres или другую систему реального времени, когда ваш поисковый индекс должен обновляться независимо от деплоя сайта.

Это включает:

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

Это реальные потребности. Притворяться, что Pagefind справляется с ними, только потому что он быстрый, было бы другой формой рекламного голоса.

Решение, которое я использую

Сначала задайте один вопрос:

Можно ли пересобрать поисковый индекс из того же статического контента, который просматривают пользователи?

Если да, начните с Pagefind. Вы получите поиск с приватностью по умолчанию, CDN-совместимые файлы и на один сервисный аккаунт меньше.

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

Algolia — не злодей в этой истории. Злодей — внедрение второй системы до того, как доказана недостаточность первой.