Kliknięcie w wynik organiczny Google nie prowadzi już bezpośrednio na Twoją stronę. Od 26 sierpnia 2026, kiedy Google potwierdził wdrożenie, każdy link w wynikach przechodzi przez google.com/goto?url= z zakodowanym tokenem, a dopiero serwer Google odsyła przeglądarkę na właściwy adres. Dla użytkownika nic się nie zmienia, dla rankingów też nie. Zmienia się to, co widzą narzędzia, które czytają wyniki z HTML-a, i to jest jedyny obszar, w którym trzeba coś sprawdzić. Ten tekst oddziela to, co Google potwierdził, od tego, co branża dopowiada, i mówi, co konkretnie sprawdzić w analityce i w WordPressie.
Co Google potwierdził, a co jest domysłem
Potwierdzenie jest jedno i krótkie. W odpowiedzi dla Search Engine Land z 26 sierpnia 2026 Google napisał:
We have a long history of deploying technical measures against evolving forms of abuse, and we regularly take steps to protect our services and users.
(Glosa: mamy długą historię wdrażania środków technicznych przeciwko rozwijającym się formom nadużyć i regularnie podejmujemy kroki, żeby chronić nasze usługi i użytkowników.)
To wszystko. Nie ma dokumentacji, nie ma opisu formatu tokenu, nie ma polityki referrera, nie ma daty rozpoczęcia. Reszta pochodzi z obserwacji, i warto wiedzieć, czyich.
| co wiemy | źródło | status |
|---|---|---|
link ma postać google.com/goto?url= z zakodowanym tokenem | obserwacje SEO od czerwca 2026 | potwierdzone wielokrotnie |
| serwer odpowiada przekierowaniem 302 na docelowy adres | obserwacje narzędzi | potwierdzone |
| tokenu nie da się odkodować lokalnie | Nozzle, SerpAPI | potwierdzone przez próby |
| wdrożenie bliskie 100 procent na adresach rezydencjalnych | Derek Perkins, Nozzle | pomiar jednej firmy |
| Search Console bez zmian | Search Engine Land | relacja, nie dokument |
| polityka referrera | nikt | nieznana |
Pierwsze zgłoszenia pochodzą z 23 czerwca (Alex Greenland) i 2 lipca (Brodie Clark), więc od pierwszej obserwacji do potwierdzenia minęły dwa miesiące. Google nazwał to środkiem przeciw nadużyciom, a kontekst jest czytelny: firma pozwała wcześniej SerpAPI za scraping i przegrała kluczowe roszczenia z DMCA. Skoro sąd nie zablokował czytania wyników, zrobiła to technika.
Mechanizm, w trzech krokach
Do 26 sierpnia link w wyniku organicznym był zwykłym <a href="https://twojastrona.pl/wpis/">. Narzędzie, które pobrało HTML wyników, miało od razu listę adresów i pozycji.
Teraz href prowadzi na https://www.google.com/goto?url= i dalej ciąg znaków, który wygląda jak base64, ale nie jest nim w żadnej publicznie znanej postaci. Przeglądarka wysyła żądanie na ten adres, serwer Google odpowiada kodem 302 z nagłówkiem Location na właściwą stronę, przeglądarka podąża. Użytkownik widzi jedno kliknięcie i jedną stronę. W pasku statusu przed kliknięciem widzi jednak adres Google, nie Twój, i to jedyna widoczna dla niego różnica.
To nie jest nowy pomysł. Google Ads od lat prowadzi kliknięcia reklamowe przez własny adres pośredni, a w wynikach organicznych podobne przekierowanie /url?q= pojawiało się dla zalogowanych użytkowników już około 2009 roku, tyle że z adresem docelowym zapisanym otwartym tekstem. Nowością nie jest przekierowanie, tylko to, że adres docelowy przestał być czytelny bez wykonania żądania.
Referrer: dlaczego apokalipsa nie nadeszła w sierpniu, bo nadeszła w 2011
Najwięcej alarmistycznych tekstów dotyczy referrera i atrybucji. Warto to ostudzić dwoma faktami.
Po pierwsze, Google nie opublikował polityki referrera dla goto. Każdy artykuł, który mówi z pewnością, co zobaczysz w Google Analytics, opisuje własne obserwacje, nie zasadę.
Po drugie, i ważniejsze: dane, których miałbyś teraz stracić, straciłeś dawno temu. W 2011 roku Google przestał przekazywać zapytanie w referrerze dla zalogowanych użytkowników (słynne „not provided”), a w kolejnych latach rozszerzył to na cały ruch. Od tego czasu przeglądarka dostaje od Google tylko origin, czyli https://www.google.com/, bez ścieżki i bez parametrów. GA4, Matomo, Umami i Plausible od lat klasyfikują taką wizytę jako google / organic wyłącznie na podstawie domeny. Przekierowanie przez google.com/goto nie zmienia domeny.
Nasze własne dane nic tu nie wniosą, i mówimy to wprost: w Umami na wppoland.com nie zbieramy referrera w ogóle, pole source oznacza u nas miejsce na stronie, z którego poszło zdarzenie, nie skąd przyszedł użytkownik. Ruchem z wyszukiwarki zarządzamy z Search Console, a ta, według relacji Search Engine Land, przekierowań goto nie widzi, bo liczy kliknięcia z własnych logów, nie z HTML-a.
Co sprawdzić, jeśli używasz GA4 albo innego narzędzia z referrerem: porównaj udział google / organic w tygodniu 8 do 17 sierpnia z tygodniem 22 do 31 sierpnia. Jeśli udział spadł, a w tym samym oknie kliknięcia w Search Console zostały na miejscu, to znaczy, że część wizyt zmieniła klasyfikację, i wtedy warto szukać dalej. Jeśli oba wykresy trzymają się razem, nie ma czego naprawiać. U nas kliknięcia z Search Console w tych dwóch oknach to 223 i 226, więc po stronie Google nic nie drgnęło.
Narzędzia do pozycji: to tutaj jest prawdziwy koszt
Rank tracker, który do tej pory wykonywał jedno żądanie na zapytanie i czytał sto adresów z HTML-a, dziś dostaje sto tokenów. Żeby dowiedzieć się, kto jest na pozycji siódmej, musi wykonać żądanie na google.com/goto dla siódmego tokenu i przeczytać nagłówek Location. Dla całej pierwszej strony i bloków dodatkowych Nozzle wycenia to na 500 do 1000 żądań na jedno zapytanie.
Konsekwencje są trzy i każda z nich pojawi się w Twoich raportach w innej formie.
Pierwsza to koszt, który narzędzia przerzucą na ceny albo na częstotliwość odczytu. Codzienny pomiar może stać się pomiarem co trzy dni bez komunikatu, a wykres pozycji zacznie wyglądać na schodkowy.
Druga to luki. Google ogranicza częstotliwość żądań na adresach rezydencjalnych, więc narzędzie, które musi wykonać tysiąc żądań zamiast jednego, częściej trafi na blokadę w środku odczytu. W raporcie zobaczysz wynik dla pozycji 1 do 4 i brak danych dalej, albo pozycję „nie znaleziono” dla strony, która w Search Console ma kliknięcia z tego samego dnia.
Trzecia to zmienność, która nie jest zmiennością rankingów. Jeśli narzędzie próbkuje, a nie mierzy, dwa kolejne odczyty tej samej frazy mogą się różnić, bo różniła się próbka, nie SERP. Sierpniowe fale „niepotwierdzonej zmienności”, które opisywał Barry Schwartz 1 do 3, 5 do 6 i 12 do 13 sierpnia, przypadają dokładnie na okres testów goto. Nie twierdzimy, że to jedyna przyczyna. Twierdzimy, że narzędzie, które w tym okresie zmieniało metodę odczytu, nie jest wiarygodnym świadkiem zmienności rankingu.
Praktyczna reguła: od 26 sierpnia Search Console jest jedynym źródłem, które nie zmieniło metody. Jeśli rank tracker i Search Console się nie zgadzają, to Search Console ma rację, a tracker ma lukę. Zanim zgłosisz klientowi spadek pozycji, porównaj wyświetlenia i średnią pozycję dla tej samej strony w Search Console za ten sam dzień.
Co to zmienia w WordPressie: nic, z dwoma wyjątkami
Żaden plik motywu, żadna wtyczka i żadne ustawienie serwera nie ma wpływu na to, jak Google buduje link w swoich wynikach. Nie trzeba niczego przebudowywać, nie trzeba dodawać nagłówków, nie ma nic do „optymalizacji pod goto”. Jeśli ktoś sprzedaje Ci taką usługę, sprzedaje powietrze.
Dwa wyjątki dotyczą wtyczek, które opierają logikę na referrerze.
Pierwszy to stare wtyczki pokazujące „frazę, z której przyszedł użytkownik” i podświetlające ją w treści. Pracują na parametrze q z referrera, którego Google nie wysyła od 2011 roku. Były martwe przed goto i są martwe po. Jeśli nadal masz taką aktywną, usuń ją, bo obciąża każde żądanie i nic nie daje.
Drugi to wtyczki A/B i personalizacji, które sprawdzają, czy referrer zawiera google., żeby pokazać inny wariant strony. One dalej dostają origin google.com, więc warunek działa, ale po 26 sierpnia warto go zweryfikować na żywo: otwórz wynik z Google w trybie prywatnym i sprawdź w logach serwera albo w narzędziach deweloperskich, jaki Referer przyszedł. Pięć minut, a odpowiedź jest twarda, nie z artykułu.
Jest jeszcze jedna rzecz, o której nikt nie pisze: pamięć podręczna i przekierowania własne. Jeśli Twój serwer ma regułę, która traktuje żądania z nietypowym referrerem jako podejrzane (niektóre konfiguracje ochrony przed hotlinkowaniem i część reguł w zaporach aplikacyjnych), sprawdź, czy google.com z goto w ścieżce referrera nie trafił na listę blokowanych. To rzadkie, ale skutkiem byłby błąd 403 dla użytkowników z wyszukiwarki, a taki błąd Search Console pokaże z opóźnieniem tygodni.
Czego nie wiemy i jak działać mimo to
Nie znamy formatu tokenu ani tego, czy Google zamierza go kiedyś udokumentować. Nie wiemy, czy przekierowanie obejmie wszystkie kraje i typy wyników, czy tylko główne linki organiczne. Nie wiemy, jaki jest cel poza ogólnym „przeciw nadużyciom”, choć ciąg zdarzeń wokół SerpAPI podpowiada odpowiedź. I nie wiemy, jak zachowają się przeglądarki w kolejnych wersjach, bo polityka referrera dla przekierowań 302 zależy od nich, nie od Google.
Decyzja operacyjna nie zależy od żadnej z tych luk. Rankingi są takie same jak przed 26 sierpnia. Search Console pokazuje to samo co przed. Użytkownik trafia tam, gdzie trafiał. Jedyne, co się zmieniło, to wiarygodność narzędzi czytających wyniki z zewnątrz, i tam trzeba przenieść ciężar dowodu: z trackera na Search Console.
Trzy czynności, które zamykają temat:
- Porównaj w GA4 albo w swoim narzędziu udział ruchu organicznego z Google w oknach przed i po 26 sierpnia. Jeśli spadł, a kliknięcia w Search Console nie, masz problem klasyfikacji do zbadania. Jeśli nie spadł, temat zamknięty.
- Sprawdź daty i luki w rank trackerze od 20 sierpnia. Każdy raport dla klienta z tego okresu powinien mieć kolumnę z pozycją z Search Console obok pozycji z narzędzia.
- Usuń wtyczki, które opierają się na frazie z referrera, i zweryfikuj na żywo te, które sprawdzają domenę referrera.
Google zabrał narzędziom mapę wyników, nie Tobie ruch. To jest różnica między zmianą, na którą trzeba zareagować, a zmianą, o której trzeba wiedzieć. Ta jest tą drugą.
