Аналитика: сайт не работает — с чего начать проверку

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

Как проверить, действительно ли сайт лежит

Откройте сайт с другого устройства или через мобильный интернет, отключив Wi-Fi. Если страница открывается — проблема локальная: не тот DNS-кэш, блокировка провайдера или расширение браузера. Полезно также заглянуть в консоль разработчика (F12, вкладка Network) — там видно, на каком запросе всё останавливается: DNS, соединение, SSL или загрузка контента.

Что анализировать в первую очередь

  • Код ответа сервера — 200 означает, что сайт работает, 4xx указывает на ошибку запроса, 5xx на сбой сервера.
  • Срок действия домена и его NS-записи — истёкший домен или неправильные серверы имён дают полную недоступность сайта.
  • SSL-сертификат — просроченный сертификат браузер помечает как небезопасное соединение и часто блокирует загрузку.
  • Логи хостинга — там видно превышение лимитов, аварийную остановку базы данных или ошибки PHP.

Разбор по типам сбоев

Если сайт открывается частично — грузится, но без стилей и картинок, — вероятная причина в неправильных путях к статике или в CDN, который перестал отдавать файлы. Белый экран без ошибок чаще всего означает падение самого приложения: стоит проверить логи PHP или Node на сервере. Ошибка подключения к базе данных обычно связана с превышением лимита соединений или неверными учётными данными в конфиге после переноса сайта.

Что делать после того, как причина найдена

Если проблема в домене — продлите регистрацию или исправьте NS-записи у регистратора и подождите обновления DNS. Если в хостинге — обратитесь в техподдержку с точным кодом ошибки и временем сбоя. Если в коде — откатите последнее изменение или разверните бэкап, а затем разбирайтесь с ошибкой уже в тестовой среде, а не на боевом сайте.

Аналитика проблемы всегда быстрее хаотичных попыток что-то поправить: сначала определите уровень сбоя, потом ищите конкретную причину внутри него.

Понравилась статья? Поделиться с друзьями: