Сайт не открывается, что ответить клиенту, чтобы он не начал паниковать и звонить каждые пять минут, я слышу регулярно, только с другой стороны: мне звонят и спрашивают именно это. За несколько лет поддержки сайтов на Tilda, WordPress и кастомных сервисах я собрал рабочий порядок действий: что проверить в первую очередь, что написать заказчику, пока идёт диагностика, и как не наврать со сроками. Ниже готовые формулировки и последовательность шагов, которые использую сам.
Сначала проверьте, у кого именно не открывается сайт
Прежде чем писать клиенту, убедитесь, что проблема не локальная. Открываю сайт с мобильного интернета, а не с рабочего вайфая, проверяю через сервис вроде downforeveryoneorjustme, при возможности дёргаю сайт командой curl -I https://example.ru с сервера. Если сайт отвечает 200, а у клиента белый экран, дело может быть в его провайдере, DNS-кэше браузера или блокировке на уровне регионального оператора. Отдельно смотрю на устройство: часто «не открывается» на деле означает «не грузится один скрипт» и сайт частично работает.
Если самостоятельно доступа к хостингу и логам нет, а клиент уже написал, что всё лежит, честнее сразу взять паузу на диагностику, чем гадать в переписке. Здесь удобно держать под рукой готовые формулировки, ниже я их привожу.
Что ответить клиенту, если сайт не открывается: 5 готовых шаблонов
Под каждую типичную ситуацию у меня заготовлен свой текст. Меняю детали под конкретный случай, но структура рабочая.
Только узнали о проблеме, причина не ясна: «Видим, что сайт недоступен, уже занимаемся диагностикой. Проверяем хостинг, домен и SSL-сертификат. Напишем с результатом и сроком в течение 30 минут».
Причина известна, чинит хостинг: «Сайт лежит из-за сбоя на стороне хостинг-провайдера, уже открыли тикет в поддержку. По их регламенту восстановление занимает до 2 часов, следим за статусом и держим вас в курсе».
Похоже на DDoS-атаку: «Фиксируем аномальный всплеск запросов к серверу, это похоже на атаку. Включаем дополнительную защиту на уровне хостинга и CDN, сайт может открываться нестабильно ещё какое-то время».
Истёк домен или SSL: «Причина найдена: сертификат безопасности сайта истёк вчера ночью, продлеваем его прямо сейчас. Обычно новый сертификат применяется за 15-30 минут после выпуска».
Сайт упал после правки клиента (например, в кастомном коде на Tilda): «Проблема появилась сразу после последнего изменения в коде страницы. Откатываем правку и проверяем сайт, дальше разберём, что пошло не так, чтобы не повторилось».
Главное правило во всех пяти случаях одно: не пишите «уже почти всё» или «через пять минут», если сами ещё не смотрели логи. Заказчик простит час простоя, но не простит третий перенос срока подряд.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Порядок действий: что делать в первые 15 минут
- Проверяю статус сайта с чужого канала связи (мобильный интернет, другой браузер, инкогнито) и через внешний чекер доступности.
- Захожу в панель хостинга: там обычно сразу видно, лежит ли сервер целиком или упал конкретный сайт из-за превышения лимитов.
- Смотрю дату окончания домена и статус DNS-записей, особенно если недавно что-то меняли у регистратора.
- Проверяю срок действия SSL-сертификата, особенно если стоит бесплатный Let’s Encrypt с автопродлением раз в 90 дней и оно могло не сработать.
- Открываю логи ошибок сервера и, если это WordPress, смотрю на дату последнего обновления плагинов, тем и ядра.
- Если правки вносили сегодня сами (скрипт в Tilda, деплой на WordPress, обновление n8n-сценария), откатываю последнее изменение и проверяю сайт заново.
- Пишу клиенту предварительный статус даже без финального решения, чтобы он не додумывал сам.
По опыту, в 6 случаях из 10 причина находится на первых трёх шагах: хостинг, домен, SSL. Остальное чаще связано с обновлением плагина WordPress, конфликтом кастомного скрипта или заражением сайта вирусом.
Типичные причины, почему сайт недоступен
| Причина | Как быстро проверить | Обычное время устранения |
|---|---|---|
| Сбой или лимиты на хостинге | Панель хостинга, статус-страница провайдера | От 15 минут до нескольких часов, зависит от хостера |
| DNS не резолвится после смены записей | Сервисы проверки DNS-пропагации | От нескольких минут до 24-48 часов на полное обновление |
| Истёк SSL-сертификат | Проверка срока действия в браузере или через openssl | 15-30 минут после перевыпуска |
| Не продлён домен | Whois-проверка у регистратора | От часа до суток, если домен уже в статусе редемпшн |
| Обновление плагина или темы сломало сайт (WordPress) | Логи ошибок, дата последнего обновления | 30-60 минут на откат |
| Заражение сайта вирусом или редиректом | Проверка файлов на изменённые даты, сканер вредоносного кода | От нескольких часов до нескольких дней, зависит от глубины заражения |
| Ошибка в кастомном скрипте на Tilda после правки | Консоль браузера, сравнение с последней рабочей версией кода | 15-40 минут |
| Аномальная нагрузка, похожая на DDoS | Графики нагрузки на сервер, логи количества запросов | От часа, зависит от масштаба атаки |
Если на сайте обнаружили заражение, не пытайтесь просто удалить подозрительные файлы наугад: часто вредоносный код прячет запасные точки входа, и через день всё повторяется. Здесь имеет смысл сразу заказать поддержку и сопровождение сайтов с полной проверкой, а не разовую чистку.
Как не потерять клиента, пока чините сайт
Первое сообщение стоит отправить даже без точной причины, важно показать, что проблему уже увидели и ей занимаются. Дальше держу интервал: если чинится быстро, пишу через 20-30 минут статус, если процесс долгий (например, ждём ответа поддержки хостинга или регистратора домена), сразу озвучиваю реалистичный срок и предупреждаю, что он может сдвинуться.
Не стоит обещать бесплатное исправление, если причина не в вашей работе, а в истёкшем домене, который клиент забыл продлить, или в его собственной правке кода. Спокойно объясняю причину и называю стоимость восстановления заранее, до начала работ, а не по факту. Для интернет-магазинов на WooCommerce отдельно проверяю, что после восстановления корректно работает приём оплаты через Т‑Банк и оформление доставки СДЭК, потому что клиенты обычно молчат про сайт, но сразу пишут, если не проходит оплата.
Если простои случаются не в первый раз, честнее предложить не разовую починку, а постоянное наблюдение за сайтом.
Когда и как сообщить, что сайт снова работает
Перед финальным сообщением проверяю сайт не только с главной страницы, а по ключевым сценариям: форма заявки отправляется, корзина в интернет-магазине считает сумму, виджет доставки на Tilda подтягивает актуальные зоны, telegram-бот на aiogram отвечает на команду /start, если он завязан на тот же сервер. Только после этого пишу клиенту: «Сайт снова доступен, причина была в [конкретика], проверили основные разделы и формы, дополнительно мониторим ближайшие пару часов».
Отдельно фиксирую для себя причину и время простоя. Это пригодится, если клиент спросит про повторяемость проблемы или если по итогам стоит перейти на постоянное сопровождение вместо разовых вызовов.
Частые вопросы
Что писать клиенту, если сайт не открывается, а причина ещё не ясна?
Честно сообщить, что проблема замечена и уже проверяется, без точных сроков и без гаданий про причину. Короткое сообщение «занимаемся, вернёмся с результатом через 30 минут» работает лучше, чем молчание или преждевременное «уже почти починили».
Нужно ли извиняться и предлагать компенсацию за простой?
Если причина на вашей стороне (ошибка в коде, забытое обновление, не тот сервер), извинение уместно и стоит явно назвать, что пошло не так. Если причина в хостинге, домене, который клиент не продлил, или в его собственной правке, извиняться не за что, важно просто спокойно объяснить причину и дальнейшие шаги.
Как быстро обычно чинится сайт после падения хостинга?
По моей практике, большинство сбоев на стороне хостинга закрывается за 15 минут до 2 часов. Если провайдер не отвечает дольше и статус-страница молчит, есть смысл параллельно готовить бэкап-план: временную страницу-заглушку с контактами, чтобы клиент не терял заявки полностью.
Кто виноват, если сайт упал после моего собственного обновления плагина WordPress?
Если обновление вносил сам заказчик без согласования, ответственность на нём, но это не повод отказываться помочь. Откатываю плагин до рабочей версии, проверяю совместимость и отдельно объясняю клиенту, что перед обновлением плагинов на боевом сайте стоит сначала тестировать на копии.