Соберите три факта до начала проверки

Попросите клиента прислать точный адрес, время ошибки, город/провайдера и скриншот целиком. Формулировка «сайт не работает» недостаточна: ошибка DNS, предупреждение сертификата и белый экран — разные проблемы.

  • Проверьте, открывается ли домен с https:// и вариант с www или без него.
  • Повторите вход в приватном окне без авторизации и расширений браузера.
  • Зафиксируйте текст ошибки браузера или код ответа, а не только «не загрузилось».

1. Домен может вести на старый или неверный IP

После переезда хостинга, смены CDN или DNS-записей часть пользователей иногда получает старый адрес из кэша. На одном соединении сайт ещё жив, на другом — уже нет или открывается старая версия.

  • Сверьте A/AAAA-записи домена и www с адресом нового сервера или CDN.
  • Проверьте, не осталась ли ненужная AAAA-запись: клиент по IPv6 пойдёт именно на неё.
  • После изменения DNS учитывайте TTL; не меняйте записи повторно, пока распространение не завершилось.

2. HTTPS и сертификат должны совпадать с адресом

Если сертификат истёк, выдан для другого домена или не включает www, браузер покажет предупреждение и часть посетителей не продолжит путь. Проблема часто проявляется только на дополнительном поддомене после продления.

  • Откройте https-версию главного домена и www в новом браузере или с другого устройства.
  • Убедитесь, что сертификат действителен и содержит все используемые имена.
  • Проверьте, что HTTP перенаправляет на один канонический HTTPS-адрес.

3. Посмотрите код ответа и цепочку редиректов

Страница может открываться у вас из кэша, а сервер в это время отдаёт 500, 502, 503 или уводит клиента по нескольким переходам. Отдельная проблема — редирект-петля между HTTP/HTTPS, www и настройками CDN.

  • Для работающей страницы ожидайте конечный HTTP 200.
  • Сократите переходы до одного: HTTP → HTTPS или www → основной домен.
  • Не редиректите неизвестные адреса на главную: для удалённой страницы нужен честный 404 или релевантный 301.

4. Сайт может отвечать слишком медленно

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

  • Сравните время ответа главной и ключевой посадочной страницы.
  • Посмотрите журнал ошибок сервера и нагрузку базы данных в момент жалобы.
  • Не путайте медленный первый ответ сервера с медленной отрисовкой: второе требует браузерного замера.

5. Иногда проблема не в сайте

Корпоративный VPN, локальный DNS, антивирус, расширение браузера или ограничение сети могут мешать только одному человеку. Это не повод сразу переносить сайт или менять сертификат.

  • Сравните результат в другой сети: мобильный интернет, домашний Wi-Fi, офис.
  • Проверьте без VPN и затем с VPN, если клиент использует его постоянно.
  • Если ошибка есть только у одного пользователя, попросите очистить DNS/браузерный кэш и проверить расширения.

Что сделать за 10 минут

  1. Введите домен в проверку доступности и сохраните код, конечный URL и время ответа.
  2. Проверьте основной домен, www и важную посадочную страницу.
  3. Если есть 5xx, петля редиректов или ошибка HTTPS — передайте разработчику точный URL и время проверки.
  4. Если технически всё нормально, попросите клиента повторить проверку из другой сети.

Инструмент ProWebStatus даёт снимок одной точки. Полный технический аудит проверяет ключевые страницы, ссылки, ошибки сети и браузерные сценарии, которые разовая проверка домена не видит.