Parametry URL wyszukiwania Google: co nadal działa w 2026 roku

Około września 2025 roku wiele narzędzi SEO i własnych skryptów po cichu przestało działać poprawnie. Winowajca? Google przestał konsekwentnie honorować parametr num=100, z którego zaawansowani użytkownicy korzystali od lat, aby pobierać po 100 wyników na stronę. Nie było oficjalnego komunikatu o wycofaniu — pojawiła się jedynie wypowiedź rzecznika dla Search Engine Land, że parametr „nie był formalnie wspierany”. Mniej więcej w tym samym czasie Google wprowadził kolejne tryby udm obok starszych pionów tbm, ogłosił, że domeny krajowe będą stopniowo przekierowywać do google.com, a także poinformował, że AI Overviews osiągnęły ponad 2,5 miliarda użytkowników miesięcznie.

Jeśli budujesz adresy URL do wyszukiwania, monitorujesz pozycje albo automatyzujesz research z użyciem parametrów URL Google, jest spora szansa, że część Twoich procesów działa teraz gorzej, niż się wydaje. W Thunderbit przeanalizowaliśmy aktualną dokumentację Google, najnowsze zapowiedzi zmian, informacje z reverse engineeringu oraz testy na żywo, aby oddzielić stabilne ustawienia od tych zależnych od kontekstu. Efekt to aktualne, warto-testować-przed-wdrożeniem kompendium parametrów URL Google Search, które mają znaczenie w 2026 roku — w tym mapowania tbm/udm, wzór kodowania uule dla targetowania na poziomie miasta oraz konflikty parametrów, które mogą oszczędzić godziny debugowania.

Czym są parametry URL wyszukiwania Google?

Parametry URL wyszukiwania Google to pary key=value, które pojawiają się po ? w adresie wyszukiwania Google. Sterują wszystkim: od tego, czego szukasz, przez kraj wyników, aż po to, czy zobaczysz obrazy, wiadomości czy klasyczne niebieskie linki.

Typowy adres Google Search wygląda tak:

https://www.google.com/search?q=best+crm+software&hl=en&gl=us&tbs=qdr:m

• Bazowy URL: https://www.google.com/search
• ? rozpoczyna ciąg zapytania
• q=best+crm+software to zapytanie wyszukiwania (spacje kodowane jako +)
• & oddziela kolejne parametry
• hl=en ustawia język interfejsu na angielski
• gl=us każe Google pokazywać wyniki tak, jakbyś był w USA
• tbs=qdr:m filtruje wyniki do ostatniego miesiąca

Warto rozróżnić dwie rzeczy: operatory wyszukiwania takie jak site:, filetype: i intitle: wpisuje się wewnątrz wartości q=. To część zapytania. Parametry URL takie jak gl, hl i tbs są osobnymi kluczami w adresie, które sterują tym, jak Google przetwarza i prezentuje wyniki. Oba mechanizmy są ważne i działają razem — ale to dwa różne światy.

Google nigdy nie opublikował jednej, wersjonowanej specyfikacji tych parametrów. Część pochodzi z formularza Advanced Search, część z Custom Search API, a część została zrekonstruowana na podstawie obserwacji własnych adresów Google. To oznacza, że artykuł, który czytasz, opiera się na testach na żywo i udokumentowanym zachowaniu, a nie na oficjalnym kontrakcie API.

Dlaczego parametry URL wyszukiwania Google są ważne w 2026 roku

Parametry URL to nie tylko temat dla developerów. Każdy w SEO, marketingu, sprzedaży, operacjach czy produkcie, kto musi zrozumieć, co Google pokazuje dla konkretnego zapytania, na konkretnym rynku i w konkretnym momencie — korzysta właśnie z tego zestawu narzędzi.

Szybki przegląd tego, komu i w jaki sposób pomagają:

Zastosowanie	Kto korzysta	Kluczowe parametry
Śledzenie pozycji SEO w różnych krajach	Zespoły SEO i marketingu	gl, hl, uule, pws
Monitorowanie konkurencji w określonych datach	Zespoły strategii i operacji	tbs, q z site:
Monitorowanie reklam na konkretnych rynkach	Zespoły paid media	gl, hl, udm
Audyty lokalnego SEO (poziom miasta)	Lokalni przedsiębiorcy	uule, gl
Research treści / śledzenie trendów	Zespoły contentowe	tbs (filtry dat), lr
Zasilanie aplikacji AI/LLM danymi z wyszukiwania	Zespoły produktowe i data	Wiele parametrów + uporządkowana ekstrakcja

Trzy duże zmiany sprawiają, że 2026 rok jest istotnie inny:

1. num=100 nie jest już niezawodne. Stary trik na liczbę wyników na stronę przestał działać konsekwentnie we wrześniu 2025. Google formalnie tego nie wycofał; rzecznik powiedział jedynie, że parametr nigdy nie był oficjalnie wspierany.
2. Przekierowania ccTLD to migracja, a nie zakończona zmiana. Google ogłosił w kwietniu 2025, że domeny krajowe (google.co.uk, google.de itd.) będą stopniowo przekierowywane do google.com. Google nie opublikował komunikatu o zakończeniu tej zmiany, więc nie zakładaj, że wszystkie lokalizacje działają już identycznie.
3. AI Overviews zmieniły SERP. Google podaje, że AI Overviews docierają do ponad 2,5 miliarda użytkowników miesięcznie i działają w ponad 200 krajach i terytoriach. Tryby udm zrekonstruowane metodą reverse engineeringu mogą w niektórych kontekstach zmieniać widok wyników, ale nie są gwarantowanym przełącznikiem AI Overview.

Jeśli Twoje workflowy nie zostały zaktualizowane pod te zmiany, prawdopodobnie otrzymujesz teraz zaniżone albo mylące wyniki, nawet o tym nie wiedząc.

Szybka ściąga z parametrów URL Google Search (2026)

Zanim przejdziemy dalej, poniższa tabela jest najbardziej aktualnym zestawieniem, jakie udało mi się przygotować. Warto ją zapisać.

Parametr	Co robi	Przykładowa wartość	Status
q	Zapytanie wyszukiwania (obsługuje operatory wewnątrz)	q=best+crm+software	✅ Aktywny
hl	Język interfejsu	hl=en, hl=ja	✅ Aktywny
gl	Kontekst kraju/rynku	gl=us, gl=jp	✅ Aktywny
lr	Ograniczenie wyników do języka treści	lr=lang_en	✅ Aktywny
cr	Ograniczenie wyników do kraju hostowania	cr=countryUS	✅ Aktywny
start	Przesunięcie paginacji	start=10 (strona 2)	✅ Aktywny
num	Liczba wyników na stronę (dawniej)	num=100	⚠️ Nie jest formalnie wspierany; od września 2025 zawodny
udm	Tryb treści zależny od kontekstu	udm=14 (klasyczna sieć)	⚠️ Zrekonstruowany; zależy od kontekstu
tbm	Pion wyszukiwania	tbm=isch (obrazy)	⚠️ Nadal obserwowany; testuj razem z udm
tbs	Filtry czasu, sortowanie, tryb werbatim	tbs=qdr:w	✅ Aktywny
safe	Kontrola SafeSearch	safe=active	✅ Aktywny
filter	Filtrowanie duplikatów	filter=0	✅ Aktywny (obserwowany)
nfpr	Wyłączenie autokorekty	nfpr=1	✅ Aktywny (obserwowany)
pws	Wyłączenie personalizacji	pws=0	✅ Aktywny
uule	Targetowanie na poziomie miasta/DMA	uule=w+CAIQICI...	✅ Aktywny (reverse-engineering)
as_q, as_epq, as_eq, itd.	Pola formularza Advanced Search	Różne	✅ Aktywny
as_sitesearch	Ograniczenie do domeny (Advanced Search)	as_sitesearch=example.com	✅ Aktywny
as_filetype	Ograniczenie do typu pliku (Advanced Search)	as_filetype=pdf	✅ Aktywny
ie, oe	Kodowanie wejścia/wyjścia	ie=UTF-8	✅ Aktywny (rzadko potrzebny)
kgmid, si, ibp	Encja Knowledge Graph / widok funkcji	Różne	⚠️ Zależne od kontekstu (nie do ogólnego użytku)
ei, ved, sxsrf, sclient	Sesja/śledzenie/telemetria	Różne	🔒 Wewnętrzne (ignoruj)
gbv	Podstawowy widok HTML (dawniej)	gbv=1	❌ Niezawodne w 2026 roku nie jest

Usuń ei, ved, sxsrf i sclient z każdego URL-a, który zapisujesz lub udostępniasz. To stan sesji i telemetria, które Google dodaje automatycznie — nie mają znaczenia przy konstruowaniu adresów wyszukiwania.

Kluczowe parametry URL Google Search, które nadal działają

Przetestowałem każdy z nich na żywo w połowie 2026 roku. To właśnie po te parametry będziesz sięgać najczęściej.

q — Twoje zapytanie wyszukiwania

Parametr q przenosi Twoje hasła wyszukiwania. Spacje są kodowane jako + albo %20. To tutaj znajdują się udokumentowane przez Google operatory wyszukiwania — wewnątrz wartości q, a nie jako osobne parametry URL.

Kilka przykładów:

• Dokładna fraza: q=%22google+search+url+parameters%22
• Wyniki z jednej domeny: q=site%3Aexample.com+pricing
• Typ pliku: q=filetype%3Apdf+annual+report+2026
• Połączenie kilku warunków: q=site%3Acompetitor.com+intitle%3Apricing+after%3A2026%2F01%2F01

Zawsze koduj URL całej wartości zapytania. Cudzysłowy, dwukropek i ukośniki muszą być poprawnie zakodowane, aby nie uszkodzić adresu.

hl — Język interfejsu

hl kontroluje język interfejsu Google (przyciski, etykiety, nagłówki typu „Inni też pytają”) i wpływa na to, które wyniki Google uznaje za priorytetowe. Wykorzystuje kody ISO 639-1 takie jak en, fr, de, ja albo tagi BCP 47, np. en-gb czy pt-br.

hl nie wymusza języka wszystkich dokumentów wyników. To silna wskazówka, ale Google może nadal pokazywać wyniki w innych językach, jeśli uzna je za szczególnie trafne. Do ograniczenia języka treści użyj lr.

gl — Kraj / geolokalizacja

gl symuluje kraj, z którego wyszukujesz, korzystając z kodów ISO 3166-1 alpha-2 (us, gb, jp, de). Wraz z tym, jak ccTLD stopniowo przekierowują do google.com, gl staje się głównym sposobem uzyskania wyników specyficznych dla danego kraju.

To samo zapytanie z różnymi wartościami gl może zwrócić zupełnie inne wyniki, featured snippets i lokalne pakiety. Na przykład q=best+bank&gl=us i q=best+bank&gl=jp pokażą Ci zupełnie inne banki.

Wskazówka: zawsze łącz gl z hl, aby uzyskać poprawnie zlokalizowane wyniki. Użycie gl=jp z hl=en daje wyniki z rynku japońskiego w angielskim interfejsie — przydatne przy międzynarodowych audytach SEO.

lr i cr — ograniczenie języka i kraju

Te dwa parametry są notorycznie mylone. Różnica ma znaczenie:

• lr=lang_en ogranicza wyniki do stron napisanych po angielsku (język treści)
• cr=countryUS ogranicza wyniki do stron hostowanych w Stanach Zjednoczonych (lokalizacja serwera / przypisanie kraju)
• gl=us symuluje wyszukiwanie z USA (wpływa na ranking, wyniki lokalne, reklamy)

Zarówno lr, jak i cr są dostępne w formularzu Advanced Search. Uważaj przy ich łączeniu — lr=lang_en + cr=countryJP oznacza „tylko anglojęzyczne strony hostowane w Japonii”, czyli bardzo wąski zestaw. Więcej o tym w sekcji o konfliktach.

start — paginacja

start=10 prosi o wyniki zaczynające się od pozycji 11 (strona 2), start=20 — od strony 3 itd. Ponieważ num=100 nie jest już niezawodne, zwiększanie start co 10 to bezpieczniejszy domyślny sposób — choć Google nadal może przepisywać albo ograniczać paginację.

Stary trik num=100&start=0, pozwalający pobrać pełną stronę 100 wyników, już nie działa. Jeśli Twoje skrypty nadal zawierają num, usuń ten parametr — jest po prostu ignorowany.

pws — wyłączenie personalizacji

pws=0 prosi Google o wyłączenie personalizacji opartej na koncie. To kluczowe w śledzeniu pozycji SEO, kiedy chcesz widzieć wyniki nieprzesunięte przez własną historię wyszukiwania, kliknięcia czy preferencje konta.

Uwaga: pws=0 zmniejsza wpływ personalizacji, ale nie usuwa wszystkich czynników kontekstowych. Google mówi, że wyniki nadal mogą różnić się w zależności od czasu, lokalizacji, języka i urządzenia. Nie istnieje coś takiego jak całkowicie „neutralny” SERP Google.

safe i filter — SafeSearch oraz filtrowanie duplikatów

• safe=active włącza SafeSearch; safe=off go wyłącza. Pamiętaj, że ustawienia konta, polityki administracyjne, konfiguracja sieci lub lokalne przepisy mogą ten parametr nadpisać.
• filter=0 wyłącza filtrowanie duplikatów przez Google. Przydatne, gdy chcesz zobaczyć każdy wynik, jaki Google ma w bazie, w tym bardzo podobne strony, które normalnie byłyby zgrupowane.

nfpr — wyłączenie autokorekty

nfpr=1 zapobiega temu, by Google na siłę przepisywał Twoje zapytanie, gdy uzna, że popełniłeś literówkę. To przydatne przy monitorowaniu marek o nietypowej pisowni, terminologii technicznej albo zapytań pisanych celowo „źle”, które konkurenci próbują przechwycić.

Warto pamiętać, że nfpr=1 wyłącza tylko wymuszone przepisywanie. Do szerszej kontroli — wyłączenia rozszerzania o synonimy, zmian pisowni i innych automatycznych modyfikacji — użyj tbs=li:1 (tryb werbatim), o którym piszę niżej w sekcji tbs.

Migracja z tbm do udm: co się zmieniło i czego używać teraz

To jedna z największych zmian parametrów w ostatnich latach — i jedna z najłatwiejszych do przecenienia.

tbm od ponad dekady służył do przełączania między pionami wyszukiwania Google — obrazami, wiadomościami, wideo, zakupami. Google wprowadził też numeryczny system udm z częściowo nakładającymi się i dodatkowymi trybami. Ponieważ Google nie opublikował stabilnego rejestru dla użytkowników końcowych, traktuj to raczej jako mapowanie zależne od kontekstu, a nie czystą, zakończoną migrację.

Pełna tabela mapowania tbm → udm

Poniższe mapowania łączą zaobserwowane zachowanie interfejsu i testy wykonane na żywo z dnia 12 sierpnia 2026. Kilka wartości zostało usuniętych lub przepisanych w żądaniach anonimowych, więc każdy wiersz należy przetestować w koncie, regionie i kliencie, w którym będzie używany:

Stary parametr	Stara wartość	Nowy parametr	Nowa wartość	Status
tbm=lcl	Miejsca / lokalne	udm=1	Miejsca / lokalne	⚠️ Zależne od kontekstu
tbm=isch	Obrazy	udm=2	Obrazy	⚠️ Zależne od kontekstu
tbm=vid	Wideo	udm=7	Wideo	⚠️ Zależne od kontekstu
tbm=nws	Wiadomości	udm=12	Wiadomości	⚠️ Zależne od kontekstu
—	—	udm=14	Klasyczna sieć (bez AI Overviews)	🆕 Nowe, bez odpowiednika tbm
—	—	udm=18	Fora	🆕 Nowe, bez odpowiednika tbm
tbm=shop	Zakupy	udm=28	Zakupy	⚠️ Zależne od kontekstu
tbm=bks	Książki	udm=36	Książki	⚠️ Zależne od kontekstu
—	—	udm=39	Krótkie wideo	🆕 Nowe, bez odpowiednika tbm
—	—	udm=50	Tryb AI Overview	🆕 Nowe, bez odpowiednika tbm

Google nie opublikował stabilnego rejestru udm — to kluczowe zastrzeżenie. Te wartości zostały zrekonstruowane na podstawie obserwacji zachowania własnego interfejsu Google. Akceptacja URL-i różni się w zależności od konta, regionu, klienta, cookies i grupy eksperymentalnej. W moich testach część wartości udm była usuwana w anonimowych żądaniach HTTP, ale działała poprawnie w interaktywnych sesjach przeglądarkowych. Nie zakładaj, że każda wartość działa uniwersalnie.

Co robi udm=14 i dlaczego SEO tak go lubią

udm=14 stał się czymś w rodzaju kultowego ulubieńca w społeczności SEO. Android Central opisał go jako sposób na uzyskanie klasycznego widoku wyników bez AI Overviews. W wielu sesjach daje tradycyjny SERP z niebieskimi linkami, ale nie jest to oficjalna ani uniwersalna gwarancja.

Dlaczego to ważne? Jeśli robisz tracking pozycji albo audyty SEO, AI Overviews mogą zepchnąć wyniki organiczne poniżej linii przewijania i utrudnić ocenę pozycji. udm=14 może dać czystszy widok, jeśli Google go honoruje.

Mimo to udm=14 nie działa gwarantowanie w każdym kontekście. W testach wykonanych na żywo 12 sierpnia 2026 Google czasem usuwał lub przepisywał wartości udm w zależności od kontekstu żądania. Wyniki będą się różnić zależnie od sesji, konta, regionu, klienta i grupy eksperymentalnej.

udm=50 obserwowano w kontekstach AI Mode / AI-result, ale nie należy opisywać go jako pewnego sposobu na wymuszenie AI Overview dla dowolnego zapytania.

Co zrobić: zaktualizuj workflowy z tbm na udm

Moja rekomendacja:

• Nowe wdrożenia: Traktuj udm jako wejście eksperymentalne/zależne od kontekstu i buduj fallbacki.
• Istniejące workflowy: Obsługuj i testuj zarówno tbm, jak i udm tam, gdzie ma to sens, zamiast zakładać, że migracja jest już zakończona.
• Nigdy nie łącz obu: Gdy w tym samym URL-u pojawiają się tbm i udm, zachowanie jest nieprzewidywalne. W moich testach Google czasem usuwał oba i zwracał zwykłe zapytanie. Więcej na ten temat w sekcji o konfliktach.

Pełna składnia tbs: niestandardowe zakresy dat, sortowanie po dacie i tryb werbatim

tbs to jeden z najpotężniejszych parametrów w zestawie narzędzi Google Search, a większość poradników ledwo go dotyka. Obejmuje filtrowanie po czasie, sortowanie po dacie, tryb werbatim i więcej — wszystko w jednej wartości rozdzielanej przecinkami.

Standardowe filtry czasu

Wartość tbs	Znaczenie	Przykładowy fragment URL
qdr:h	Ostatnia godzina	&tbs=qdr:h
qdr:d	Ostatnie 24 godziny	&tbs=qdr:d
qdr:w	Ostatni tydzień	&tbs=qdr:w
qdr:m	Ostatni miesiąc	&tbs=qdr:m
qdr:y	Ostatni rok	&tbs=qdr:y

To podstawy, które opisuje większość przewodników. Ale tbs potrafi znacznie więcej.

Niestandardowe zakresy dat

Potrzebujesz wyników z konkretnego przedziału czasu? Użyj składni cdr:1,cd_min:MM/DD/YYYY,cd_max:MM/DD/YYYY:

&tbs=cdr:1,cd_min:01/01/2026,cd_max:06/01/2026

To zawęża wyniki do tych, które Google powiąże z datami pomiędzy 1 stycznia a 1 czerwca 2026. Jest to bardzo przydatne w researchu konkurencji — na przykład: „co konkurenci publikowali o cenach w Q1 2026?”. Pamiętaj tylko, aby zakodować cały URL, bo dwukropki i ukośniki wymagają kodowania.

Praktyczna uwaga: przypisywanie dat przez Google nie zawsze jest trafne. Data wyświetlana w wynikach wyszukiwania to najlepsze przypuszczenie Google, a niekoniecznie rzeczywista data publikacji. Zawsze sprawdzaj datę na docelowej stronie.

Sortowanie po dacie i tryb werbatim

Tu przewodnik wchodzi na obszar, którego nie pokrywa żaden konkurencyjny artykuł.

sbd:1 sortuje wyniki według daty (najnowsze najpierw). Samo w sobie jest użyteczne, ale nie wyjątkowe. Sztuczka polega na tym, że możesz połączyć je z filtrami zakresu czasu w jednej wartości tbs:

&tbs=qdr:m,sbd:1

To daje wyniki z ostatniego miesiąca, posortowane po dacie — od najnowszych. To najszybszy sposób, by znaleźć świeżo opublikowane treści na dany temat. Używam tego połączenia cały czas przy monitorowaniu treści konkurencji.

li:1 włącza tryb werbatim — odpowiednik kliknięcia narzędzia „Verbatim” w interfejsie Google Search. Tryb werbatim wyłącza autokorektę, rozszerzanie o synonimy, zmiany pisowni i inne automatyczne modyfikacje zapytania.

Różnica między li:1 a nfpr=1 sprowadza się do zakresu działania:

• nfpr=1: wyłącza tylko wymuszone przepisywanie literówek/zapytań (np. zatrzymuje zmianę „teh” na „the”)
• tbs=li:1: wyłącza wszystkie automatyczne modyfikacje — pisownię, synonimy, powiązane terminy, korekty personalizacji

Możesz nawet łączyć kilka wartości tbs. Na przykład tbs=qdr:m,sbd:1,li:1 daje wyniki z ostatniego miesiąca, posortowane po dacie, z dopasowaniem werbatim. W moich testach to działa, choć polecam zweryfikować to na własnych zapytaniach, ponieważ składnia tbs nie jest oficjalnie udokumentowana.

Jak zbudować kod uule do targetowania na poziomie miasta

Jeśli gl to krajowa lupa, uule jest mikroskopem na poziomie miasta. W lokalnym SEO — przy sprawdzaniu, jak Twoja firma rankuje w Denver vs. Dallas albo co widzi użytkownik w tokijskiej dzielnicy Shibuya — samo gl nie jest wystarczająco precyzyjne.

Żaden wysoko pozycjonowany artykuł tak naprawdę nie tłumaczy, jak zbudować kod uule — wspominają, że taki parametr istnieje, i przechodzą dalej. Poniżej pełne omówienie.

Kiedy używać gl, uule i cr

Parametr	Precyzja	Typowe zastosowanie	Wymaga kodowania?
gl=us	Poziom kraju	Szybka symulacja kraju	Nie
cr=countryUS	Poziom kraju (ograniczenie)	Filtrowanie po kraju hostingu	Nie
uule=w+CAIQICI...	Poziom miasta/DMA	Sprawdzanie pozycji lokalnego SEO	Tak

Algorytm kodowania uule krok po kroku

Parametr uule używa zakodowanego sygnału nazwanego miejsca. Jego konstrukcja została zrekonstruowana, nie jest oficjalnie opisana przez Google, ale została szeroko potwierdzona przez społeczność SEO.

Bezpieczniejsze podejście to kodowanie niewielkiego payloadu Protocol Buffers zamiast polegać na powszechnie kopiowanym skrócie (który może zawieść przy znakach spoza ASCII). Oto proces:

1. Pobierz kanoniczną nazwę lokalizacji w Google. Google publikuje geograficzne cele z nazwami kanonicznymi w Google Ads API geographic targeting data. Przykład: New York,New York,United States
2. Zakoduj nazwę jako bajty UTF-8.
3. Zbuduj mały payload protobuf z nazwą i jej długością w bajtach.
4. Zakoduj payload w base64url i dodaj prefiks w+.

Oto fragment Pythona, który to robi:

import base64

def encode_varint(value: int) -> bytes:
    out = bytearray()
    while True:
        byte = value & 0x7F
        value >>= 7
        if value:
            out.append(byte | 0x80)
        else:
            out.append(byte)
            return bytes(out)

def build_uule(canonical_name: str) -> str:
    name = canonical_name.encode("utf-8")
    payload = b"\x08\x02\x10\x20\x12" + encode_varint(len(name)) + name
    encoded = base64.urlsafe_b64encode(payload).decode().rstrip("=")
    return "w+" + encoded

#Example
print(build_uule("New York,New York,United States"))
#Output: w+CAIQICIeTmV3IFlvcmssTmV3IFlvcmssVW5pdGVkIFN0YXRlcw

Gdy dodasz to do URL-a, upewnij się, że dosłowny znak + w w+ jest poprawnie zakodowany jako %2B przez bibliotekę URL. Większość implementacji URLSearchParams albo urllib.parse.urlencode zrobi to automatycznie.

Poprawnie zbudowane uule nadal jest tylko jednym z sygnałów lokalizacji. Nie nadpisuje adresu IP, ustawień konta, urządzenia ani grupy eksperymentalnej. Używaj go do kierunkowych sprawdzeń lokalnego SEO, a nie jako gwarancji dokładnej pozycji w konkretnym mieście.

Kiedy parametry URL Google Search wchodzą ze sobą w cichy konflikt

Kombinacje parametrów mogą zawodzić bez żadnego komunikatu: Google może zignorować jedno z wejść, przepisać URL albo zwrócić inny widok wyników. Poniższe testy konfliktów warto dodać do każdego workflowu z linkami wyszukiwania.

Żaden konkurencyjny artykuł nie omawia interakcji parametrów. Ale jeśli budujesz adresy wyszukiwania z wieloma parametrami — a pewnie tak jest — musisz wiedzieć, które kombinacje współpracują, a które się gryzą.

gl + uule: który parametr wygrywa?

Gdy oba są obecne, uule daje bardziej precyzyjny sygnał lokalizacji niż gl. Jeśli ustawisz gl=uk, a uule będzie wskazywać Tokio, dostaniesz wyniki bardziej z Tokio niż z UK.

Rekomendacja: Jeśli używasz uule, albo całkiem pomiń gl, albo ustaw gl na kraj, w którym leży miasto z uule. Nie wysyłaj sprzecznych sygnałów.

tbm + udm: nie używaj obu

W moich testach, gdy tbm i udm pojawiały się w tym samym URL-u, Google czasem usuwał oba parametry i zwracał zwykłe wyniki sieciowe. Zachowanie jest niespójne między sesjami i kontami.

Rekomendacja: W nowych wdrożeniach używaj tylko udm. Jeśli musisz wspierać starsze workflowy, używaj jednego albo drugiego — nigdy obu naraz.

lr + cr: podwójne filtrowanie może zwrócić zero wyników

To podchwytliwa pułapka. lr=lang_en ogranicza do treści anglojęzycznych. cr=countryJP ogranicza do stron hostowanych w Japonii. Połączenie obu parametrów oznacza „anglojęzyczne strony hostowane w Japonii” — czyli bardzo mały wycinek sieci.

Rekomendacja: Używaj jednego albo drugiego, chyba że naprawdę potrzebujesz części wspólnej. Jeśli je łączysz, licz się z drastycznie mniejszą liczbą wyników.

num + start: zepsuta paginacja

Stare skrypty używające num=100&start=0 zwracają teraz po cichu tylko około 10 wyników. Parametr num nie jest już honorowany, ale nie generuje błędu — po prostu jest ignorowany.

Rekomendacja: Usuń num ze wszystkich URL-i. Paginuj, zwiększając start co 10, i deduplikuj wyniki między stronami.

Szybka ściąga konfliktów

Kombinacja	Co się dzieje	Rekomendacja
gl + uule	uule daje bardziej precyzyjny sygnał	Dopasuj kraj i miasto albo usuń gl
tbm + udm	Nieprzewidywalne — oba mogą zostać usunięte	Używaj tylko udm
lr + cr	Agresywne zawężenie, często prawie zero wyników	Używaj jednego albo drugiego
num + start	num jest ignorowany, zwraca się tylko ok. 10 wyników	Usuń num, paginuj przez start
nfpr=1 + tbs=li:1	Powiązane, ale nieidentyczne sterowanie	Przetestuj swoje konkretne zapytanie
hl + lr	Język interfejsu ≠ filtr języka treści	Używaj świadomie; hl nie jest filtrem treści

Od parametrów URL Google Search do uporządkowanej ekstrakcji danych

W tym momencie masz już precyzyjny URL Google Search — odpowiednie zapytanie, właściwy kraj, właściwy zakres dat, klasyczne wyniki sieciowe. Następny krok to wydobycie z wyników danych w uporządkowanej formie.

Niezależnie od tego, czy budujesz narzędzie do monitorowania pozycji, śledzisz konkurencję, czy karmisz workflow badawczy danymi z wyszukiwania, samo zobaczenie właściwych wyników to dopiero połowa pracy. Potrzebujesz tytułów, URL-i, snippetów, pozycji i dat w arkuszu lub bazie danych.

Budowanie ukierunkowanego URL-a Google Search (składanie wszystkiego razem)

Pełny przykład łączący wiele parametrów:

https://www.google.com/search?q=site%3Acompetitor.com+intitle%3Apricing&hl=en&gl=us&tbs=qdr:m,sbd:1&udm=14&pws=0

Rozbicie na części:

• q=site%3Acompetitor.com+intitle%3Apricing — strony na competitor.com z „pricing” w tytule
• hl=en — angielski interfejs
• gl=us — kontekst rynku USA
• tbs=qdr:m,sbd:1 — ostatni miesiąc, sortowanie po dacie
• udm=14 — klasyczne wyniki sieciowe (bez AI Overviews)
• pws=0 — bez personalizacji

Możesz zbudować to programowo przez curl:

curl -L -G 'https://www.google.com/search' \
  --data-urlencode 'q=site:competitor.com intitle:pricing' \
  --data-urlencode 'hl=en' \
  --data-urlencode 'gl=us' \
  --data-urlencode 'tbs=qdr:m,sbd:1' \
  --data-urlencode 'udm=14' \
  --data-urlencode 'pws=0' \
  -H 'User-Agent: Mozilla/5.0'

Albo w Pythonie:

import requests

params = {
    "q": "site:competitor.com intitle:pricing",
    "hl": "en",
    "gl": "us",
    "tbs": "qdr:m,sbd:1",
    "udm": "14",
    "pws": "0",
}

response = requests.get(
    "https://www.google.com/search",
    params=params,
    headers={"User-Agent": "Mozilla/5.0"},
    timeout=20,
)
print(response.url)

Anonimowe żądania HTTP do Google często zwracają powłoki JavaScript bez wyników renderowanych po stronie serwera albo ostrzeżenia o nietypowym ruchu — i właśnie tutaj przewagę ma ekstrakcja oparta na przeglądarce.

Jak wyciągać dane SERP bez pisania parsera

Parsowanie HTML Google jest kruche. Struktura DOM często się zmienia, nazwy klas są zaciemnione, a to, co widzisz w przeglądarce, nie zawsze odpowiada surowej odpowiedzi HTTP.

Prostsze podejście dla osób nietechnicznych: otwórz starannie zbudowany URL wyszukiwania w Chrome, a potem użyj narzędzia do ekstrakcji w przeglądarce, aby pobrać uporządkowane dane z widocznej strony. W Thunderbit zbudowaliśmy nasz rozszerzenie Chrome właśnie do takich workflowów — możesz użyć AI Suggest Fields, aby wskazać kolumny takie jak tytuł wyniku, docelowy URL, treść snippetu czy widoczna pozycja, a potem wyeksportować je do arkusza bez pisania parsera.

To nie jedyna droga. Podejścia oparte na kodzie też działają, zwłaszcza jeśli potrzebujesz dużej skali albo regularnej ekstrakcji. Ale w przypadku doraźnego researchu, audytów i jednorazowej analizy konkurencji ekstrakcja w przeglądarce całkowicie eliminuje kruchość parsowania HTML.

Kiedy zamiast tego użyć oficjalnego API

Tu ważna uwaga o odpowiedzialnym użyciu.

Warunki korzystania z Google zabraniają zautomatyzowanego dostępu z pominięciem mechanizmów ochronnych, a Google Search Help wprost klasyfikuje search scrapery i oprogramowanie wysyłające automatyczne zapytania do określania pozycji jako ruch automatyczny. Uruchamianie scrapera Google na skalę produkcyjną naraża Cię na blokady IP, CAPTCHA i potencjalne problemy prawne.

W przypadku produkcyjnych, wysokowolumenowych potrzeb związanych z danymi z wyszukiwania lepszą drogą jest oficjalne API. Google Custom Search JSON API jest zamykane dla nowych klientów — obecni użytkownicy mają czas do 1 stycznia 2027, aby się przenieść, z 100 darmowymi zapytaniami dziennie i stawką $5 za 1,000 zapytań później. Google rekomenduje w przyszłości Vertex AI Search dla wyszukiwania po kontrolowanych witrynach.

Dla stron, które posiadasz, Search Analytics API w Search Console jest źródłem first-party dla kliknięć, wyświetleń, CTR i średniej pozycji — bez potrzeby scrapingu.

Traktuj wiedzę o parametrach URL jako narzędzie diagnostyczne i badawcze: świetne do budowy precyzyjnych linków, ręcznych audytów i zrozumienia, jak Google pokazuje wyniki. Nie jako zamiennik oficjalnych API na dużą skalę.

Operatory wyszukiwania Google: parametry wewnątrz zapytania

Operatory wyszukiwania znajdują się wewnątrz parametru q=, ale są niezbędnym uzupełnieniem parametrów URL. Poniższa tabela obejmuje te, które Google obecnie dokumentuje, oraz kilka takich, które nadal działają w praktyce:

Operator	Co robi	Przykład
site:	Ogranicza do domeny	q=site:example.com+SEO
filetype:	Ogranicza do typu pliku	q=filetype:pdf+annual+report
intitle:	Słowo musi wystąpić w tytule	q=intitle:pricing+SaaS
inurl:	Słowo musi wystąpić w adresie URL	q=inurl:blog+marketing
-	Wyklucza termin	q=apple+-fruit
""	Dokładne dopasowanie frazy	q=%22google+search+url+parameters%22
OR	Jeden z warunków	q=scraping+OR+crawling
before:	Wyniki sprzed danej daty	q=AI+before:2026-01-01
after:	Wyniki po danej dacie	q=AI+after:2025-06-01
related:	Podobne strony	q=related:hubspot.com

Prawdziwa siła pojawia się wtedy, gdy łączysz operatory wewnątrz q z parametrami URL poza nim:

q=site:competitor.com+intitle:pricing+after:2026/01/01&tbs=sbd:1&gl=us&udm=14

To wyszukuje strony na competitor.com z „pricing” w tytule, opublikowane po styczniu 2026, posortowane po dacie, na rynku USA, z klasycznymi wynikami sieciowymi. To bardzo precyzyjne zapytanie do analizy konkurencji zbudowane wyłącznie z parametrów URL i operatorów.

Google zaznacza, że wyniki site: nie są gwarantowanie kompletne — nie traktuj zapytania site: jako pełnej inwentaryzacji zindeksowanych stron.

Odpowiedzialne użycie: warunki Google i limity zapytań

Krótki, ale ważny kontekst.

Warunki korzystania z Google zakazują nadużyć i obchodzenia mechanizmów ochronnych. Google Search Help wprost wskazuje search scrapery i automatyczne oprogramowanie do rankingu jako przykłady ruchu automatycznego. Naruszenie tych zasad może skutkować blokadami IP, CAPTCHA, ograniczeniem konta i potencjalnie działaniami prawnymi.

Wiedzę o parametrach URL najlepiej stosować do: ręcznego budowania precyzyjnych adresów wyszukiwania, tworzenia bookmarkowalnych linków dla zespołu, małoskalowych audytów w przeglądarce i rozumienia, jak działa interfejs wyszukiwania Google. Do automatyzacji na dużą skalę używaj oficjalnych API Google — albo licencjonowanego zewnętrznego dostawcy danych wyszukiwania, takiego jak Brave Search API.

W Thunderbit nasze rozszerzenie przeglądarki jest stworzone do ekstrakcji uruchamianej przez użytkownika z widocznej strony — nie do masowego, automatycznego odpytywania Google. To istotna różnica.

Najważniejsze wnioski: Twój zestaw narzędzi do parametrów URL Google Search w 2026

W skrócie:

• Używaj gl + hl jako sygnałów lokalizacji i języka i nie polegaj wyłącznie na ccTLD w trakcie migracji przekierowań Google
• Testuj zarówno udm, jak i tbm, gdy ma to sens — żaden z nich nie jest stabilnym, wersjonowanym API dla użytkowników końcowych
• udm=14 może prosić o klasyczne wyniki bez AI Overviews, ale Google może go usunąć lub przepisać
• Używaj uule do targetowania na poziomie miasta z formułą kodowania protobuf opisaną wyżej
• Opanuj tbs do precyzyjnego filtrowania dat (cdr:1,cd_min:...,cd_max:...), sortowania po dacie (sbd:1) i wyszukiwania werbatim (li:1)
• Uważaj na konflikty parametrów: gl kontra uule, tbm kontra udm, lr kontra cr
• num=100 jest zawodny i nigdy nie był formalnie wspierany — bezpieczniej paginować przez start co 10
• Do uporządkowanych danych SERP używaj narzędzi browser-based, takich jak Thunderbit przy pracy doraźnej, albo oficjalnych API w środowisku produkcyjnym
• Szanuj warunki Google — parametry URL to narzędzie badawcze, nie licencja na scrapowanie

Google nadal zmienia parametry bez zapowiedzi. Będę aktualizować to zestawienie wraz ze zmianami — zapisz je i wracaj tu regularnie.

Dowiedz się więcej

• 9 najlepszych API SEO na 2026 rok (z rzeczywistymi danymi o koszcie zapytania)
• Jak opanować scraping wyszukiwarek: kompletny przewodnik
• Top 27 narzędzi do analizy i monitorowania pozycji stron
• Jak używać paginacji w web scraperze dla efektywnej ekstrakcji
• Czym jest automatyzacja wyszukiwania? Korzyści, narzędzia i strategie

FAQ

Co robi udm=14 w URL-u wyszukiwania Google?

udm=14 może prosić o klasyczny widok wyników bez AI Overviews, dlatego jest popularny wśród praktyków SEO. Jest zrekonstruowany na podstawie obserwacji, a nie oficjalnie udokumentowany przez Google, i Google może go usunąć albo przepisać w zależności od sesji, konta, regionu, klienta i grupy eksperymentalnej.

Czy parametr num nadal działa w 2026 roku?

Nie polegaj na nim. Google przestał konsekwentnie honorować num=100 we wrześniu 2025, a rzecznik powiedział, że parametr nigdy nie był formalnie wspierany. Używaj start co 10 jako bezpieczniejszego domyślnego sposobu paginacji i sprawdzaj zwracaną liczbę wyników, bo Google nadal może przepisać albo ograniczyć odpowiedź.

Jak zasymulować wyszukiwanie Google z konkretnego miasta?

Użyj parametru uule z zakodowaną nazwą miasta. Sekcja o kodowaniu powyżej zawiera algorytm oparty na protobuf i przykład w Pythonie. Potrzebujesz kanonicznej nazwy lokalizacji w Google (dostępnej w Google Ads geographic targeting data), którą zakodujesz do wartości uule takiej jak uule=w+CAIQICIeNew+York,New+York,United+States.

Jaka jest różnica między gl, lr i cr?

Te trzy parametry kontrolują różne aspekty targetowania geograficznego i językowego. gl symuluje lokalizację wyszukiwania na poziomie kraju (wpływa na ranking i wyniki lokalne). lr ogranicza wyniki do stron napisanych w określonym języku treści. cr ogranicza wyniki do stron hostowanych w konkretnym kraju. Można je łączyć, ale sprzeczne kombinacje (np. lr=lang_en + cr=countryJP) drastycznie zawężą wyniki.

Czy mogę połączyć wiele wartości tbs w jednym URL-u?

Tak — oddziel je przecinkami w ramach jednego parametru tbs. Na przykład tbs=qdr:m,sbd:1 filtruje wyniki do ostatniego miesiąca i sortuje po dacie (najnowsze pierwsze). Możesz też dodać li:1 dla trybu werbatim: tbs=qdr:m,sbd:1,li:1. Składnia tbs nie jest oficjalnie udokumentowana, więc testuj konkretne kombinacje, aby potwierdzić, że działają zgodnie z oczekiwaniami.