Status strony

Status strony: jak sprawdzić, czy strona działa

Sprawdzenie statusu strony polega na wysłaniu zapytania z naszego serwera pod wskazany adres i odczekaniu na odpowiedź — maksymalnie 15 sekund. Jeśli nie podasz protokołu, narzędzie użyje https://. Zapytanie idzie metodą HEAD: serwer zwraca same nagłówki bez treści strony, więc test trwa chwilę i nie obciąża serwisu. Przekierowania (do dziesięciu) narzędzie przechodzi samo i pokazuje adres końcowy.

W wyniku zobaczysz:

• „Strona działa” albo „Strona niedostępna”. „Działa” oznacza, że serwer odpowiedział kodem od 200 do 499 bez błędu sieci. Mieszczą się tu także 404 i 403 — serwer żyje, ale konkretny adres zwraca błąd. Dlatego zawsze patrz na sam kod.
• Status HTTP ostatecznej odpowiedzi, po wszystkich przekierowaniach.
• Czas odpowiedzi całego zapytania po naszej stronie: DNS, połączenie, TLS i przekierowania.
• TTFB — czas do pierwszego bajtu ostatniej odpowiedzi, czyli ile serwer „myślał” nad zapytaniem.
• SSL — czy połączenie HTTPS zwróciło certyfikat. Certyfikat jest weryfikowany: wygasły lub wystawiony na inną nazwę kończy się błędem połączenia, a strona zostaje oznaczona jako niedostępna.
• Liczba przekierowań, końcowy URL, nagłówek Server i tabela łańcucha przekierowań (status, skąd, dokąd).

Jak sprawdzić, czy strona działa, czy nie działa tylko u mnie

To najczęstsze pytanie. Nasze zapytanie wychodzi z centrum danych, a nie z Twojego komputera, więc wynik pozwala oddzielić awarię strony od problemu z Twoim łączem:

Uczciwie o ograniczeniu: test wykonujemy z jednej lokalizacji. Jeśli strona blokuje ruch z wybranych krajów albo nie działa tylko u konkretnego operatora, z naszego centrum danych może wyglądać na sprawną. Dostępność z innego kraju sprawdzisz przez VPN z wyjściem w tym kraju albo przez internet mobilny.

Strona nie działa tylko u Ciebie — co zrobić

1. Otwórz stronę na telefonie przez internet mobilny, z wyłączonym Wi-Fi. Jeśli działa — problem leży w Twojej sieci domowej lub firmowej.
2. Wyczyść pamięć DNS: w Windows polecenie ipconfig /flushdns w wierszu poleceń, w macOS sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder.
3. Porównaj odpowiedzi DNS: nslookup example.pl 8.8.8.8. Jeśli publiczny serwer zwraca inny adres niż Twój domyślny, zmień serwery DNS w systemie lub routerze na 1.1.1.1 albo 8.8.8.8.
4. Wyłącz VPN, proxy i rozszerzenia przeglądarki, spróbuj w oknie incognito.
5. Uruchom ponownie router — zdarza się, że zawiesza się jego wbudowany serwer DNS.

Kody odpowiedzi serwera — co oznacza status strony

Każdy krok łańcucha z osobnymi nagłówkami pokaże sprawdzenie kodu HTTP.

Strona niedostępna bez kodu odpowiedzi

Gdy zamiast kodu pojawia się komunikat błędu, problem leży wcześniej niż w samej aplikacji:

• Could not resolve host — domena się nie rozwiązuje: wygasła rejestracja, usunięto serwery NS albo rekord A. Datę ważności domeny sprawdzisz w WHOIS.
• Connection refused — serwer działa, ale nic nie nasłuchuje na porcie 443 lub 80: serwer WWW jest zatrzymany albo port zablokowała zapora. Sprawdzisz to testem portów.
• Timed out — brak odpowiedzi w ciągu 15 sekund: przeciążenie, atak DDoS, awaria sieci u hostingodawcy.
• SSL certificate problem — wygasły certyfikat, brak certyfikatu pośredniego albo niezgodna nazwa. Szczegóły pokaże sprawdzenie certyfikatu SSL. Przy Let's Encrypt najczęstszą przyczyną jest nieudane automatyczne odnowienie co 90 dni.

Strona nie działa — co zrobić, jeśli jest Twoja

Hosting współdzielony i kreatory stron

1. Zaloguj się do panelu hostingu i sprawdź, czy konto nie zostało zawieszone za brak płatności lub przekroczenie limitów.
2. Sprawdź komunikaty o awariach u hostingodawcy — przy awarii serwera zwykle informuje o niej w panelu lub na stronie statusu.
3. Sprawdź termin ważności domeny u rejestratora: wygasła domena to jedna z najczęstszych przyczyn „nagłego” zniknięcia strony.

WordPress

Biały ekran lub błąd 500 tuż po aktualizacji wtyczki zwykle usuwa zmiana nazwy jej katalogu przez FTP lub menedżer plików (wp-content/plugins/nazwa → nazwa-off). Prawdziwą przyczynę zapisze do logu wpis define('WP_DEBUG', true); i define('WP_DEBUG_LOG', true); w wp-config.php — log trafi do wp-content/debug.log.

VPS z nginx i PHP-FPM

systemctl status nginx php8.3-fpm
tail -n 50 /var/log/nginx/error.log
df -h          # czy nie skończyło się miejsce na dysku
free -m        # czy nie zabrakło pamięci

Błąd 502 przy działającym nginx prawie zawsze oznacza, że PHP-FPM padł lub nie nadąża. Zapełniony dysk psuje jednocześnie bazę danych, sesje i logi.

Przykład: zbędne przekierowania w wyniku

Typowy obraz przy sprawdzaniu adresu bez protokołu i bez www: łańcuch ma dwa kroki — http://example.pl → 301 → https://example.pl/ → 301 → https://www.example.pl/ → 200. Status strony jest prawidłowy, ale każdy odwiedzający i każdy robot przechodzi dodatkowe koło, a czas odpowiedzi rośnie o jedno połączenie. Lepiej kierować wszystkie warianty na adres kanoniczny jednym krokiem. W nginx:

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

Dla wersji HTTPS bez www potrzebny jest osobny, analogiczny blok server z listen 443 ssl. Na Apache to samo załatwiają reguły RewriteRule w .htaccess — kluczowe, by prowadziły od razu do adresu docelowego. Więcej o łańcuchach w artykule o sprawdzaniu przekierowań.

Czy awaria strony szkodzi pozycjom w Google

Krótka przerwa — kilka minut czy godzin — nie zrujnuje pozycji. Gdy Googlebot dostaje błąd 5xx lub przekroczenie czasu, zwalnia indeksowanie i wraca później. Jeśli jednak serwer zwraca 5xx przez kilka dni, Google zaczyna usuwać takie adresy z indeksu, a powrót do wcześniejszych pozycji trwa tygodniami. Wynikają z tego dwie zasady:

• Prace serwisowe zamykaj kodem 503 z nagłówkiem Retry-After, a nie stroną „trwa przerwa techniczna” z kodem 200 ani błędem 404. Kod 503 mówi robotom, że niedostępność jest chwilowa, więc Twoje podstrony nie zostaną w indeksie zastąpione komunikatem o przerwie.
• Przy przeciążeniu nie odpowiadaj robotom kodem 403 lub 404 zamiast 503: błędy 4xx Google odczytuje jako „tej strony nie ma”, a nie „serwer jest zajęty”.

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

W WordPressie tryb konserwacji w czasie aktualizacji domyślnie zwraca właśnie 503, ale część wtyczek „maintenance mode” serwuje stronę z kodem 200 — sprawdź status strony w trakcie przerwy i upewnij się, że widzisz 503.

Czas odpowiedzi strony: jakie wartości są w normie

Google uznaje TTFB poniżej 0,8 sekundy za dobry. Jeśli TTFB stale jest wyższy, hamuje serwer: brak cache stron, wolna baza danych, zbyt słaby pakiet hostingu. Jeśli TTFB jest niski, a czas całkowity wysoki, czas uciekł na przekierowania, DNS lub zestawienie połączenia — spójrz na łańcuch w raporcie.

To jednorazowe sprawdzenie statusu strony, a nie monitoring: narzędzie nie obserwuje serwisu przez całą dobę i nie wysyła powiadomień. Gdy strona pada okresowo, sprawdź ją w chwili awarii i zapisz kod oraz treść błędu — z tymi danymi rozmowa z pomocą techniczną hostingu jest znacznie krótsza.