Dlaczego błędy SEO są droższe, niż się wydaje
Błędy SEO to coś do czego nie możemy podchodzić na zasadzie liczenia kosztów pracy programisty, bo mogą mieć skutki w postaci braku przychodu z wybranych sekcji stron, kiedy wylatują z indeksu. Najdroższa część błędu indeksacji to nie jego naprawa, lecz czas, przez który działał, zanim ktokolwiek go zauważył.
Weźmy przypadkowy noindex na ważnej kategorii produktów, sama poprawka to usunięcie jednej linijki, więc zajmuje dosłownie minuty. Później, między momentem, gdy błąd trafił na produkcję, a momentem jego wykrycia, dzieje się cały łańcuch strat. Jeśli crawler może pobrać stronę, Google przy kolejnym crawlu odczytuje noindex i może usunąć URL z indeksu. Ruch organiczny z tej strony spada na łeb na szyję, spadają konwersje, które ten ruch generował. Straciliśmy mnóstwo nerwów i w atmosferze pożaru, w końcu błąd zostaje wreszcie naprawiony, ale odzyskanie widoczności nie jest natychmiastowe. Google musi ponownie scrawlować i zaindeksować stronę, a ranking wraca stopniowo albo wymaga dalszej diagnostyki. Straty finansowe się zwiększają z każdym dniem, a sama naprawa trwała minuty.
To właśnie odróżnia błąd SEO od typowej awarii, ponieważ gdy pada checkout, wiesz o tym natychmiast, bo użytkownicy nie mogą kupować i zgłoszenia spływają w minuty. Gdy psuje się indeksacja, nie ma tak widocznego sygnału alarmowego, czyli strona ładuje się poprawnie, działa bez zarzutu, a problem ujawnia się dopiero w danych o ruchu, z kilkudniowym opóźnieniem albo pośrednio, bo nie ma transakcji.
Co gorsza, część tych błędów jest niewidoczna nawet w przeglądarce. Rozjazd między serwerowym HTML a stanem po hydracji potrafi sprawić, że użytkownik widzi poprawną stronę, a crawler albo narzędzie testowe dostaje inny sygnał w HTML źródłowym lub w wyrenderowanej wersji strony. Google potrafi renderować JavaScript, ale ma ograniczenia, a przy noindex w kodzie źródłowym może pominąć dalsze renderowanie. Nie zobaczysz tego, klikając po serwisie. Zobaczysz dopiero wtedy, gdy Search Console pokaże spadek pokrycia albo dziwne błędy indeksacji — czyli już po fakcie, gdy strata narasta od dni.
Jak policzyć koszt jednego incydentu
Dopóki nie przełożysz kosztu błędu na liczby jest to czysta abstrakcja, więc nie przemawia za bardzo do wyobraźni. Spróbujmy to sobie obliczyć.
Zacznijmy od wartości ruchu organicznego dotkniętych stron, weźmiemy miesięczny ruch z wyszukiwarki, przemnożymy przez i przez średnią wartość pojedynczej konwersji. W rezultacie, mamy przybliżony przychód, który te strony generują w miesiącu z kanału organicznego. To nasza baza.
Następnie, przechodzimy do oszacowania czasu trwania tego incydentu. Liczymy go od wdrożenia błędu do poprawki, ale potem musimy też doliczyć powrót widoczności po ponownym crawlowaniu i indeksacji. Trzeba pamiętać, że Google nie gwarantuje natychmiastowego powrotu do wyników ani do poprzednich pozycji (warto to zapamiętać na przyszłość).
Podstawmy liczby, żeby zobaczyć skalę i wyjść z abstrakcji. Załóżmy kategorię produktową generującą około 40 000 zł przychodu organicznego miesięcznie, a przypadkowy noindex trafia na produkcję i strona wypada z indeksu na trzy tygodnie, zanim ktoś zauważy spadek. Naprawa to minuty, ale odbudowa pozycji zajmuje kolejne dwa tygodnie (przykładowo) przez ten czas ruch wraca stopniowo, powiedzmy średnio na połowie wydajności. Ostatecznie, trzy tygodnie po zero (~30 000 zł) plus dwa tygodnie po połowie (~10 000 zł) to około 40 000 zł straty z jednego błędu. Teraz zestaw tę liczbę z kosztem asercji, która zablokowałaby noindex w PR...
Dlaczego prewencja popłaca
Warto zobaczyć, jak wygląda Zestaw testów regresji SEO w CI/CD to głównie jednorazowa praca, czyli brak noindex, zgodny adres kanoniczny, status redirectów, obecność metadanych. Kilkanaście asercji. Godziny, nie tygodnie.
Zakres tych asercji nie jest przypadkowy — pokrywa dokładnie te elementy, które najczęściej cicho psują techniczne SEO: link kanoniczny wskazujący niekanoniczną wersję strony, hreflang rozjeżdżający wersje językowe, redirect, który zamiast trwałego przekierowania zwraca tymczasowe albo pętli. Każdy z nich działa po cichu, każdy da się sprowadzić do jednej asercji w PR.
Po stronie zysków masz natomiast każdy incydent, który ten mechanizm zablokuje przez cały czas życia projektu. Wystarczy jeden poważny przypadek deindeksacji, żeby inwestycja się zwróciła, a w aktywnie rozwijanym projekcie, gdzie kod zmienia się codziennie, takich okazji do pomyłki jest bardzo dużo. Im większa zależność biznesu od ruchu organicznego i im częstsze zmiany w kodzie, tym szybszy i pewniejszy zwrot z automatyzacji.
To nie znaczy, że musisz pokryć testami całą stronę w pierwszym tygodniu, ponieważ znacznie lepszą strategią jest działanie stopniowe. Najpierw sprawdź, które strony dowożą najwięcej przychodu organicznego, i zabezpiecz najpierw je, a potem resztę dokładasz stopniowo, w miarę jak projekt rośnie. Tę samą logikę priorytetyzacji według wartości wykorzystuję przy ratowaniu crawl budgetu na dużych serwisach. Po prostu skup najpierw zasoby tam, gdzie stawka jest najwyższa.
