Rozebrałem na czynniki pierwsze nowy mechanizm przekierowań Google → /goto?url=

Lubię grzebać, a doświadczenie w researchu Google mówi mi, że to coś strukturalnego. Nie potrafię przejść obok czegoś takiego bez sprawdzenia, więc o to co znalazłem.

Masz tu opis jak wygląda rozbieranie na czynniki pierwsze nieznanego formatu binarnego od zera oraz uczciwa odpowiedź na pytanie: „ile z tego faktycznie ma znaczenie dla kogoś kto zajmuje się SEO”. Spoiler: mniej niż myślałem 😀 ale właśnie to, co znalazłem po drodze uważam za warte opisania.

Ahrefs wyłapał „goto” już 5 grudnia 2025 roku

Pierwsze informacje o „/goto?url=” Ahrefs pokazuje już 5 grudnia 2025 roku. Patrząc na poniższy obraz mam wątpliwości czy w tym przypadku można mówić o „ograniczonym” wdrożeniu.

Dodatkowo warto zwrócić uwagę na przekrój podmiotów, których treści Google wrzucił do „goto”. Od Pinterest i YouTube, przez włoski serwis informacyjny Tgcom24, po Denver Broncos (strona na temat zespołu futbolu amerykańskiego) czy serwis bukmacherski.

Punkt wyjścia: 2 warstwy przekierowań nałożone na siebie

Zacząłem od zebrania próbek. Operator Google site: na dzień publikacji pokazuje 380 unikalnych linków, z czego 4 prowadziły do tych samych stron.

Pierwsza rzecz, która rzuciła mi się w oczy: nowy mechanizm nie zastąpił starego. Pełny link wygląda tak:

https://www.google.com/url?sa=t&source=web&...&url=https://www.google.com/goto%3Furl%3D<TOKEN>&ved=<VED>&usg=<USG>

Nowy token /goto?url= jest zagnieżdżony wewnątrz starego mechanizmu /url?. Google dokłada nową warstwę, nie zastępując (na razie?) starej. To dość typowy wzorzec dla ostrożnego wdrażania – jeśli coś pójdzie źle, to można się wycofać bez przebudowy całej infrastruktury przekierowań. Zanotowałem to sobie jako pierwszy konkretny fakt i skupiłem się na samym tokenie.

Sam token wyglądał tak:

CAESdAE7q4ylCqz3hVmL8SHjZ68DuX1yk6TB5-xaiSDrayUfemhRYI6oGZqvLTbcdjZJgb_bKVrFRLKzcZhj_6k8eZJ8B3HoVE4a0ZvaOqs_hgH3wx88TYEJumNjsqnOVWiEsOhgoMiohetnWt2aPdpk4iz4HSNQ

Odkrycie 1: to jest Protocol Buffers (protobuff)

Zdekodowałem base64 do surowych bajtów i zacząłem je czytać zgodnie ze specyfikacją Protocol Buffers, czyli binarnego formatu serializacji danych, który Google stosuje wewnętrznie praktycznie wszędzie. Pierwsze kilka bajtów przykładowego tokenu:

08 01 12 9C 01 [...]

Rozbiłem to ręcznie:

• 08 to tag mówiący „pole numer 1, typ varint”
• 01 czyli wartość tego pola to liczba 1
• 12 to tag „pole numer 2, dane o zmiennej długości”
• 9C 01 to zakodowana jako varint długość tych danych – po przeliczeniu wynosi 156

Z moich próbek wychodzi, że każdy token to dokładnie dwa pola:

1. Pierwsze pole – zawsze wartość true, bez żadnego wyjątku w całej próbie
2. Drugie pole – blok danych o zmiennej długości. Od 54 do 299 bajtów w moim zbiorze

Odkrycie 2: Tink

Spojrzałem na pierwszy bajt zawartości pola drugiego we wszystkich 380 próbkach. Zawsze 0x01. Zero wyjątków, zero zmienności.

Sam w sobie stały bajt niewiele mówi. W połączeniu z 4 kolejnymi bajtami wygląda dokładnie jak standardowy nagłówek wyjściowy biblioteki Tink – otwartoźródłowego frameworka kryptograficznego Google, używanego wewnętrznie do szyfrowania z uwierzytelnianiem integralności (w skrócie AEAD). Format Tink dla identyfikacji kluczem wygląda tak:

• jeden bajt znacznika
• cztery bajty identyfikatora klucza
• potem zaszyfrowane dane

Nie mam potwierdzenia, że to faktycznie Tink ale mam zgodność formatu binarnego ze znaną i publicznie udokumentowaną specyfikacją tej biblioteki. Dodatkowo w Google właśnie biblioteka Tink jest narzędziem standardowym do tego typu zadań. Dlatego uważam to za wysokie prawdopodobieństwo, a nie potwierdzony fakt. Policzyłem ile różnych czterobajtowych identyfikatorów klucza pojawia się w 380 próbkach:

• ee47aa4d – 235 wystąpień (61,8%)
• 3bab8ca5 – 92 wystąpienia (24,2%)
• 5826ba61 – 48 wystąpień (12,6%)
• 4a8bf25e – 5 wystąpień (1,3%)

Dla losowych czterobajtowych danych taka koncentracja na czterech wartościach przy próbie 380 sztuk byłaby niemożliwa do wyjaśnienia. Dlatego uważam, że są to identyfikatory kluczy szyfrujących, używanych rotacyjnie – jeden dominujący (prawdopodobnie obecny klucz „podstawowy”), reszta prawdopodobnie starsze, jeszcze niewygaszone, albo przypisane do innych wariantów infrastruktury. Nie ustaliłem dokładnie, który to przypadek – do tego potrzebowałbym zbierać próbki systematycznie przez dłuższy czas, czego nie zrobiłem.

Odkrycie 3: ten sam link zawsze daje identyczny token

To był moment, w którym zacząłem podejrzewać, że trafiłem na coś bardziej konkretnego niż „jakieś tam szyfrowanie”.

Miałem w swoim zbiorze 380 próbek i cztery pary identycznych ciągów w polu drugim – bajt w bajt te same. Sprawdziłem kontekst każdej pary przez równoległe zdekodowanie towarzyszącego parametru ved (o którym więcej za chwilę, chociaż to temat na osobny artykuł) i okazało się, że każda para pochodziła z różnych wystąpień tego samego linku – różny czas (rzędu kilkudziesięciu sekund), różna pozycja na stronie, różna głębokość paginacji, a mimo to token identyczny co do bajtu.

To jest ważne, bo standardowe szyfrowanie z uwierzytelnianiem korzysta z losowego elementu przy każdej operacji – zaszyfrowanie tego samego tekstu dwa razy z rzędu normalnie da za każdym razem inny wynik. Tu tak się nie dzieje. Wskazuje to na użycie pozbawionego losowości wariantu szyfrowania z uwierzytelnianiem. Tak się składa, że Tink oferuje taki mechanizm zaprojektowany właśnie z myślą o przypadkach, gdzie ta sama wartość wejściowa musi zawsze dać ten sam zaszyfrowany wynik. Przykłąd wykorzystania: cache wygenerowanego tokennu zamiast szyfrowania go od nowa z każdym renderem strony wyników. To oczywiście wniosek wyprowadzony z obserwacji.

Odkrycie 4: modyfikacja tokenu nie działa

Wziąłem działający token i zmieniłem 1 znak, żeby zobaczyć co się stanie. Stało się to, co podejrzewałem – błąd 🙂

Serwer Google odpowiedział kodem HTTP 400, czyli błąd żądania. Tyle i bardzo dobrze, bo każda modyfikacja ciphertextu jest wykrywana przy próbie odszyfrowania, zanim serwer w ogóle spróbuje zinterpretować zawartość. W praktyce oznacza to, że nie da się samodzielnie skonstruować działającego tokenu wskazującego na dowolny, wybrany przez siebie adres – bez znajomości tajnego klucza, który ma tylko i wyłącznie Google. Gdyby można było zrobić własny token, to zaprawdę, piękny byłby to cloaking ❤️

Błąd, który prawie zepsuł całą analizę 🙂

Chcę to opisać, bo uważam że przyznanie się do pomyłek w tego typu analizie jest równie ważne jak same odkrycia. Mianowicie chciałem sprawdzić, czy długość zaszyfrowanego tokenu ma jakikolwiek związek z długością prawdziwego adresu URL, do którego prowadzi.

Zebrałem 20 par: token + URL, do którego prowadził. Policzyłem korelację statystyczną między długością tokenu, a długością tego tekstu i wyszło ZERO. Dosłownie – współczynnik korelacji bliski 0, nawet lekko ujemny. Spróbowałem jeszcze porównać z wersją tekstu poddaną standardowej kompresji, z nadzieją że może Google kompresuje URL przed szyfrowaniem. Niestety 🙂

  cipher_len vs plain_len (surowy URL):        r = -0.0843
  cipher_len vs gzip(url).length:              r = -0.1275
  cipher_len vs deflate(url).length:           r = -0.1275

Na tej podstawie wyciągnąłem wniosek: może token wcale nie zawiera zaszyfrowanego adresu URL, tylko jakiś wewnętrzny identyfikator odsyłający do rekordu w bazie danych Google, a faktyczne przekierowanie dzieje się przez lookup po stronie serwera. Brzmiało to sensownie ale okazało się, że dane wejściowe były błędne. Cały zestaw 20 par, na którym oparłem wcześniejszy wniosek wyrzuciłem i zacząłem analizę od nowa 😀 Podwójna weryfikacja, zawsze!

Dane zweryfikowane bezpośrednim żądaniem

Wziąłem sam token, wysyłałem bezpośrednie zapytanie curl do https://www.google.com/goto?url=<token> z zablokowanym automatycznym podążaniem za przekierowaniem i odczytywałem nagłówek Location z odpowiedzi. Token i prawdziwy adres pochodziły z tego samego żądania.

Uzbierałem w ten sposób 16 w pełni wiarygodnych par token→prawdziwy adres. Policzyłem dla każdej różnicę między długością zaszyfrowanego tokenu a długością rzeczywistego adresu URL w bajtach.

Odkrycie 5: dwa czyste klastry

Dla dominującego klucza (ee47aa4d) różnica między długością tokenu, a długością prawdziwego adresu przyjmowała w mojej próbie dokładnie 2 wartości: 35 bajtów albo 56 bajtów. Żadnych wartości pośrednich. Różnica między klastrami: dokładnie 21 bajtów.

• Klaster z narzutem 35 obejmował krótkie adresy i 1 z najdłuższych w całej próbie;
• Klaster z narzutem 56 – to coś innego niż sama długość linku decyduje, do którego wariantu trafia dany token. Szczerze mówiąc, nie wiem co. Sprawdziłem typ strony, protokół, długość domeny i żadna nie dała jednoznacznego podziału na 16 testowanych próbkach

Dla drugiego zweryfikowanego klucza (5826ba61) miałem tylko dwie próbki i dały identyczny narzut – 60 bajtów mimo różnych długości adresów.

Najbardziej prawdopodobne wytłumaczenie istnienia 2 klastrów w obrębie jednego klucza: to szyfrowana jest jakaś mała struktura zawierająca URL plus dodatkowe, opcjonalne pole długości około 21 bajtów, obecne w części, ale nie wszystkich przypadków. Czym jest to pole – nie wiem. Dlatego to tylko hipoteza, a nie fakt.

Odkrycie 6: jeden bajt różnicy, który potwierdził coś ważnego

Wśród 16 próbek jedna wyłamywała się z opisanego wyżej wzorca – link do Facebooka, o długości adresu 135 znaków dał narzut 36 bajtów zamiast 35 dla swojego klastra.

W Protobuf pole zawierające tekst ma z przodu zapisaną swoją długość jako liczbę typu varint – a ten format koduje wartości do 127 na jednym bajcie i od 128 wzwyż potrzebuje już dwóch bajtów. Adres Facebooka przekracza tę granicę i zaobserwowany narzut wzrósł dokładnie o jeden bajt.

Wnioskuję, że to bezpośrednia konsekwencja sposobu kodowania długości pola w Protobuf. To co jest szyfrowane, samo w sobie jest zapisane jako struktura Protocol Buffers, w której adres URL jest jednym z pól tekstowych, a nie surowym i niestrukturyzowanym ciągiem znaków. Gdyby było inaczej, przekroczenie akurat tej konkretnej granicy (128) nie miałoby żadnego powodu wpływać na długość wyniku w sposób inny niż zwykłe dodanie tylu bajtów, o ile URL się wydłużył.

Co robi równolegle parametr ved, i dlaczego to dobra wiadomość

Osobno od całego tego śledztwa, każdy wynik wyszukiwania Google od dawna ma też parametr ved. Zdekodowałem go i potwierdziłem, że zawiera m.in. precyzyjny znacznik czasu w mikrosekundach. Wartości był dokładną datą i czasem, kiedy zbierałem próbki. Ved zawiera też typ linku, pozycję wyniku, stronę paginacji.

UWAGA! ved nie zmienił się i nie jest częścią tego eksperymentu. Nowy, szyfrowany token /goto odpowiada za bezpieczne przekierowanie do adresu docelowego. Cała reszta telemetrii – pozycja, czas, typ wyniku – nadal jest jawna i możliwa do zdekodowania.

To rozdzielenie ma sens, bo Google nie przebudowuje całej infrastruktury śledzenia kliknięć, tylko dokłada kolejną warstwę do adresu URL.

Czego jestem pewny

Zbieram to w jedną listę, żeby było jasne, co jest twardym faktem, a nie wrażeniem:

1. Google testuje na ograniczonej grupie użytkowników mechanizm przekierowań /goto?url=
2. Token to poprawna struktura Protocol Buffers (Protobuf) z 2 polami – stałą flagą logiczną i blokiem danych zmiennej długości. Ten blok ma format zgodny z wyjściem biblioteki kryptograficznej Tink, z 4 rotacyjnie używanymi identyfikatorami kluczy
3. Szyfrowanie jest całkowicie przewidywalne – ten sam cel zawsze daje identyczny token, niezależnie od kontekstu wyświetlenia
4. Token jest chroniony przed modyfikacją – zmiana jednego znaku daje błąd zamiast błędnego przekierowania
5. Długość tokenu względem długości prawdziwego adresu układa się w dyskretne klastry, różniące się o stałe wartości, z dodatkowym, matematycznie uzasadnionym skokiem przy przekroczeniu 128 znaków adresu
6. Parametr ved pozostaje niezmieniony i niezależny od tego mechanizmu

Czego nie jestem pewny

1. Nie wiem czy to naprawdę jest biblioteka Tink, czy tylko coś o identycznym formacie nagłówka.
2. Jaki dokładnie algorytm szyfrujący stoi za obserwowanym brakiem losowości
3. Co konkretnie różni linki trafiające do klastra narzutu 35 od tych trafiających do klastra 56 – sprawdziłem kilka oczywistych hipotez i żadna się nie potwierdziła na mojej niewielkiej próbie
4. Czy 4 zidentyfikowane klucze rotują w czasie, czy działają równolegle dla różnych segmentów infrastruktury.
5. Czy mechanizm obejmuje coś poza zwykłymi wynikami organicznymi – cała moja próba dotyczyła wyłącznie tego typu wyników. Nie wiem, czy i kiedy (jeśli w ogóle) trafi to do pełnego wdrożenia

Co z tego wynika dla kogoś, kto robi SEO na co dzień?

Chcę być tu szczery, bo najłatwiej byłoby teraz dopisać sekcję „5 rzeczy, które musisz zrobić już dziś” żeby ten tekst wyglądał na bardziej praktyczny niż jest 😀

Jedyna konkretna, praktyczna rada, jaką mogę uczciwie dać, to: jeśli zarządzasz kampaniami płatnymi, warto pilnować, czy ten mechanizm pojawi się u ciebie w linkach reklamowych. Dane z Ahrefs pokazują równoległy wzrost płatnego ruchu (paid traffic) dla /goto do 5,5 miliona.

Myślę, że jest to sygnał wystarczająco konkretny, żeby nie czekać już bezczynnie na potwierdzenie, tylko zacząć to sprawdzać aktywnie.

Po co więc ta analiza

Niewiele praktycznych wniosków ale napisałem to ponieważ:

1. Jeśli mechanizm „goto” faktycznie trafi kiedyś do szerszego wdrożenia, to będzie wtedy fala artykułów pisanych na szybko. Wolę żeby istniał w sieci tekst, który faktycznie rozłożył to na czynniki pierwsze zanim to się stanie
2. Uważam, że to jest ciekawe samo w sobie, niezależnie od (bez)użyteczności. Rozbieranie na czynniki pierwsze nieznanego formatu, łapanie się na własnych błędach metodologicznych po drodze i w końcu znalezienie czegoś tak konkretnego jak matematyczny próg przy 128 bajtach, to jest dla mnie wystarczający powód, żeby to opisać, nawet gdyby nikt inny nie znalazł w tym praktycznej wartości
3. Temat mnie zainteresował, a może akurat coś bym odkrył 🙂

Skoro mowa o grzebaniu i odkryciach, to polecam inne moje artykuły, które są dogłębnym researchem i niosą praktycznie wnioski dla specjalistów SEO

• unicornClicks – sygnał kliknięć dzieci – Analiza dokumentacji i dekompilacja aplikacji mobilnych
• Google zaindeksował ponad pół miliona URLi z parametrem /gtm_latency=1, a nie powinien!
• Viewport Googlebota – czyli inżynieria wsteczna Web Rendering Service
• Wielowymiarowa rola kliknięć w ocenie i rankingu – czyli dogłębna analiza sygnałów interakcji użytkowników w Google
• Roboty AI ignorują LLMS.txt ale skanują internet na potęgę
• Ukryte w kodzie źródłowym 13 kategorii intencji użytkownika Bing Webmaster Tools

1. Google dodało disallow do pliku robots.txt po 19.07.2026 – stary plik robots.txt bez ten zmiany na WebArchive.org ↩︎