Czym jest keyword monitoring?

Monitor pobiera body odpowiedzi i sprawdza czy konkretny string pojawia się (tryb present) lub nie pojawia się (tryb absent). Użyj do wykrywania kiedy strona zmieniła treść, pojawił się komunikat błędu lub został usunięty konkretny element.

Czy mogę używać HTML czy tylko plain text?

Oba. Wyszukiwanie to substring match na raw response body. Możesz dopasować plain text ("Dodaj do koszyka"), fragmenty HTML (<button class="buy">) lub konkretne atrybuty. Wszystko co pojawia się dosłownie w źródle HTML można dopasować.

Czym to się różni od narzędzia content-diff?

Narzędzia diff porównują z baseline i raportują każdą zmianę. Keyword monitoring to ukierunkowana asercja — określasz co MUSI tam być (lub NIE MOŻE). Diff jest hałaśliwy na dynamicznych stronach; keyword jest precyzyjny co do tego co ma znaczenie.

Czy mogę sprawdzić że komunikat błędu NIE jest na stronie?

Tak — użyj trybu "absent" z keyword jak "Internal Server Error" lub "Wystąpił błąd". Monitor zawodzi gdy tekst błędu się pojawia. Przydatne do łapania błędów 500 które zwracają HTTP 200 ze stroną błędu (powszechna błędna konfiguracja frameworków).

Czy keyword monitoring działa na stronach renderowanych przez JavaScript?

Domyślnie nie — monitor pobiera surowy HTML przed wykonaniem JS. Dla SPA lub stron heavy-JS keyword musi pojawić się w początkowej odpowiedzi HTML (np. server-rendered lub w bloku <noscript>). Checki rendowane przez przeglądarkę to osobna funkcja.

Monitoring słów kluczowych

HTTP 200 nie znaczy że strona działa. Monitoring słów kluczowych łapie sytuacje gdy serwer mówi OK, a treść jest popsuta.

Problem "200 OK ale popsute"

Każde narzędzie do uptime potrafi powiedzieć, czy serwer zwrócił kod HTTP 2xx. Ten sygnał wygląda uspokajająco, ale kłamie częściej, niż myślisz. Strona główna może wyrenderować pustą białą stronę i wciąż zwracać 200. Strona koszyka może po cichu zgubić przycisk "Kup teraz" po deploy'u i nigdy nie rzucić błędu. WordPress potrafi zastąpić treść komunikatem "Błąd połączenia z bazą danych" - oczywiście wyrenderowanym jako 200 OK z prawdziwym HTML-em.

Monitoring słów kluczowych łata tę martwą strefę. Mówisz monitorowi, co strona powinna zawierać - lub czego nie powinna - a przy każdym sprawdzeniu w treści odpowiedzi szukane jest to wyrażenie. Jeśli słowa brak (gdy powinno być) lub jest (gdy nie powinno), monitor zgłasza awarię, mimo że HTTP-owo wszystko wygląda OK.

Jakie ciągi monitorować

Dobre słowo kluczowe to coś, co potwierdza poprawne wyrenderowanie kluczowej części strony. Kilka przykładów:

Strona główna ecommerce: monitoruj "Dodaj do koszyka" lub nazwę najpopularniejszego produktu. Jeśli feed katalogu się zepsuł, słowo znika - i wiesz.
Strona logowania: monitoruj "Zaloguj się" lub "Odzyskaj hasło". JS error wymazujący formularz - i słowa nie ma.
Blog lub portal: monitoruj tytuł najnowszego artykułu. Jeśli CMS zaczął pokazywać wczorajszą treść, słowo się nie zgadza.
Strona z cenami: monitoruj string ceny. Deploy gubiący blok cen widać natychmiast.
Endpoint statusu / health: monitoruj "ok" lub "healthy". Jeśli upstream padł, endpoint zwraca "degraded" - słowo nie matchuje.

Można też użyć trybu nieobecności - alert, gdy pojawi się ciąg, którego nie powinno być. Typowe: "Database connection error", "Whoops! Something went wrong", "Tryb konserwacji", "Fatal error", "Wkrótce". Jeśli któryś z nich wycieka na produkcję, dostajesz alert.

Jak działa sprawdzenie

Monitor wykonuje normalne żądanie HTTP(S) GET (lub dowolną metodę - POST, PUT, itd.), podąża za maks. 5 przekierowaniami, pobiera body odpowiedzi i skanuje je case-insensitive na obecność słowa. Wynik dopasowania zapisany jest obok kodu HTTP, czasu odpowiedzi i SSL. Jeśli warunek nie jest spełniony 2 razy z rzędu (domyślny próg potwierdzenia), otwierany jest incydent i wysyłane powiadomienia przez włączone kanały - Email, Telegram, Slack, Discord i SMS.

Dla treści dynamicznej (SPA) gdzie słowo pojawia się dopiero po wykonaniu JavaScript, użyj funkcji premium multi-location, która korzysta z prawdziwej headless przeglądarki przez ScrapingBee.

Łącz z HTTP i SSL

Pojedynczy monitor słowa kluczowego w DiagnoSEO Uptime Monitoring uruchamia również pełne sprawdzenie strony: kod HTTP, czas odpowiedzi, SSL, wygaśnięcie domeny, rekordy DNS i wykrywanie hostingu. Jeden monitor chroni Cię więc przed pełnym spektrum - awarie serwera, wygasanie certyfikatu, podmiany DNS i ciche awarie treści.

Jak skonfigurować

Otwórz narzędzie, kliknij "Dodaj monitor", wybierz typ "Słowo kluczowe", wklej URL, wpisz słowo, wybierz "musi być obecne" lub "musi być nieobecne", ustaw interwał (1-30 minut zależnie od planu) i zapisz. Od następnego cyklu monitor pilnuje tej strony i alarmuje, jeśli słowo zniknie - nawet gdy wszystkie inne sygnały mówią, że strona działa.

Najczęściej zadawane pytania

Czym jest keyword monitoring?
Monitor pobiera body odpowiedzi i sprawdza czy konkretny string pojawia się (tryb present) lub nie pojawia się (tryb absent). Użyj do wykrywania kiedy strona zmieniła treść, pojawił się komunikat błędu lub został usunięty konkretny element.
Czy mogę używać HTML czy tylko plain text?
Oba. Wyszukiwanie to substring match na raw response body. Możesz dopasować plain text ("Dodaj do koszyka"), fragmenty HTML (<button class="buy">) lub konkretne atrybuty. Wszystko co pojawia się dosłownie w źródle HTML można dopasować.
Czym to się różni od narzędzia content-diff?
Narzędzia diff porównują z baseline i raportują każdą zmianę. Keyword monitoring to ukierunkowana asercja — określasz co MUSI tam być (lub NIE MOŻE). Diff jest hałaśliwy na dynamicznych stronach; keyword jest precyzyjny co do tego co ma znaczenie.
Czy mogę sprawdzić że komunikat błędu NIE jest na stronie?
Tak — użyj trybu "absent" z keyword jak "Internal Server Error" lub "Wystąpił błąd". Monitor zawodzi gdy tekst błędu się pojawia. Przydatne do łapania błędów 500 które zwracają HTTP 200 ze stroną błędu (powszechna błędna konfiguracja frameworków).
Czy keyword monitoring działa na stronach renderowanych przez JavaScript?
Domyślnie nie — monitor pobiera surowy HTML przed wykonaniem JS. Dla SPA lub stron heavy-JS keyword musi pojawić się w początkowej odpowiedzi HTML (np. server-rendered lub w bloku <noscript>). Checki rendowane przez przeglądarkę to osobna funkcja.