Czy strona działa?
Sprawdź dostępność strony w kilka sekund: kod HTTP, czasy odpowiedzi, SSL, nagłówki bezpieczeństwa i podgląd SEO. Profesjonalne narzędzie online, które działa w Twojej przeglądarce. Szybko, bezpiecznie i bez instalowania zbędnego oprogramowania.
-
1Wprowadź dane
Wpisz treść, wklej tekst lub załaduj plik z dysku. -
2Kliknij przycisk
Narzędzie natychmiast przetworzy Twoje dane w przeglądarce. -
3Pobierz wynik
Skopiuj gotowy tekst lub zapisz plik na urządzeniu.
return "Wynik gotowy w 0.1s";
}
Sprawdź status strony
Błyskawiczna analiza dostępności, SSL i wydajności.
Powiązane narzędzia
Inne narzędzia, które mogą Ci się przydaćCzy strona działa? Sprawdź online w 12 sekund, bez zgadywania
Są dni, kiedy internet udaje, że wszystko jest okej… a twoja strona właśnie znika ludziom z oczu. Ten tester odpowiada prosto: czy problem leży po stronie serwera, DNS, SSL, czy może u ciebie. Wpisujesz adres i dostajesz czytelny werdykt + techniczne podpowiedzi, które da się przekazać hostingowi bez tłumaczenia „coś nie działa”.
Co dokładnie sprawdzamy i dlaczego to ma znaczenie
W typowym „nie działa mi strona” mieszają się różne problemy, które na pierwszy rzut oka wyglądają identycznie: biała strona, timeout, błąd przeglądarki, czasem przekierowania w pętlę. Dlatego dobry test nie kończy się na jednym pingnięciu. Ten monitor rozkłada temat na warstwy: najpierw czy domena w ogóle prowadzi gdziekolwiek, potem czy serwer przyjmuje połączenia, a na końcu czy aplikacja oddaje sensowną odpowiedź HTTP.
1) DNS — czy domena ma dokąd prowadzić
Jeśli DNS leży, reszta jest bez znaczenia. Strona może „istnieć”, serwer może działać, ale użytkownik i tak nie trafi, bo przeglądarka nie wie, pod jaki adres IP iść. Wynik DNS to pierwsza lampka: gdy jest błąd, najczęściej winne są rekordy, propagacja zmian albo chwilowa awaria operatora DNS.
W praktyce: jeśli DNS nie odpowiada lub zwraca puste rekordy, nie ma sensu szukać problemu w WordPressie, wtyczkach czy kodzie — to inna półka.
2) TCP 80/443 — czy serwer przyjmuje połączenia
Port 80 (HTTP) i 443 (HTTPS) mówią, czy serwer „w ogóle słucha”. Możesz mieć poprawny DNS, ale firewall, awaria sieci, błędna konfiguracja reverse proxy albo limit połączeń zrobią swoje. Ten krok jest bardzo pomocny, kiedy HTTP krzyczy timeoutem — bo wtedy od razu wiesz, czy to problem aplikacji, czy „nie dobijasz do serwera”.
Jeśli 80 działa, a 443 nie — to często wskazówka: SSL, certyfikat, konfiguracja HTTPS, albo blokada na 443.
3) HTTP — kod odpowiedzi i czas, który czujesz w palcach
Kod HTTP (200, 301, 403, 404, 500…) jest jak diagnoza na kartce: krótka, ale konkretna. To tu dowiadujesz się, czy strona faktycznie oddaje treść, czy przekierowuje, czy serwer ma błąd, czy blokuje dostęp. Dodatkowo dostajesz czasy po drodze (DNS lookup, connect, TTFB, total). Dzięki temu łatwo odróżnić „strona działa, tylko jest wolna” od „strona nie odpowiada”.
A jeśli włączysz śledzenie przekierowań, zobaczysz, dokąd finalnie trafia użytkownik — bez ręcznego klikania i domyślania się, czy to 301, 302, czy pętla.
4) Deep dive — SSL, bezpieczeństwo i szybki podgląd SEO
Gdy strona jest online, dokładamy warstwę „czy jest zdrowa”: certyfikat SSL (kto wystawił, do kiedy ważny, ile dni zostało), podstawowe nagłówki bezpieczeństwa (HSTS, CSP, X-Frame-Options itd.) oraz podgląd tego, co często jako pierwsze widzi Google: title i meta description.
To nie jest pełny audyt SEO ani security — raczej szybki test, który wyłapie typowe braki i pozwoli ustawić priorytety.
Jak użyć narzędzia, żeby wynik był naprawdę wiarygodny
Najwięcej fałszywych alarmów bierze się z drobiazgów: wklejony adres z błędem, brak „https”, literówka w domenie, albo serwis działający tylko na jednej wersji (www vs bez www). Dlatego warto podejść do testu jak do krótkiej procedury: najpierw prosty adres, potem ewentualnie sprawdzenie przekierowań i porównanie wariantów.
- Wpisz domenę tak, jak ją widzi użytkownik. Jeśli ludzie wchodzą na „example.com”, nie testuj od razu jakiegoś długiego URL-a z parametrami — zacznij od podstaw.
- Włącz śledzenie przekierowań, gdy podejrzewasz 301/302. To pomaga przy migracjach, zmianach HTTPS, przejściach na www lub bez www.
- Porównaj wyniki dla wersji http i https. Niby oczywiste, ale zaskakująco często HTTPS psuje się jako pierwsze (certyfikat, łańcuch, konfiguracja).
- Zwróć uwagę na czasy (TTFB i total). Jeśli total rośnie, a connect jest szybki — problem jest „wyżej” (aplikacja, baza, cache, przeciążenie), a nie w samym łączu.
Interpretacja wyników bez technicznego bełkotu
Werdykt jest prosty: ONLINE, OFFLINE albo NIEZNANY. Ale najciekawsze dzieje się w szczegółach: to one mówią, komu i co zgłosić oraz ile to może potrwać. Poniżej masz „ściągę” w ludzkim języku.
| Co widzisz w raporcie | Co to zwykle oznacza | Co zrobić dalej |
|---|---|---|
| DNS: błąd / brak IP | Domena nie wskazuje na serwer lub trwa zmiana DNS | Sprawdź rekordy A/AAAA/CNAME, poczekaj na propagację, zapytaj operatora DNS |
| TCP 80/443: brak połączenia | Serwer nie przyjmuje połączeń, firewall blokuje, awaria sieci | Kontakt z hostingiem / adminem, sprawdzenie firewall, limitów i statusu maszyny |
| HTTP: 200 | Strona działa (co najmniej w warstwie HTTP) | Jeśli „coś nie gra”, problem jest w treści/aplikacji (np. błędy w środku strony) |
| HTTP: 301/302 | Przekierowanie (często normalne) | Włącz śledzenie przekierowań i sprawdź finalny adres; uważaj na pętle |
| HTTP: 403 | Blokada dostępu (WAF, reguły, geoblokada, autoryzacja) | Sprawdź reguły bezpieczeństwa, whitelist, konfigurację serwera/proxy |
| HTTP: 404 | Serwer żyje, ale zasób nie istnieje | Sprawdź poprawność URL-a, routing, przekierowania, reguły .htaccess |
| HTTP: 500/502/503/504 | Błąd aplikacji albo problem po drodze (proxy/gateway) | Logi serwera, obciążenie, błędy backendu, status usług; zgłoś hostingowi z kodem |
| SSL: wygasł / brak | HTTPS nie jest poprawnie zabezpieczone | Odnowienie certyfikatu, poprawna instalacja łańcucha, wymuszenie HTTPS |
| Nagłówki bezpieczeństwa: braki | Serwis działa, ale ma prostą konfigurację ochronną | Ustaw HSTS, CSP, X-Frame-Options itd. w zależności od projektu |
Po co ci ocena prędkości, skoro to nie PageSpeed?
Ta ocena jest „użytkowa”, a nie marketingowa. Nie ma udawać audytu, tylko szybko pokazać, czy serwer odpowiada jak sprinter, czy jak ktoś, kto dopiero szuka kluczy. Gdy widzisz ocenę A/A+ i nadal masz wrażenie, że strona muli, to najczęściej problem leży w renderowaniu po stronie przeglądarki (ciężkie skrypty, obrazy, fonty). Gdy natomiast widzisz B/C, a szczególnie wysoki TTFB, to zwykle znak: backend, cache, baza, przeciążenie, albo zewnętrzne integracje trzymają odpowiedź.
W skrócie: to nie jest „ranking”, tylko sygnał alarmowy. Taki, który możesz pokazać komuś od hostingu i powiedzieć: „tu się to opóźnia”.
Kiedy to narzędzie jest najbardziej przydatne
Najlepsze w tym teście jest to, że działa zarówno dla właściciela strony, jak i dla osoby, która „tylko ma zgłoszenie”. W praktyce: support, webmaster, marketer, a nawet ktoś, kto po prostu chce sprawdzić, czy awaria jest globalna, czy lokalna.
Sklep przestaje ładować koszyk albo checkout. Zamiast „u mnie działa”, masz kod HTTP i czasy odpowiedzi, które pokazują, czy problem jest po stronie serwera.
Zmiana hostingu, przejście na HTTPS, nowe DNS-y. Widzisz finalny URL po przekierowaniach i łapiesz pętle zanim zrobi to klient.
Komunikat o niezaufanym certyfikacie? Sprawdzasz, kiedy wygasa i czy w ogóle jest aktywny, zanim zacznie się gaszenie pożaru.
Podgląd title i meta description pomaga złapać sytuacje typu: brak tytułu, dziwne znaki, niechciane przekierowanie na inną domenę.
Zgłoszenie od klienta: „strona nie działa”. W 30 sekund masz dane do odpowiedzi i wiesz, czy eskalować do hostingu.
Szybki sanity check po deployu: czy serwer oddaje 200, czy nie wypluwa 500/502 i czy HTTPS nadal stoi prosto.
Najczęstsze powody, że strona „nie działa” (a wcale nie jest martwa)
Paradoks internetu polega na tym, że strona może być online i jednocześnie „nie działać” w odczuciu użytkownika. Przykład? Kod 200, ale aplikacja wyświetla błąd wewnątrz strony. Albo 301, które prowadzi w kółko, więc przeglądarka się poddaje. Albo 403, bo filtr bezpieczeństwa uznał twój ruch za podejrzany.
- Przekierowania po zmianie domeny/HTTPS — finalny adres jest inny niż myślisz.
- Wygasły certyfikat — strona „jest”, ale przeglądarka straszy.
- Blokada firewall/WAF — kod 403 dla części użytkowników lub krajów.
- Przeciążenie serwera — rosnące czasy odpowiedzi, a potem 503/504.
- Błędny DNS po zmianach — jedni widzą nowy serwer, inni jeszcze stary.
- Gateway/proxy po drodze — 502/504 mimo że aplikacja w środku żyje.
FAQ — pytania, które ludzie zadają zawsze (i słusznie)
Czy wynik „ONLINE” oznacza, że strona na pewno działa poprawnie?
Oznacza, że strona odpowiada na poziomie sieci i HTTP — czyli użytkownik jest w stanie dostać odpowiedź z serwera. To świetny pierwszy filtr, ale nie wyklucza problemów „w środku”, np. błędów w treści, niedziałających funkcji, błędów JavaScript czy problemów z logowaniem. Jeśli masz 200 i sensowne czasy, a użytkownicy nadal zgłaszają problem, warto sprawdzić konkretną podstronę lub scenariusz (koszyk, formularz, panel).
Co oznacza „NIEZNANY” i kiedy to się zdarza?
„NIEZNANY” to sytuacja, w której test nie może jednoznacznie stwierdzić, czy serwis jest up czy down — zwykle dlatego, że odpowiedź jest nietypowa, niestabilna albo blokowana. Może się zdarzyć przy mocnych zabezpieczeniach (np. ochrona przed botami), przy chwilowych problemach po drodze lub gdy serwer zwraca niejednoznaczne błędy. Wtedy najważniejsze są szczegóły: DNS, porty i kod HTTP mówią, w którą stronę iść.
Dlaczego mam 301/302, skoro „strona się nie otwiera”?
Bo przekierowanie może prowadzić w złe miejsce albo tworzyć pętlę. Użytkownik widzi wtedy komunikat typu „zbyt wiele przekierowań” albo stronę, która kończy się na timeout. Włączenie śledzenia przekierowań pozwala zobaczyć finalny adres i szybko wykryć, czy problemem jest np. konflikt www vs bez www, HTTP vs HTTPS, albo źle ustawione reguły na serwerze.
Czy narzędzie sprawdza też SSL i kiedy zobaczę te dane?
Tak — jeśli strona jest dostępna i da się zestawić połączenie po HTTPS, dostaniesz podstawowe informacje o certyfikacie, w tym datę ważności i liczbę dni do wygaśnięcia. To szczególnie przydatne, bo SSL potrafi „wywrócić” biznes w jeden dzień: użytkownicy się boją, przeglądarki ostrzegają, a reklamy i SEO potrafią dostać rykoszetem.
Wynik pokazuje 403 — czy to znaczy, że strona jest zhakowana?
Zwykle nie. 403 oznacza „odmowę dostępu” i najczęściej wynika z konfiguracji: reguł firewall/WAF, blokady na poziomie serwera, ograniczeń geograficznych, braku autoryzacji albo błędnych uprawnień. Oczywiście, jeśli 403 pojawił się nagle i dotyczy wszystkich, warto sprawdzić, czy nie zmieniły się reguły bezpieczeństwa, ale sam kod 403 nie jest dowodem włamania.
Czy mogę sprawdzić stronę, która ma ochronę anty-bot (np. challenge)?
Zależy od rodzaju ochrony. Jeśli serwis wymaga interakcji (challenge, captcha, dynamiczne skrypty), test może dostać odpowiedź inną niż zwykły użytkownik i wtedy wynik bywa niejednoznaczny. W takich przypadkach traktuj raport jak diagnostykę sieciowo-serwerową: DNS, porty i podstawowa odpowiedź HTTP nadal są wartościowe, ale pełna weryfikacja „czy działa dla człowieka” może wymagać testu w przeglądarce.
Jak najszybciej zgłosić problem do hostingu, żeby nie odbić się od „proszę o więcej danych”?
Wyślij trzy rzeczy: testowaną domenę, kod HTTP (albo informację o braku odpowiedzi) i czasy (szczególnie total oraz TTFB), plus informację, czy port 80/443 jest osiągalny. Hosting i administratorzy kochają konkrety — to skraca ping-ponga mailowego. Jeśli masz też informację o DNS (czy zwraca IP), tym lepiej, bo od razu wiadomo, czy temat dotyczy serwera czy ustawień domeny.
Na koniec: jeśli chcesz, żeby „działa” znaczyło „działa”
Jednorazowy test jest super, ale prawdziwy spokój daje nawyk: sprawdzić stronę po zmianach DNS, po wdrożeniu, po odnowieniu certyfikatu, po większej kampanii marketingowej. Internet jest bezlitosny: gdy coś się wysypie, użytkownik nie czeka — po prostu znika. A ty zostajesz z pytaniem: „czy to wina serwera, czy u mnie?”. Lepiej mieć odpowiedź od razu.
Uruchom analizę dostępności