Czego SEO techniczne może nauczyć się od SRE: monitoring, alerty i postmortemy

Przypadkowy noindex, pusta mapa witryny albo JavaScript, który przestał renderować treść, to awarie SEO, nawet gdy serwer odpowiada kodem 200. Ustal SLI i SLO dla 5 do 10 najważniejszych szablonów, rozdziel alerty pilne od zadań i po każdym incydencie spisz postmortem z właścicielem działań. Statusy HTTP sprawdzisz zaraz po wdrożeniu, a ruch i konwersje dopiero w porównaniu z okresem sprzed zmiany.

Strona jako usługa dla kilku odbiorców

SRE łączy tworzenie oprogramowania z utrzymaniem systemów. Zespół mierzy między innymi dostępność, opóźnienia, skuteczność zmian i reakcję na awarie (Google SRE, 2026). W SEO technicznym oznacza to, że strona musi być stale dostępna dla kilku grup:

• użytkownika,
• robota wyszukiwarki,
• systemów analitycznych,
• narzędzi generatywnej wyszukiwarki,
• zespołu marketingu i sprzedaży.

Awaria rzadko wygląda jak czarny ekran. Serwer może zwracać kod 500, jednak równie groźny bywa przypadkowy noindex, błędny robots.txt, pusta mapa witryny, masowe przekierowania albo JavaScript, który przestał renderować główną treść. Z perspektywy SEO awarią jest każda zmiana, która odcina robota albo użytkownika od treści, nawet gdy serwer działa bez zarzutu.

Porada projektseo.pl: Spisz ścieżki krytyczne. W sklepie będą to wejście na kategorię, karta produktu, wyszukiwarka wewnętrzna, koszyk i płatność. Każda ścieżka dostaje właściciela, sposób pomiaru i procedurę sprawdzenia po wdrożeniu.

SLI, SLO i budżet błędów w praktyce SEO

SLI to konkretny pomiar, na przykład odsetek adresów kanonicznych zwracających kod 200. SLO to cel dla tego pomiaru. SLA jest formalnym zobowiązaniem i pojawia się raczej w umowie z hostingiem lub agencją. Zespół SEO na co dzień pracuje na dwóch pierwszych.

Z celu wynika budżet błędów. Przy dostępności 99,9% dopuszczasz 0,1% niedostępności w przyjętym okresie (Google SRE, 2026). W SEO budżet obejmuje akceptowalną liczbę błędnych odpowiedzi, złych przekierowań czy stron niedostępnych dla Googlebota. Cel SLO mierzy to, czego doświadcza użytkownik i robot, a liczba zamkniętych zadań nie jest jego miarą.

Obszar	SLI	Przykładowe SLO	Gdzie sprawdzić wynik
Dostępność	odsetek poprawnych odpowiedzi HTTP	ustalony poziom dla stron krytycznych	logi serwera, monitoring HTTP
Indeksowanie	udział ważnych adresów w indeksie	cel dla grupy adresów	Search Console, raport indeksowania
Wydajność	LCP, INP, CLS dla 75. percentyla	LCP do 2,5 s, INP do 200 ms, CLS do 0,1	Search Console, PageSpeed Insights, dane RUM
Mapa witryny	adresy z kodem 200 i właściwą wersją kanoniczną	wszystkie adresy spełniają warunki	własny skrypt, Search Console
Przekierowania	przekierowania kończące się prawidłową stroną	cel ustalony dla migracji	testy HTTP, crawler

Progi Core Web Vitals pochodzą z dokumentacji Google (Google Search Central, 2026). Każda metryka opisuje coś innego: LCP ładowanie, INP reakcję na interakcję, CLS stabilność układu (web.dev, 2026).

Monitoring, który widzi objawy

SRE zaczyna od objawów odczuwanych przez użytkownika. Pozycje w wyszukiwarce reagują na awarie techniczne z opóźnieniem, dlatego wcześniejszych sygnałów szukaj w trzech warstwach:

• techniczna: statusy HTTP, czas odpowiedzi, certyfikat TLS, DNS, dostępność robots.txt, mapy witryny i zasobów,
• wyszukiwarkowa: indeksowanie, adresy kanoniczne, błędy crawlowania, wykluczenia, żądania Googlebota na ważnych adresach,
• biznesowa: ruch organiczny, formularze, transakcje, przychód i współczynnik konwersji.

Warstwa biznesowa chroni przed fałszywym spokojem. Więcej stron w indeksie nie oznacza jeszcze lepszego wyniku firmy. Dane rzeczywistych użytkowników mają przewagę nad testem laboratoryjnym, bo pojedyncza sesja nie oddaje warunków wszystkich odbiorców (web.dev, 2026). Jeśli chcesz zautomatyzować zbieranie tych danych, sięgnij po API Search Console i GA4.

Porada projektseo.pl: Nie analizuj domeny jako jednego zbioru. Utwórz osobne widoki dla produktów, kategorii, bloga, stron lokalnych i informacyjnych. Od razu zobaczysz, czy problem dotyczy całej witryny, czy jednego szablonu.

Alert ma uruchamiać działanie

W SRE alert oznacza sytuację wymagającą szybkiej reakcji człowieka. Informacja, że coś się zmieniło, trafia do raportu lub zadania (Google SRE, 2026). Dobry alert SEO zawiera:

1. opis problemu,
2. zakres adresów,
3. wpływ,
4. próg uruchomienia,
5. właściciela,
6. termin sprawdzenia,
7. instrukcję pierwszego kroku.

Sygnał	Kategoria
wzrost kodów 5xx na stronach z ruchem organicznym	alert pilny
noindex na stronach sprzedażowych	alert pilny
robots.txt blokujący istotne zasoby	alert pilny
masowa zmiana adresów kanonicznych	alert pilny
mapa witryny z błędem lub samymi nieprawidłowymi adresami	alert pilny
pojedyncze 404 dla usuniętych stron	zadanie
powolne pogorszenie INP	zadanie
niewielki wzrost wykluczonych adresów	zadanie

Google SRE zaleca, by alerty oparte na SLO reagowały na tempo zużywania budżetu błędów (Google SRE, 2026). Powiadomienie ma przychodzić przy realnym zagrożeniu celu, a każde drobne odchylenie zostaje w raporcie. Raporty Search Console zmieniają się też przez przetwarzanie danych i sezonowość, więc próg uwzględnia czas trwania i znaczenie biznesowe.

Reakcja na incydent: najpierw skutki, potem przyczyna

1. Potwierdź problem w kilku źródłach.
2. Ustal, które adresy, szablony i urządzenia są dotknięte.
3. Sprawdź, czy problem dotyczy użytkowników, Googlebota, czy obu grup.
4. Zatrzymaj wdrożenie albo wycofaj ostatnią zmianę.
5. Przywróć poprawną odpowiedź strony.
6. Sprawdź robots.txt, dyrektywy indeksowania, adresy kanoniczne i mapy witryny.
7. Zweryfikuj strony krytyczne narzędziem sprawdzania adresu.
8. Poinformuj marketing, sprzedaż i obsługę klienta.
9. Zapisz oś czasu zdarzeń.

Przy migracji pilnuj rodzaju przekierowań. Google traktuje przekierowanie stałe jako silny sygnał adresu kanonicznego, a tymczasowe nie pełni tej funkcji (Google Search Central, 2026). Plik robots.txt kontroluje crawlowanie, ale nie usuwa strony z indeksu. Wycofanie zmiany zatrzymuje szkody, jednak analiza trwa, dopóki nie wiesz, dlaczego testy przepuściły błąd. Skala problemu jest znana z innych branż: w 2024 roku błędne zmiany i aktualizacje oprogramowania kosztowały użytkowników usług telekomunikacyjnych w Unii Europejskiej 515 milionów godzin (ENISA, 2025).

Porada projektseo.pl: Przy każdym spadku ruchu zestaw trzy osie czasu: analitykę, historię wdrożeń i Search Console. Jeśli spadek zaczyna się tuż po publikacji, najpierw sprawdź tę zmianę. Aktualizację algorytmu traktuj jako jedną z hipotez.

Postmortem bez szukania winnego

Postmortem opisuje incydent po jego zamknięciu: wpływ, oś czasu, przyczyny, czynniki sprzyjające i działania zapobiegawcze. Google SRE zaleca formułę bez obwiniania, bo wtedy ludzie chętniej zgłaszają problemy i słabe punkty procesu (Google SRE, 2026). Zapis „wdrożono błędny kod” kończy analizę za wcześnie. Lepszy zapis brzmi: zmiana szablonu dodała noindex, a proces publikacji nie testował indeksowalności wersji produkcyjnej. Działaniem naprawczym staje się test i warunek blokujący publikację.

POSTMORTEM SEO
Incydent:
Początek problemu (data, godzina):
Moment wykrycia i źródło sygnału:
Zakres: adresy, szablony, urządzenia:
Wpływ n a użytkowników:
Wpływ na indeksowanie i ruch:
Zmiana poprzedzająca incydent:
Sygnały, które powinny uruchomić wcześniejszą reakcję:
Co ograniczyło skutki:
Co zawiodło w testach:
Działania | właściciel | termin:

Najcenniejsza część dokumentu to lista działań z właścicielem i terminem. Wpisuj je do kolejki prac obok innych zadań, tak jak przy porządkowaniu backlogu SEO. Postmortem przygotuj też po zdarzeniach, które nie wywołały alarmu, bo właśnie one odsłaniają luki w monitoringu.

Minimalny model na start i gdzie zobaczysz efekt

Mała firma nie potrzebuje działu SRE. Wystarczy:

• wybrać od 5 do 10 najważniejszych szablonów,
• przypisać im SLI i cele SLO,
• zapisac progi alertów i właścicieli,
• przygotować listę działań po alarmie,
• testować po każdej większej zmianie,
• prowadzić rejestr incydentów i raz w miesiącu analizować powtórki.

Darmowy zestaw to Search Console, narzędzie sprawdzania adresu, PageSpeed Insights, dane CrUX i logi serwera. Prosty skrypt sprawdzi statusy HTTP, kanoniczne adresy, dyrektywy indeksowania i obecność adresów w mapie witryny, co pomaga też wyłapać duplikaty i problemy z parametrami.

Każdy wskaźnik ma swoje miejsce i czas odczytu:

• statusy HTTP i dostępność sprawdzisz zaraz po wdrożeniu,
• robots.txt, mapę witryny i kanoniczne potwierdzisz od razu oraz po ponownym crawlowaniu,
• Core Web Vitals w Search Console pokażą zmianę dopiero po zebraniu danych rzeczywistych użytkowników,
• indeksowanie zmieni się po ponownym przetworzeniu adresów przez Google,
• ruch i konwersje porównasz z okresem sprzed zmiany, z uwzględnieniem sezonowości.

Porada projektseo.pl: Przy migracji weryfikuj osobno każdą właściwość w Search Console i obserwuj raport map witryny razem ze stanem indeksowania, zgodnie z zaleceniem Google (Google Search Central, 2026). Wynik zapisz w rejestrze incydentów, nawet jeśli wszystko poszło dobrze.