Сайт — база знаний

Вводные

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

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

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

Кому подходит

• Продуктовые и IT-компании — документация, API-справочник, гайды по внедрению.
• Сервисы и SaaS — help-центр, снимающий поток однотипных обращений.
• Компании с сложным продуктом — оборудование, ПО, услуги с длинным циклом: контент помогает продавать, а не только поддерживать.
• Экспертный бизнес — юристы, бухгалтеры, консультанты, медицина: справочные материалы работают как источник входящего трафика и доказательство квалификации.
• Компании, растущие командой — внутренние регламенты и онбординг перестают жить в чатах и головах.
• Учебные и отраслевые проекты — методички, справочники, каталоги знаний.

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

Составляющие и особенности

Структура: разделы → подразделы → статьи, с боковой навигацией, хлебными крошками и оглавлением внутри статьи. Сверху — поиск, снизу — связанные материалы и обратная связь («помогла ли статья»).

Особенности, отличающие формат от обычного сайта:

• Поиск — главный элемент интерфейса. В базе знаний им пользуются чаще, чем меню. Он должен работать мгновенно, с опечатками и по содержимому статей, а не только по заголовкам.
• Контент как данные. Статьи хранятся в Markdown или в структурированной CMS, а не в вёрстке: их можно переносить, версионировать, переиспользовать и отдавать в поиск, чат-бота или ИИ-ассистента.
• Массовость определяет архитектуру. Сайт на 500 статей и сайт на 20 — разные проекты: у первого критичны навигация, теги, скорость сборки и работа редакции.
• Процесс важнее запуска. Кто пишет, кто вычитывает, кто актуализирует. Без этого база устаревает и начинает вредить: неверная инструкция хуже отсутствующей.
• SEO с длинным хвостом. Каждая статья — посадочная под свой запрос. Правильная разметка (FAQ, HowTo, breadcrumbs) заметно улучшает вид в выдаче.
• Версии и языки. Для документации типична поддержка нескольких версий продукта и нескольких языков одновременно.

Базовая комплектация

• Иерархия разделов и шаблон статьи с автоматическим оглавлением.
• Боковая навигация, хлебные крошки, связанные материалы.
• Полнотекстовый поиск по всем материалам.
• Поддержка Markdown/MDX: заголовки, списки, таблицы, изображения, блоки кода, врезки и предупреждения.
• Адаптив и читаемая типографика — для длинного текста это функциональное требование.
• SEO: ЧПУ, мета-теги, sitemap, микроразметка, канонические адреса.
• Аналитика: просмотры статей, поисковые запросы внутри сайта, статьи без ответов.
• Перенос стартового объёма материалов (согласованное количество).
• Домен, SSL, публикация, бэкапы.

Дополнительные опции

• Разграничение доступа — закрытые разделы для сотрудников, клиентов или партнёров, вход по логину или через корпоративный аккаунт.
• Мультиязычность — переключатель языков с раздельной навигацией и SEO.
• Версионирование — несколько версий документации продукта одновременно.
• Обратная связь по статье — оценка полезности и форма уточняющего вопроса с передачей в поддержку.
• Форма обращения из статьи — если ответ не помог, обращение сразу уходит в CRM или тикет-систему с контекстом.
• ИИ-поиск и ассистент — ответы по содержимому базы, семантический поиск вместо ключевых слов.
• Редакционный процесс — черновики, ревью, публикация по расписанию, авторы.
• Экспорт в PDF — для инструкций, которые нужны офлайн или в договоре.
• Импорт из Notion, Confluence, Google Docs — перенос накопленного объёма материалов.
• Интеграция с виджетом поддержки — подсказки статей прямо в чате.
• Наполнение и редактура — вычитка, унификация, структурирование существующих материалов.

Разброс цен

Ориентиры на типовой проект.

Вариант	Что входит	Порядок цен
Компактная база	Структура, шаблон статьи, поиск, до ~30 материалов	80–180 тыс. ₽
Стандартная	Индивидуальный дизайн, теги, обратная связь, аналитика, до ~200 материалов	180–400 тыс. ₽
Расширенная	Доступы, мультиязычность, версии, ИИ-поиск, редпроцесс	от 400 тыс. ₽

На стоимость влияют: объём и состояние исходных материалов (главный фактор), число языков и версий, требования к правам доступа, сложность поиска.

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

Сроки: 3–5 недель для компактной базы, 6–10 недель для стандартной; наполнение идёт параллельно и обычно дольше разработки.

Частые вопросы

Чем это отличается от блога?

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

Можно ли обойтись Notion или Confluence?

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

Кто будет писать статьи?

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

Как понять, что база работает?

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

Нужен ли ИИ-поиск?

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

Что с закрытыми разделами для сотрудников?

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