Проверить доступность сайта: что сломалось и кто это чинит

Если сайт не открывается, порядок такой: сначала проверить, у всех ли, потом посмотреть код ответа сервера, и только после этого что-то делать. Код и есть диагноз. На 500, 502 и 504 владелец сайта на своей стороне не чинит ничего — это хостинг или разработчик. 403 и 404 правятся на самом сайте. А «сайт не найден» вообще без кода — это чаще всего домен или DNS, и там нужно не чинить, а ждать от трёх часов до трёх суток. Вся проверка укладывается в десять минут и ничего не стоит.

Я открыл десять страниц, которые отдаются по запросам «проверить доступность сайта» и «мониторинг доступности сайта». Семь из них принадлежат сервисам мониторинга и ведут к подписке, одна написана для посетителя чужого сайта, а не для владельца, одна устарела на девять лет. Ни одна не цитирует ни стандарт HTTP, ни справку Яндекса, ни SLA хостера — коды объясняются своими словами, и у двух страниц объяснения расходятся между собой. Поэтому таблицы ниже я собрал по первоисточникам.

01Шаг 1. Понять, у всех не открывается или только у вас

Это первая развилка, и она отсекает половину случаев. Делается за две минуты.

Откройте сайт с телефона, выключив Wi-Fi, — через мобильный интернет вы приходите из другой сети и от другого провайдера. Работает там, но не работает на компьютере — дело не в сайте: это кэш DNS у вашего провайдера, запись в файле hosts, расширение браузера или антивирус. Не работает нигде — причина на стороне сайта, и дальше идём по шагам.

Для верности есть внешние чекеры без регистрации. Isitdownrightnow описывает свою работу так: «Just enter the url and a fresh site status test will be performed on the domain name in real time using our online website checker tool». У Ping-Admin есть бесплатная разовая проверка из разных точек мира — она полезна, когда сайт лежит только в одном регионе.

Правило, которое стоит запомнить: «у меня открывается» проверкой не считается. Смотреть надо минимум из двух разных сетей.

02Шаг 2. Посмотреть, что отвечает сервер

Браузер показывает не код, а человеческую формулировку, и по ней диагноз не поставить. Код даёт один из трёх бесплатных способов.

Яндекс Вебмастер, «Проверка ответа сервера» — самый полезный для владельца, потому что показывает не ваш браузер, а робота. Справка описывает его так: «С помощью инструмента Проверка ответа сервера вы можете узнать, доступны ли страницы сайта для роботов Яндекса, а также другую информацию о сайте, например, статус SSL-сертификата». Точный адрес — webmaster.yandex.ru/tools/server-response/. Нужен вход в Яндекс ID, но добавлять сайт и подтверждать права не обязательно: «Вы можете воспользоваться инструментами, даже если ваш сайт не добавлен в Яндекс Вебмастер или права на управление сайтом не подтверждены». Лимиты при этом урезаны и «обновляются в 00:00 по московскому времени».

У инструмента есть честная оговорка, про которую стоит знать: «Ответ, полученный с помощью инструмента «Проверка ответа сервера», может отличаться от реального ответа роботу, так как инструмент имеет другой IP-адрес».

curl -I <адрес> — одна команда в терминале, которая показывает только заголовки. В документации curl опция описана так: «Fetch the headers only. HTTP-servers feature the command HEAD which this uses to get nothing but the header of a document». Первая строка ответа и есть код.

ping и nslookup — проверка не сайта, а сети и имени. Microsoft описывает ping как инструмент, который «verifies IP-level connectivity to another TCP/IP computer by sending Internet Control Message Protocol (ICMP) echo Request messages», и даёт ровно тот признак, который нужен владельцу: «If pinging the IP address is successful, but pinging the computer name isn't, you might have a name resolution problem». То есть IP отвечает, а имя нет — это DNS. Про nslookup: инструмент «displays information that you can use to diagnose Domain Name System (DNS) infrastructure». Оговорка: многие серверы ICMP блокируют, поэтому молчащий ping сам по себе ничего не доказывает.

03Шаг 3. Что означает код — по тексту стандарта

Здесь важно брать формулировки из стандарта, а не из пересказов. Ниже — RFC 9110, тот самый документ, который описывает семантику HTTP, в сокращении до сути, и мой третий столбец: кто это чинит.

Две детали из того же стандарта, которые меняют поведение владельца. Первая: 403 и 404 различаются не всегда, потому что стандарт прямо разрешает маскировку — сервер, который хочет скрыть существование закрытого ресурса, «MAY instead respond with a status code of 404 (Not Found)». Поэтому 404 на странице, которая точно есть, не обязательно означает удалённый файл.

Вторая касается 503, и из-за неё 503 нельзя считать надёжным признаком перегрузки. В тексте стандарта стоит примечание: «The existence of the 503 status code does not imply that a server has to use it when becoming overloaded. Some servers might simply refuse the connection». То есть при перегрузке вы с равной вероятностью увидите и 503, и просто обрыв соединения без всякого кода.

Яндекс те же коды описывает короче и с точки зрения индексирования: 403 — «Доступ к документу запрещен. Если вы хотите, чтобы страница индексировалась, необходимо разрешить доступ к ней»; 503 — «Возникла ошибка из-за временной перегрузки или отключения на техническое обслуживание сервера». Если код оказался 404 и страниц с ним много, разбирается это отдельно: что значит ошибка 404 и как найти битые ссылки — там же порядок, по которому старые адреса закрываются редиректом, а не оставляются отдавать 404 годами.

04Шаг 4. Если кода нет вовсе: домен, DNS и сертификат

Когда браузер пишет «Не удаётся найти DNS-адрес сервера» или «Сайт не найден», до сервера дело не дошло. Google в своей справке даёт формулировки, по которым это видно: «ERR_NAME_NOT_RESOLVED. Имя хоста (веб-адрес) не существует или связано с другим IP-адресом» и «ERR_CONNECTION_REFUSED. Страница не дает Chrome подключиться, или же она заблокирована».

Причин три, и все три проверяются без техника.

Домен не продлён. Самая частая и самая обидная: сайт исправен, сервер работает, но имя больше не указывает ни на что. Проверяется в личном кабинете регистратора за минуту. Если домен оформлен не на вас, это отдельная проблема, и решать её лучше до аварии — на кого регистрировать домен и как выбрать имя разобрано отдельно, вместе с тем, что делать, если домен записан на бывшего подрядчика.

DNS ещё не обновился. Это не поломка, а ожидание, и сроки у всех участников свои.

Почему разброс такой большой, объясняет сам стандарт доменных имён: у каждой записи есть TTL — «a 32 bit unsigned integer that specifies the time interval (in seconds) that the resource record may be cached before it should be discarded». Пока у провайдера посетителя в кэше лежит старая запись с живым TTL, он будет приходить на старый адрес, и ускорить это с вашей стороны нельзя никак. Отсюда рабочая мерка: сутки — норма, трое суток — ещё не повод для паники, больше — пора в поддержку. Та же арифметика действует и при переносе сайта на другой хостинг, поэтому переезд не планируют на вечер пятницы.

Истёк сертификат. Сайт при этом открывается, но с предупреждением, и часть людей дальше не идёт. Let's Encrypt называет срок прямо: «Our default certificates are valid for 90 days», и отдельно — опция коротких сертификатов на шесть дней. Регламент обновления там же: «We recommend renewing 90 day certificates every 60 days and six day certificates every three days», а в руководстве по интеграции — общее правило «renewing certificates automatically when they have a third of their total lifetime left». Если автопродление настроено и работает, вы об этом никогда не узнаете; если нет — узнаете ровно на 90-й день. Подробнее про то, что видит посетитель при истёкшем сертификате и как его выпустить, написано отдельно, с путями в панелях трёх хостеров.

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

05Шаг 5. Что будет с поиском, пока сайт лежит

Этот вопрос владельцы задают чаще всего, и ответ у Яндекса есть прямой. Справка пишет без смягчений: «если поисковому роботу не удалось подключиться к сайту из-за ошибки сервера, то сайт может полностью пропасть из поиска».

Критерий — тот же код ответа: «Код ответа 200 ОК означает, что на момент проверки всё в порядке и страница доступна для роботов и посетителей сайта. Страница с другим кодом ответа недоступна для роботов и посетителей и не может попасть в поиск». То есть важен не хронометраж простоя, а то, попал ли на него визит робота. Последствия справка перечисляет списком: «отдельные страницы или весь сайт пропадут из результатов поиска» либо «замедлится индексирование страниц сайта или снизится его качество».

Отдельно про DNS, и это та причина, которую владельцы не рассматривают вовсе: «Раз в сутки поисковый робот обращается к DNS-серверам, чтобы определить IP-адрес сервера сайта. Если робот не получит IP-адрес сайта, он не проиндексирует его». И про скорость — важное для тех, у кого сайт не лежит, а еле ворочается: если некоторые страницы загружаются больше трёх секунд, робот фиксирует это как ошибку, и «из-за медленной работы сервера индексирование сайта может задерживаться». В инструменте проверки ответа та же граница сформулирована жёстче: «Истек срок ожидания ответа. Он должен быть получен в течение трех секунд».

Обратная дорога тоже описана числом: «Робот придет в течение двух недель. Когда страница будет отдавать код 200 OK и содержимое будет доступно, предупреждение в Яндекс Вебмастере пропадет в течение нескольких дней». Ускорить это можно переобходом, а проверить — по экрану «Диагностика сайта», который, по справке, обновляется «в течение нескольких дней», и это «не влияет на индексирование сайта». Если после аварии страницы из поиска действительно выпали, порядок возврата описан в разборе причин, по которым сайт не индексируется, и первое, что там проверяется, — тот же код ответа.

06Что хостер обещает и что должен за простой

Проценты в рекламе выглядят внушительно, а в деньгах означают немного. Я собрал цифры из трёх официальных документов.

Читать эту таблицу надо вместе с тремя оговорками, которые стоят в тех же документах. Первая: плановые работы в процент доступности не входят — Timeweb пишет, что «в показатель доступности не включено время на проведение запланированных работ по модернизации аппаратной и программной частей Платформы». Вторая — потолок ответственности, и это самая важная строка во всём SLA: у Timeweb Cloud возмещение ограничено суммой, «не превышающей суммы, фактически уплаченной Лицензиатом по тарифу за месяц», и это «единственное и исключительное возмещение Лицензиату ущерба за возникшие сбои». У Beget потолок тот же по смыслу — «не может превышать сумму, эквивалентную стоимости услуг Заказчика за 30 суток».

Третья: компенсацию надо запросить самому, и срок на это ограничен. Timeweb по VDS пишет: «Для получения компенсации пользователю необходимо в течение 30 дней с момента возникновения инцидента создать соответствующий тикет». Выплачивается она не деньгами, а временем: «Во всех случаях компенсация начисляется пользователям в виде увеличения периода оказания услуг».

Практический вывод простой. 99,98 % в год — это около 1 часа 45 минут простоя, и он разрешён договором. Компенсация за сутки простоя на тарифе за 500 ₽ в месяц — примерно 17 ₽. Если простой стоит вашему бизнесу дороже, защита — не SLA, а резервная копия и быстрый канал связи с поддержкой. Для сайта, через который идут заявки, годовой счёт за хостинг и то, что в него входит, стоит считать вместе с этими цифрами, а не отдельно.

Разберём именно
ваш сайт бесплатно

Посмотрю страницу и рекламу, найду,
где теряются заявки, и пришлю план,
что поменять.

Что входит в разбор

• 1
  Где теряются заявкипуть от объявления до формы
• 2
  Что поправить на сайтепервый экран, оффер, формы
• 3
  Что поменять в рекламезапросы, объявления, бюджет

Михаил Лапошинразберу ваш проект лично

Ваше имяТелефонСайт

TelegramWhatsAppЗвонок

Согласен на обработку данных и политику конфиденциальностиПолучить бесплатный разбор

✓ Заявка принята — отвечу в течение часа

07Нужен ли платный мониторинг и сколько он стоит

Смысл мониторинга в том, что о простое вы узнаёте не от клиента. Я свёл четыре официальные страницы тарифов — и бесплатные планы там тоже есть.

Вывод из таблицы один и он приятный: для одного сайта платить не за что. Бесплатного плана UptimeRobot на 50 адресов с проверкой раз в пять минут хватает малому бизнесу с запасом в десятки раз, а Ping-Admin при редких проверках стоит буквально центы — у них на странице тарифов это сказано прямо: «для сервисов менее важных можно выполнять проверки реже (например, раз в 10 минут), и тогда для них стоимость получится менее 0,9 $ в месяц». Платить имеет смысл за две вещи: минутный интервал вместо пятиминутного и проверки из нескольких географических точек.

Чего мониторинг не делает — не ловит то, что падением не является. Истекающий домен, истекающий сертификат и подмена контента проходят мимо него: он видит код 200 и считает, что всё хорошо.

08Чего нет ни у одной из десяти страниц

Ни одна страница пула не цитирует первоисточники: коды 403, 500, 502, 503 и 504 везде объясняются словами автора, без ссылки на стандарт, и у двух страниц объяснения расходятся. Ни одна не называет точный адрес инструмента Вебмастера и не предупреждает, что для него нужен вход в Яндекс ID. Ни одна не отвечает на главный вопрос владельца — выпадет ли сайт из поиска за время простоя — со ссылкой на справку. Ни одна не приводит SLA хостера: ни процента доступности, ни порога компенсации, ни потолка ответственности в размере месячного платежа. Сроки обновления DNS называет одна страница, и то без ссылки. И ни одна не даёт сравнения цен мониторинга в одной таблице: сервисы рекламируют себя, а обзор девятилетней давности цен не содержит вовсе.

Оговорка про метод замера: позиции я не снимал. На автоматический запрос Яндекс отдаёт SmartCaptcha, поэтому выше — пул страниц, которые устойчиво отдаются по запросам кластера, а не измеренный топ-10 по порядку. Объёмы страниц в пуле — от 510 до 1870 слов, контентная таблица есть у двух из десяти.

09Как не возвращаться к этому каждые полгода

Четыре записи в календаре и одна проверка раз в квартал закрывают почти все случаи из этой статьи.

Дата продления домена — в календарь с напоминанием за месяц, и отдельно проверить, что домен оформлен на вас, а не на подрядчика. Автопродление сертификата — настроить и один раз убедиться, что оно сработало: следующая дата обновления должна прийти раньше срока истечения, по правилу Let's Encrypt — когда осталась треть срока жизни. Бесплатный мониторинг — завести на главную страницу и на страницу с формой заявки отдельно: главная может работать, когда форма уже нет. Резервная копия — проверять не её наличие, а восстановление, хотя бы раз в квартал.

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

Михаил ЛапошинМаркетолог, руководитель Laposhin Agency

«Делаем сайты и запускаем Яндекс Директ так, чтобы
сайт приносил заявки, а не просто был»

Есть вопрос по статье?Задать вопрос в Telegram