Введение: статический сайт быстрый, но правки могут быть адом
Статический сайт на SSG обычно летает. Пока вы его не начинаете править.
И вот тут вскрывается любимый цирк: “поменяйте телефон”, “добавьте услугу”, “перепишите оффер” — и всё. Без разработчика нельзя. Разработчик занят. Маркетинг бесится. Вы теряете заявки.
Проблема не в статике. Проблема в том, что вам продали “быстро”, но не продали процесс. Сейчас покажу, как сделать правки на статическом сайте нормально: с CMS, предпросмотром (preview) и деплоем без истерик.
Логика системы: кто правит, где правит, как попадает на сайт
Правки на статическом сайте — это всегда цепочка:
- Источник контента (файлы в Git или headless CMS)
- Предпросмотр (чтобы не публиковать кривь)
- Публикация (сборка SSG)
- Деплой (выкат на прод)
- Откат (если всё сломали)
Если хотя бы одного пункта нет — вы платите временем, деньгами или нервами. Обычно всем сразу.
Вариант 1: Git-based подход (дёшево, но не для “гуманитариев”)
Подходит, если контент правит технарь/редактор, который не падает в обморок от слов “commit” и “pull request”.
Как работает
- Контент хранится в репозитории (Markdown/JSON/YAML).
- Редактор правит → коммитит → PR → после мержа запускается сборка и деплой.
Плюсы
- Контроль версий, понятный откат.
- Дёшево по инфраструктуре.
- Прозрачность: кто и что менял.
Минусы
- Для большинства “контент-менеджеров” это как пилотировать вертолёт.
Если у вас менеджеры и маркетологи, которые считают Git религией программистов — идём дальше.
Вариант 2: Headless CMS (норм для бизнеса, если сделано с головой)
Это ваш лучший кандидат, если вы хотите “админку как у людей”: роли, редакторы, статусы, медиатека.
Что выбрать в целом (по типам, без фанатизма)
- Hosted headless (платные SaaS): быстро стартовать, но подписки и ограничения.
- Self-hosted headless: больше контроля, но вы отвечаете за сервер, обновления и безопасность.
- Git-based CMS с интерфейсом: что-то среднее между “админка” и “Git”.
Я не продаю тут конкретные бренды. Я продаю вам мысль: CMS выбирается под процесс и бюджет поддержки, а не “что модно в Твиттере”.
Обязательные требования к CMS для статики
- Роли и права (хотя бы “редактор/админ”).
- Черновики и расписание публикаций (желательно).
- Медиа-хранилище (или интеграция).
- Webhooks на сборку.
- Preview (иначе будет вечная херня).
Preview: вот где рождается экономия нервов
Предпросмотр — это отдельная ссылка, где редактор видит, как страница будет выглядеть до публикации.
Нормальный preview бывает двух типов
- Draft preview: CMS отдаёт черновики, сайт их показывает на отдельном окружении.
- Deploy preview: каждое изменение запускает сборку в отдельное превью-окружение (часто на уровне хостинга/CI).
Если preview нет — вы публикуете “на прод” вслепую. Это не “храбро”. Это тупо.
Деплой без боли: автоматизация, окружения и “кнопка отката”
Минимальная схема, которая работает
- Dev/Preview: там смотрят и согласуют.
- Production: там живут клиенты.
Что должно быть автоматом
- Публикация в CMS → webhook → запускается сборка SSG → деплой.
- Логи сборки и уведомления (иначе вы узнаете о проблеме от клиента).
- Версионирование релизов и быстрый rollback.
Ключевой бизнес-показатель
Сколько времени проходит от “поменять текст” до “на сайте видно”?
Если больше 30–60 минут для простых правок — у вас не статика, у вас бюрократия в коде.
Практическая польза: схема под ваши задачи
Если правок мало (1–5 в месяц)
- Git-based контент + простая сборка/деплой.
- Один ответственный.
- Главное — документация и откат.
Если правок много и делает маркетинг
- Headless CMS + preview + авто-деплой.
- Роли, черновики, процесс согласования.
- Сборка должна быть быстрой, иначе маркетинг вас сожрёт.
Если много страниц и SEO-структура растёт
- CMS обязательна.
- Шаблоны блоков, чтобы не плодить уникальные “снежинки”.
- Регламент: кто создаёт страницы, кто проверяет.
Типичные ошибки и решения
Ошибка 1: “Сделаем статический сайт без админки, там же всё просто”
Решение: либо Git-процесс с ответственным, либо CMS. Иначе каждая правка = платная молитва разработчику.
Ошибка 2: “Preview не нужен, мы аккуратные”
Решение: вы не аккуратные. Никто не аккуратный. Preview экономит деньги и репутацию.
Ошибка 3: “Поставим CMS, а процесс как-нибудь сложится”
Решение: процесс сначала: роли, кто согласует, что считается готовым, SLA на правки. Потом инструменты.
Ошибка 4: “Деплой вручную, зато под контролем”
Решение: вручную — это значит “когда Вася не в отпуске”. Автоматизация дешевле, чем простой бизнеса.
Вывод
Правки на статическом сайте могут быть быстрыми и дешёвыми. Но только если вы заранее закладываете три вещи: CMS (или Git-процесс), preview и автоматический деплой с откатом.
Статика без процесса — это не “современно”. Это просто ещё один способ сделать бизнес зависимым от разработчика и терять деньги на задержках.
