Monitoring dostępności witryny dla stron SEO i sprzedażowych

Monitoruj publiczny URL projektu, analizuj dostępność i odpowiedzi z 30 dni oraz nieudane kontrole HTTP. Łącz historię incydentów i kwalifikujące się e-maile z pracą SEO.

Monitoruj dostępność witryny Porównaj plany

Panel monitorowania dostępności w Screpy z bieżącym stanem, dostępnością z 30 dni, historią czasu odpowiedzi, ostatnimi kontrolami i incydentami

Skonfiguruj monitoring dostępności

Włącz cykliczne kontrole publicznego URL projektu Screpy. Najpierw wybierz cel istotny dla użytkowników, potem częstotliwość.

Każdy projekt monitoruje jeden URL HTTP lub HTTPS, nie osobną listę endpointów.
Ustawienia projektu kontrolują włączenie, interwał 1–60 minut i opcjonalny adres powiadomień.
Zaplanowane kontrole wymagają aktywnego uprawnionego płatnego planu; domyślne interwały różnią się.
Brak aktywności zespołu wydłuża interwały; po 30 nieaktywnych dniach kontrole ustają.
Ostatnia kontrola wskazuje aktualność; ustawiony interwał nie gwarantuje dokładnego czasu wykonania.

Sprawdź ustawienia projektu

example.com60 s

Zrozum procent dostępności

Zobacz udział udanych kontroli w ostatnich 30 dniach. Czytaj procent razem z liczbą kontroli i ostatnią datą.

Dostępność to udane kontrole podzielone przez wszystkie zapisane kontrole, pomnożone przez 100.
Bieżący status pochodzi z ostatniej zakończonej kontroli w tym okresie.
Brak zapisanych kontroli oznacza niedostępne dane, nie 100% dostępności.
Procent opiera się na próbkach; nie można go bezpośrednio przeliczyć na minuty awarii ani SLA ważone czasem.

Poznaj metodę pomiaru

Dostępność

93,8%

12 wrz503200

Śledź czas odpowiedzi strony

Wykrywaj wolniejsze odpowiedzi i powtarzające się błędy na wykresie. Dostępny URL również może odpowiadać wolno.

Wykres korzysta z maksymalnie 160 ostatnich kontroli z 30 dni; szerokość ekranu określa widoczną część.
Linia trendu uśrednia pięć kontroli; średni czas odpowiedzi wykorzystuje udane kontrole z całych 30 dni.
Czas mierzy opóźnienie HTTP, nie pełne ładowanie, Core Web Vitals ani ścieżkę użytkownika.

Zbadaj ładowanie stron

Czas odpowiedzi

240 ms

Sprawdź statusy HTTP

Przejrzyj osiem ostatnich kontroli ze statusem, datą, kodem HTTP i czasem odpowiedzi. Porównaj je z oczekiwanym zachowaniem publicznego URL.

HTTP 200–399 oznacza dostępność; inne odpowiedzi HTTP niedostępność. Przekroczenie czasu i błąd są osobne.
Przekierowania nie są śledzone: wynik 3xx nie potwierdza działania celu.
Kontrole używają HEAD, ponawiając przez GET przy 405 lub 501; błędy połączenia mogą nie mieć kodu HTTP.
Dostępność nie sprawdza treści, formularzy ani zakupu; strona błędu z HTTP 200 również może być dostępna.

Sprawdź zachowanie URL

Status HTTP

200

GET /HTTP/2 200

Przejrzyj incydenty niedostępności

Śledź incydent od pierwszej nieudanej do późniejszej udanej kontroli. Przyczynę zbadaj osobno.

Pierwszy błąd otwiera incydent, kolejne go aktualizują, pierwsza udana kontrola rozwiązuje.
Panel pokazuje historyczne liczby otwartych i rozwiązanych incydentów oraz pięć ostatnich ze statusem, początkiem i szczegółami.
Daty odzwierciedlają kontrole, nie dokładny początek między próbkami; krótkie awarie mogą pozostać niewykryte.

Przeczytaj poradnik dostępności

Okres

12 min

12 wrz503200

Otrzymuj e-maile o awariach

Wysyłaj kwalifikujące się powiadomienia członkom projektu i na dodatkowy opcjonalny adres. Incydent jest rejestrowany przed spełnieniem warunków e-maila.

Późniejszy błąd tego samego incydentu może uruchomić e-mail dla obsługiwanych kodów, np. 404, 500 lub 503.
Przekroczenia czasu, błędy połączenia i nieobsługiwane kody są zapisywane, ale nie uruchamiają tych e-maili.
Projekt ma osobne limity jednego e-maila o awarii i jednego o przywróceniu działania na 24 godziny.
E-mail o przywróceniu wymaga wcześniej zgłoszonego, niewyciszonego incydentu; zapisana długość nie dowodzi dokładnej przerwy doświadczonej przez użytkowników.

Ustaw adres powiadomień

Projektexample.com

Weryfikacja

Czytaj dostępność przez SEO MCP

Poproś połączonego asystenta AI o wyjaśnienie zapisanych wyników dostępnego projektu. Data odróżnia zapisane dane od nowej kontroli.

SEO MCP zwraca status z 30 dni, procent, średnią udanych kontroli i ostatnią kontrolę.
Do 160 ostatnich rekordów zawiera status, odpowiedź i datę, bez kodów HTTP i incydentów.
Odczyt nie uruchamia kontroli, nie rozpoznaje ani nie naprawia awarii; brakujące wyniki pozostają niedostępne.

Połącz SEO MCP

GET/projectsJSON

{
  "data": [
    { "domain": "example.com" }
  ]
}

Dodaj dostępność do raportów SEO

Udostępniaj dane w zapisanym raporcie dla klienta lub zespołu. Migawka odpowiada na inne pytanie niż monitoring na żywo.

Widget zawiera statystyki 30 dni, ostatnie kontrole i incydenty nakładające się na okres raportu.
Liczba incydentów może różnić się od historycznej liczby w panelu; rozwiązane incydenty mogą zawierać zapisaną długość.
Raport przechwytuje zapisane dane podczas tworzenia i nie wysyła alertów na żywo.

Poznaj raporty SEO

Sekcje

aACMERaportPDF

Wynik kondycji87/100

Pozycja+24

Porozmawiaj o Monitorowanie dostępności. Z SEO MCP.

Odczytaj przez SEO MCP zapisane dane dostępności z 30 dni i ostatnie statusy oraz odpowiedzi. Sprawdź datę przed uznaniem statusu za aktualny; nie zawiera incydentów ani kodów HTTP.

Poznaj Screpy SEO MCP Połącz asystenta AI

Skonfiguruj użyteczną pętlę monitoringu uptime.

Wybierz publiczny cel, włącz monitoring i ustaw odpowiedzialny adres. Przy błędzie zbadaj aktualne rekordy i potwierdź późniejszą udaną kontrolę.

Użyj publicznego adresu URL witryny projektu

Użyj właściwego publicznego URL bez wymogu logowania. Cele przekierowań sprawdzaj osobno, bo kontrole nie śledzą przekierowań.
Włącz kontrole i skonfiguruj interwał

Włącz monitoring w ustawieniach, zapisz interwał i opcjonalny adres; potwierdź uprawniony płatny dostęp i ostatnie kontrole.
Zbadaj ostatnie nieudane kontrole

Czytaj status, ostatnią kontrolę, wyniki HTTP i szczegóły incydentu. Krytyczny błąd zbadaj od razu; procent z 30 dni daje kontekst, nie powód do czekania.
Zbadaj i potwierdź przywrócenie

Porównaj błąd z logami wdrożenia, DNS, TLS, hostingu i aplikacji. Potwierdź udaną kontrolę; rozwiązanie incydentu nie sprawdza każdej ścieżki użytkownika.

Nadaj priorytet witrynom, w których przestój ma realny koszt.

Używaj cyklicznych kontroli dla projektów, w których dostępność wpływa na sprzedaż, leady, kampanie, dostęp klientów lub możliwość pobierania publicznych treści przez crawlery.

Witryny przychodowe

Obejmij cyklicznymi zewnętrznymi kontrolami dostępności sklep, stronę rezerwacji, produkt subskrypcyjny lub witrynę generującą leady.

Zasoby wyszukiwania organicznego

Obserwuj publiczną witrynę, do której muszą dotrzeć crawlery i odwiedzający organiczni, zanim jakość treści lub praca nad pozycjami będzie miała znaczenie.

Witryny premier i kampanii

Śledź witrynę projektu podczas premier, migracji, redesignów i aktywnych kampanii, gdy problem z dostępnością ma natychmiastowy koszt.

Portfele wielu projektów

Sprawdzaj uptime osobno dla każdego projektu Screpy, aby agencje i zespoły wewnętrzne mogły utrzymywać witryny klientów lub marek w jednym procesie.

Poznaj granice wyniku uptime.

Screpy dostarcza zewnętrzne dane HTTP i historię incydentów dla skonfigurowanej witryny projektu. Korzystaj z infrastruktury, logów, testów transakcji i danych wyszukiwania, gdy pytanie wykracza poza ten zakres.

Jeden cel witryny projektu

Uptime Monitoring sprawdza publiczny adres URL skonfigurowany dla projektu Screpy. Nie jest ogólną listą niezależnych monitorów endpointów.

Kontrola zewnętrzna, nie telemetria infrastruktury

Wynik opisuje, czy publiczny cel odpowiedział. Nie sprawdza CPU, pamięci, kontenerów, baz danych, sieci prywatnych ani logów serwera.

Dane incydentu, nie dowód przyczyny

Status HTTP, czas i sygnatury incydentu zawężają analizę, ale nie dowodzą, czy przyczyną był DNS, TLS, hosting, wdrożenie, zapora czy kod aplikacji.

Dostępność nie gwarantuje SEO

Działająca publiczna strona jest potrzebna odwiedzającym i crawlerom, ale sam wysoki procent uptime nie gwarantuje indeksowania, pozycji, ruchu, przychodu ani konwersji.

Użyj procesu kondycji witryny odpowiedniego do awarii.

Monitoruj osiągalność w czasie, audytuj szerszą witrynę, gdy powtarzają się błędne adresy URL lub wzorce crawlu, albo sprawdzaj wydajność strony po ustabilizowaniu dostępności.

Monitorowanie dostępności

Analizuj dostępność z 30 dni opartą na kontrolach, odpowiedzi, wyniki HTTP i incydenty publicznego URL.

Monitoruj uptime witryny

Audyt witryny

Wykonaj crawl szerszej witryny, aby znaleźć powtarzające się błędne strony, problemy przekierowań, niedziałające cele i wzorce techniczne wokół problemu dostępności.

Audytuj witrynę

Monitorowanie PageSpeed

Uruchamiaj cykliczne laboratoryjne kontrole wydajności, gdy witryna jest osiągalna, ale ładowanie lub responsywność nadal wymagają analizy.

Monitoruj PageSpeed

Dokumentacja Screpy

Dowiedz się, jak monitorować uptime witryny

Dowiedz się, jak wybrać publiczny cel, ustawić monitoring i powiadomienia, interpretować odpowiedzi i badać incydenty.

Przeczytaj przewodnik Uptime Monitoring

Odpowiedzi na pytania o monitoring uptime witryny.

Odpowiedzi o próbkowaniu, nieaktywnych projektach, przekierowaniach, brakujących kontrolach, e-mailach i wydajności stron.

Co mierzy Screpy Uptime Monitoring?

Screpy zapisuje status, dostępny kod HTTP, czas odpowiedzi i datę jednego publicznego URL. Panel liczy dostępność i średnie z 30 dni, pokazuje osiem ostatnich kontroli oraz osobno historyczne liczby i pięć ostatnich incydentów.

Jak często Screpy sprawdza uptime witryny?

Ustawienia przyjmują 1–60 minut z płatnym dostępem. W ciągu dnia od aktywności zespołu obowiązuje ten interwał. Później co najmniej 10 minut, po siedmiu dniach co najmniej 60. Po 30 nieaktywnych dniach kontrole ustają. Sprawdzaj rzeczywistą datę ostatniej kontroli.

Jak działają incydenty niedostępności i odzyskiwanie?

Pierwszy błąd otwiera incydent, kolejne utrzymują go otwartego, udana kontrola rozwiązuje. Panel pokazuje status, początek i szczegóły; kwalifikujące się e-maile przywrócenia zawierają zapisaną długość. Próbki nie wskazują dokładnego początku ani każdej krótkiej awarii.

Czy przestój witryny może wpływać na crawl lub indeksację?

Utrzymujące się błędy serwera mogą spowolnić indeksującego robota i uniemożliwić pobranie treści. Dostępny wynik nie dowodzi dostępu Googlebota, celu przekierowania, indeksacji ani pozycji. Zbadaj również dane crawlowania i wyszukiwania.

Czy Screpy wysyła alerty o przestoju?

Późniejszy błąd w otwartym incydencie może wysłać e-mail dla 404, 410, 500, 501, 502, 503, 504, 505, 507, 508, 525 lub 526. Odbiorcami są członkowie i dodatkowy odrębny adres. Awaria i przywrócenie mają osobne limity jednego e-maila na projekt na 24 godziny. Wyciszony incydent nie jest zgłaszany później; przywrócenie wymaga wcześniejszego niewyciszonego powiadomienia o awarii. Przekroczenia czasu, błędy bez kodu i inne kody nie kwalifikują się.

Co Screpy uznaje za działanie lub niedostępność?

HTTP 200–399 oznacza dostępność, inne odpowiedzi HTTP niedostępność; przekroczenie czasu i błąd są osobnymi stanami. Przekierowania nie są śledzone, a treść nie jest sprawdzana. Przekierowanie lub strona błędu HTTP 200 może być dostępna bez potwierdzenia właściwej strony.

Czy Uptime Monitoring pokazuje historię czasu odpowiedzi?

Tak. Wykres ładuje do 160 ostatnich odpowiedzi z 30 dni, mniej widocznych na małych ekranach. Trend pięciu kontroli różni się od średniej udanych kontroli z 30 dni. Odpowiedź HTTP nie mierzy renderowania ani interakcji.

Czy monitoring uptime zastępuje monitoring serwera lub transakcji?

Nie. Screpy sprawdza publiczny cel HTTP(S), bez badania prywatnej infrastruktury, logowania, zakupów, treści, dostępności geograficznej ani diagnozowania przyczyn. Użyj logów i specjalnych kontroli.

Mocne SEO. Lżejsze dla portfela.

Kompleksowy zestaw narzędzi SEO w naprawdę przystępnej cenie.

Audyty techniczne, śledzenie pozycji i widoczność w AI
Badanie słów kluczowych, analiza backlinków i monitoring dostępności
Jedna przestrzeń pracy. Elastyczne plany. Mniej wydatków.

Plany i ceny Tanie narzędzie SEO

Więcej pieniędzy w Twojej kieszeni