Podsumowanie w 30 sekund
26 sierpnia 2026 r. Google potwierdził, że linki w wynikach wyszukiwania przechodzą teraz przez google.com/goto?url=[zaszyfrowany token], zanim dotrą do celu. Opisał to Barry Schwartz w Search Engine Roundtable i Search Engine Land, a rzecznik Google potwierdził, że to część „długoterminowych środków technicznych przeciwko ewoluującym formom nadużyć".
Jeśli Twój zespół wyciąga docelowe adresy URL z wyników wyszukiwania Google (śledzenie pozycji, scraping SERP, zbieranie danych dla AI), właśnie pękło jedno założenie: prawdziwy URL nie jest już widoczny w linku. Jest zaszyfrowany w tokenie, który przeglądarka podąża jak zwykłe przekierowanie.
Dobra wiadomość: to da się naprawić, a naprawa jest mniejsza, niż większość sądzi. Tokenu nie da się odszyfrować, ale da się go rozwiązać jednym dodatkowym żądaniem HTTP, a ponieważ jest deterministyczny — zakeszować. Ten artykuł przeprowadzi Cię przez 30-minutową naprawę: wykryj zmianę, rozwiąż ją bezpiecznie i upewnij się, że raporty wciąż pokazują właściwe strony. Jeśli nie scrapujesz SERP i nie porównujesz pozycji z adresami URL wyciągniętymi z tych stron, przeskocz do „Czego zmiana nie dotyczy". Na Twojej stronie nic się nie zmienia.
Co dokładnie się zmieniło
Przez lata link wyniku Google niósł prawdziwy cel w samym linku:
<a href="https://yoursite.com/landing-page?utm_...">...Teraz ten sam wynik może nieść link tranzytowy:
<a href="https://www.google.com/goto?url=TtFp1Lc2026...*">...Po wejściu Google zwraca przekierowanie HTTP do celu. Dwa ważne punkty dotyczące działania:
- Token jest zaszyfrowany i odporny na manipulację. Według niezależnego reverse engineeringu (opublikowanego w sierpniu 2026 r.) składa się z jednobajtowego znacznika, czterobajtowego identyfikatora klucza i danych w formacie Tink. Zmienisz jeden znak — Google odpowie HTTP 400. Bez kluczy Google nie da się ani podrobić tokenu, ani zdekodować URL-u.
- Token jest deterministyczny. Ten sam docelowy URL zawsze generuje ten sam token. To samo czyni całą naprawę tanią: rozwiąż raz, potem używaj cache tokenów.
Derek Perkins z Nozzle zaobserwował wdrożenie bliskie „100%" u kilku dostawców rezydencjalnych IP — i właśnie dlatego tym razem to więcej niż eksperyment.
Co przetrwa zmianę
Nadal czytelne | Zniknęło |
|---|---|
URL wyświetlany pod snippetem (zwykle domena) | Dokładny docelowy URL w |
Parametr | Bezpośrednie dopasowanie URL na poziomie linku |
Tytuły wyników, snippety, pozycje | Wszelkie dekodowanie linków po stronie klienta |

To, że parametr ved przetrwał, zasługuje na uwagę: dane o pozycji i typie kliknięcia, które narzędzia śledzące czytały z linków wyników, wciąż są na miejscu. Ukryty jest tylko docelowy URL.
Czego zmiana nie dotyczy
- Pozycje i ruch. System rankingu Google nie ma nic wspólnego z tym, jakie linki renderuje.
- Dane Google Search Console. Pozycje, wyświetlenia i kliknięcia w GSC pochodzą z wewnętrznych danych Google i nie są naruszone.
- Boty odwiedzające Twoją stronę. Googlebot, GPTBot i każde boty crawlonowe Twoich stron nie dotykają
google.com/goto. Pojawia się tylko w linkach, które Google Ci pokazuje. - Bing i inne wyszukiwarki. To zmiana wyłącznie po stronie Google.
Dotknięte są tylko osoby prowadzące pipeline'y czytające linki z tabel wyników Google. Jeśli jesteś jedną z nich — to poczujesz; jeśli nie — to tylko szum.
Sprawdź, czy Cię to dotyczy
Wykonaj cztery kontrole. Pierwsze dwie zajmują pięć minut; ostatnie dwie to rozmowa z dostawcą.
Kontrola | Jak | Jeśli widzisz to |
|---|---|---|
1. Surowe dane SERP | Poszukaj | Jakiekolwiek wystąpienie = Twoje źródło już tokenizowane |
2. Żywa próbka SERP | Odpal zwykłe zapytanie, kliknij prawym przyciskiem wynik i skopiuj link | Link |
3. Kolumna URL w narzędziu | Otwórz ostatni raport słów kluczowych: czy kolumna URL pokazuje | Narzędzie przechowuje linki tranzytowe |
4. Wzorce dryfu pozycji | Porównaj zmiany śledzonych URL w tym tygodniu z rzeczywistymi zmianami na Twojej stronie | Duże rozjazdy po spokojnym tygodniu = problem parsera, nie zmiana pozycji |
Jeśli wszystko czyste — to nie Twoja sprawa: dodaj tę stronę do zakładek i idź dalej.
Jeśli znajdziesz wystąpienie, kolejne cztery kroki przywrócą pipeline'owi precyzję. Każdy krok mówi, co zrobić, jak wygląda dobry wynik i jak się odbić, gdy nie wychodzi.

Krok 1: Wykryj tokeny tam, gdzie się pojawiają
Co zrobić. W swoim skrypcie ekstrakcji SERP zbierz wszystkie linki wyników i zaznacz wszystko, co zaczyna się od https://www.google.com/goto?url= (dopasuj też gołe /goto?url= pojawiające się na niektórych powierzchniach oraz url= po którym następuje ładunek w stylu base64). Zapisuj wskaźnik zaznaczeń na zapytanie — to Twój wskaźnik wdrożenia. I z obserwacji Dereka Perkinsa: wdrożenie nie jest równomierne między zakresami IP, więc śledź per dostawca, nie agregatowo.
Oczekiwany wynik. Jeden goto_rate na zapytanie. 0% oznacza, że źródło wciąż zwraca bezpośrednie linki; 100% — pełną tokenizację.
Kontrola jakości. Uruchom to samo zapytanie dwa razy z dwóch różnych IP. Jeśli jedno jest tokenizowane, a drugie nie, doszło do podziału zakresów IP i trzeba obsłużyć obie strony.
Odbicie. Jeśli próbka daje zero wystąpień, ale podejrzewasz tokenizację, sprawdź, czy Twoja ekstrakcja czyta DOM renderowany przez JavaScript zamiast surowego HTML. Tokeny mogą pojawić się w wyrenderowanym markupie, nawet gdy surowa odpowiedź pozostaje w starym formacie.
Krok 2: Rozwiąż jeden token jednym przekierowaniem
Co zrobić. Gdy wynik niesie token, podążaj za linkiem po stronie serwera z wyłączonym śledzeniem przekierowań i przeczytaj nagłówek Location:
curl -sI "https://www.google.com/goto?url=TtFp1Lc..." | grep -i locationOdpowiedź to HTTP 3xx do prawdziwego celu. Zachowaj ją. Dwie zasady czynią ten krok tanim i bezpiecznym:
- Cache wg tokenu, nie wg URL. Ponieważ tokenizacja jest deterministyczna, wystarczy jedno rozwiązanie na token. Zapisz
token -> resolved_urli używaj go dalej. - Nigdy nie crawluuj `google.com/goto` jako strony. Google dodał
Disallow: /goto?do własnego robots.txt pod koniec lipca 2026 r. Ten adres wprost nie jest przeznaczony do pobierania przez boty; dobry fetcher lekko podąża za linkiem-tokenem i czyta tylko łańcuch przekierowań; zepsuty fetcher indeksuje lub archiwizuje sam URL goto i śmieci w Twoich danych. Do końca lipca prawie 3 750 takich URL było już zaindeksowanych na samym google.com.
Kontrola kosztów przed startem: pierwszy przebieg po SERP z setkami wyników to setki dodatkowych żądań do google.com — dokładnie ten rodzaj obciążenia, które śledzi detekcja botów Google. Deterministyczny cache ogranicza to do jednego żądania na unikalny token, więc nie oszczędzaj na tym kroku.
Oczekiwany wynik. Stabilna tabela mapowania między tokenami a celami. Sprawdź dziesięć losowych tokenów w przeglądarce: każdy powinien prowadzić na sensowną stronę.
Kontrola jakości. Potwierdź, że długość tokenu jest stabilna między różnymi URL-ami i że identyczne docelowe URL-e zawsze dają ten sam token. Jeśli mapowanie się psuje — była rotacja kluczy (patrz Krok 5).
Odbicie. Token zwracający 400 jest podrobiony, ucięty lub pochodzi z wygasłej sesji; zrób ponownie scraping SERP i spróbuj znowu. Dwa kolejne błędy zwykle oznaczają przeterminowany HTML w archiwum, nie zepsuty token.
Krok 3: Przechowuj cel, nie opakowanie
Co zrobić. Reszta pipeline'u (mapowanie słowo kluczowe-strona, kontrole indeksacji, audyt schematów) musi widzieć docelowy URL. Po Kroku 2 przechowuj więc trzy pola na wynik: resolved_url, token i accessed_at. Usuń linki goto z kolumny URL każdego raportu; URL google.com w raporcie słów kluczowych to błąd jakości danych w kilkunastu postaciach.
Jeśli w tym tygodniu nie możesz dodać resolvera, bezpiecznym krokiem pośrednim jest całkowite pominięcie celu zamiast przechowywania tokenu: dane o pozycjach i rankingach pozostają znaczące, tylko kolumna URL zostaje pusta. Narzędzie, które uczciwie pisze „brak URL", jest znacznie łatwiejsze do interpretacji niż takie, które zgłasza ciąg tokenu jako prawdziwy adres.
Oczekiwany wynik. Raport, w którym 100% wierszy to URL-e http(s) Twoich domen i zero wierszy google.com.
Kontrola jakości. Porównaj dane na poziomie URL z Search Console dla dziesięciu słów kluczowych. Wiersze muszą się zgadzać. Jeśli Search Console daje pozycję URL-owi, który Twój raport nazywa „nie znaleziono", jest dziura w resolverze lub parserze.
Odbicie. Jeśli niewielka część URL-i wciąż się nie rozwiązuje, rejestruj ich tokeny osobno. Większość niepowodzeń prowadzi do dwóch winowajców z Kroku 2: przeterminowany HTML albo ściana detekcji botów przy kolejnym żądaniu.
Krok 4: Sprawdź, co robi Twój dostawca
Co zrobić. Jeśli opierasz się na narzędziu do śledzenia pozycji lub SERP API (także tych zbudowanych na sczaniowanych danych Google), wdrożenie trwa od tygodni. Zadaj te pięć pytań i zestawiaj z nimi każdą zmianę w raportach:
Pytanie | Dobra odpowiedź | Uwaga |
|---|---|---|
Czy rozwiązujecie tokeny | Tak, przed zwróceniem wyników | „Wysyłamy URL-e tak jak są" |
Czy kolumna URL może zawierać | Nigdy | „Rzadko" = wciąż zepsute |
Czy cache'ujecie rozwiązane tokeny? | Tak, bo są deterministyczne | Rozwiązywanie przy każdym wywołaniu pali kredyty |
Czy kredyty lub ceny zmieniają się przez przekierowania? | Brak planowanych zmian | Dopłata za każde podążenie |
Czy używacie IP rezydencjalnych? | Tak | IP z centrów danych tokenizowano wcześniej i mogą być traktowane inaczej |
Oczekiwany wynik. Albo potwierdzona naprawa, albo jasny powód do przejścia. W ciągu 30 dni powinieneś móc scalać URL-e z raportów z logiem zmian serwisu bez szumu.
Ścieżka powrotna. Bez poprawy od dostawcy w ciągu tygodnia: podmień ten punkt danych na Google Search Console API dla pozycji, bo pochodzi wprost z danych Google i nigdy nie widzi tokenu. Cena to odrobinę mniej szczegółu na poziomie linku; akceptowalne, jeśli Twoje decyzje wymagają precyzji, a nie funkcji zewnętrznych.
Krok 5: Obserwuj następny krok
Mechanizm nie stoi w miejscu. Śledź co miesiąc trzy rzeczy:
- Rotacja kluczy. Próbka reverse engineeringu znalazła w obiegu cztery identyfikatory kluczy, z jednym dominującym („ee47aa4d", około 62% tokenów). Jeśli pojawi się piąty klucz i dominujący udział się przesunie — spodziewaj się unieważnienia cache: rozwiąż tokeny ponownie przy rotacji.
- Rozszerzenie na inne powierzchnie.
/gotozaobserwowano też w linkach sponsorowanych i innych typach wyników. Jeśli Twoje narzędzia dotykają reklam lub obrazów, poszerz wyszukiwanie z Kroku 1. - Ciągłe twardnienie. To część dłuższej serii: wymuszony render JavaScript (początek 2025), start SearchGuard, zamknięcie
&num=100(wrzesień 2025) i akcja DMCA na podstawie Section 1201 przeciw SerpApi (grudzień 2025). Każdy punkt jest udokumentowany osobno; artykuł o reverse engineeringu zbiera większość. Spodziewaj się, że zdobycie finalnego URL będzie trudniejsze, nie łatwiejsze.
Weryfikacja końcowego wyniku
- [ ] Detektor z Kroku 1 działa w CI lub harmonogramie i loguje
goto_ratena zapytanie - [ ] Wszystkie tokeny z próbki rozwiązują się do prawdziwych celów, sprawdzone w przeglądarce
- [ ] Zero URL-i
google.com/gotow Twoich raportach (grep z ostatniego eksportu) - [ ] Dziesięć słów kluczowych zgadza się z Search Console wiersz po wierszu
- [ ] Dostawca potwierdził strategię rozwiązania lub dane o pozycjach idą przez GSC API
- [ ] W Twoim miesięcznym rytmie jest dedykowana kontrola rotacji kluczy
Częste pytania
Czy to wpływa na moje pozycje lub ruch? Nie. Zmienia się ścieżka kliknięcia; system rankingu, wyniki i to, co widzi pytający, nie zmieniają się. Twoje organiczne wyniki są zagrożone tylko wtedy, gdy narzędzie, które obsługujesz, zacznie zgłaszać złe dane.
Czy da się zdekodować token goto? Z zewnątrz nie. To zaszyfrowany ładunek w formacie Tink, a zmiana jednego znaku zwraca HTTP 400, więc podrobienie też nie wchodzi w grę. Wykonalna droga to podążyć za przekierowaniem i przeczytać nagłówek Location — dokładnie to robi przeglądarka.
Czy scraper może podążać za linkami `/goto`? W praktyce to samo robi kliknięcie w przeglądarce, ale Google zablokował /goto? w swoim robots.txt, a regulamin ogranicza zautomatyzowany dostęp do wyników wyszukiwania. Jeśli scrapujesz SERP, już jesteś po złej stronie tych regulaminów; to wdrożenie tego nie zmienia — tylko utrudnia. Wybierz swoją postawę zgodności, zanim zbudujesz resolver.
Czy muszę coś zmienić na swojej stronie? Nie. Zmiana leży w całości w linkach, które renderuje Google. Do sprawdzenia są narzędzia, które czytają SERP w Twoim imieniu — to Krok 4.
Autorka: Olivia Stone, badaczka inteligencji SERP w Auspia (analizuje ponad 25 000 zapytań). Pisze o analizie SERP, wzorcach rankingu i o tym, jak zmiany w wynikach wyszukiwania wpływają na dane pozycji.












