Zespoły, które prowadzą testy A/B na stronach generujących ruch z wyszukiwarki, zadają zwykle to samo pytanie: czy pokazywanie dwóch wersji tej samej podstrony nie zostanie uznane za manipulację. Odpowiedź jest krótsza, niż sugerują branżowe dyskusje. Google od lat jasno komunikuje, że testowanie wariantów jest normalną praktyką optymalizacyjną, a problem pojawia się dopiero wtedy, gdy robot dostaje coś innego niż użytkownik. Cała reszta to kwestia poprawnej implementacji i rozsądnego czasu trwania eksperymentu.
Co Google uznaje za cloaking, a co nie
Cloaking to podawanie robotowi wyszukiwarki treści różniącej się od tej, którą widzi człowiek wchodzący pod ten sam adres. Kluczowe jest słowo „różnicowanie po tożsamości odbiorcy”: jeśli serwer sprawdza user agenta albo zakres IP i na tej podstawie decyduje o zawartości, mamy do czynienia z naruszeniem wytycznych dotyczących spamu. Testy A/B działają inaczej: dzielą cały ruch losowo, bez względu na to, kto wysłał żądanie. Robot trafia do tej samej loterii co użytkownik i dlatego nie ma tu cloakingu.
Granica robi się cienka w trzech sytuacjach. Pierwsza: wariant testowy zawiera treść, której nigdy nie planujesz wdrożyć, a służy wyłącznie do karmienia robota słowami kluczowymi. Druga: podział ruchu jest tak skonstruowany, że Googlebot zawsze widzi wariant A, bo dzielisz po cookie, a robot cookies nie przyjmuje. Trzecia: test trwa kwartał i de facto stał się stałym elementem serwisu, w którym dwie wersje tej samej strony konkurują ze sobą w indeksie. Każdy z tych przypadków da się naprawić zmianą implementacji, nie rezygnacją z testowania.
Testy po stronie serwera i po stronie klienta
Z punktu widzenia wyszukiwarki te dwa podejścia zachowują się zupełnie inaczej. W teście serwerowym decyzja o wariancie zapada przed wysłaniem odpowiedzi HTML, więc robot otrzymuje gotowy dokument. To rozwiązanie najbezpieczniejsze pod kątem SEO, bo nie wymaga od Googlebota wykonania żadnego skryptu. Jego koszt to zwykle udział zespołu backendowego i ryzyko, że cache (CDN albo cache strony w WordPressie) zacznie serwować jeden wariant wszystkim.
Testy klienckie, typowe dla narzędzi opartych o snippet JavaScript, podmieniają elementy strony po wczytaniu dokumentu. Googlebot renderuje JavaScript, ale robi to w osobnej kolejce i nie gwarantuje, że zobaczy końcowy stan DOM dokładnie tak, jak przeglądarka użytkownika. Jeśli testujesz nagłówek H1 albo blok treści, licz się z tym, że indeks zapisze wersję sprzed podmiany. Szerzej o tym, jak wyszukiwarka traktuje treść generowaną skryptami, pisaliśmy w materiale o renderowaniu i hydratacji w JavaScript SEO.
| Aspekt | Test serwerowy | Test kliencki |
|---|---|---|
| Co widzi robot | wariant w HTML | zwykle wersję bazową |
| Ryzyko migotania treści | brak | realne (FOUC) |
| Wpływ na INP i LCP | minimalny | zauważalny |
| Nakład wdrożenia | wyższy | niski |
| Testowanie elementów SEO (title, H1, treść) | wskazane | niezalecane |
Przekierowania 302 i rola canonical w testach
Część narzędzi realizuje test przez przekierowanie z adresu bazowego na osobny URL wariantu. Takie podejście jest dopuszczalne, pod dwoma warunkami. Po pierwsze, przekierowanie musi być tymczasowe, czyli 302 albo 307. Kod 301 komunikuje trwałą przeprowadzkę i po zakończeniu testu możesz zostać z adresem wariantu w indeksie zamiast oryginału. Po drugie, każdy wariant powinien wskazywać w elemencie link rel="canonical" adres strony bazowej, a nie samego siebie.
Ten punkt bywa pomijany, bo wiele systemów CMS generuje canonical automatycznie, na podstawie bieżącego URL-a. Efekt: w indeksie pojawiają się dwa niemal identyczne dokumenty, a Search Console pokazuje ostrzeżenia o zduplikowanej treści bez wybranej wersji kanonicznej. Zanim uruchomisz test, sprawdź źródło strony wariantu i upewnij się, że canonical faktycznie prowadzi do oryginału.
- 302 lub 307 dla przekierowań testowych, nigdy 301.
- Canonical na wszystkich wariantach wskazuje adres bazowy.
- Adresy wariantów nie trafiają do sitemapy XML.
- Parametry typu
?variant=bsą czytelniejsze w logach niż osobne katalogi. - Po zakończeniu testu przekierowania znikają, a nie zostają „na chwilę”.
Czy wykluczać roboty z testu
To pytanie pojawia się przy każdym wdrożeniu i odpowiedź jest kontrintuicyjna: nie, nie wykluczaj. Wykrywanie Googlebota po user agencie, żeby zawsze podać mu wariant kontrolny, jest technicznie tym samym mechanizmem co cloaking. Nawet jeśli intencja jest ostrożnościowa, budujesz warstwę, która różnicuje treść po tożsamości klienta. Dodatkowo tracisz informację: nie dowiesz się, czy wariant testowy ma problem z renderowaniem, bo robot nigdy go nie zobaczy.
Wyjątek dotyczy sytuacji, w której test dotyczy wyłącznie zalogowanych użytkowników albo obszaru za formularzem. Tam robot i tak nie wejdzie, więc temat jest bezprzedmiotowy. W pozostałych przypadkach pozwól, by Googlebot przeszedł przez ten sam losowy podział ruchu co każdy inny klient. Jeżeli chcesz kontrolować, co robią boty na twoim serwisie, rób to na poziomie robots.txt i dostępu do zasobów, a nie przez podmianę treści w locie.
Jak długo może trwać test bez ryzyka
Wytyczne nie podają konkretnej liczby dni, ale sens jest jasny: test powinien trwać tyle, ile potrzeba na uzyskanie rozstrzygnięcia statystycznego, i ani dnia dłużej. W praktyce oznacza to zwykle od dwóch do sześciu tygodni, w zależności od wolumenu ruchu i wielkości oczekiwanego efektu. Serwis z pięcioma tysiącami sesji miesięcznie potrzebuje znacznie dłuższego okna niż sklep z pięćdziesięcioma tysiącami, a przy bardzo niskim ruchu test może być po prostu niewykonalny w rozsądnym czasie. Policzyliśmy to na konkretnych liczbach w analizie czasu trwania testu przy 5000 sesji miesięcznie, więc warto zacząć od oszacowania wielkości próby, zanim włączysz eksperyment.
Zbyt długi test niesie dwa ryzyka. Pierwsze jest techniczne: im dłużej dwa adresy żyją równolegle, tym większa szansa, że wariant zostanie zaindeksowany, zalinkowany z zewnątrz albo trafi do czyjejś sitemapy. Drugie jest analityczne: po kilku miesiącach warunki zewnętrzne (sezonowość, zmiana miksu kanałów, aktualizacja algorytmu) zmieniają się tak mocno, że porównujesz dwie różne populacje, nie dwa warianty.
Wpływ testu na Core Web Vitals
Najczęściej pomijany koszt testów klienckich to pogorszenie metryk wydajnościowych. Snippet narzędzia testowego ładuje się zwykle synchronicznie w sekcji head, bo musi zdążyć przed wyrenderowaniem treści. Blokuje wtedy parsowanie dokumentu i podnosi czas do największego wyrenderowania elementu. Dodatkowo podmiana DOM po wczytaniu generuje przesunięcia układu, a obsługa zdarzeń w skrypcie testowym wydłuża czas reakcji na pierwszą interakcję.
Zanim uruchomisz eksperyment na kluczowych podstronach, zmierz metryki przed i po włączeniu snippetu. Jeśli INP rośnie o kilkadziesiąt milisekund, a strona była blisko progu, test pogorszy ocenę wydajności niezależnie od tego, który wariant wygra. Praktyczne podejście do tej metryki opisaliśmy w tekście o INP w praktyce na WordPressie. Alternatywą jest przeniesienie testu na stronę serwera, co eliminuje problem u źródła.
Jak wdrożyć zwycięski wariant i posprzątać po teście
Zakończenie testu jest etapem, na którym najczęściej zostaje bałagan techniczny. Scenariusz jest zawsze podobny: wariant B wygrał, zespół wdrożył zmiany na stronie bazowej i przeszedł do następnego zadania, a przekierowania oraz adresy wariantów zostały aktywne jeszcze przez kwartał. Warto przejść zamknięcie według stałej listy kroków.
- Przenieś zwycięską treść na adres bazowy, tak aby wariant przestał być potrzebny.
- Usuń przekierowania testowe i snippet narzędzia z szablonu.
- Jeśli adresy wariantów były indeksowane, ustaw na nich przekierowanie 301 na stronę bazową.
- Sprawdź w Search Console, czy raport indeksowania nie pokazuje wariantów jako osobnych adresów.
- Wyczyść cache serwera i CDN, żeby nie serwowały zapamiętanego wariantu.
- Zanotuj datę wdrożenia w dokumentacji zmian, bo bez niej nie powiążesz późniejszych wahań ruchu z tym testem.
Ostatni punkt dotyczy pomiaru. Po wdrożeniu wyniku porównanie konwersji między systemami zwykle się nie zgadza, bo narzędzie testowe, GA4 i panel reklamowy liczą w innych modelach i oknach atrybucji. Zanim uznasz, że wzrost z testu nie przełożył się na realne przychody, sprawdź źródła rozbieżności opisane w materiale o tym, dlaczego GA4 pokazuje mniej konwersji niż Google Ads.
FAQ
Czy test A/B może obniżyć pozycje w Google?
Sam podział ruchu nie jest czynnikiem rankingowym. Pozycje spadają z powodu błędów implementacji: przekierowań 301 zamiast 302, canonical wskazującego na wariant, zaindeksowanych duplikatów albo pogorszonych metryk wydajności. Poprawnie wdrożony test jest neutralny dla widoczności.
Czy mogę testować tag title i nagłówek H1?
Tak, ale tylko w teście serwerowym, w którym robot widzi finalny HTML. Przy podmianie skryptem Google najczęściej zapisze wersję bazową, więc wynik testu nie powie ci nic o wpływie wariantu na kliknięcia w wynikach wyszukiwania.
Co zrobić, gdy wariant już trafił do indeksu?
Ustaw na jego adresie przekierowanie 301 na stronę bazową i usuń go z sitemapy. Nie używaj tagu noindex razem z przekierowaniem, bo te sygnały są sprzeczne. Po kilku tygodniach sprawdź raport indeksowania, czy adres wypadł z indeksu.
Czy personalizacja treści to też cloaking?
Nie, jeśli różnicujesz treść po zachowaniu albo lokalizacji użytkownika i robot dostaje wersję domyślną, taką samą jak nowy użytkownik bez historii. Cloaking zaczyna się tam, gdzie warunkiem jest rozpoznanie robota.
Ile wariantów można testować jednocześnie?
Technicznie dowolnie wiele, ale każdy kolejny wariant wydłuża czas potrzebny na rozstrzygnięcie i mnoży liczbę adresów, które trzeba potem posprzątać. Przy ruchu poniżej kilkudziesięciu tysięcy sesji miesięcznie trzymaj się dwóch wariantów.
Czy test A/B wymaga zgody w banerze cookies?
Zależy od implementacji. Jeśli narzędzie zapisuje identyfikator w cookie lub pamięci przeglądarki, potrzebujesz zgody na kategorię analityczną. Testy serwerowe bez trwałego identyfikatora bywają traktowane łagodniej, ale decyzję skonsultuj z osobą odpowiedzialną za zgodność.