Новостные сюжеты про безопасность сайтов начинаются одинаково: нашли критическую уязвимость в PHP-стеке, владельцы сайтов бегут ставить патчи, кто-то не успевает. Мы в какой-то момент посмотрели на это со стороны и задали неудобный вопрос: а зачем вообще держать на сервере исполняемый код, если задача сайта — показывать текст, картинки и форму заявки?
Ответ оказался скучным и очень полезным: не зачем. Статический сайт — это HTML-файлы, собранные заранее и разложенные по полке. На проде нет PHP, нет базы данных, нет админки. А вместе с ними уходит половина причин, по которым сайты вообще взламывают.
Этот блог и наш основной сайт собраны именно так — на Hugo, генераторе статических сайтов. И большую часть рутинной поддержки делает AI-агент: правит файлы, пересобирает, проверяет страницы и присылает pull request. Дальше — как это устроено по шагам, чем в статике заменяют формы, поиск и многоязычность, и в каких случаях такой подход вам честно не подойдёт.
Table Of Contents
Очередная дыра в PHP — не случайность, а свойство стека
Сайт на PHP — это живой исполняемый код на сервере: ядро, тема, подключённые плагины, каждый со своими зависимостями. Этот код выполняется заново на каждый запрос посетителя. Поэтому уязвимость вида «удалённое выполнение кода» в таком стеке — не аномалия и не чья-то личная халатность, а нормальный режим жизни большой кодовой базы, которую кто-то когда-то скачал и подключил. Подробный разбор того, чем это заканчивается, мы разбирали в статье «Почему PHP опасен для бизнеса».
Жизнь такого сайта — это гонка обновлений. Вышло исправление: обновили — вёрстка поехала, один плагин конфликтует с другим, второй ждёт совместимости. Не обновили — сканеры подбирают пароль к админке или отрабатывает готовый эксплойт, который уже лежит в открытом доступе. Третий вариант — «обновим потом» — самый частый, и именно он превращает новостной сюжет про чужую уязвимость в ваш инцидент.
Симптомы взлома стандартные: подменённые редиректы на сайты с «чудо-таблетками», скрытые скрипты в подвале страниц, украденная база пользователей и заявок, сайт в чёрных списках поисковиков. И самое противное — починка почти никогда не заканчивается одним «переустановили и забыли»: если дыра сидит в самом стеке, рано или поздно вы снова останетесь ждать чужой патч.
Что такое статический сайт, если без аббревиатур
Конвейер выглядит так: контент в markdown → сборка → готовые HTML/CSS/JS → раздача. Автор пишет статью в текстовой файл, генератор (у нас это Hugo версии 0.153.2) подставляет её в шаблоны, применяет меню, стили, скрипты, языковые версии — и на выходе получается готовая папка с файлами. Именно она уезжает на прод.
На сервере в рантайме не выполняется ничего. Нет PHP-процесса, нет подключения к базе на каждый хит, нет панели «Войти», нет API-эндпоинта, который что-то пишет в таблицу. Есть файловый сервер и CDN: пришёл запрос на страницу — отдали файл. Точка.
Слово «статический» пугает владельцев, потому что его путают со «застывшим». На деле меняется всё, что угодно: текст, дизайн, структура меню, форма, интеграции. Просто это меняется в коде и собирается заново, а не правится «на живом сайте» через админку. Изменение, которое нельзя применить к живому сайту одним случайным кликом, — это не ограничение, а защита.
Почему это безопаснее: не «меньше дыр», а дырить нечего
Главная разница даже не в количестве уязвимостей, а в их природе. Пройдёмся по списку того, чего в статике просто нет:
- Нет удалённого выполнения кода. Уязвимости вида «выполнение кода в PHP» неприменимы физически: PHP на проде отсутствует, исполнять прилетевший код некому.
- Нет SQL-инъекций. Некуда вставлять: базы данных нет, а значит нет и дампа таблицы с пользователями и заявками.
- Нет админки. Нечего брутфорсить, нечего обходить по токену, нечего эксплуатировать через залитый «безобидный» плагин.
- Нет цепочки обновлений. Плагины и модули — тот слой, через который прилетает больше всего проблем; в статике его нет как класса.
- Нечего красть. Данные формы не хранятся на сайте: они уходят наружу через вебхук и живут там, где им и место, — в CRM.
Что остаётся в зоне ответственности: доступ к репозиторию и к деплою, настройки TLS, DNS и сам CDN. Это честный и короткий список — его реально контролировать, в отличие от бесконечного дерева чужих PHP-зависимостей.
Как это работает у нас: git, ветка, PR и агент на 90% работы
Процесс выглядит так: правка в git → отдельная ветка → сборка → проверка страниц → PR → ревью человеком. Никакого «зашли в админку и нажали опубликовать». Перед тем как что-то появится на сайте, это существует как предложение в ветке.
Агент делает 90% этой работы. Он берёт задачу, поднимает ветку, правит или создаёт markdown-файлы, запускает сборку локально, смотрит, что страницы рендерятся, ссылки не битые, меню сходится, — и открывает pull request с внятным описанием. Человек делает оставшиеся 10%: читает diff и мержит.
Diff здесь — не бюрократия, а граница безопасности. Любое изменение сайта — это набор файлов в git: видно, кто, что и зачем поменял; любая ошибка откатывается revert’ом. Даже если кто-то получит доступ к сборочному контуру, он не сможет «подмешать код в рантайм»: на прод уезжает только то, что прошло ревью и попало в сборку. Повреждённая страница — это сломанный файл, а не дыра в сервере.
Warning
Агенту можно доверять писать и собирать, но нельзя доверять публиковать. У нас финальный merge всегда за человеком: агент не имеет доступа к проду и не может слить свой же PR. Ключи от репозитория и контура деплоя в такой схеме — это и есть ключи от сайта, беречь их надо соответственно.
«Сложные» функции, которые в статике оказываются простыми
Все страхи про статику — это страхи про формы, поиск и «а как же управлять». Разбираем по пунктам.
Формы и интеграции. Кнопка «Оставить заявку» не требует серверного кода на сайте: данные уходят вебхуком или в REST API — например, прямиком в Битрикс24, где лид и появляется. Сайт остаётся файлами, а вся логика — в системе, для которой она и предназначена.
Поиск. Индекс строится при сборке из тех же markdown-файлов, а ищет уже браузер посетителя, без запросов к серверу. Для блога или корпоративного сайта этого более чем достаточно.
Комментарии и пользовательский контент. Их либо выносят на сторону (внешний виджет), либо оставляют форму с модерацией. Хранить чужой текст на витрине — лишний риск, который сам себе создают только потому, что «так было в CMS».
Многоязычность. Языковые версии — это отдельные наборы файлов контента и переключатель в шаблоне; при сборке получаются готовые директории для каждого языка. Разница с CMS в том, что языки не «складываются в базу», а разъезжаются по папкам.
llms.txt. Файл-навигатор для AI-краулеров у нас тоже генерируется шаблоном прямо при сборке — как и всё остальное. Зачем он нужен и что в нём писать, мы разбирали в статье «llms.txt: как сделать сайт понятным для нейросетей».
Скорость, CDN и SEO: бонус, за который статику любят отдельно
Безопасность — приятная причина, но вторая не менее весомая: страница отдаётся как файл, значит время ответа не зависит от того, сколько человек зашло одновременно и сколько таблиц нужно было собрать в шаблон. Контент лежит на CDN ближе к посетителю, кэш работает предсказуемо, а всплеск трафика с карточки в соцсети не превращается в упавший сервер.
Поисковикам и AI-ботам такой сайт тоже нравится: чистый HTML без мусора от плагинов, стабильная разметка, быстрые страницы, внятная перелинковка. Моментальная отдача страниц — это то, что потом видно в отчётах по качеству: сайт просто не успевает тормозить.
И обратная сторона та же: когда сайт работает и грузится быстро, но при этом уязвим к PHP-эксплойтам, быстрый не спасает. Если хотите понять, что именно мешает вашему текущему сайту — и заодно посмотреть на дыры в стеке, — у нас есть методичка «Как ИИ проверяет сайт».
PHP-сайт и статика: сравнение по осям
| Ось | Сайт на PHP (CMS) | Статика на Hugo |
|---|---|---|
| Обновления | Ядро, тема, плагины — постоянно, с риском поломки | Пересобирается шаблон; обновлять нечего |
| Поверхность атаки | PHP + база + админка + чужие модули | Файлы на CDN; исполняемого кода нет |
| Удалённое выполнение кода | Реальный сценарий при каждой новой волне уязвимостей | Неприменимо: выполнять нечего |
| Кража данных | База с пользователями и заявками — главный приз | На сайте хранить нечего |
| Скорость | Зависит от сервера, кэша и нагрузки | Отдача готового файла, обычно с CDN |
| Хостинг | Сервер с PHP и базой, запас под пиковую нагрузку | Статическая раздача, дешёвая и почти без лимитов |
| Доступ для ИИ | HTML генерируется в рантайме, боту сложнее | Готовые файлы + llms.txt из сборки |
| Публикация | Через админку, в один клик, задним числом | Через git и PR, с историей и откатом |
| Изменение «на лету» | Любое, из браузера | Только через сборку и деплой |
Последняя строка — единственная, где статика честно проигрывает, и именно она определяет область применения.
Info
Статический сайт — не аскеза, а перенос сложности туда, где ей место. Редактор не должен чинить упавший PHP: он получает PR и кнопку merge. Вся «живая» логика — заявки, статусы, платежи — живёт в CRM или приложении, а не на витрине.
Итог: когда статика подходит, а когда нет
Статика — правильный выбор для корпоративного сайта, блога, лендинга, документации, портфолио, страницы бренда: там, где контент читают, а не редактируют прямо на сайте. Она не подходит ровно в одном случае — когда пользователю нужны собственные данные и собственные права на этом же сайте: личный кабинет с балансом, корзина с оплатой, сервис с ролями и одобрениями, сложный CRUD-интерфейс. Там исполняемый код нужен, и он должен быть — но не там, где лежит публичная витрина.
Что с этим делать на практике:
- Разделяйте. Публичная часть — статика на CDN, а кабинет или магазин — отдельное приложение или поддомен, где безопасность проектируется осознанно.
- Не позволяйте сайту хранить то, что он не обязан хранить: заявки и контакты — в CRM, файлы — в хранилище, аналитика — в сервисе счётчиков.
- Ведите изменения через git и ревью, даже если редакторов много: агент пишет и собирает, человек решает, что выходит.
- Проверьте текущий сайт на лишний исполняемый код и незакрытые дыры — часто выясняется, что половина «необходимой динамики» не используется вовсе.
Мы собираем и ведём такие сайты сами и умеем переносить на статику существующие: от миграции контента и сборки шаблонов до форм с вебхуками в Битрикс24 и настройки AI-доступа к содержимому. Смотрите, как мы внедряем ИИ в процессы, — или начните со статьи о том, почему PHP опасен для бизнеса.