Po miesiącu używania własnego projektu pobocznego jako poligonu SEO miałem 632 organicznych odwiedzających. To był dobry sygnał, ale najciekawsza lekcja przyszła z innej liczby: 15 października strona osiągnęła dzienny szczyt 83 odwiedzających, a część tego ruchu nie wyglądała na ludzką.
Przygotowywałem się wtedy do większej inicjatywy SEO w pracy i zależało mi na praktyce, nie na kolejnej porcji teorii. Side project dawał mi miejsce, w którym mogłem wprowadzać zmiany, patrzeć na dane i mylić się bez zamieniania każdej obserwacji w decyzję produkcyjną.
To rozróżnienie szybko okazało się kluczowe. Metryka może zmienić się w tym samym czasie co wdrożenie, ale nie dowodzi to przyczynowości. Skok ruchu może wyglądać jak wzrost, dopóki nie rozbije się go na źródła. A nagranie sesji może pokazać coś dziwnego bez odpowiedzi, dlaczego tak się stało.
Co naprawdę mówiło mi 632 odwiedzających organicznych
W pierwszym miesiącu było 632 organicznych odwiedzających. To wynik, który mogę potwierdzić. Sama liczba nie dowodzi jednak, że znalazłem powtarzalną receptę na SEO, że każda zmiana poprawiła pozycje ani że trend będzie trwał.
W projekcie edukacyjnym najważniejsze było to, że pojawiło się wystarczająco dużo realnego ruchu z wyszukiwarek, by mieć co obserwować. Mogłem wprowadzić zmianę, sprawdzić, co się poruszyło, i zadać precyzyjniejsze pytanie. To było znacznie bardziej wartościowe niż traktowanie SEO jako checklisty, w której każda „best practice” ma automatycznie dawać wzrost pozycji.
Zmiana rozmiaru fontu nauczyła mnie ostrożności z przyczynowością
Zaskoczyła mnie korelacja między zmianami rozmiaru fontu a metrykami wydajności. Łatwo byłoby napisać: „małe detale UX wpływają na ranking”. Moje dane nie uzasadniają tak mocnego wniosku.
Faktycznie zaobserwowałem tylko tyle: zmieniłem rozmiar fontu, a później część metryk się poruszyła. Nie przeprowadziłem kontrolowanego eksperymentu izolującego tę zmianę od wszystkich innych i nie mam dowodu, że wyszukiwarka zmieniła pozycje z powodu tej konkretnej reguły CSS. Font może zmienić zawijanie tekstu, układ i pozycje elementów, a tym samym niektóre pomiary renderowania lub UX. Dokładny mechanizm w moim przypadku nie został jednak potwierdzony.
Bezpieczniejsza zasada dla takich eksperymentów brzmi: najpierw zapisać obserwację, dopiero potem ją wyjaśniać. „Metryka X zmieniła się po zmianie Y” to dane. „Y spowodowało X” pozostaje hipotezą, dopóki nie mam wystarczających dowodów.
Dzień z 83 odwiedzającymi wyglądał lepiej przed otwarciem Webvisora
15 października strona osiągnęła najwyższy dotąd wynik dzienny: 83 odwiedzających. Nie znaczy to, że było to 83 użytkowników organicznych; chodziło o całkowity dzienny szczyt, który analizowałem. Po rozbiciu źródeł zauważyłem, że spora część ruchu pochodziła z Chin i była oznaczona jako ruch bezpośredni.
„Direct” łatwo odczytać jako „ktoś wpisał mój adres”. W Yandex Metrica do tej kategorii mogą jednak trafić także sesje bez przekazanego referrera i inne przypadki. Yandex opisuje to w dokumentacji źródeł ruchu. Sama etykieta nie mówi więc, kim był odwiedzający ani jak naprawdę trafił na stronę.
Następnie obejrzałem podejrzane sesje w Yandex Webvisor. Strona wyglądała tak, jakby była otwierana z wyłączonym CSS. Na podstawie wzorca oszacowałem, że około 20 takich „użytkowników” prawdopodobnie było botami.
Brak CSS był wskazówką, nie dowodem
Ta liczba nadal jest szacunkiem. Istnieją co najmniej dwa ogólne wyjaśnienia.
- Żądania naprawdę były automatyczne. Scraper może pobierać HTML, a pomijać arkusze stylów, obrazy i inne niepotrzebne zasoby. Oszczędzanie transferu jest sensownym wyjaśnieniem, ale nie potwierdziłem, że właśnie taki był cel.
- Replay mógł nie odtworzyć idealnie pierwotnej sesji. Systemy session replay rekonstruują stronę z zapisanych danych. Yandex dokumentuje przypadki, gdy nagranie wygląda inaczej niż strona widziana przez użytkownika, w tym problemy z CSS podczas odtwarzania po zmianach w arkuszach stylów.
„Webvisor pokazał stronę bez CSS” jest więc obserwacją. „Odwiedzający celowo wyłączył CSS” to interpretacja. „Czyli był botem” to kolejny wniosek. Hipoteza o botach była dla mnie wiarygodna, ale jedna cecha replayu nie wystarcza do pewnej klasyfikacji.
Co sprawdziłbym w logach
Przy takiej anomalii bardziej ufam logom serwera niż wizualnemu replayowi. Porównałbym User-Agent, adresy IP lub zakresy sieci, rytm i powtarzalność requestów, pobierane zasoby, ścieżki, statusy HTTP i referrery. Sprawdziłbym też, czy klient pobierał tylko HTML, czy również CSS, JavaScript i obrazy, oraz czy ten sam wzorzec jest widoczny w analityce: przeglądarka, obsługa JavaScript, region, długość sesji i landing page.
Żaden sygnał nie jest doskonały w izolacji. Łącznie mogą znacznie lepiej potwierdzić lub osłabić hipotezę o botach niż samo wrażenie, że „nagranie wyglądało dziwnie”.
Największa lekcja dotyczyła pomiaru, nie pozycji
Zacząłem side project, bo chciałem zdobyć praktyczne doświadczenie SEO przed większą inicjatywą w pracy. Po miesiącu wartością nie było wyłącznie 632 organicznych odwiedzających. Równie ważne było zobaczenie, jak szybko z niepełnych danych można zbudować atrakcyjną historię.
Mógłbym nazwać pik 83 odwiedzających wzrostem. Mógłbym uznać zmianę fontu za czynnik rankingowy. Mógłbym nazwać botem każdą sesję bez CSS. Wszystkie trzy opowieści byłyby prostsze. Żadna nie byłaby wystarczająco dobrze poparta.
W przyszłych eksperymentach bardziej defensywny proces to: rozdzielać źródła ruchu, prowadzić changelog, porównywać „przed” i „po” bez automatycznego zakładania przyczynowości, analizować anomalie na poziomie żądań HTTP i pamiętać, że narzędzia analityczne też mają ograniczenia.
Dla mnie to najcenniejszy element eksperymentu. SEO dało mi ruch do obserwacji; trudniejszą umiejętnością jest ocena, co dane naprawdę dowodzą.
Nadal analizuję logi, szczególnie bezpośredni ruch z Chin. Jeśli znajdę powtarzalny wzorzec requestów, będę miał dużo mocniejszą odpowiedź na pierwotne pytanie: czy te około 20 wizyt rzeczywiście pochodziło od botów i czy pomijanie CSS było częścią ich zachowania.