Parametry Google Search URL: Co stále funguje v roce 2026

Někdy kolem září 2025 se potichu rozbila celá řada SEO nástrojů i vlastních skriptů. Kdo za to mohl? Google přestal spolehlivě respektovat parametr num=100, na který power uživatelé roky spoléhali při získávání 100 výsledků na stránku. Nešlo o žádné oficiální oznámení o ukončení podpory — jen mluvčí pro Search Engine Land řekl, že tento parametr „nebyl nikdy formálně podporován“. Ve stejném období Google zavedl více režimů udm vedle starších vertikál tbm, oznámil, že domény s ccTLD budou postupně přesměrovány na google.com, a uvedl, že AI Overviews dosahují více než 2,5 miliardy měsíčních uživatelů.

Pokud vytváříte vyhledávací URL, sledujete pozice nebo automatizujete research pomocí URL parametrů Google, je dost pravděpodobné, že některé vaše workflowy právě teď běží v omezeném režimu, aniž byste si toho všimli. V Thunderbit jsme prošli aktuální dokumentaci Googlu, nová oznámení o změnách, reverzně inženýrované reference i živé testy, abychom oddělili stabilní ovládací prvky od těch kontextových. Výsledkem je časově označený referenční materiál „testuj před nasazením“ pro Google search URL parametry, které v roce 2026 opravdu záleží — včetně mapování tbm/udm, kódovacího vzorce uule pro geotargeting na úrovni města a konfliktů parametrů, které mohou ušetřit hodiny ladění.

Co jsou parametry Google Search URL?

Parametry Google Search URL jsou dvojice ve formátu key=value, které se objevují za znakem ? ve vyhledávací URL Google. Řídí všechno od toho, co hledáte, přes to, z jaké země uvidíte výsledky, až po to, zda dostanete obrázky, zprávy nebo klasické modré odkazy.

Typická Google Search URL vypadá takto:

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

• Základní URL: https://www.google.com/search
• ? začíná query string
• q=best+crm+software je vyhledávací dotaz (mezery jsou kódované jako +)
• & odděluje jednotlivé parametry
• hl=en nastavuje jazyk rozhraní na angličtinu
• gl=us říká Googlu, aby zobrazoval výsledky, jako byste hledali z USA
• tbs=qdr:m filtruje výsledky na poslední měsíc

Je důležité rozlišovat dvě věci: vyhledávací operátory jako site:, filetype: a intitle: patří dovnitř hodnoty q=. Jsou součástí dotazu. Naproti tomu URL parametry jako gl, hl a tbs jsou samostatné klíče v URL, které řídí, jak Google zpracuje a zobrazí výsledky. Obojí je důležité a funguje to společně — ale jsou to dvě různé věci.

Google nikdy nezveřejnil jednu ucelenou, verzovanou specifikaci těchto parametrů. Některé pocházejí z formuláře Pokročilé vyhledávání, jiné z Custom Search API a další byly odvozeny reverzním inženýrstvím z URL, které používá sám Google. To znamená, že článek, který čtete, vychází z živého testování a zdokumentovaného chování, ne z oficiálního API kontraktu.

Proč jsou parametry Google Search URL v roce 2026 důležité

URL parametry nejsou jen téma pro vývojáře. Každý v SEO, marketingu, sales, ops nebo produktovém týmu, kdo potřebuje vědět, co Google ukazuje pro konkrétní dotaz, v konkrétním trhu a v konkrétním čase — ten tyto parametry potřebuje.

Rychlý přehled, kdo z nich těží a jak:

Use Case	Who Benefits	Key Parameters
Sledování SEO pozic napříč zeměmi	SEO a marketingové týmy	gl, hl, uule, pws
Monitoring konkurence podle data	Strategy & Ops týmy	tbs, q s site:
Monitoring reklam na konkrétních trzích	Týmy placené reklamy	gl, hl, udm
Lokální SEO audit (na úrovni města)	Majitelé lokálních firem	uule, gl
Obsahový research / sledování trendů	Content týmy	tbs (datumové filtry), lr
Napojení vyhledávacích dat do AI/LLM aplikací	Produktové a datové týmy	Více parametrů + strukturovaná extrakce

Tři zásadní změny dělají rok 2026 výrazně odlišným:

1. num=100 už není spolehlivý. Starý trik s počtem výsledků na stránku přestal spolehlivě fungovat v září 2025. Google jej formálně neukončil; mluvčí pouze uvedl, že nikdy nebyl formálně podporován.
2. Přesměrování ccTLD je migrace, ne hotový přepínač. Google oznámil v dubnu 2025 , že domény s národní koncovkou (google.co.uk, google.de atd.) budou postupně přesměrovány na google.com. Google nezveřejnil oznámení o dokončení, takže nepředpokládejte, že se každý locale už chová úplně stejně.
3. AI Overviews změnily SERP. Google uvádí, že AI Overviews dosahují více než 2,5 miliardy měsíčních uživatelů a více než 200 zemí a území. Reverzně inženýrované režimy udm mohou v některých kontextech změnit podobu výsledků, ale nejsou garantovaným přepínačem AI Overview.

Pokud jste své workflowy těmto změnám nepřizpůsobili, nejspíš získáváte zkreslené nebo oslabené výsledky, aniž byste si to uvědomovali.

Přehled parametrů Google Search URL pro rok 2026

Než se pustíme hlouběji, tabulka níže je nejaktuálnější přehled, který jsem dal dohromady. Uložte si ji do záložek.

Parameter	What It Does	Example Value	Status
q	Search query (supports operators inside)	q=best+crm+software	✅ Active
hl	Interface language	hl=en, hl=ja	✅ Active
gl	Country/market context	gl=us, gl=jp	✅ Active
lr	Restrict results to a content language	lr=lang_en	✅ Active
cr	Restrict results to a hosting country	cr=countryUS	✅ Active
start	Pagination offset	start=10 (page 2)	✅ Active
num	Results per page (formerly)	num=100	⚠️ Not formally supported; unreliable since Sept 2025
udm	Contextual content mode	udm=14 (classic web)	⚠️ Reverse-engineered; varies by context
tbm	Search vertical	tbm=isch (images)	⚠️ Still observed; test alongside udm
tbs	Time filters, sort, verbatim	tbs=qdr:w	✅ Active
safe	SafeSearch control	safe=active	✅ Active
filter	Duplicate-result filtering	filter=0	✅ Active (observed)
nfpr	Disable auto-correction	nfpr=1	✅ Active (observed)
pws	Disable personalization	pws=0	✅ Active
uule	City/DMA-level geo-targeting	uule=w+CAIQICI...	✅ Active (reverse-engineered)
as_q, as_epq, as_eq, etc.	Advanced Search form fields	Various	✅ Active
as_sitesearch	Restrict to a domain (Advanced Search)	as_sitesearch=example.com	✅ Active
as_filetype	Restrict to file type (Advanced Search)	as_filetype=pdf	✅ Active
ie, oe	Input/output encoding	ie=UTF-8	✅ Active (rarely needed)
kgmid, si, ibp	Knowledge Graph entity / feature view	Various	⚠️ Contextual (not for general use)
ei, ved, sxsrf, sclient	Session/tracking/telemetry	Various	🔒 Internal (ignore)
gbv	Basic HTML view (formerly)	gbv=1	❌ Unreliable in 2026

Parametry ei, ved, sxsrf a sclient odstraňujte ze všech URL, které ukládáte nebo sdílíte. Jde o stav relace a telemetrii, které Google přidává automaticky — při konstrukci vyhledávací URL jsou irelevantní.

Základní parametry Google Search URL, které stále fungují

Každý z nich jsem testoval živě k polovině roku 2026. To jsou parametry, ke kterým se budete vracet nejčastěji.

q — váš vyhledávací dotaz

Parametr q nese vaše hledané výrazy. Mezery se kódují jako + nebo %20. Tady žijí dokumentované vyhledávací operátory Googlu — patří dovnitř hodnoty q, ne jako samostatné URL parametry.

Pár příkladů:

• Přesná fráze: q=%22google+search+url+parameters%22
• Omezení na web: q=site%3Aexample.com+pricing
• Typ souboru: q=filetype%3Apdf+annual+report+2026
• Kombinace: q=site%3Acompetitor.com+intitle%3Apricing+after%3A2026%2F01%2F01

Vždy URL-kódujte celou hodnotu dotazu. Uvozovky, dvojtečky i lomítka je potřeba správně zakódovat, jinak si URL poškodíte.

hl — jazyk rozhraní

hl řídí jazyk rozhraní Googlu (tlačítka, popisky, nadpisy typu „People also ask“) a ovlivňuje, které výsledky Google upřednostní. Používá kódy ISO 639-1 jako en, fr, de, ja nebo tagy BCP 47 jako en-gb či pt-br.

hl ale nevynutí, aby všechny výsledné dokumenty byly v tomto jazyce. Jde o silný signál, ale Google stále může zobrazit i výsledky v jiných jazycích, pokud jsou vysoce relevantní. Pro omezení podle jazyka obsahu použijte raději lr.

gl — země / geolokace

gl simuluje zemi, odkud vyhledáváte, pomocí kódů ISO 3166-1 alpha-2 (us, gb, jp, de). S tím, jak se ccTLD postupně přesměrovávají na google.com, je gl dnes hlavní způsob, jak získat výsledky specifické pro danou zemi.

Stejný dotaz s různými hodnotami gl může vrátit úplně jiné výsledky, featured snippets i lokální panely. Například q=best+bank&gl=us a q=best+bank&gl=jp vám ukážou velmi odlišné banky.

Tip: vždy kombinujte gl s hl, abyste dostali přesně lokalizované výsledky. gl=jp spolu s hl=en vám dá výsledky pro japonský trh v anglickém rozhraní — užitečné pro mezinárodní SEO audity.

lr a cr — omezení jazyka a země

Tyto dva parametry se neustále pletou. Rozdíl je důležitý:

• lr=lang_en omezuje výsledky na stránky psané anglicky (jazyk obsahu)
• cr=countryUS omezuje výsledky na stránky hostované ve Spojených státech (umístění serveru / asociace země)
• gl=us simuluje hledání z USA (ovlivňuje pořadí, lokální výsledky i reklamy)

lr i cr jsou dostupné přes formulář Pokročilé vyhledávání Googlu. Pozor na jejich kombinování — lr=lang_en + cr=countryJP znamená „pouze anglicky psané stránky hostované v Japonsku“, což je velmi úzký výsek. Více o tom v části o konfliktech.

start — stránkování

start=10 žádá výsledky od 11. pozice (stránka 2), start=20 od 21. pozice (stránka 3) a tak dál. Protože num=100 už není spolehlivý, je bezpečnější výchozí volba zvyšovat start po desítkách — Google ale může stránkování stále přepisovat nebo omezovat.

Starý trik num=100&start=0 pro získání celé stostránkové sady už nefunguje. Pokud vaše skripty stále obsahují num, odstraňte ho — Google ho tiše ignoruje.

pws — vypnutí personalizace

pws=0 požaduje, aby Google vypnul personalizaci na základě účtu. To je zásadní pro sledování SEO pozic, kde chcete výsledky, které nejsou zkreslené vaší historií vyhledávání, prokliknutými výsledky ani nastavením účtu.

Upozornění: pws=0 snižuje personalizaci, ale neeliminuje všechny kontextové faktory. Google uvádí, že výsledky se mohou stále lišit podle času, lokace, jazyka a zařízení. Neexistuje nic jako skutečně „neutrální“ Google SERP.

safe a filter — SafeSearch a filtrování duplicit

• safe=active zapíná SafeSearch; safe=off ho vypíná. Uvědomte si, že nastavení účtu, firemní politika, síťová konfigurace nebo regionální legislativa mohou tento parametr přepsat.
• filter=0 vypíná filtrování duplicitních výsledků. Hodí se, když chcete vidět každý výsledek, který Google má, včetně téměř duplicit, které by jinak sloučil.

nfpr — vypnutí automatických oprav

nfpr=1 brání Googlu, aby váš dotaz násilně přepisoval, když si myslí, že jste udělali překlep. Hodí se pro sledování brandových výrazů s neobvyklým pravopisem, technického žargonu nebo úmyslně „špatně“ psaných dotazů, na které cílí konkurence.

Pozor: nfpr=1 potlačuje jen vynucený přepis. Pro širší kontrolu — vypnutí rozšiřování synonym, změn pravopisu a dalších automatických úprav — použijte tbs=li:1 (verbatim režim), který popisuji níže v části o tbs.

Přechod z tbm na udm: co se změnilo a co používat teď

Tohle je jedna z největších změn parametrů za poslední roky — a zároveň jedna z těch, které se nejčastěji přeceňují.

tbm byl více než deset let běžným způsobem, jak přepínat mezi vertikálami vyhledávání Google — obrázky, zprávy, video, shopping. Google zároveň zavedl číselný systém udm s překrývajícími i novými režimy. Protože Google nezveřejnil stabilní veřejný registr, berte to jako kontextové mapování, ne jako čistou a definitivní náhradu.

Kompletní tabulka mapování tbm na udm

Níže uvedená mapování kombinují pozorované chování rozhraní a živé testy s datem 12. srpna 2026. Některé hodnoty byly v anonymních požadavcích odstraněny nebo přepsány, takže každý řádek je potřeba ověřit v konkrétním účtu, regionu a klientovi, kde bude použit:

Old Parameter	Old Value	New Parameter	New Value	Status
tbm=lcl	Places/Local	udm=1	Places/Local	⚠️ Contextual
tbm=isch	Images	udm=2	Images	⚠️ Contextual
tbm=vid	Videos	udm=7	Videos	⚠️ Contextual
tbm=nws	News	udm=12	News	⚠️ Contextual
—	—	udm=14	Classic web (no AI Overview)	🆕 New, no tbm equivalent
—	—	udm=18	Forums	🆕 New, no tbm equivalent
tbm=shop	Shopping	udm=28	Shopping	⚠️ Contextual
tbm=bks	Books	udm=36	Books	⚠️ Contextual
—	—	udm=39	Short videos	🆕 New, no tbm equivalent
—	—	udm=50	AI Overview mode	🆕 New, no tbm equivalent

Google nezveřejnil stabilní registr udm — to je zásadní upozornění. Tyto hodnoty byly odvozeny reverzním inženýrstvím na základě chování vlastního rozhraní Googlu. Přijetí URL se liší podle účtu, regionu, klienta, cookies a experimentální skupiny. Při testování se některé hodnoty udm v anonymních HTTP požadavcích odstranily, ale v interaktivní relaci v prohlížeči fungovaly bez problémů. Nepředpokládejte, že každá hodnota funguje univerzálně.

Co dělá udm=14 (a proč ho SEO komunita miluje)

udm=14 se stal jakýmsi kultovním favoritem v SEO komunitě. Android Central jej popsal jako způsob, jak požádat o klasické výsledky webu bez AI Overviews. V mnoha relacích vrací tradiční SERP s modrými odkazy, ale není to oficiální ani univerzální záruka.

Proč je to důležité? Pokud děláte sledování pozic nebo SEO audit, AI Overviews mohou organické výsledky vytlačit pod fold a ztížit vyhodnocení pozic. udm=14 může poskytnout čistší pohled, pokud jej Google respektuje.

Zároveň ale udm=14 nefunguje zaručeně v každém kontextu. V živých kontrolách z 12. srpna 2026 Google někdy hodnoty udm odstranil nebo přepsal podle kontextu požadavku. Záleží na relaci, účtu, regionu, klientovi i experimentální skupině.

udm=50 byl pozorován v kontextech AI Mode / AI výsledků, ale neměl by být popisován jako garantovaný způsob, jak vynutit AI Overview pro libovolný dotaz.

Co dělat: aktualizujte workflow z tbm na udm

Moje doporučení:

• Nové implementace: Berte udm jako experimentální / kontextový vstup a přidejte fallbacky.
• Stávající workflowy: Podporujte a testujte tam, kde to dává smysl, jak tbm, tak udm, místo abyste předpokládali, že migrace je už kompletní.
• Nikdy nekombinujte obojí: Když jsou v URL současně tbm i udm, chování je nepředvídatelné. V mých testech Google někdy oba parametry odstranil a vrátil obyčejný dotaz. Více o tom v části konfliktů.

Kompletní syntaxe tbs: vlastní datumové rozsahy, řazení podle data a verbatim režim

tbs je jeden z nejmocnějších parametrů v nástrojové sadě Google search URL a většina průvodců se ho dotýká jen velmi povrchně. Zvládá časové filtrování, řazení podle data, verbatim režim a další věci — vše zabalené v jedné hodnotě oddělené čárkami.

Standardní časové filtry

tbs Value	Meaning	Example URL Fragment
qdr:h	Past hour	&tbs=qdr:h
qdr:d	Past 24 hours	&tbs=qdr:d
qdr:w	Past week	&tbs=qdr:w
qdr:m	Past month	&tbs=qdr:m
qdr:y	Past year	&tbs=qdr:y

Tohle jsou základy, které pokrývá většina návodů. tbs ale umí mnohem víc.

Vlastní datumové rozsahy

Potřebujete výsledky z konkrétního časového okna? Použijte syntaxi 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

Tímto omezíte výsledky na ty, které Google spojuje s daty mezi 1. lednem a 1. červnem 2026. Je to neocenitelné pro konkurenční research — například „co konkurenti publikovali o cenách v Q1 2026?“ Jen nezapomeňte celou hodnotu URL zakódovat, protože dvojtečky i lomítka vyžadují encoding.

Praktická poznámka: přiřazování dat Googlu není vždy přesné. Datum, které vidíte ve výsledcích vyhledávání, je nejlepší odhad Googlu, ne nutně skutečné datum publikace. Datum na cílové stránce si vždy ověřte.

Řazení podle data a verbatim režim

Tady se dostáváme k oblasti, kterou konkurující články vůbec nepokrývají.

sbd:1 seřadí výsledky podle data (nejnovější první). Samo o sobě je to užitečné, ale ne přelomové. Trik je v tom, že jej můžete kombinovat s časovými filtry v jedné hodnotě tbs:

&tbs=qdr:m,sbd:1

Dostanete tak výsledky za poslední měsíc seřazené podle data — nejnovější nahoře. Je to nejrychlejší způsob, jak zjistit, co bylo k tématu právě publikováno. Tuhle kombinaci používám neustále při sledování obsahu konkurence.

li:1 zapíná verbatim režim — URL ekvivalent kliknutí na nástroj „Verbatim“ v rozhraní vyhledávání Google. Verbatim režim vypíná automatické opravy, rozšiřování synonym, změny pravopisu a další automatické úpravy dotazu.

Rozdíl mezi li:1 a nfpr=1 je v rozsahu:

• nfpr=1: Potlačuje jen vynucené přepisování pravopisu / dotazu (např. zabrání Googlu změnit „teh“ na „the“)
• tbs=li:1: Vypíná všechny automatické úpravy — pravopis, synonyma, související výrazy i personalizační úpravy

Můžete dokonce skládat více hodnot tbs. Například tbs=qdr:m,sbd:1,li:1 dá výsledky za poslední měsíc, seřazené podle data, s verbatim porovnáním. V mých testech tato kombinace funguje, ale doporučuji ji ověřit na vašich konkrétních dotazech, protože syntaxe tbs není oficiálně dokumentovaná.

Jak vytvořit kód uule pro geotargeting na úrovni města

Pokud je gl jako zoom na úrovni země, uule je mikroskop na úrovni města. Pro lokální SEO — kontrolu, jak si vaše firma vede v Denveru vs. Dallasu, nebo co vidí hledající ve čtvrti Shibuya v Tokiu — gl samo o sobě nestačí.

Žádný z top článků ve výsledcích ve skutečnosti nevysvětluje, jak kód uule vytvořit — jen zmíní, že takový parametr existuje, a tím skončí. Níže je kompletní rozklad.

Kdy použít gl vs. uule vs. cr

Parameter	Granularity	Typical Use Case	Requires Encoding?
gl=us	Country-level	Quick country simulation	No
cr=countryUS	Country-level (restrict)	Filter by hosting country	No
uule=w+CAIQICI...	City/DMA-level	Local SEO rank checking	Yes

Algoritmus kódování uule krok za krokem

Parametr uule používá zakódovaný signál pojmenované lokace. Konstrukce je odvozena reverzním inženýrstvím, nikoli oficiálně dokumentována Googlem, ale SEO komunita ji široce ověřila.

Bezpečnější přístup je zakódovat malý payload v Protocol Buffers místo používání běžně kopírovaného zkráceného postupu, který může selhat u znaků mimo ASCII. Postup je následující:

1. Získejte kanonický název lokace od Googlu. Google publikuje geografické cíle s kanonickými názvy prostřednictvím Google Ads API geografických targetů. Příklad: New York,New York,United States
2. Zakódujte název jako UTF-8 bajty.
3. Sestavte malý protobuf payload s názvem a jeho délkou v bajtech.
4. Payload zakódujte přes base64url a přidejte předponu w+.

Tady je Python ukázka, která to dělá:

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

Když to vložíte do URL, ujistěte se, že literál + ve w+ je správně zakódován jako %2B podle vaší URL knihovny. Většina implementací URLSearchParams nebo urllib.parse.urlencode to řeší automaticky.

Správně sestavené uule je stále jen jeden signál lokace. Nepřebíjí IP adresu, nastavení účtu, zařízení ani experimentální skupinu. Používejte ho pro orientační lokální SEO kontrolu, ne jako záruku přesných městských pozic.

Když si parametry Google Search URL tiše odporují

Kombinace parametrů mohou selhat tiše: Google může ignorovat jeden vstup, přepsat URL nebo vrátit jinou podobu výsledků. Kontroly konfliktů níže se vyplatí přidat do každého workflow pro práci se search odkazy.

Žádný z konkurenčních článků neřeší interakce parametrů. Pokud ale stavíte vyhledávací URL s více parametry — a pravděpodobně ano — potřebujete vědět, které kombinace spolu fungují a které si navzájem překážejí.

gl + uule: který vyhraje?

Když jsou přítomny oba, uule poskytuje konkrétnější signál lokace než gl. Pokud nastavíte gl=uk a uule mířící na Tokio, dostanete výsledky ovlivněné Tokiem, ne výsledky pro UK.

Doporučení: Pokud používáte uule, buď gl vynechte úplně, nebo nastavte gl na zemi, do které vaše město v uule patří. Neposílejte protichůdné signály.

tbm + udm: nepoužívejte obojí

Při testování se stávalo, že když byly ve stejné URL přítomné tbm i udm, Google oba parametry někdy odstranil a vrátil obyčejný webový dotaz. Chování je nekonzistentní napříč relacemi a účty.

Doporučení: Pro nové implementace používejte jen udm. Pokud musíte podporovat starší workflowy, používejte jedno nebo druhé — nikdy obojí.

lr + cr: dvojité filtrování může vrátit nula výsledků

Tohle je záludná past. lr=lang_en omezuje výsledky na anglicky psaný obsah. cr=countryJP omezuje výsledky na stránky hostované v Japonsku. Když je zkombinujete, ptáte se na „anglicky psané stránky hostované v Japonsku“ — což je velmi malý výsek webu.

Doporučení: Používejte jen jedno z toho, pokud výslovně nepotřebujete průnik. Pokud je zkombinujete, počítejte s výrazně menším počtem výsledků.

num + start: rozbité stránkování

Staré skripty používající num=100&start=0 dnes tiše vrátí jen zhruba 10 výsledků. Parametr num už není respektován, ale nevyhodí chybu — prostě je ignorován.

Doporučení: Odstraňte num ze všech URL. Stránkujte pomocí start po desítkách a výsledky mezi stránkami deduplikujte.

Rychlá referenční tabulka konfliktů

Combination	What Happens	Recommendation
gl + uule	uule provides more specific signal	Align country and city, or omit gl
tbm + udm	Unpredictable — both may be stripped	Use only udm
lr + cr	Aggressive narrowing, often near-zero results	Use one or the other
num + start	num ignored, only ~10 results returned	Remove num, paginate with start
nfpr=1 + tbs=li:1	Related but not identical controls	Test your specific query
hl + lr	Interface language ≠ content language restriction	Use deliberately; hl is not a content filter

Od parametrů Google Search URL ke strukturované extrakci dat

V této chvíli máte přesnou Google Search URL — správný dotaz, správnou zemi, správný datumový rozsah, klasické webové výsledky. Dalším krokem je získat z výsledků strukturovaná data.

Ať už budujete sledování pozic, monitorujete konkurenci nebo posíláte vyhledávací data do research workflow, vidět správné výsledky je jen polovina práce. Potřebujete názvy, URL, úryvky, pozice a data ve spreadsheetu nebo databázi.

Vytvoření cílené Google Search URL (vše dohromady)

Kompletní příklad kombinující více parametrů:

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

Rozpad na části:

• q=site%3Acompetitor.com+intitle%3Apricing — stránky na competitor.com s výrazem „pricing“ v titulku
• hl=en — anglické rozhraní
• gl=us — kontext trhu USA
• tbs=qdr:m,sbd:1 — poslední měsíc, seřazeno podle data
• udm=14 — klasické webové výsledky (bez AI Overviews)
• pws=0 — vypnutá personalizace

Programově to můžete sestavit pomocí 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'

Nebo v Pythonu:

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)

Anonymní HTTP požadavky na Google často vracejí JavaScriptové shell stránky bez server-side renderovaných výsledků nebo upozornění na neobvyklý provoz — a právě tady má browserová extrakce navrch.

Extrakce dat ze SERPu bez psaní parseru

Parsování HTML od Googlu je křehká práce. Struktura DOM se často mění, názvy tříd jsou obfuskované a to, co vidíte v prohlížeči, není vždy to, co dostanete v raw HTTP odpovědi.

Jednodušší přístup pro ne-vývojáře: otevřete pečlivě sestavenou search URL v Chromu a pak použijte nástroj pro extrakci z prohlížeče, který vytáhne strukturovaná data z viditelné stránky. V Thunderbit jsme vytvořili Chrome extension přesně pro tento typ workflow — můžete použít AI Suggest Fields pro identifikaci sloupců jako název výsledku, cílová URL, text úryvku a viditelná pozice a pak je vyextrahovat do spreadsheetu bez psaní parseru.

To ale není jediná cesta. Kódované přístupy fungují také, hlavně pokud potřebujete velký objem nebo opakovanou extrakci. Pro ad hoc research, audity a jednorázovou konkurenční analýzu však browserová extrakce úplně obchází křehkost HTML parsingu.

Kdy místo toho použít oficiální API

Připomínka odpovědného použití — a je důležitá.

Podmínky služby Googlu zakazují automatizovaný přístup, který obchází ochranná opatření, a Google Search Help výslovně řadí search scrapery a software posílající automatizované dotazy za účelem zjištění pozic mezi automatizovaný provoz. Provozování Google scrapera ve velkém měřítku vás vystavuje riziku blokací IP, CAPTCHA a možných právních problémů.

Pro produkční potřeby s vysokým objemem vyhledávacích dat je lepší cesta oficiální API. Google Custom Search JSON API je uzavřen pro nové zákazníky — stávající uživatelé mají čas na přechod do 1. ledna 2027, přičemž jsou k dispozici 100 bezplatných dotazů denně a poté sazba $5 za 1 000 dotazů. Google pro řízené vyhledávání na vlastních webech doporučuje Vertex AI Search.

Pro weby, které vlastníte, je Search Console Search Analytics API první stranou poskytující kliknutí, zobrazení, CTR a průměrnou pozici — bez potřeby scrapingu.

Berete-li znalost URL parametrů jako diagnostický a research nástroj, je to skvělé pro tvorbu přesných search odkazů, manuální audity a pochopení toho, co Google zobrazuje. Není to náhrada za oficiální API v rozsahu.

Operátory Google Search: parametry uvnitř dotazu

Vyhledávací operátory žijí uvnitř parametru q=, ale jsou zásadním doplňkem URL parametrů. Tabulka níže pokrývá ty, které Google aktuálně dokumentuje, plus několik dalších, které v praxi stále fungují:

Operator	What It Does	Example
site:	Restrict to a domain	q=site:example.com+SEO
filetype:	Restrict to file type	q=filetype:pdf+annual+report
intitle:	Word must appear in title	q=intitle:pricing+SaaS
inurl:	Word must appear in URL	q=inurl:blog+marketing
-	Exclude a term	q=apple+-fruit
""	Exact phrase match	q=%22google+search+url+parameters%22
OR	Either term	q=scraping+OR+crawling
before:	Results before a date	q=AI+before:2026-01-01
after:	Results after a date	q=AI+after:2025-06-01
related:	Similar sites	q=related:hubspot.com

Skutečná síla přichází kombinací operátorů uvnitř q s URL parametry mimo něj:

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

Tímto najdete stránky na competitor.com s titulkem „pricing“, publikované po lednu 2026, seřazené podle data, pro trh USA, s klasickými webovými výsledky. To je velmi přesný query pro competitive intelligence postavený čistě z URL parametrů a operátorů.

Google uvádí, že výsledky site: nejsou zaručeně kompletní — nepovažujte tedy dotaz site: za vyčerpávající inventář všech indexovaných stránek.

Zodpovědné použití: podmínky služby Googlu a limity rychlosti

Krátký, ale důležitý kontext.

Podmínky služby Googlu zakazují zneužívající přístup a obcházení ochranných opatření. Google Search Help výslovně uvádí search scrapery a automatizovaný ranking software jako příklady automatizovaného provozu. Porušení těchto podmínek může vést k blokaci IP, CAPTCHA, omezení účtu a případně i právním krokům.

Znalost URL parametrů je nejlepší používat pro: ruční sestavování přesných vyhledávacích URL, tvorbu bookmarkovatelných search odkazů pro tým, malé audity v prohlížeči a pochopení toho, jak vyhledávací rozhraní Googlu funguje. Pro automatizaci v produkčním rozsahu používejte oficiální API Googlu — nebo licencovaného poskytovatele třetích stran pro vyhledávací data, jako je Brave Search API.

V Thunderbit je náš browser extension navržen pro extrakci z viditelné stránky iniciovanou uživatelem — ne pro vysokofrekvenční automatizované dotazování Googlu. To je důležitý rozdíl.

Hlavní závěry: váš toolkit parametrů Google Search URL pro rok 2026

Zkrácená verze:

• Pro lokalizaci používejte gl + hl a během migračního přesměrování Googlu nespoléhejte jen na ccTLD
• Tam, kde to dává smysl, testujte udm i tbm — ani jeden není stabilní verzované consumer API
• udm=14 může požádat o klasické webové výsledky bez AI Overviews, ale Google ho může odstranit nebo přepsat
• Pro geotargeting na úrovni města používejte uule s výše uvedeným protobuf kódováním
• Ovládněte tbs pro přesné filtrování podle data (cdr:1,cd_min:...,cd_max:...), řazení podle data (sbd:1) a verbatim search (li:1)
• Dávejte pozor na konflikty parametrů: gl vs. uule, tbm vs. udm, lr vs. cr
• num=100 je nespolehlivý a nikdy nebyl formálně podporován — bezpečnější výchozí je stránkování po 10 pomocí start
• Pro strukturovaná SERP data použijte browserové nástroje jako Thunderbit pro ad hoc práci, nebo oficiální API pro produkční rozsah
• Respektujte podmínky služby Googlu — URL parametry jsou výzkumný nástroj, ne licence ke scrapingu

Google stále mění parametry bez oznámení. Tento referenční materiál budu držet aktuální podle toho, jak se situace mění — uložte si ho do záložek a vraťte se k němu.

Zjistit více

• 9 nejlepších SEO API pro rok 2026 (s reálnými daty o ceně za request)
• Jak zvládnout scraping vyhledávačů: kompletní průvodce
• Top 27 nástrojů pro analýzu a sledování pozic webu
• Jak používat stránkování Web Scraperu pro efektivní extrakci
• Co je search automation? Výhody, nástroje a strategie

Často kladené otázky

Co dělá udm=14 ve vyhledávací URL Google?

udm=14 může požádat o klasické výsledky webu bez AI Overviews, proto je oblíbený mezi SEO profesionály. Jde o reverzně inženýrované chování, ne o oficiálně zdokumentovaný kontrakt Googlu, a Google jej může podle relace, účtu, regionu, klienta a experimentální skupiny odstranit nebo přepsat.

Funguje parametr num i v roce 2026?

Nespoléhejte na něj. Google přestal spolehlivě respektovat num=100 v září 2025 a mluvčí uvedl, že tento parametr nikdy nebyl formálně podporován. Jako bezpečnější výchozí pro stránkování používejte start po 10 a ověřujte počet vrácených výsledků, protože Google může odpověď stále přepsat nebo omezit.

Jak nasimuluji vyhledávání Google z konkrétního města?

Použijte parametr uule s zakódovaným názvem města. Výše uvedená sekce o kódování nabízí algoritmus založený na protobufu i ukázku v Pythonu. Budete potřebovat kanonický název lokace od Googlu (dostupný v Google Ads geographic targeting data), který zakódujete do hodnoty uule, například uule=w+CAIQICIeNew+York,New+York,United+States.

Jaký je rozdíl mezi gl, lr a cr?

Tyto tři parametry řídí různé aspekty geografického a jazykového cílení. gl simuluje vaši vyhledávací lokaci na úrovni země (ovlivňuje pořadí i lokální výsledky). lr omezuje výsledky na stránky napsané v určitém jazyce obsahu. cr omezuje výsledky na stránky hostované v určité zemi. Lze je kombinovat, ale protichůdné kombinace (například lr=lang_en + cr=countryJP) vaše výsledky výrazně zúží.

Můžu v jedné URL kombinovat více hodnot tbs?

Ano — oddělte je čárkami v rámci jednoho parametru tbs. Například tbs=qdr:m,sbd:1 filtruje výsledky na poslední měsíc a seřadí je podle data (nejnovější první). Můžete přidat i li:1 pro verbatim režim: tbs=qdr:m,sbd:1,li:1. Syntaxe tbs není oficiálně dokumentovaná, proto konkrétní kombinace vždy otestujte, abyste si potvrdili, že fungují podle očekávání.