Статус сайту

Як перевірити, чи працює сайт

Перевірка доступності сайту надсилає запит із нашого сервера на вказану адресу й чекає відповіді до 15 секунд. Якщо протокол не вказано, підставляється https://. Використовується метод HEAD: сервер повертає лише заголовки без тіла сторінки, тож перевірка швидка й не навантажує сайт. Редиректи (до десяти) інструмент проходить сам і показує кінцеву адресу.

Що є у звіті:

• «Сайт працює» / «Сайт недоступний». «Працює» — сервер відповів кодом 200–499 без мережевої помилки. Тобто 404 і 403 теж сюди потрапляють: сервер живий, а конкретна сторінка віддає помилку. Тому дивіться на сам код.
• HTTP-статус кінцевої відповіді після всіх редиректів.
• Час відповіді — повний шлях запиту з нашого боку: DNS, з'єднання, TLS, редиректи.
• TTFB — час до першого байта останньої відповіді, тобто скільки сервер обробляв запит.
• SSL — чи отримано сертифікат. Сертифікат перевіряється: прострочений або виданий на інше ім'я дає помилку з'єднання, і сайт буде позначено як недоступний.
• Кількість редиректів, фінальний URL, заголовок Server і таблиця ланцюжка «статус — звідки — куди».

Сайт не працює у всіх чи лише в мене

Наш запит іде з дата-центру, а не з вашого пристрою. Тому результат допомагає відділити проблему сайту від проблеми вашої мережі:

Перевірка йде з однієї точки. Якщо сайт обмежено за геолокацією або він недоступний лише в конкретного провайдера, з нашого дата-центру він може відкриватися. Щоб перевірити з іншої країни, скористайтеся VPN або мобільним інтернетом.

Сайт не відкривається лише у вас

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

Коди відповіді сервера

Детальніше пройти ланцюжок кодів допоможе перевірка HTTP-статусу.

Помилка без коду відповіді

• Could not resolve host — домен не розв'язується: закінчилася реєстрація, видалено NS чи A-запис. Перевірте дати у WHOIS.
• Connection refused — сервер живий, але порт 443 чи 80 ніхто не слухає: вебсервер зупинено або порт закрито фаєрволом. Порт перевірить перевірка портів.
• Timed out — сервер не відповів за 15 секунд: перевантаження, DDoS, мережеві проблеми хостингу.
• SSL certificate problem — прострочений сертифікат, немає проміжного сертифіката або не збігається ім'я. Деталі покаже перевірка 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. На віртуальному хостингу та конструкторах спершу перевірте, чи не заблоковано акаунт за несплату і чи не оголошено аварію на платформі.

Приклад: зайві редиректи у звіті

Типова картина, коли перевіряєте адресу без протоколу й без 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

Короткий збій на кілька хвилин чи годин позицій не обвалить: отримавши 5xx або тайм-аут, Googlebot зменшує частоту сканування й повертається пізніше. Але якщо сервер віддає 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 чи встановлення з'єднання. Одна перевірка — це один замір, а не моніторинг: інструмент не стежить за сайтом цілодобово й не надсилає сповіщень. Якщо сайт падає періодично, перевіряйте його в момент збою та зберігайте код і текст помилки — з ними простіше говорити з хостером.