Google indeksuje strony z parametrem gtm_latency=1, a nie powinien!

Wszystko zaczęło się od jednej linijki w logach serwera.

Przeglądając ruch Googlebota na jednej z analizowanych stron, zauważyłem coś dziwnego. Robot odwiedzał adresy URL z parametrem ?gtm_latency=1, którego nigdzie nie było w strukturze serwisu:

• W linkowaniu wewnętrznym nie mam takiego parametru
• Żadna mapa strony go nie zawierała (i nie zawiera)
• Parametr ?gtm_latency=1 dosłownie pojawił się znikąd, a właściwie został dodany przez samego Googlebota, o czym dowiedziałem się później

Pierwszy raz Googlebot odwiedził adres z tym parametrem 15.08.2025 o 01:49.

Szybkie wyszukiwanie w Google nie dało odpowiedzi. W dokumentacja Google Tag Manager nie ma o tym informacji. Fora SEO nie znają tematu. Zapytałem znanych mi specjalistów SEO ale też nie znają parametru. Dokładnie 18 sierpnia 2025 zapytałem społeczność na LinkedIn… no była próba pomocy ale podobne twierdzenia dostawałem od AI, co kompletnie mnie nie usatysfakcjonowało, bo podchodzi to pod halucynacje.

Następnie dnia 21 sierpnia 2025 napisałem na LinkedIn nowy post wyjaśniający co to jest parametr ?gtml_latency=1 z drobnymi informacjami technicznymi oraz protipem aby nie blokować tego parametru w robots.txt

Odczekałem miesiąc i na LinkedIn pojawiła się nowa publikacja, tym razem w języku angielskim, w której wprost oznaczyłem takie osobistości jak Barry Schwartz oraz John Mueller pytając o ten parametr ponieważ w Google już było zaindeksowanych ponad 166k stron.

Zapytałem:

• Co stoi za rosnącą indeksacją stron z parametrem gtm_latency?
• Dwa lata temu Gary Illyes wspomniał, że GoogleOther miał odciążyć główny indeks od zadań niezwiązanych z wyszukiwaniem. Czy coś się zmieniło w sposobie, w jaki GoogleOther wpływa na wyniki wyszukiwania?

Jednak odpowiedzi nie uzyskałem, a mój post został… zignorowany 🥲

Dlaczego to powinno obchodzić każdego specjalistę SEO?

Jeśli pracujesz w SEO, wiesz jak istotna jest kontrola nad tym co trafia do indeksu. Duplicate content, kanibalizacja, crawl budget, render budget to fundamenty technicznego SEO, a tutaj mamy sytuację, w której:

1. Google sam generuje warianty URLi poprzez dodawanie parametrów diagnostycznych
2. Te warianty trafiają do indeksu mimo że nie powinny
3. Strony bez poprawnego canonical mogą mieć realny problem z duplikacją
4. Nikt o tym nie mówi!

Także zaczynam 🙂

Czym jest ?gtm_latency=1

Przekopałem chyba pół internetu w poszukiwaniu wytłumaczenia i znalazłem dosłownie nic. Temat jest praktycznie nieobecny w publicznej przestrzeni. Kilka osób zadawało podobne pytania, ale bez odpowiedzi. Oficjalna dokumentacja Google Tag Managera na ten temat milczy. Nie znajdziesz go w żadnym przewodniku, FAQ ani artykule pomocy. Postanowiłem zajrzeć do kodu źródłowego gtm.js – to ten plik, który Google Tag Manager ładuje na każdej stronie z zainstalowanym kontenerem.

Co to jest parametr ?gtm_latency=1

?gtm_latency=1 to wewnętrzny parametr diagnostyczny Google Tag Managera, który aktywuje rozszerzone zbieranie danych telemetrycznych o wydajności i zachowaniu tagów na stronie.

Mówiąc prościej: to przełącznik, który mówi GTM „włącz tryb pełnego monitoringu”.

function il(a) {
    var b = String(a[mf.Na] || "").replace(/_/g, "");
    return Kb(b, "cvt") ? "cvt" : b
}

var jl = x.location.search.indexOf("?gtm_latency=") >= 0 || 
         x.location.search.indexOf("&gtm_latency=") >= 0;

var kl = Math.random(),
    ll, ml = dj(27);
ll = jl || kl < ml;

var nl, ol = dj(42);
nl = jl || kl >= 1 - ol;

var pl = function(a) {
    pl[" "](a);
    return a
};
pl[" "] = function() {};

var kl = Math.random();      // losowa wartość 0-1
var ml = dj(27);             // = 0.005 (czyli 0.5%)
ll = jl || kl < ml;          // true jeśli wylosowano < 0.005

https://www.googletagmanager.com/td?id=...&v=3&t=t&pid=...

HTTP/3 204 
date: Thu, 21 Aug 2025 08:47:40 GMT
pragma: no-cache
expires: Fri, 01 Jan 1990 00:00:00 GMT
cache-control: no-cache, no-store, must-revalidate
content-type: text/plain
cross-origin-resource-policy: cross-origin
server: Golfe2
content-length: 0

Co Google wie dzięki telemetrii GTM

Zbierając dane z trybu diagnostycznego, Google otrzymuje pełny obraz:

O stronie:

• URL i struktura
• Wersja i konfiguracja kontenera GTM
• Aktywne eksperymenty

O wydajności:

• Czasy ładowania skryptów
• Kolejność ładowania zasobów
• Pozycja GTM względem innych skryptów

O tagach:

• Lista wszystkich tagów w kontenerze
• Status wykonania każdego tagu (sukces/porażka/błąd)
• Czasy wykonania
• Zależności między tagami

O zgodach:

• Stan Consent Mode
• Zgodność z GDPR/RODO i DMA
• Historia zmian zgód
• Wpływ zgód na wykonanie tagów

O błędach:

• Które tagi zgłaszają błędy
• Typy błędów (exception, failure)
• Kontekst błędów

Pytanie brzmi: kto i dlaczego dodaje ten parametr do adresów URL podczas crawlowania?

GoogleOther – robot, który miał być niewidoczny

W 2023 roku Gary Illyes z Google oficjalnie ogłosił wprowadzenie nowego user-agenta: GoogleOther.

Zadaniem miało być odciążenie głównego Googlebota od zadań niezwiązanych bezpośrednio z wyszukiwarką. GoogleOther to robot przeznaczony do celów badawczo-rozwojowych (R&D) – testowania, eksperymentowania, zbierania danych diagnostycznych.

Gary Illyes o GoogleOther

Dodaliśmy nowego robota, GoogleOther, do naszej listy robotów, który ostatecznie odciąży Googlebota. To dla Ciebie zmiana bezużyteczna, ale i tak uważam, że ciekawa.

Optymalizując sposób i zakres indeksowania Googlebota, chcieliśmy zapewnić, aby zadania indeksowania Googlebota były wykorzystywane wyłącznie wewnętrznie do tworzenia indeksu używanego przez wyszukiwarkę. W tym celu dodaliśmy nowego robota indeksującego, GoogleOther, który zastąpi niektóre inne zadania Googlebota, takie jak indeksowanie w ramach prac badawczo-rozwojowych, aby zwolnić część zasobów indeksowania dla Googlebota.

Nowy robot korzysta z tej samej infrastruktury co Googlebot, a zatem ma te same ograniczenia i funkcje: ograniczenia obciążenia hosta, robotstxt (choć inny token agenta użytkownika), wersję protokołu HTTP, rozmiar pobierania i tak dalej. To w zasadzie Googlebot pod inną nazwą.

Dokładnie 20 kwietnia 2023 Gary Illyes napisał to na swoim profilu LinkedIn

To logiczne rozwiązanie, skoro Google chce testować strony, sprawdzać wydajność, przeprowadzać audyty techniczne – nie powinno to wpływać na to, co widzą użytkownicy w wynikach wyszukiwania.

Teoria brzmi sensownie. Praktyka wygląda inaczej.

Dane z logów serwera

Analizując logi serwera dla stron, na których zauważyłem parametr ?gtm_latency=1, zidentyfikowałem następujące wzorce:

Obserwacja:

Parametr ?gtm_latency=1 jest dodawany przez robota GoogleOther – dokładnie tego, który według Google miał być oddzielony od głównego indeksu.

Robot R&D wykonuje test diagnostyczny GTM. To pasuje do jego przeznaczenia.

Problem pojawia się w następnym kroku.

URLe wyciekają do głównego indeksu

Sprawdziłem, ile stron z parametrem ?gtm_latency=1 znajduje się w indeksie Google:

inurl:gtm_latency=1

Timeline wzrostu:

Pół miliona adresów URL z parametrem diagnostycznym w głównym indeksie Google.

To nie powinno się zdarzyć moim zdaniem 🙂

Czy to bug?

Niestety nie ma oficjalnego stanowiska Google w tej sprawie. Próbowałem uzyskać odpowiedź:

• Oznaczyłem Barry’ego Schwartza na LinkedIn – brak odpowiedzi
• Oznaczyłem Johna Muellera na LinkedIn – brak odpowiedzi
• Przeszukałem oficjalne kanały Google – brak wzmianki o problemie

Mogę jedynie spekulować na podstawie obserwacji:

Hipoteza 1: To niezamierzony bug

GoogleOther miał być odizolowany, ale gdzieś w pipeline’ie indeksowania następuje „wyciek” – URLe odwiedzone przez GoogleOther trafiają do głównego indeksu wbrew założeniom.

Hipoteza 2: Zmiana polityki

Google zmieniło sposób działania GoogleOther ale nie zakomunikowało tego publicznie. URLe są teraz celowo indeksowane.

Hipoteza 3: Częściowa izolacja

GoogleOther jest oddzielony tylko dla niektórych typów crawli ale nie dla wszystkich. Crawle z parametrem ?gtm_latency=1 prześlizgują się przez system.

Bez oficjalnego stanowiska Google, pozostajemy w sferze domysłów.

Potencjalne konsekwencje SEO

Niezależnie od przyczyny, fakt pozostaje faktem: ponad pół miliona URLi z parametrem diagnostycznym znajduje się w indeksie Google. Co to oznacza dla właścicieli stron?

Problem 1: Duplikacja treści

Każdy URL z ?gtm_latency=1 to potencjalny duplikat strony bez parametru:

strona.pl/produkt/nazwa/                ← oryginał
strona.pl/produkt/nazwa/?gtm_latency=1  ← duplikat w indeksie

Jeśli strona nie ma poprawnie skonfigurowanego tagu rel="canonical", Google może:

• Traktować obie wersje jako osobne strony
• Dzielić sygnały rankingowe między nimi
• Wybrać „złą” wersję jako kanoniczną (małe szanse ale prawdopodobne)

Problem 2: Kanibalizacja słów kluczowych

Dwie wersje tej samej strony mogą konkurować o te same frazy kluczowe:

Problem 3: Crawl budget

Każdy URL, który Google indeksuje, to URL który musi crawlować. Dla dużych serwisów:

• 10,000 stron produktowych = potencjalnie 10,000 dodatkowych URLi z parametrem
• Podwojenie liczby URLi do crawlowania
• Wolniejsze odkrywanie nowych treści
• Wolniejsze odświeżanie istniejących stron
• Gorszy wynik związany z render budget

Problem 4: Zanieczyszczenie raportów

W Google Search Console mogą pojawić się:

• Strony oznaczone jako „Indexed, not submitted in sitemap”
• Rozbieżności w danych między wersjami URL

Uwaga: W moich obserwacjach strony z ?gtm_latency=1 NIE pojawiały się w GSC – widoczne były tylko w logach serwera. To może oznaczać, że Google traktuje je inaczej, lub że problem jest jeszcze nie w pełni widoczny w standardowych narzędziach albo do GSC trafiają wyniki tylko i wyłącznie bezpośrednio od głównego Googlebota, a GoogleOther nie ma powiazania z GSC.

Problem 5: Użytkownicy trafiają na URLe diagnostyczne

Jeśli URL z parametrem jest zaindeksowany, to może pojawić się w wynikach wyszukiwania. Użytkownik klika i trafia na stronę z parametrem, a następnie:

• Udostępnia URL z parametrem
• Linkuje do URL z parametrem
• Zapisuje w zakładkach URL z parametrem

Parametr się rozprzestrzenia i to nie przez bezpośrednie działanie Google!

Analiza canonical – co pokazały dane

Przeprowadziłem audyt 142 losowo wybranych adresów z parametrem ?gtm_latency=1 widocznych w indeksie Google:

Interpretacja:

• 77.5% stron jest „bezpiecznych” – nawet jeśli URL z parametrem jest w indeksie, Google powinno respektować canonical i pokazywać prawidłową wersję w wynikach
• 10.6% stron nie ma żadnej ochrony – brak canonical oznacza, że Google sam decyduje która wersja jest „kanoniczna”
• 6.3% stron ma poważny problem – canonical wskazuje na URL z parametrem, co może utrwalić duplikację
• 0.7% ma błędną konfigurację – canonical na stronę główną zamiast na właściwą podstronę
• 4.9% zwraca błędy – co może generować dodatkowe problemy z indeksacją

Rekomendacje i protipy, czyli moje rozwiązania dla tego problemu

Skoro znam już mechanizm działania ?gtm_latency=1, skalę problemu i potencjalne konsekwencje SEO, czas odpowiedzieć na najważniejsze pytanie: co z tym zrobić?

Poniżej przedstawiam konkretne rekomendacje oparte na moich obserwacjach i analizie problemu.

✅ Rekomendacja 1: Przeprowadź audyt tagów canonical

To jest absolutna podstawa higieny technicznego SEO. Mam kilka scenariuszy:

Scenariusz A – Canonical skonfigurowany poprawnie:

<!-- Na stronie: strona.pl/produkt/nazwa/?gtm_latency=1 -->
<link rel="canonical" href="hxxps://strona.pl/produkt/nazwa/" />

Google widzi canonical wskazujący na wersję bez parametru. W większości przypadków:

• Respektuje ustawienie canonicala
• Wyświetli w wynikach wyszukiwania wersję bez parametru
• Skonsoliduje sygnały rankingowe na właściwym URL

Scenariusz B – Brak canonical:

<!-- Na stronie: strona.pl/produkt/nazwa/?gtm_latency=1 -->
<!-- Brak tagu canonical -->

Google nie otrzymuje sygnału o wersji kanonicznej. Sam musi zdecydować:

• Która wersja jest „lepsza”
• Którą wyświetlić w wynikach
• Jak podzielić sygnały rankingowe

W praktyce może wybrać wersję z parametrem jako kanoniczną. Tym bardziej jeśli to ona została zaindeksowana jako pierwsza!

Scenariusz C – Canonical wskazuje na siebie (self-referencing z parametrem):

<!-- Na stronie: strona.pl/produkt/nazwa/?gtm_latency=1 -->
<link rel="canonical" href="hxxps://strona.pl/produkt/nazwa/?gtm_latency=1" />

To najgorszy scenariusz. Google otrzymuje wyraźny sygnał: „Wersja z parametrem jest wersją kanoniczną” – utrwala to duplikację

Jak przeprowadzić audyt canonical

Krok 1: Sprawdź czy Twoja strona jest dotknięta problemem

Wyszukaj w Google:

site:twojadomena.pl inurl:gtm_latency=1

Jeśli wyniki są puste, to z dużym prawdopodobienstwem strona nie ma zaindeksowanych URLi z tym parametrem na obecną chwile.

Jeśli wyniki się pojawiają – masz potwierdzenie problemu i listę konkretnych URLi do sprawdzenia.

Krok 2: Dla każdego znalezionego URL sprawdź canonical

Canonical powinien wskazywać na URL bez parametru ?gtm_latency=1.

Stany problematyczne:

<!-- PROBLEM: Brak tagu canonical -->
<!-- (nic nie znaleziono) -->

<!-- PROBLEM: Canonical z parametrem -->
<link rel="canonical" href="https://twojadomena.pl/sciezka/do/strony/?gtm_latency=1" />

<!-- PROBLEM: Canonical na stronę główną zamiast właściwą podstronę -->
<link rel="canonical" href="https://twojadomena.pl/" />

Krok 3: Sprawdź implementację canonical w całym serwisie

Problem może dotyczyć nie tylko stron już zaindeksowanych z parametrem ale całej logiki generowania tagów canonical.

Typowe błędy implementacyjne:

❌ Rekomendacja 2: NIE blokuj parametru w robots.txt

To jest błędne podejście. Nie rób tego, o to dlaczego tak uważam.

Powód 1: robots.txt blokuje crawlowanie, nie indeksowanie

To różnica, którą wielu specjalistów SEO nie rozumie w pełni:

1. robots.txt → Mówi robotom: „Nie wchodź na tę stronę”
2. Robot nie crawluje strony ale…
3. …jeśli strona już jest w indeksie lub ma linki zewnętrzne…
4. …to Google MOŻE ją dalej wyświetlać w wynikach (bez snippetu)

Blokując ?gtm_latency=1 w robots.txt:

• Googlebot nie będzie crawlował tych URLi
• Ale jeśli URL już jest w indeksie – pozostanie w indeksie, bo Google nie widzi że nie powinien jej wyindeksować
• Jeśli URL ma linki zewnętrzne – Google może go wyświetlać z adnotacją „Opis niedostępny z powodu robots.txt”
• Nie rozwiążesz problemu duplikacji, a jedynie go pogorszysz

Powód 2: Blokujesz dostęp do danych diagnostycznych

Parametr ?gtm_latency=1 służy Google do zbierania danych o wydajności GTM. Blokując go:

• Google nie może przeprowadzić audytu wydajności strony
• Tracisz potencjalne korzyści z optymalizacji GTM po stronie Google
• Możesz być nieświadomie wykluczony z pewnych optymalizacji

Powód 3: Możesz zablokować więcej niż zamierzasz

Reguły w robots.txt mogą mieć niezamierzone konsekwencje:

# Próba zablokowania parametru
Disallow: /*?gtm_latency=1

# ALE ta reguła może też zablokować:
# /strona/?gtm_latency=1&inny_parametr=wartość
# /strona/?ważny_parametr=coś&gtm_latency=1

W zależności od implementacji, możesz przypadkowo zablokować URLe z innymi, ważnymi parametrami.

Powód 4: To leczenie objawów, nie przyczyny

Blokowanie w robots.txt jest jedynie próbą obejścia problemu, a nie jego rozwiązaniem. Nawet jeśli zablokujesz ?gtm_latency=1, co z innymi parametrami które mogą pojawić się w przyszłości? ?utm_source=...? ?fbclid=...? ?gclid=...?

Poprawny canonical rozwiązuje problem dla wszystkich parametrów, raz na zawsze.

Co zamiast robots.txt ?

✅ Rekomendacja 3: Monitoruj logi serwera

Google Search Console jest świetnym narzędziem ale nie pokazuje wszystkiego. W przypadku ?gtm_latency=1 zauważyłem, że:

• URLe z parametrem pojawiają się w logach serwera
• Ale NIE pojawiają się w raportach GSC

To oznacza, że jeśli polegasz tylko na GSC, możesz przegapić problem.

Dlaczego logi serwera są najważniejsze

Logi serwera to jedyne źródło pełnej prawdy o tym, co roboty robią na stronie:

Narzędzia do analizy logów

Podsumowanie

To, co zaczęło się od jednej dziwnej linijki w logach serwera, okazało się znacznie większym problemem niż mogłem przypuszczać 🙂

?gtm_latency=1 to wewnętrzny parametr diagnostyczny Google Tag Managera, który:

• Wymusza pełną telemetrię wydajności, tagów i Consent Mode
• Jest dodawany przez robota GoogleOther podczas crawlowania
• Teoretycznie nie powinien trafiać do głównego indeksu wyszukiwarki

Fakty