Сайт отвечает 200 OK, но не работает. Почему?
Участники рынка отмечают, что сайт может возвращать 200 OK, но при этом быть неработоспособным. Это не ошибка мониторинга — это ошибка понимания, что значит «работает сайт».
200 OK, но интерфейс не грузится
Сайт отвечает на запрос, сервер жив, мониторинг зелёный — но пользователь видит белый экран. Код не запускается, потому что JavaScript не загрузился, не потому что сервер упал. Это не ошибка. Это иллюзия работоспособности.
Даже если Nginx возвращает 200, это не значит, что приложение работает. Оно может не загрузить файлы, получить их с неправильным типом, или попытаться загрузить несуществующий ресурс. И всё это — без единого 500-го кода.
Почему 200 OK — это не гарантия
HTTP 200 — это ответ на запрос. Не на задачу. Браузер запрашивает HTML, сервер отвечает 200, всё хорошо. Но если JavaScript не загрузился, интерфейс не появляется. Или если файл есть, но Nginx его не находит — в ответ приходит index.html, вместо кода. И 200 всё равно возвращается.
Мониторинг, который проверяет только HTTP-код, не видит разницы между работоспособным сайтом и мёртвым. Он видит только, что сервер отвечает. А пользователь видит, что ничего не работает.
Раньше проверяли сервер, теперь — пользователь
Раньше достаточно было убедиться, что сайт открывается. Теперь — нужно понимать, что открывается. Сайт больше не просто страница. Это приложение, которое должно выполнить свою задачу: показать товар, позволить купить, дать доступ к личному кабинету.
Раньше проверяли, работает ли сервер. Сейчас — проверяют, работает ли пользователь. Если он не может купить, не может войти, не видит карточку — сайт не работает, даже если 200 OK.
Кто в зоне риска — и как понять
Все, кто зависит от сайта как от канала продаж. Интернет-магазины, маркетплейсы, сервисы красоты с онлайн-записью, личные кабинеты клиентов. Если на сайте белый экран — уходит клиент. И это не фиксится в логах, потому что сервер жив.
Понять, что это про ваш бизнес, можно по тому, как вы проверяете работоспособность. Если вы смотрите только на HTTP-коды — вы не видите реальную ситуацию. Если после деплоя клиенты жалуются, что «сайт не работает» — это не сбой, это сигнал.
Как проверить, что сайт работает
Нужно проверять не сервер, а приложение. Не 200 OK, а результат. Первый уровень — доступность главной страницы. Второй — наличие ключевых ресурсов: JS, CSS, изображений. Третий — работоспособность: элементы отображаются, кнопки кликаются, форма отправляется.
Проверка должна имитировать пользователя. Не curl, а браузерный тест. Проверить, что элемент появился, что скрипт выполнился.
Что мы с этим делаем
Мы в Cetera работаем с 2002 года, более 1000 проектов. В каждом из них — проверка не только доступности, но и функциональности. Включаем в аудит и тесты, которые имитируют пользователя. Проверяем, что ресурсы загружаются с правильным типом, что JavaScript работает, что интерфейс отображается.
Если хотите понять, как это выглядит у вас — давайте обсудим вашу задачу.
Это часть нашей работы — Администрирование. Поддерживаем сайты всех типов на CMS и фреймворках: Cetera CMS, Laravel, Yii2, InSales, «1С-Битрикс», Bitrix24, WordPress, WooCommerce, Ecwid, OpenCart, Drupal, Joomla, Magento2, Shopify и самописные системы на PHP и Python. Инфраструктура, развитие и продвижение включены. Администрирование
Автор: Святослав Семенов из Cetera Labs