Większość awarii SEO nie wygląda jak awaria. Serwis działa, sprzedaż jeszcze nie spada, a w tle Googlebot od kilku dni dostaje noindex na kategoriach albo trafia na łańcuch przekierowań po wdrożeniu nowego szablonu. Ruch zaczyna topnieć dopiero po tygodniu lub dwóch, a raport kwartalny pokazuje problem, gdy jego koszt jest już policzalny w tysiącach złotych. Dobrze ustawione alerty SEO skracają ten czas z tygodni do godzin. W tym tekście opisujemy, co monitorować codziennie, jakie progi przyjąć, żeby powiadomienia nie zamieniły się w szum, i jak sprawdzić, że cały system w ogóle działa.
Sześć awarii, które zdarzają się najczęściej
Z doświadczeń agencji i zespołów in-house wyłania się dość powtarzalna lista. Zanim zaczniesz konfigurować narzędzia, warto wiedzieć, czego szukasz, bo każdy z tych problemów wymaga innego sygnału.
- Blokada w robots.txt przeniesiona ze środowiska testowego na produkcję (klasyczne
Disallow: /). - Masowy noindex, zwykle po aktualizacji wtyczki SEO lub zmianie ustawień szablonu.
- Błędy 5xx pod obciążeniem albo po migracji serwera.
- Zepsute przekierowania: pętle, łańcuchy, 302 zamiast 301, przekierowania na stronę główną.
- Zmiana tagów canonical wskazująca na złą wersję adresu (np. z parametrem lub na środowisko stagingowe).
- Zniknięcie treści: pusty szablon kategorii, usunięty blok z opisem, renderowanie wyłącznie po stronie klienta.
Wspólny mianownik jest prosty: wszystkie te błędy powstają w jednym momencie (wdrożenie, aktualizacja, migracja), a ich skutki narastają powoli. Właśnie dlatego monitoring musi patrzeć na stan techniczny, a nie tylko na ruch, który reaguje z opóźnieniem.
Monitoring pliku robots.txt i znaczników noindex
Robots.txt to najtańszy do monitorowania element serwisu. Wystarczy raz na godzinę pobrać plik, porównać go z zapisaną wersją wzorcową i wysłać alert przy każdej różnicy. Nie ma tu sensu ustawiać progów: każda zmiana w tym pliku powinna być zauważona przez człowieka, nawet jeśli okaże się zamierzona. Szczegóły interpretacji reguł opisuje dokumentacja Google Search Central, warto ją mieć pod ręką przy analizie zmian.
Ze znacznikami noindex jest trudniej, bo siedzą w kodzie HTML lub w nagłówku X-Robots-Tag każdej podstrony. Praktyczne rozwiązanie to próbka kontrolna: lista 30–50 adresów reprezentujących każdy typ strony (strona główna, kategorie, produkty, wpisy, strony filtrów, które mają być indeksowane). Skrypt lub narzędzie typu crawler sprawdza je codziennie i zgłasza każdy adres, na którym pojawił się noindex albo zmienił się canonical. Próbka powinna obejmować też te strony, które celowo mają noindex, żeby wychwycić odwrotny błąd.
Kontrola kodów odpowiedzi i przekierowań
Na tej samej próbce warto mierzyć kody HTTP. Każda strona z listy kontrolnej powinna zwracać 200, a każde zapisane przekierowanie (np. stare adresy po migracji) powinno kończyć się jednym skokiem 301 do docelowego adresu z kodem 200. Alert powinien uruchamiać się, gdy:
- dowolny adres z próbki zwraca 5xx dwa razy z rzędu w odstępie kilku minut (pojedynczy błąd bywa przypadkowy);
- adres, który zwracał 200, zaczyna zwracać 404 lub 410;
- przekierowanie wydłuża się do dwóch lub więcej skoków albo zmienia typ z 301 na 302;
- czas odpowiedzi serwera przekracza dwukrotność mediany z ostatnich siedmiu dni.
Uzupełnieniem jest analiza logów serwera. Jeśli udział odpowiedzi 5xx dla Googlebota przekroczy 1–2% w skali doby, to sygnał, że robot może ograniczyć tempo crawlowania, nawet jeśli użytkownicy niczego nie zauważają.
Nagłe zmiany liczby zaindeksowanych stron
Raport indeksowania w Search Console aktualizuje się z opóźnieniem, więc nie nadaje się do alertów godzinowych, ale świetnie sprawdza się jako sygnał dzienny. Najwygodniej pobierać dane przez API i zapisywać je w hurtowni; opisywaliśmy to w tekście o tym, jak działa masowy eksport Search Console do BigQuery, gdzie jedno zapytanie SQL wystarczy, żeby porównać liczbę stron z wyświetleniami dzień do dnia.
Warto śledzić trzy wskaźniki: liczbę adresów z co najmniej jednym wyświetleniem, liczbę zaindeksowanych stron w raporcie stron oraz liczbę adresów w mapie witryny. Rozjazd między mapą witryny a indeksem, który rośnie przez kilka dni, często wskazuje na problem z jakością lub duplikacją, zanim pojawi się on w ruchu. Dane z tego monitoringu przydają się też przy okresowym audycie; dobrze uzupełniają je punkty z naszej checklisty kwartalnego przeglądu Search Console.
Progi alertów, które nie generują szumu
Najczęstszy powód, dla którego monitoring przestaje działać, to nie awaria narzędzia, tylko zmęczenie alertami. Zespół dostaje dwadzieścia powiadomień tygodniowo, z czego dziewiętnaście jest nieistotnych, więc po miesiącu nikt ich nie czyta. Dlatego progi warto dzielić na trzy poziomy.
| Sygnał | Próg krytyczny (natychmiast) | Próg ostrzegawczy (raport dzienny) |
|---|---|---|
| robots.txt | dowolna zmiana reguł Disallow | zmiana komentarzy lub adresu sitemap |
| noindex / canonical | zmiana na stronie głównej lub kategorii | zmiana na pojedynczym wpisie |
| Kody 5xx | 2 kolejne błędy na próbce | powyżej 1% odpowiedzi dla Googlebota w dobie |
| Kliknięcia z Google | spadek o 40% dzień do dnia przy co najmniej 500 kliknięciach dziennie | spadek o 20% tydzień do tygodnia |
| Strony z wyświetleniami | spadek o 30% w ciągu 3 dni | spadek o 10% w ciągu 7 dni |
Dwie zasady pomagają utrzymać sensowny poziom szumu. Po pierwsze, porównuj dane z tym samym dniem tygodnia, bo ruch w niedzielę i w poniedziałek różni się naturalnie o kilkadziesiąt procent. Po drugie, ustaw minimalny wolumen: spadek z 12 do 6 kliknięć to 50%, ale statystycznie nie znaczy nic. Dla małych serwisów lepiej sprawdzają się progi tygodniowe niż dzienne.
Kanały powiadomień i dyżur
Alert krytyczny musi trafić do osoby, która może zareagować, a nie do skrzynki, którą ktoś przegląda raz w tygodniu. W praktyce sprawdza się podział: powiadomienia krytyczne na dedykowany kanał Slacka lub Teams z oznaczeniem dyżurnego, ostrzeżenia w zbiorczym raporcie dziennym wysyłanym mailem. Takie raporty można zbudować bez programisty, podobnie jak inne automatyzacje oparte na arkuszu Google i narzędziach typu Make, które opisujemy przy okazji tematu stron programmatic z arkusza Google.
Każdy alert powinien zawierać trzy informacje: co się zmieniło, kiedy zaczęło się dziać i link do miejsca, w którym można to zweryfikować. Komunikat w stylu „spadek ruchu” bez kontekstu zmusza dyżurnego do kwadransa śledztwa, zanim w ogóle oceni, czy problem jest realny. Warto też ustalić, kto odpowiada za alerty z poszczególnych obszarów, bo zablokowany feed produktowy to zwykle sprawa zespołu e-commerce, a nie SEO; przykłady takich problemów pokazujemy w tekście o tym, kiedy wymagane są GTIN, MPN i marka w feedzie.
Test alertów: jak sprawdzić, że działają
Monitoring, którego nikt nie testował, jest tylko założeniem. Raz na kwartał warto przeprowadzić kontrolowany test na środowisku stagingowym lub na jednym, mało ważnym adresie z próbki:
- Dodaj noindex do testowej podstrony i sprawdź, po ilu godzinach przyszło powiadomienie.
- Zmień przekierowanie 301 na 302 i zweryfikuj, czy alert trafił na właściwy kanał.
- Wyłącz na chwilę mapę witryny (zwrot 404) i potwierdź, że sygnał pojawił się w raporcie dziennym.
- Zapisz czas wykrycia każdego testu i porównaj go z poprzednim kwartałem.
Jeśli któryś test przeszedł bez echa, to dokładnie ta luka, przez którą przejdzie prawdziwa awaria. Dobrym punktem odniesienia jest historia z naszego case study o alertach spadków pozycji, w którym czas reakcji skrócił się z trzech tygodni do dwóch dni głównie dzięki temu, że zespół regularnie sprawdzał, czy powiadomienia dochodzą.
FAQ
Jakie narzędzia wystarczą do podstawowych alertów SEO?
Na start wystarczą Search Console z powiadomieniami e-mail, prosty monitoring dostępności (np. UptimeRobot) oraz zaplanowany crawl próbki adresów w narzędziu typu Screaming Frog lub Sitebulb. Bardziej zaawansowane zespoły dokładają eksport danych do BigQuery i własne reguły w SQL.
Jak często sprawdzać robots.txt?
Co godzinę to rozsądny kompromis. Plik jest mały, więc częste pobieranie nie obciąża serwera, a przypadkowa blokada wykryta po godzinie zwykle nie zdąży wpłynąć na indeksowanie.
Dlaczego alert o spadku ruchu nie wystarczy?
Ruch reaguje na błędy techniczne z opóźnieniem kilku dni lub tygodni. Alert oparty wyłącznie na kliknięciach informuje o problemie, gdy szkody już powstały, dlatego trzeba go uzupełnić monitoringiem robots.txt, noindex i kodów odpowiedzi.
Ile adresów powinna mieć próbka kontrolna?
Zwykle 30–50 adresów wystarcza, pod warunkiem że obejmują każdy typ szablonu w serwisie. Ważniejsza od liczby jest reprezentatywność: jeden adres z każdego typu strony wychwyci błąd szablonu szybciej niż sto adresów tego samego typu.
Co zrobić, gdy alertów jest za dużo?
Przenieś mniej istotne sygnały do raportu dziennego, dodaj minimalny wolumen dla alertów ruchowych i porównuj dane z tym samym dniem tygodnia. Jeśli alert przez miesiąc ani razu nie prowadził do działania, warto podnieść próg albo go usunąć.