Если сайт недоступен, сначала определите, что именно видит посетитель: пустую страницу, код ошибки, предупреждение браузера или сообщение «на сайте возникли технические неполадки». От этого зависит, кому звонить: хостинг-провайдеру, регистратору домена или разработчику. Ниже чек-лист из восьми шагов, который владелец сайта может пройти за 15-20 минут без технических знаний, и подсказка, что говорить каждому специалисту.
На проектах B2BPRO.KZ мы чаще всего видим один и тот же сценарий: сайт перестает открываться вечером или в выходной, владелец звонит сразу разработчику, а причина оказывается в просроченном домене или сертификате. Час уходит на разбирательство, хотя ответ можно было получить за пять минут. Поэтому начинаем не со звонков, а с быстрой диагностики.
Как понять, что сайт действительно недоступен для всех?
Сначала проверьте, что проблема не только у вас: откройте сайт с телефона через мобильный интернет и попросите коллегу из другого места открыть его на своем устройстве. Если сайт открывается у других, причина в вашем интернете, кеше браузера или блокировке со стороны провайдера. Если не открывается ни у кого, переходим к чек-листу.
Зафиксируйте три вещи, пока проблема свежая: точное время, что именно показывает страница и сделайте скриншот. Эти данные сэкономят специалисту полчаса. Фраза «сайт не работает» ничего не говорит, а «в 19:40 открывается белая страница, на телефоне то же самое» сразу сужает поиск.
Что означает сообщение или код ошибки на странице?
Сообщение на странице почти всегда подсказывает, на каком уровне сломалось: у сервера, у связки сервера с сайтом или у самого сайта. Расшифровка самых частых вариантов:
| Что видите | Что это обычно значит | К кому обращаться в первую очередь |
|---|---|---|
| Ошибка 500 | Внутренняя ошибка сервера, которую не удалось обработать точнее | Разработчик или хостинг |
| Ошибка 502 | Шлюз или прокси получил некорректный ответ от вышестоящего сервера | Хостинг |
| Ошибка 503 | Сервер временно недоступен: обслуживание или перегрузка | Хостинг |
| Белая пустая страница | Часто фатальная ошибка в коде сайта, плагина или темы | Разработчик |
| Сообщение «на сайте возникли технические неполадки» | WordPress сам поймал фатальную ошибку и показал безопасный экран | Разработчик, проверьте письмо на почте администратора |
| Предупреждение браузера о безопасности соединения | Проблема с SSL-сертификатом, например истекший срок | Хостинг или тот, кто выпускал сертификат |
| Сайт не найден, сервер не отвечает | Проблема с доменом или DNS | Регистратор домена |
Определения кодов 500, 502 и 503 соответствуют описанию кода 503 на MDN: он означает временную недоступность сервера, чаще всего из-за обслуживания или перегрузки. Такой код отдают специально, чтобы показать, что сервис вернется позже.
Шаг 1. Проверьте домен: не истек ли срок регистрации?
Домен, у которого закончился срок регистрации, перестает открываться, и это самая обидная причина, потому что ее легко предотвратить. Зайдите в личный кабинет у регистратора, где вы покупали домен, и посмотрите дату окончания. Если срок истек, продлите домен и подождите: возобновление работы может занять от нескольких минут до нескольких часов.
Если не помните, где регистрировали домен, поищите в почте письма от регистратора со словами «домен», «продление» или «регистрация». Часто домен когда-то оформлял сотрудник или подрядчик, и доступ остался у него. Эту информацию стоит найти заранее, а не во время аварии: запишите регистратора, логин и дату окончания в общую таблицу компании.
Шаг 2. Проверьте оплату хостинга
Хостинг, за который вовремя не заплатили, отключают, и сайт перестает открываться. Зайдите в кабинет хостинг-провайдера и проверьте статус услуги, баланс и письма о задолженности. Часто уведомления уходят на почту, которую давно никто не читает.
Если услуга приостановлена, достаточно оплатить и написать в поддержку хостинга с просьбой включить аккаунт. Если с оплатой все в порядке, откройте раздел уведомлений и статус сервера: некоторые провайдеры показывают плановые работы и аварии прямо в кабинете.
Отдельно проверьте, на чье имя оформлен аккаунт хостинга и какая почта к нему привязана. Часто уведомления о задолженности приходят на адрес бывшего сотрудника или подрядчика, и о проблеме никто не узнает до момента отключения. Привяжите к аккаунту общий корпоративный адрес и убедитесь, что письма оттуда не попадают в спам. Это занимает пять минут и закрывает целый класс аварий.
Шаг 3. Проверьте SSL-сертификат
Если браузер пугает красной страницей о небезопасном соединении, скорее всего, истек срок SSL-сертификата. Нажмите на значок замка или предупреждения рядом с адресом и посмотрите срок действия сертификата. Бесплатные сертификаты обычно продлеваются автоматически, но продление иногда ломается после переноса сайта или смены настроек сервера.
Пока сертификат просрочен, посетители видят предупреждение и многие уходят. Для срочной проверки хватит одного вопроса хостингу: «Продлен ли SSL-сертификат для домена и почему не сработало автоматическое продление?»
Шаг 4. Проверьте, не показывает ли сайт страницу восстановления WordPress
Если на странице написано, что на сайте возникли технические неполадки, проверьте почту администратора: WordPress мог отправить письмо с ссылкой на режим восстановления. Согласно описанию режима восстановления в WordPress 5.2, при фатальной ошибке письмо приходит на адрес администратора и содержит секретную ссылку. Перейдя по ней и войдя в админку, вы увидите список приостановленных плагинов и тем с описанием ошибок.
Важная деталь: в режиме восстановления проблемные расширения отключены только для вашего браузера, а для остальных посетителей сайт остается сломанным, пока ошибка не исправлена. Вы можете деактивировать проблемный плагин, что обычно считается временным решением, или передать текст ошибки разработчику. Не нужно удалять плагины наугад: сначала запишите, какой из них назван в ошибке.
Шаг 5. Вспомните, что меняли перед сбоем
Чаще всего сайт ломается после какого-то изменения, поэтому вспомните последние действия за 24-48 часов. Спросите коллег и подрядчиков: обновляли ли плагины или тему, устанавливали ли новый плагин, меняли ли хостинг, тариф или версию PHP, правили ли код сайта.
Ответ на этот вопрос часто сразу дает причину. Если обновили плагин, проблема, вероятно, в нем. Если переносили сайт, смотрите настройки домена и сертификата. Подробные рекомендации по безопасному обновлению мы разбирали в статье про обновление WordPress и что проверить после него, а по переносу есть материал про перенос сайта на другой хостинг без простоя.
Шаг 6. Проверьте, не взломан ли сайт
Если вместо вашего сайта открывается чужая страница, реклама, перенаправление на подозрительный адрес или хостинг написал о вредоносном коде, сайт мог быть взломан. В таком случае не нужно самостоятельно менять файлы: это может стереть следы и усложнить лечение. Сообщите хостингу и разработчику, смените пароли администратора, хостинга и почты.
Базовые меры защиты, которые стоит принять до аварии, перечислены в нашем материале про защиту сайта на WordPress от взлома. После лечения проверьте, что резервная копия существует и открывается, иначе следующая авария будет такой же долгой.
Шаг 7. Соберите информацию и позвоните нужному специалисту
Прежде чем звонить, подготовьте короткую справку: когда началось, что видит посетитель, что меняли перед сбоем и что уже проверено. Такая справка занимает минуту и превращает разговор из хаоса в понятную задачу. Фраза «ничего не меняли» чаще всего неверна, поэтому проверьте это у коллег, прежде чем ее произносить.
Кому звонить зависит от симптома:
- Хостинг-провайдеру: ошибки 502 и 503, недоступность сервера, приостановка услуги, проблемы с SSL.
- Регистратору домена: истекший срок домена, проблемы с DNS, смена серверов имен.
- Разработчику сайта: белая страница, ошибка 500, сообщение о технических неполадках, ошибки после обновления.
- Специалисту по безопасности или разработчику вместе с хостингом: взлом, вредоносный код, нежелательные перенаправления.
Если у вас нет постоянного разработчика, подрядчик по разработке и поддержке сайтов может взять на себя диагностику и восстановление. Лучше заключить такое соглашение заранее, чем искать исполнителя в момент аварии.
Как разработчик ищет причину и о чем его просить?
Разработчик начинает с журнала ошибок, поэтому полезно знать, как это устроено. В WordPress для поиска причины включают отладку: в файле настроек добавляют константы WP_DEBUG и WP_DEBUG_LOG, и ошибки записываются в файл debug.log в каталоге wp-content. Об этом написано в документации WordPress по отладке. Там же есть важное предупреждение: на рабочих сайтах отладочные инструменты использовать не рекомендуется, предпочтительнее копия сайта для тестирования.
Для владельца отсюда следуют практические выводы. Попросите разработчика сначала сделать резервную копию, потом искать причину на копии или с отключенным показом ошибок посетителям. И не соглашайтесь на правки «вслепую» прямо на рабочем сайте без бэкапа: если исправление не сработает, откатиться будет не к чему.
Чего не стоит делать в первые минуты аварии?
В панике владельцы чаще всего совершают одни и те же действия, которые усложняют восстановление. Пять из них стоит запомнить заранее.
- Менять сразу несколько вещей. Если вы одновременно поменяли пароль, отключили плагины и перезагрузили сервер, потом невозможно понять, что помогло. Меняйте по одному и записывайте.
- Удалять файлы и плагины наугад. Удаленное можно не вернуть, а лишние потери данных превращают аварию на час в проблему на неделю.
- Переустанавливать сайт с нуля. Новая установка стирает настройки и контент, которые можно было сохранить.
- Платить за «срочное восстановление» первому встречному. Подрядчик из объявления получает доступ ко всему сайту. Передавайте доступы только проверенным исполнителям.
- Молчать с клиентами. Если сайт недоступен долго, клиентам нужен другой способ связаться с вами.
Вторая группа ошибок связана с доступами. Не отправляйте пароли в открытых чатах и не оставляйте их в письмах. Лучше создать отдельного пользователя для специалиста и отозвать его после работы. Это занимает пару минут и защищает сайт.
Как сообщить клиентам, что сайт временно недоступен?
Если сбой продолжается больше часа, расскажите об этом клиентам через другие каналы, чтобы они не решили, что вы закрылись. Сайт может быть недоступен, но у компании остаются телефон, мессенджеры, социальные сети и почта.
Короткое сообщение в социальных сетях или статусе мессенджера работает лучше длинных объяснений. В нем достаточно трех пунктов: сайт временно недоступен, заказы и заявки принимаются по такому-то телефону или в такой-то переписке, ожидаемое время восстановления сообщим дополнительно. Не нужно обещать срок, пока он неизвестен: обманутое ожидание раздражает сильнее, чем честное «выясняем».
Если вы запускаете рекламу, проверьте, куда она ведет. Объявления на недоступную страницу тратят бюджет без результата, поэтому на время аварии их стоит приостановить или перенаправить на рабочий канал, например на мессенджер. После восстановления проверьте, что формы заявок и аналитика снова работают, иначе вы еще несколько дней будете терять обращения незаметно.
Как оценить ущерб от простоя и решить, нужно ли что-то менять?
Ущерб от простоя считается просто: сколько заявок и денег сайт приносит в среднем за час, умножьте на длительность аварии. Возьмите среднее число заявок в день из CRM или аналитики, поделите на рабочие часы и получите ориентир. Для компаний, у которых сайт главный канал, цифра быстро убеждает вложиться в мониторинг и резервное копирование.
Кроме прямых потерь, считайте косвенные: потраченный рекламный бюджет, упущенные звонки, влияние на позиции в поиске при долгой недоступности и время сотрудников на разбирательства. Вы можете не знать точных чисел, но даже грубая оценка помогает объяснить, почему поддержка сайта по регулярному договору дешевле, чем разовые срочные вызовы.
После аварии проведите короткий разбор по трем вопросам: что сломалось, почему мы узнали об этом так поздно и что изменить, чтобы не повторилось. Результат запишите на одну страницу. Через полгода такие записи показывают, какие проблемы повторяются, и позволяют целенаправленно улучшать процесс, а не тушить пожары.
Что включить в регламент на случай аварии сайта?
Регламент аварии помещается на одну страницу и состоит из ответов на пять вопросов: кто узнает о сбое первым, кто принимает решение, кому звонить по каждому симптому, как информировать клиентов и кто проверяет результат после восстановления.
Запишите конкретные имена и телефоны, а не должности. Укажите, кто имеет право отдавать срочные распоряжения подрядчикам и тратить деньги на экстренное восстановление, чтобы в субботу вечером не искать руководителя. Добавьте ссылку на карточку сайта с доступами. И раз в год проверяйте, что регламент не устарел: сотрудники уходят, подрядчики меняются, а в документе остаются прежние контакты.
Как не допустить повторения?
После устранения аварии потратьте полчаса на меры, которые защитят от повторения. Они недорогие, а ценность каждой понятна после первой потерянной ночи.
- Включите мониторинг доступности, чтобы узнавать о сбое раньше клиентов. Как это сделать для небольшой компании, мы описывали в статье про мониторинг доступности сайта.
- Запишите сроки: дата окончания домена, хостинга и сертификата, ответственный за продление.
- Направьте уведомления на живую почту, которую читают, а не на адрес уволившегося сотрудника.
- Проверьте резервные копии: где хранятся, как часто делаются, пробовали ли их восстанавливать.
- Составьте карточку сайта: регистратор, хостинг, разработчик, доступы, телефоны поддержки. Хранить ее нужно в общем месте, доступном руководителю.
- Договоритесь о порядке обновлений: кто и когда обновляет плагины, и как делается проверка после этого.
Карточка сайта и список сроков кажутся формальностью, пока сайт работает. Зато в день аварии они дают возможность действовать за минуты вместо часов, и это прямо влияет на заявки: пока сайт недоступен, реклама продолжает тратить бюджет, а клиенты уходят к конкурентам.
Пример: как выглядит разбор аварии
Для наглядности возьмем вымышленную компанию из Алматы, у которой сайт перестал открываться в субботу вечером. Это иллюстрация, а не данные реального клиента.
| Время | Действие | Результат |
|---|---|---|
| 19:40 | Владелец открыл сайт с телефона через мобильный интернет | Не открывается, значит проблема не локальная |
| 19:45 | Проверил срок домена в кабинете регистратора | Домен действует, причина не здесь |
| 19:50 | Проверил почту администратора | Пришло письмо от WordPress о фатальной ошибке в плагине |
| 20:00 | Написал разработчику с текстом ошибки и временем сбоя | Плагин деактивирован, сайт открылся |
Весь разбор занял 20 минут, потому что владелец шел по шагам, а не звонил всем подряд. Разработчику не пришлось выяснять, что случилось: текст ошибки и время уже были у него.
Частые вопросы
Что делать в первую очередь, если сайт не открывается?
Сначала проверьте, что сайт не открывается у других: откройте его с телефона через мобильный интернет и попросите коллегу проверить. Затем зафиксируйте время, скриншот и текст ошибки. После этого проверьте срок домена, оплату хостинга и SSL-сертификат, и только потом звоните специалисту.
Почему сайт мог перестать открываться ночью или в выходные?
Чаще всего причина в истекшем сроке домена, хостинга или сертификата, в автоматическом обновлении плагина или в перегрузке сервера. Эти события не привязаны к рабочему времени. Поэтому полезен мониторинг, который присылает уведомление сразу, а не утром от клиента.
Что означает ошибка 503 на сайте?
Ошибка 503 означает, что сервер временно не может обработать запрос: он на обслуживании или перегружен. Код специально сообщает, что недоступность временная. Если ошибка держится дольше нескольких минут, обратитесь в поддержку хостинга.
Можно ли самому отключить плагин, если сайт сломался?
Можно, если вы получили доступ в админку, например через ссылку режима восстановления WordPress из письма. Но сначала запишите название плагина и текст ошибки, а лучше сделайте резервную копию. Удалять плагины наугад не стоит, чтобы не потерять данные и настройки.
Кому звонить, если не знаешь, в чем причина?
Если по симптомам не получается понять, начните с хостинг-провайдера: у него есть доступ к состоянию сервера и логам. Он подскажет, проблема на стороне сервера или в коде сайта. Если проблема в коде, подключайте разработчика и передайте ему всю собранную информацию.