Статус сайта

Как проверить, работает ли сайт: читаем отчёт

Проверка доступности сайта отправляет запрос к указанному адресу с нашего сервера и ждёт ответа до 15 секунд. Если схема не указана, используется https://. Запрос идёт методом HEAD — сервер отдаёт только заголовки без тела страницы, поэтому проверка быстрая и не нагружает сайт. Редиректы инструмент проходит сам (до десяти) и показывает итоговый адрес.

В отчёте вы увидите:

• «Сайт работает» или «Сайт недоступен». «Работает» означает, что сервер ответил кодом от 200 до 499 без сетевой ошибки. Обратите внимание: 404 и 403 тоже попадают сюда — сервер жив, но конкретная страница отдаёт ошибку. Поэтому всегда смотрите на сам код.
• HTTP-статус итогового ответа после всех редиректов.
• Время ответа — полный путь запроса с нашей стороны, включая DNS, соединение, TLS и редиректы.
• TTFB — время до первого байта последнего ответа: сколько сервер думал над запросом.
• SSL — получен ли сертификат при HTTPS-соединении. Сертификат проверяется: просроченный или выданный на другое имя даёт ошибку соединения, и сайт будет помечен как недоступный.
• Редиректы, финальный URL, заголовок Server и таблица цепочки «статус — откуда — куда».

Сайт не работает у всех или только у меня

Главный вопрос, с которым приходят на такую проверку. Наш запрос идёт из дата-центра, а не с вашего компьютера, поэтому результат отделяет проблему сайта от проблемы вашей сети:

Учтите, что проверка идёт из одной точки. Если сайт закрыт по геолокации или недоступен у конкретного провайдера, из нашего дата-центра он может открываться. Для проверки из другой страны попробуйте VPN или мобильный интернет.

Если сайт не открывается только у вас

1. Откройте сайт с телефона через мобильную сеть, без Wi-Fi.
2. Сбросьте DNS-кэш: Windows — ipconfig /flushdns, macOS — sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder.
3. Проверьте, куда резолвится домен: nslookup example.com 8.8.8.8. Если ответ другой, чем через ваш DNS, смените DNS-серверы на 1.1.1.1 или 8.8.8.8.
4. Отключите VPN, прокси и расширения браузера, попробуйте окно инкогнито.

Коды ответа: что означает статус

Сайт недоступен без кода ответа

Если вместо кода — сообщение об ошибке, дело не в приложении, а раньше по цепочке:

• Could not resolve host — домен не резолвится: истёк срок регистрации, удалены NS или A-запись. Проверьте даты в WHOIS и командой nslookup example.com 8.8.8.8.
• Connection refused — сервер жив, но на порту 443 или 80 никто не слушает: веб-сервер остановлен или закрыт файрволом. Порт проверит проверка портов.
• Timed out — сервер не ответил за 15 секунд: перегрузка, DDoS, сетевые проблемы хостинга.
• SSL certificate problem — просрочен сертификат, не хватает промежуточного сертификата или имя не совпадает. Подробности покажет проверка SSL, а разбор типичных ошибок есть в статье «Проверка SSL-сертификата».

Что делать владельцу, если сайт лежит

На VPS с nginx и PHP-FPM порядок диагностики обычно такой:

systemctl status nginx php8.3-fpm
tail -n 50 /var/log/nginx/error.log
df -h          # закончилось место на диске?
free -m        # закончилась память?

502 при живом nginx почти всегда означает, что упал или не справляется PHP-FPM. Полный диск ломает и базу данных, и сессии, и логи одновременно.

На WordPress после обновления плагина белый экран или 500 лечится переименованием папки плагина через FTP или файловый менеджер (wp-content/plugins/имя → имя-off); причину покажет define('WP_DEBUG', true); и define('WP_DEBUG_LOG', true); в wp-config.php. На виртуальном хостинге и конструкторах (Tilda, Wix) сначала проверьте, не заблокирован ли аккаунт за неоплату и нет ли объявленной аварии у платформы.

Пример: лишние редиректы в отчёте

Частая картина при проверке адреса без протокола и www: в цепочке два шага — http://example.com → 301 → https://example.com/ → 301 → https://www.example.com/ → 200. Сайт работает, но каждый пользователь и каждый робот проходят лишний круг, а время ответа растёт на одно соединение. Лучше вести все варианты на канонический адрес одним шагом. В nginx:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}

Для HTTPS-версии без www нужен такой же отдельный блок server с listen 443 ssl и тем же return. Подробный разбор цепочек — в статье «Как проверить редиректы».

Как недоступность сайта влияет на позиции в Google

Короткий сбой на несколько минут или часов позиции не обрушит. Googlebot, получив 5xx или таймаут, снижает частоту обхода и приходит позже. Если же сервер отдаёт 5xx днями, Google начинает удалять такие адреса из индекса — восстанавливаться потом придётся неделями. Отсюда два правила:

• Плановые работы закрывайте кодом 503 с заголовком Retry-After, а не страницей «ведутся работы» с кодом 200 и не 404. Тогда робот поймёт, что сбой временный, и не заменит в индексе ваши страницы заглушкой.
• Не отдавайте роботам 403 и 404 вместо 503 при перегрузке: 4xx Google воспринимает как «страницы нет», а не «сервер занят».

location / {
    return 503;
}
add_header Retry-After 3600 always;

Скорость ответа: какие цифры нормальны

Google относит к хорошему TTFB значения до 0,8 секунды. Если TTFB стабильно выше, тормозит сервер: нет кэша страниц, медленная база, слабый тариф. Если TTFB низкий, а общее время велико, время уходит на редиректы, DNS или установку соединения — смотрите цепочку в отчёте. Одна проверка — это один замер; для серии замеров используйте проверку времени ответа.

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