Robię SEO od kilku lat; pracuję w agencji z portfelem kilkudziesięciu klientów. Sklepy, strony firmowe, kilka serwisów contentowych, parę stron na WordPressie, które ktoś kiedyś zrobił i nikt nie wie kto. I przez długi czas mój proces „monitorowania" wyglądał tak: raz na jakiś czas wchodziłem na stronę klienta, sprawdzałem czy wszystko jest z nią w porządku, przepuszczałem przez narzędzia SEO i wracałem do linkowania.

Problem w tym, że w SEO awaria nie kosztuje godziny. Kosztuje tygodnie. Strona leżąca w nocy przez trzy godziny to jedno. Ale noindex wrzucony przez dewelopera przy wdrożeniu i niezauważony przez trzy tygodnie to zjazd, z którego wychodzi się miesiącami - i rozmowa z klientem, gdzie to my jesteśmy tą stroną, która „nie zauważyła" problemu.

Dlatego opiszę, jak dziś mam to poukładane w aplikacji Uptime Monitor, i które funkcje realnie zmieniły mi pracę. Bez marketingowego lania wody - tak, jak tego używam.

Po pierwsze: dostępność, ale sensownie

Podstawa jest nudna i tak ma być. Każda strona klienta ma monitor HTTP/HTTPS sprawdzany co minutę (interwał ustawiasz sam, od 1 minuty do 12 godzin - dla wizytówki, którą sprawdzam raz dziennie, nie ma sensu palić limitów).

Co jest ważne z perspektywy agencji:

  • Alerty idą tam, gdzie faktycznie patrzę. E-mail, powiadomienia push w przeglądarce i powiadomienia na telefon przez ntfy. Ja mam włączone push na desktopie w godzinach pracy i ntfy na telefonie - awaria o 23:00 dociera do mnie zanim klient rano napisze.
  • Alerty ustawiam per monitor. Dla sklepu chcę wiedzieć o wszystkim. Dla bloga firmowego, który leży raz na kwartał na 40 sekund, wystarczy mi sam raport.
  • Godziny w mailach są w mojej strefie czasowej, więc „Niedostępna od 02:14" znaczy 02:14 u mnie, a nie w UTC. Drobiazg, ale przy raportowaniu klientowi to różnica.
  • Pauza monitora. Klient robi migrację hostingu w sobotę? Wstrzymuję monitor, okno przerwy zapisuje się w historii i nie psuje statystyki uptime. Nie muszę potem tłumaczyć w raporcie, skąd 97%.

Do tego jest strona „Wymaga uwagi" - wchodzę rano, widzę na jednym ekranie co leży, co wróciło i któremu klientowi za chwilę wygaśnie certyfikat. To zastąpiło mi arkusz w Excelu.

Cztery typy monitorów i po co SEO-wcowi trzy z nich

Na start dodaje się monitor HTTP i to wystarcza w 80% przypadków. Ale pozostałe typy rozwiązują dokładnie te awarie, których nie widać „na oko", bo strona się otwiera.

Typ Co robi Kiedy tego używam
HTTP/HTTPS Pobiera adres i ocenia odpowiedź Każda strona klienta, domyślnie
Port (TCP) Otwiera połączenie do host:port Serwery, które budzą się wolno, poczta, panele
DNS Pyta resolver o rekord i porównuje z oczekiwaną wartością Po każdej migracji, przy domenach klienta
API (JSON) Porównuje kształt odpowiedzi z zapisanym wzorcem Sklepy i serwisy, gdzie front żywi się API

Jest jeszcze jedna opcja, o której warto wiedzieć: monitor odwrócony, czyli „ten adres ma być niedostępny". Trzymam tak stagingi klientów zamknięte na IP. Jeśli ktoś zdejmie blokadę i staging zacznie odpowiadać publicznie, dostaję alert - zanim Google zdąży zaindeksować kopię serwisu.

Certyfikat SSL, czyli awaria z kalendarza

Certyfikat wygasa zawsze w piątek wieczorem albo w wigilię. Włączam monitoring certyfikatu i dostaję ostrzeżenia na 30, 14 i 7 dni przed wygaśnięciem. Błąd certyfikatu oznacza stronę jako niedostępną, więc jak coś się posypie z odnawianiem Let's Encrypt, wiem o tym od razu.

Trzydzieści dni to jest dokładnie tyle, ile potrzeba, żeby napisać do klienta, przypomnieć klientowi, przypomnieć klientowi jeszcze raz i w końcu dogadać się z jego hostingiem.

Monitoring treści, czyli „strona działa" to za mało

Tu zaczyna się rzecz, która dla SEO jest ważniejsza niż samo uptime. Serwer może odpowiadać kodem 200 i mieć na stronie komunikat o błędzie bazy danych. Dla monitoringu dostępności - wszystko gra. Dla Google - też, i to jest właśnie problem.

W monitorze treści podaję do pięciu fraz i wybieram tryb:

  • musi zawierać - np. nazwa firmy w stopce albo tekst przycisku „Dodaj do koszyka". Jak fraza znika, strona się nie wyrenderowała jak trzeba.
  • nie może zawierać - np. „Error establishing a database connection", „Fatal error", „Strona w budowie". Klasyk po nieudanej aktualizacji wtyczek.

U jednego klienta mam wpisaną frazę z sekcji generowanej przez skrypt zewnętrznego dostawcy. Jak dostawca leży, jego sekcja znika, a strona wygląda normalnie - poza tym, że nie ma na niej połowy oferty.

Tym co mi się w tym monitorze super podoba jest to, że na jeden monitor (określony adres URL) mogę wprowadzić do pięciu różnych fraz, które są dla mnie istotne i które powinny występować u klienta na stronie pod kątem pozycjonowania. Jeśli klient przez pomyłkę lub celowo usunie te frazy ze strony, Uptime Monitor mnie o tym poinformuje.

Kondycja strony, czyli funkcja, dla której to wszystko robię

To jest moduł, przez który przestałem traktować to narzędzie jako „coś dla adminów". Raz dziennie strona przechodzi audyt, a wynik jest porównywany z poprzednim. Kategorie: dostępność, bezpieczeństwo, SEO, dobre praktyki i wydajność (Core Web Vitals z danych CrUX od Google, czyli realne pomiary użytkowników Chrome).

To nie jest narzędzie, które zastąpi dedykowane rozwiązania jak np. PageSpeed Insights, Lighthouse czy inne tego typu, bo ta aplikacja nie do tego służy. Zadaniem tego narzędzia jest monitoring kondycji strony pod kątem wyłapywania regresji.

Z listy sprawdzeń SEO-wca interesuje przede wszystkim:

  • indeksowanie - czy strona nie ma noindex w meta robots albo w nagłówku X-Robots-Tag,
  • tytuł i meta description - czy istnieją i czy mają sensowną długość,
  • adres kanoniczny,
  • dokładnie jeden H1,
  • atrybut lang,
  • mixed content - zasoby po HTTP na stronie HTTPS,
  • łańcuch przekierowań - czy do strony nie prowadzą dwa skoki zamiast jednego,
  • meta viewport, dane strukturalne i Open Graph, alty i wymiary obrazków.

Do tego bezpieczeństwo (HSTS, CSP, X-Frame-Options, flagi cookies, wyciek wersji oprogramowania) - to akurat rzadziej mój dział, ale świetnie się tym argumentuje przy rozmowie o budżecie na „porządki techniczne".

Najlepsze jest jednak wykrywanie regresji. System nie pokazuje mi listy „100 rzeczy do poprawy" jak większość audytorów. Historia to dziennik zmian: wpis powstaje wtedy, kiedy coś się zepsuło, naprawiło albo zmieniło (plus wpis kontrolny co 7 dni, żebym wiedział, że nadal patrzymy). Jak dostaję alert „kondycja się pogorszyła", to wiem, że coś realnie się zmieniło od wczoraj.

Przy każdej regresji dostaję jeszcze kontekst: co jeszcze zmieniło się w tym samym oknie czasowym - czy zmieniła się treść strony, czy zniknęły nagłówki, czy zmienił się serwer, o ile urósł HTML, czy doszło przekierowanie. To jest dokładnie ten zestaw informacji, który pozwala napisać do dewelopera „wdrożyliście coś 12 marca około 14:00 i wtedy wleciał noindex" zamiast „coś się popsuło, sprawdźcie".

Osobno liczony jest wynik samej strony (bez CrUX), bo Core Web Vitals potrafią się ruszyć bez żadnej zmiany po naszej stronie - i to właśnie ten „czysty" wynik wyzwala alerty regresji. Sensowna decyzja, bo inaczej dostawałbym alerty o cudzych fluktuacjach.

Jest też TTFB mierzony co minutę, z medianą i P95 dzień po dniu. Nie „test z jednego kliknięcia", tylko baseline, do którego porównywane są ostatnie dni.

Cztery sytuacje z ostatnich miesięcy

1. noindex po wdrożeniu

Klient (sklep, ok. 4 tys. podstron) robił redesign u zewnętrznego dewelopera. Wdrożenie w czwartek wieczorem, w piątek rano mam alert o pogorszeniu kondycji: sprawdzenie „Indeksowanie w wyszukiwarkach" zmieniło status na błąd. Deweloper wypchnął na produkcję konfigurację ze stagingu razem z noindex.

Zgłosiłem to o 9:15, poprawione przed 11:00. Bez tego alertu dowiedziałbym się przy najbliższym audycie albo - realnie - dwa tygodnie później ze spadku wyświetleń w Search Console. Przy tej skali to jest różnica między „nie zdążyło zaboleć" a kwartałem odbudowy.

2. Wtyczka, która zjadła serwer

Strona contentowa, ruch głównie z bloga. Nic nie leżało, nikt nie zgłaszał problemów. Ale wykres TTFB pokazał, że mediana odpowiedzi serwera skoczyła z ok. 300 ms do ponad 1,2 s i tak zostało. Data zmiany zgadzała się z instalacją wtyczki do „optymalizacji" (ironia zamierzona) przez osobę z firmy klienta.

Miałem konkretny wykres i konkretną datę. Rozmowa z klientem trwała pięć minut zamiast dwóch tygodni ustalania, czy to „nam się wydaje, że wolniej".

3. Hosting, który leżał tylko w nocy

Mały klient upierał się przy swoim hostingu za 90 zł rocznie. Ja twierdziłem, że serwer jest przeciążony, on twierdził, że „u niego zawsze działa". I miał rację - działało zawsze, kiedy sprawdzał, czyli w dzień.

Monitor co minutę pokazał regularne przerwy między 2:00 a 4:00 w nocy, po kilka-kilkanaście minut, prawie codziennie. Uptime w miesiącu: 98,6%. Pokazałem historię zdarzeń z ostatnich 90 dni, klient przeniósł się na przyzwoity hosting w ciągu tygodnia. Google crawluje w nocy równie chętnie jak w dzień.

4. Klient usunął frazy, na które strona była pozycjonowana

Klient z branży usług remontowych, strona z kilkoma landing page'ami. Nowa osoba od marketingu po stronie klienta uznała, że teksty „brzmią sztucznie" i przepisała część z nich w weekend. Nie zostaliśmy o tym powiadomieni, bo przecież to tylko zmiana treści.

W praniu zniknęły frazy, na których stała cała widoczność tych podstron, a title strony głównej zmienił się z konkretnego na nazwę firmy i slogan.

Wiedziałem o tym w poniedziałek rano z dwóch stron naraz. Monitor treści na trzech landing page'ach zgłosił błąd, bo frazy ustawione w trybie „musi zawierać" po prostu przestały występować na stronie. Do tego audyt kondycji pokazał w dzienniku zmian, że zmieniła się treść strony, a sprawdzenie „Tytuł strony" zmieniło status.

Napisałem do klienta w poniedziałek z listą konkretnych podstron i tym, co dokładnie zniknęło. Wróciliśmy do poprzednich wersji tekstów w środę, dopisując przy okazji te frazy w sposób, który zadowolił obie strony. Rankingi nie zdążyły się ruszyć.

Bez monitoringu treści zobaczyłbym to dopiero przy comiesięcznym raporcie widoczności, czyli po jakichś pięciu tygodniach - kiedy tłumaczenie „ktoś przepisał teksty" brzmi już jak szukanie wymówki.

Jak to układam przy kilkudziesięciu stronach

Kilka rzeczy, które ratują mnie organizacyjnie:

  • Projekty. Grupuję monitory po kliencie. Sklep ma stronę główną, kartę produktu, koszyk, API i rekordy DNS w jednym projekcie - widzę całego klienta na jednym ekranie.
  • Dodawanie wielu adresów naraz. Wchodząc w nowego klienta wrzucam od razu kilkanaście URL-i (strona główna, kluczowe kategorie, najważniejsze landing page'e) zamiast klikać każdy osobno.
  • Zespół i udostępnianie. Członkom zespołu udostępniam wybrane monitory. Junior prowadzący klienta widzi statusy i ustawia sobie własne alerty, ale nie skasuje mi monitora. Jak trzeba, nadaję uprawnienie edytora - wtedy może zmienić ustawienia udostępnionego monitora, ale nadal nie doda ani nie usunie żadnego.
  • Publiczne strony statusów. To jest ten element, którego nie doceniałem, a klienci go uwielbiają. Tworzę stronę z wybranymi serwisami klienta i wysyłam mu link. Opcjonalnie zabezpieczam ją hasłem. Klient sam sobie sprawdza, czy jego strona działa, zamiast pisać do mnie. A przy okazji widzi, że ktoś tego pilnuje - co jest zaskakująco dobrym argumentem przy przedłużaniu umowy.

Co bym poradził komuś, kto zaczyna

Nie zaczynaj od wszystkiego. Mój sensowny minimum dla nowego klienta wygląda tak:

  1. Monitor HTTP na stronę główną, co 1-5 minut, alert dostępności na e-mail i telefon.
  2. Monitoring certyfikatu SSL z alertem na 30/14/7 dni.
  3. Monitoring kondycji strony z alertem o regresji - to jest ta jedna rzecz, która broni ruchu organicznego.
  4. Monitory DNS na rekordy A i MX, szczególnie jeśli klient ma dostęp do panelu domeny (a zawsze ma).
  5. Monitor treści z frazą, która musi być na stronie - najlepiej z sekcji, która renderuje się dynamicznie.
  6. Publiczna strona statusów dla klienta, link w mailu powitalnym.

To jest kwadrans roboty na klienta. W zamian przestajesz być osobą, która dowiaduje się o awarii z maila klienta - i zaczynasz być tą, która pisze pierwsza.

A z mojego doświadczenia: to jedna z najtańszych rzeczy, jakie możesz zrobić dla retencji klientów w agencji.