Сайт не открывается: что делать прямо сейчас
Утро. Вы открываете браузер, чтобы проверить сайт перед рабочим днём - и видите белый экран или ошибку. Или вам звонит клиент: «Ваш сайт не работает уже час». Первая реакция - паника. Вторая - звонок разработчику, который не берёт трубку. Знакомо? Ситуация «сайт не открывается что делать» - одна из самых стрессовых для владельца бизнеса без собственного сисадмина. Именно в первые 30 минут принятые решения определяют, восстановится ли сайт за час или будет лежать сутки.
Прежде чем звонить и писать всем подряд, важно понять несколько базовых вещей. Аптайм - это процент времени, в течение которого сайт доступен пользователям (например, 99,9% означает не более 8,7 часов простоя в год). Инцидент - это незапланированное событие, которое нарушает нормальную работу сервиса. Эскалация - это передача проблемы на более высокий уровень ответственности, когда первичный исполнитель не может её решить самостоятельно.
Эта статья даст вам конкретный алгоритм на первые 30 минут аварии:
- Как за 2 минуты проверить - сайт упал у всех или только у вас
- Что означают ошибки 500, 502, 503, 504 и кому их передавать
- Матрица ответственности: хостинг, разработчик или контент-менеджер
- Готовый шаблон письма в техподдержку хостинга - скопируйте и отправьте
Первичная диагностика: как убедиться, что сайт действительно упал
Не торопитесь звонить хостинг-провайдеру, пока не убедитесь в масштабе проблемы. Иногда сайт не открывается только у вас - из-за кеша браузера, настроек DNS на вашем компьютере или блокировки со стороны провайдера.
Шаг 1. Откройте сервис downforeveryoneorjustme.com или isitdownrightnow.com, введите адрес сайта и нажмите проверку. Если сервис показывает «It’s not just you!» - сайт недоступен для всех. Если «It’s just you» - проблема на вашей стороне. Если сайт упал глобально, переходите к следующим шагам немедленно.
Шаг 2. Проверьте сайт со смартфона через мобильный интернет (не Wi-Fi). Это исключает проблему с вашей локальной сетью или кешем устройства. Если через мобильный сеть сайт тоже не открывается - подтверждается глобальный сбой.
Шаг 3. Попросите коллегу или знакомого в другом городе открыть сайт. Так вы исключаете региональные сбои DNS и убеждаетесь, что проблема не локальная.
Шаг 4. Зафиксируйте точное время обнаружения сбоя. Это важно для отчёта хостингу и для понимания, сколько времени простоя downtime уже накопилось.
Коды ошибок HTTP: что значат 500, 502, 503, 504
Когда сайт не открывается, браузер или сервер почти всегда показывает код ошибки. Правильно расшифровать его - значит сэкономить минимум 15 минут и сразу обратиться к нужному специалисту.
| Код ошибки HTTP | Причина | Первое действие |
|---|---|---|
| 500 Internal Server Error | Ошибка внутри сервера или приложения. Часто - сбой PHP-скрипта, некорректный .htaccess, кончившаяся память | Проверьте логи сервера (error_log). Свяжитесь с разработчиком или хостингом |
| 502 Bad Gateway | Сервер-посредник (nginx, CDN) получил некорректный ответ от основного сервера. Часто - упал PHP-FPM или backend-сервис | Свяжитесь с хостингом. Если есть доступ - перезапустите PHP-FPM |
| 503 Service Unavailable | Сервер временно не может обработать запросы: перегрузка, техработы, режим обслуживания | Проверьте панель управления хостинга на предмет технических работ. Дождитесь 5-10 минут |
| 504 Gateway Timeout | Сервер-посредник не дождался ответа от основного сервера за отведённое время | Симптом перегрузки или зависания backend. Сообщите хостингу с указанием кода |
| DNS_PROBE_FINISHED_NXDOMAIN | Домен не резолвится. Истёк срок домена, неверные DNS-записи, проблема у регистратора | Проверьте срок действия домена в панели регистратора. Убедитесь, что NS-записи корректны |
| ERR_SSL_PROTOCOL_ERROR | Проблема с SSL-сертификатом: истёк, не обновился автоматически, конфликт настроек | Проверьте дату истечения сертификата в панели хостинга. Перевыпустите или обновите |
Пошаговый план действий в первые 30 минут
Ниже - чёткий алгоритм аварийной поддержки сайта. Каждый шаг самодостаточен: в нём указано действие, ожидаемый результат и что делать дальше.
- Минута 1-2: Подтвердите факт сбоя. Используйте downforeveryoneorjustme.com и проверку с мобильного. Результат: вы знаете, глобальный это сбой или локальный. Если локальный - очистите кеш DNS командой
ipconfig /flushdns(Windows) илиsudo dscacheutil -flushcache(Mac) и перепроверьте. - Минута 3-5: Зафиксируйте симптомы. Сделайте скриншот ошибки с кодом, запишите время начала сбоя и с каких устройств/сетей сайт недоступен. Это ускорит диагностику хостингом в 2-3 раза.
- Минута 5-8: Проверьте панель управления хостингом. Войдите в личный кабинет хостинг-провайдера. Проверьте: статус серверов на странице статуса провайдера, баланс аккаунта (сайт мог отключиться из-за неоплаты), активность технических работ. Если хостинг сообщает о плановых работах - вы уже знаете причину и примерное время восстановления.
- Минута 8-12: Проверьте домен и SSL. Войдите в панель регистратора домена (REG.RU, Namecheap, GoDaddy и т.д.). Убедитесь, что домен не истёк и DNS-записи указывают на правильный IP-адрес. Проверьте срок SSL-сертификата на сайте ssllabs.com или в панели хостинга. Истёкший домен или SSL-сертификат - одна из самых частых причин, по которой сайт недоступен для посетителей.
- Минута 12-18: Свяжитесь с хостингом. Напишите или позвоните в техподдержку хостинга с конкретными данными: кодом ошибки, временем начала сбоя, подтверждением глобальности. Используйте шаблон ниже.
- Минута 18-22: Оцените, нужен ли разработчик. Если хостинг подтверждает, что с их стороны всё в порядке - проблема в коде сайта или настройках CMS. Свяжитесь с разработчиком или веб-студией.
- Минута 22-28: Уведомите ключевых клиентов и команду. Если сайт - это основной канал продаж или лидогенерации, сообщите об инциденте менеджерам, которые общаются с клиентами вживую. Разместите уведомление в социальных сетях.
- Минута 28-30: Определите необходимость восстановления из бэкапа. Если хостинг и разработчик не дают быстрого решения, а сайт недоступен уже более 20 минут - инициируйте восстановление из резервной копии. Время простоя downtime растёт с каждой минутой.
Матрица ответственности: кто виноват при каждом типе сбоя
Главная точка конфликта при инцидентах - «кто должен это чинить». Хостинг говорит «проблема в коде», разработчик говорит «проблема на сервере», а сайт продолжает лежать. Эта матрица поможет сразу определить правильного исполнителя.
| Тип сбоя | Ответственный | Что требовать |
|---|---|---|
| Сервер недоступен, ошибка 503/504, проблемы с оборудованием | Хостинг-провайдер | SLA, компенсацию времени простоя, отчёт о причинах |
| Ошибка 500, белый экран после обновления CMS или плагина | Разработчик / веб-студия | Откат обновления, исправление кода, отчёт о причинах |
| Истёк домен или неверные DNS-записи | Владелец аккаунта у регистратора (часто - сам клиент или агентство) | Продление домена, восстановление DNS-записей |
| Истёк SSL-сертификат | Хостинг или разработчик (в зависимости от того, кто настраивал) | Перевыпуск и установку сертификата |
| Сайт упал после публикации нового контента или правок в CMS | Контент-менеджер + разработчик | Откат к предыдущей версии, анализ изменений |
| DDoS-атака, взлом сайта | Хостинг + разработчик совместно | Активацию защиты, смену паролей, аудит безопасности |
| Закончились деньги на аккаунте хостинга или домена | Владелец бизнеса / бухгалтерия | Немедленную оплату и настройку автоплатежа |
Кому передавать проблему: хостинг, разработчик или администратор
Когда сайт не работает, важно не просто позвонить «кому-нибудь», а обратиться к правильному исполнителю с конкретной информацией. Это сокращает время восстановления.
Техподдержка хостинга - первый звонок в 70% случаев. Они имеют доступ к серверным логам, могут перезапустить сервисы и видят статус всей инфраструктуры. Обращайтесь к ним при кодах ошибок 502, 503, 504, при проблемах с SSL, при подозрении на аппаратный сбой.
Разработчик или веб-студия - при ошибке 500 после обновлений, при белом экране без изменений на сервере, при проблемах с кодом или базой данных сайта. Важно: у разработчика должны быть FTP/SSH-доступ и доступ к базе данных - без этого он не сможет помочь удалённо.
Регистратор домена - при ошибках DNS_PROBE_FINISHED_NXDOMAIN, при подозрении на истечение домена или неверные DNS-настройки. Для ускорения получите заранее логин и пароль от аккаунта регистратора.
Готовый шаблон сообщения в техподдержку хостинга
Большинство руководств описывают, что нужно сообщить хостингу - но не дают конкретного текста. Вот готовый шаблон, который можно скопировать и отправить прямо сейчас. Пометка «КРИТИЧНО» в теме письма реально увеличивает приоритет обращения у большинства провайдеров.
Тема письма: КРИТИЧНО - Сайт полностью недоступен, аварийная поддержка сайта
Текст:
Здравствуйте.
Сайт [адрес сайта] полностью недоступен для всех посетителей.
- Время обнаружения сбоя: [дата и время]
- Код ошибки: [502 / 503 / 504 / другой]
- Проверено через: downforeveryoneorjustme.com - сайт недоступен глобально
- Проверено с устройств: компьютер (браузер Chrome), смартфон (мобильный интернет)
- Последние изменения на сайте: [не было изменений / обновили плагин X / опубликовали материал]
- Баланс аккаунта: проверен, средства есть
Прошу провести диагностику и сообщить о причинах и сроках восстановления в течение 30 минут.
[Ваше имя, номер договора или логин аккаунта]
Как уведомить клиентов о недоступности сайта
Если сайт лежит более 15-20 минут и является основным каналом продаж - молчание хуже, чем честное сообщение. Клиенты, которые видят недоступный сайт и не получают объяснений, теряют доверие быстрее, чем за время самой аварии.
Социальные сети. Опубликуйте короткое сообщение: «Мы знаем о проблеме с сайтом и уже работаем над её решением. Для связи используйте [телефон/мессенджер]. Ориентировочное время восстановления - [время]». Не нужно технических подробностей - нужна уверенность и альтернативный контакт.
Email-рассылка - если у вас есть активная база подписчиков или ожидаются транзакционные письма. Отправьте короткое уведомление с альтернативным способом связи.
Мессенджеры и чаты. Сообщите менеджерам по продажам - они должны знать о сбое, чтобы не отправлять клиентов «посмотрите на сайте».
Google Мой бизнес / Яндекс Бизнес. Если сбой затяжной (более 2 часов), можно временно обновить описание с указанием альтернативного контакта.
Восстановление из резервной копии
Резервная копия (бэкап) - это сохранённая копия файлов сайта и базы данных на определённый момент времени, которую можно использовать для восстановления после сбоя или взлома.
Если хостинг и разработчик не могут быстро восстановить работу сайта, а причина - сбой в коде или базе данных - самый быстрый путь это восстановление из бэкапа. Вот как это работает:
- Найдите актуальный бэкап. В панели управления большинства хостингов (cPanel, ISPmanager, Plesk) есть раздел «Резервные копии» или «Backup». Убедитесь, что последний бэкап создан до момента сбоя.
- Определите, что восстанавливать. Чаще всего достаточно восстановить базу данных - она содержит весь контент сайта. Файлы восстанавливайте только если проблема в них (например, после взлома).
- Инициируйте восстановление. В панели хостинга выберите нужную дату бэкапа и нажмите «Восстановить». Или попросите техподдержку хостинга сделать это за вас - многие провайдеры делают это бесплатно по запросу.
- Проверьте работу сайта после восстановления. Зайдите на главную, проверьте форму заказа, убедитесь, что последние публикации на месте.
Важно: если у вас нет бэкапов или последний бэкап недельной давности - это критическая уязвимость. Нормальная частота бэкапов для активного сайта - ежедневно для базы данных, еженедельно для файлов.
Как предотвратить повторный сбой: мониторинг и бэкапы
Аварийная поддержка сайта - это хорошо, но куда лучше узнавать о сбое раньше клиентов и автоматически. Мониторинг доступности - это автоматическая проверка сайта с заданной частотой с уведомлением по SMS или email при недоступности.
Базовые инструменты мониторинга доступности, которые позволят вам узнавать о проблеме первым:
- UptimeRobot - бесплатный план позволяет мониторить до 50 сайтов с проверкой каждые 5 минут и уведомлениями на email и в Telegram
- Better Uptime - есть бесплатный тариф, уведомления в Slack и звонок на телефон при падении
- Яндекс Вебмастер - бесплатно, уведомляет о проблемах с доступностью через личный кабинет
- Pingdom - платный, но даёт подробную статистику аптайма и географию проверок
Что ещё снизит риск длительного простоя downtime:
- Настроить автоматические ежедневные бэкапы с хранением минимум 7 последних копий
- Хранить бэкапы не только на том же сервере, но и на внешнем хранилище (Google Drive, S3, Яндекс Диск)
- Иметь актуальный контакт техподдержки хостинга и разработчика в телефоне - не только email
- Проверять срок действия домена и SSL-сертификата хотя бы раз в квартал
- Настроить уведомления об оплате хостинга за 30, 14 и 7 дней до истечения
По данным исследований, 60% малых бизнесов узнают о падении сайта от клиентов, а не от системы мониторинга. При среднем трафике 500 посетителей в сутки и конверсии 2%, каждый час простоя - это около 0,5-1 потенциальных заявки. За один рабочий день без сайта можно потерять 5-10 лидов.
Часто задаваемые вопросы
Как понять - проблема на моей стороне или на стороне сервера?
Откройте downforeveryoneorjustme.com и введите адрес вашего сайта. Если сервис говорит «It’s not just you» - сайт упал глобально и проблема на сервере. Если «It’s just you» - очистите кеш браузера (Ctrl+Shift+Del), сбросьте DNS-кеш командой ipconfig /flushdns (Windows) или sudo dscacheutil -flushcache (Mac), попробуйте открыть сайт с другого устройства или через мобильный интернет.
Сайт не открывается, а хостинг не отвечает?
Если техподдержка хостинга не отвечает более 30 минут по приоритетному каналу - попробуйте другие каналы: чат на сайте хостинга (обычно работает быстрее email), телефонную линию, Telegram-бот поддержки если есть. Параллельно проверьте статусную страницу провайдера (обычно status.[имя хостинга].ru) - там могут быть уведомления о работах. Если сайт критически важен и хостинг молчит более часа - начните процедуру переноса к резервному провайдеру или задействуйте эскалацию: напишите руководству хостинга через корпоративный email или соцсети.
Что означает ошибка 502 Bad Gateway и как её исправить?
Ошибка 502 Bad Gateway означает, что сервер-посредник (например, nginx или CDN) получил некорректный ответ от основного сервера приложения. Чаще всего причина - упавший PHP-FPM, перегруженный backend или зависший процесс. Самостоятельно: подождите 2-3 минуты (иногда процесс перезапускается автоматически) и обновите страницу. Если ошибка сохраняется - обращайтесь в техподдержку хостинга с указанием кода 502, времени начала и адреса сайта. Разработчик нужен, если хостинг подтвердит, что сервер работает нормально - тогда проблема в коде приложения.
Почему сайт открывается у меня, но недоступен для других посетителей?
Возможные причины: у вас закешированная версия сайта в браузере (очистите кеш); ваш провайдер или корпоративная сеть резолвит домен на старый IP-адрес из-за медленного обновления DNS (занимает до 48 часов после смены); сайт заблокирован для определённых регионов или IP-диапазонов. Для проверки используйте VPN или попросите кого-то из другого города/провайдера открыть сайт. Инструмент ping.eu/tracert также покажет, на каком узле теряется соединение.
Как быстро уведомить клиентов, когда сайт лежит?
Приоритет каналов зависит от вашего бизнеса. Для B2C с активными соцсетями - пост во ВКонтакте или Telegram-канал сразу, как только подтвердили сбой. Для B2B - звонок или сообщение в мессенджере ключевым клиентам, которые могли обращаться к сайту прямо сейчас. Для интернет-магазина - уведомление менеджеров по телефонным продажам и поста в соцсетях с альтернативным контактом. Главное правило - сообщите честно: «Знаем о проблеме, работаем, свяжитесь с нами по [контакт]». Клиенты прощают технические сбои, но не прощают игнорирование.
Что делать если сайт не работает после обновления плагина или темы?
Это типичный сбой, ответственный за который - разработчик или тот, кто производил обновление. Первый шаг - попробуйте войти в административную панель CMS (например, /wp-admin для WordPress). Если вход возможен - деактивируйте последний обновлённый плагин через раздел плагинов. Если белый экран не позволяет войти в админку - нужен доступ по FTP или SSH для отключения плагина вручную через файловый менеджер. Это работа для разработчика. Именно поэтому перед любым обновлением плагинов обязательно нужно делать бэкап.
Что делать если сайт не открывается: итог
Сайт не открывается - это всегда стресс, но с правильным алгоритмом первые 30 минут аварийной поддержки сайта превращаются в управляемый процесс, а не хаотичные звонки. Главные принципы: сначала диагностика - потом звонки, обращайтесь к правильному исполнителю с конкретными данными (код ошибки, время, масштаб), не молчите перед клиентами при затяжном сбое.
Самый надёжный способ сократить время простоя downtime - не иметь его вовсе. Мониторинг доступности, ежедневные бэкапы и прописанный план эскалации инцидентов превращают аварию из катастрофы в рутинный инцидент.
Если вы хотите защитить свой сайт системно - команда Digitalriff.ru проведёт технический аудит: проверим состояние сервера, бэкапы, мониторинг доступности и готовность к аварии. Узнайте слабые места своего сайта до того, как это сделает сбой - оставьте заявку на сайте digitalriff.ru.
Савенков Александр
Автор статьи




