W nowoczesnych stronach różnice między tym, co dostaje robot wyszukiwarki, a tym, co widzi użytkownik, pojawiają się częściej, niż się wydaje: przy renderowaniu JavaScriptu, personalizacji, testach A/B, paywallach czy zabezpieczeniach przed botami. Część z nich jest całkowicie w porządku, a część Google traktuje jak cloaking i karze ręcznym działaniem. W tym wpisie pokazuję, gdzie przebiega ta granica, jak wdrażać takie rozwiązania bez ryzyka i jak sprawdzić, czy Twoja strona nie pokazuje robotom czegoś innego niż ludziom.
Gdzie przebiega granica
Zasada, którą stosuję przy każdej decyzji, jest prosta: robot może dostać treść w innej formie technicznej, ale nie może dostać innej treści. Jeśli Googlebot widzi gotowy HTML, a użytkownik tę samą treść zbudowaną przez JavaScript, wszystko jest w porządku. Jeśli Googlebot widzi artykuł o kredytach, a użytkownik stronę z hazardem, to klasyczny cloaking.
Drugie kryterium to powód różnicy. Zmiana zależna od języka, lokalizacji czy urządzenia użytkownika jest dozwolona, pod warunkiem że robot odwiedzający stronę z tych samych warunków dostanie to samo co człowiek. Zmiana zależna wyłącznie od tego, że odwiedza ją robot, jest sygnałem ostrzegawczym.
Najczęstsze sytuacje w praktyce
| Sytuacja | Czy to cloaking | Jak zrobić to poprawnie |
|---|---|---|
| Dynamic rendering, czyli gotowy HTML dla robotów i wersja JavaScript dla ludzi | Nie, jeśli treść jest taka sama | Traktować jako rozwiązanie przejściowe i przejść na renderowanie po stronie serwera lub generowanie statyczne |
| Test A/B z różnymi wersjami strony | Nie, jeśli robot jest traktowany jak zwykły użytkownik | Canonical na stronę oryginalną, przekierowania 302 do wariantów, test tylko tak długo, jak to potrzebne |
| Paywall lub treść dla zalogowanych | Nie, jeśli jest oznaczony | Dane strukturalne informujące, która część treści jest płatna |
| Wersja językowa lub waluta według lokalizacji | Nie, jeśli robot z danego kraju dostaje to samo co użytkownik | Osobne adresy dla wersji językowych, znaczniki hreflang, brak wymuszonych przekierowań po adresie IP |
| Treść tekstowa widoczna tylko dla Googlebota | Tak | Pokazać tę treść wszystkim albo usunąć |
| Przekierowanie użytkowników, ale nie robotów, na inną stronę | Tak, to tzw. sneaky redirect | Jedno przekierowanie 301 dla wszystkich |
| Zabezpieczenie przed botami blokujące Googlebota stroną weryfikacyjną | Nie, ale strona wypada z indeksu | Weryfikacja prawdziwego Googlebota i przepuszczanie go bez wyzwań |
Dynamic rendering w praktyce
Dynamic rendering powstał jako obejście dla stron, których treść generuje JavaScript, a wyszukiwarki nie radziły sobie z jego wykonywaniem. Serwer rozpoznaje robota i zamiast aplikacji zwraca mu wcześniej wyrenderowany HTML. Google nie traktuje tego jako cloakingu, o ile obie wersje zawierają tę samą treść, ale sam określa to rozwiązanie jako tymczasowe obejście, a nie docelową architekturę.
W praktyce widzę z nim dwa problemy. Pierwszy to rozjeżdżanie się wersji: zmiana w aplikacji trafia do użytkowników, a pamięć podręczna renderera serwuje robotom stary HTML przez dni lub tygodnie. Drugi to dodatkowa infrastruktura do utrzymania. Dlatego przy nowych projektach zamiast dynamic renderingu wybieram renderowanie po stronie serwera lub generowanie statyczne, a różnice między nimi opisuje porównanie metod renderowania CSR, SSR, SSG i ISR. Tam, gdzie dynamic rendering już działa, regularnie porównuję obie wersje strony.
Personalizacja i zmiany na brzegu sieci
Coraz więcej personalizacji odbywa się na brzegu sieci, w CDN, zanim strona dotrze do użytkownika: zmiana waluty, języka, formatu zdjęć czy wariantu testu. Rozwiązania Edge SEO są tu bardzo wygodne, ale wymagają dyscypliny. Reguły opieram na cechach użytkownika, takich jak kraj, język przeglądarki czy urządzenie, a nie na nazwie robota. Googlebot skanuje strony głównie z adresów w USA, więc jeśli wersja językowa zależy od lokalizacji, każda wersja musi mieć też własny adres, do którego robot dotrze bez zmiany kraju.
Osobną pułapką są zabezpieczenia przed botami w CDN. Agresywna reguła potrafi pokazać Googlebotowi stronę z weryfikacją zamiast treści. To nie jest cloaking w sensie wytycznych, ale skutek bywa podobny: strony znikają z indeksu. Przy konfiguracji CDN zawsze dodaję wyjątek dla zweryfikowanych robotów wyszukiwarek, sprawdzając ich prawdziwość odwrotnym zapytaniem DNS, a nie samą nazwą w nagłówku User-Agent, którą łatwo podrobić.
Jak wygląda kara i jak z niej wyjść
Wykryty cloaking kończy się ręcznym działaniem, widocznym w Google Search Console w sekcji Bezpieczeństwo i ręczne działania. Może dotyczyć części serwisu albo całej domeny, a jego skutkiem jest spadek lub całkowite zniknięcie stron z wyników. Po usunięciu przyczyny składa się prośbę o ponowne rozpatrzenie, w której trzeba opisać, co było nie tak i co zostało poprawione. Odpowiedź może przyjść po kilku dniach lub tygodniach.
W praktyce cloaking dość często nie jest świadomą decyzją właściciela, tylko skutkiem włamania. Złośliwy kod pokazuje Googlebotowi strony ze spamem, np. reklamy leków czy podróbek, a zwykłemu użytkownikowi normalną stronę. Właściciel dowiaduje się o problemie dopiero z wyników wyszukiwania albo z ręcznego działania. Dlatego przy każdym nagłym pojawieniu się w indeksie dziwnych adresów sprawdzam pliki na serwerze i bazę danych pod kątem zainfekowanego kodu.
Jak sprawdzam, czy strona nie pokazuje robotom czegoś innego
- Narzędzie do sprawdzania adresów URL w Search Console. Test aktywnego adresu pokazuje wyrenderowany HTML i zrzut ekranu tak, jak widzi je Google. Porównuję je z tym, co widzę w przeglądarce.
- Żądanie z nagłówkiem robota. Porównuję odpowiedź serwera dla zwykłej przeglądarki i dla nagłówka Googlebota:
curl -A "Googlebot" https://twojadomena.pl/. Różnica w treści to sygnał do dalszej analizy. - Crawl jako Googlebot. W Screaming Frogu ustawiam nagłówek User-Agent robota Google i renderowanie JavaScriptu, a potem porównuję wyniki z crawlem jako zwykła przeglądarka.
- Wyszukiwanie z operatorem
site:. Nieznane adresy i tytuły w indeksie to częsty pierwszy objaw włamania. - Logi serwera. Analiza logów pokazuje, jakie kody odpowiedzi i jakie adresy dostaje prawdziwy Googlebot, co pozwala wychwycić blokady i przekierowania działające tylko dla robotów.
Takie porównanie jest stałym elementem, gdy przeprowadzam audyt techniczny SEO strony opartej na JavaScripcie albo korzystającej z personalizacji. Przy tego typu architekturze rozbieżności powstają zwykle przypadkiem, a nie celowo, i właśnie dlatego trzeba ich aktywnie szukać.