Google Search URL-parameters: wat nog werkt in 2026

Rond september 2025 liep er stilletjes iets mis bij heel wat SEO-tools en custom scripts. De boosdoener? Google ondersteunde de parameter num=100 niet langer betrouwbaar, terwijl power users daar jarenlang op vertrouwden om 100 resultaten per pagina op te halen. Er kwam geen officiële deprecatie-aankondiging — alleen een woordvoerder die tegen Search Engine Land zei dat de parameter "niet formeel werd ondersteund." In dezelfde periode introduceerde Google meer udm-modi naast de oudere tbm-verticals, kondigde het aan dat landcode-domeinen geleidelijk zouden doorverwijzen naar google.com, en meldde het dat AI Overviews meer dan 2,5 miljard maandelijkse gebruikers bereikten.

Als je zoek-URL's bouwt, rankings volgt of onderzoek automatiseert met Google’s URL-parameters, is de kans groot dat sommige workflows op dit moment ongemerkt slechter werken. Bij Thunderbit hebben we de huidige Google-documentatie, recente wijzigingsaankondigingen, reverse-engineered verwijzingen en live checks naast elkaar gelegd om stabiele instellingen te scheiden van contextafhankelijke. Het resultaat is een datumgebonden, eerst-testen-dan-uitrollen referentie voor de Google search URL-parameters die in 2026 relevant zijn, inclusief tbm/udm-mapping, de uule-coderingsformule voor geo-targeting op stadniveau en parameterconflicten die uren debugwerk kunnen besparen.

Wat zijn Google Search URL-parameters?

Google Search URL-parameters zijn de key=value-paren die na de ? in een Google-zoek-URL staan. Ze bepalen alles: waar je op zoekt, uit welk land de resultaten komen en of je afbeeldingen, nieuws of de klassieke blauwe links krijgt.

Een typische Google-zoek-URL ziet er zo uit:

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

• Basis-URL: https://www.google.com/search
• ? begint de querystring
• q=best+crm+software is de zoekopdracht (spaties zijn gecodeerd als +)
• & scheidt elke parameter
• hl=en zet de interface op Engels
• gl=us vertelt Google om resultaten te tonen alsof je in de VS zoekt
• tbs=qdr:m filtert op resultaten van de afgelopen maand

Een belangrijk onderscheid: zoekoperators zoals site:, filetype: en intitle: zitten in de q=-waarde. Ze maken deel uit van je zoekopdracht. URL-parameters zoals gl, hl en tbs zijn losse sleutels in de URL die bepalen hoe Google resultaten verwerkt en weergeeft. Beide zijn belangrijk en werken samen — maar het zijn wel verschillende dingen.

Google heeft nooit één versiegebonden specificatie voor deze parameters gepubliceerd. Sommige komen uit het Advanced Search-formulier, sommige uit de Custom Search API, en sommige zijn reverse-engineered op basis van Google’s eigen URL’s. Dat betekent dat dit artikel is gebaseerd op live tests en gedocumenteerd gedrag, niet op een officiële API-overeenkomst.

Waarom Google Search URL-parameters in 2026 belangrijk zijn

URL-parameters zijn niet alleen interessant voor ontwikkelaars. Iedereen in SEO, marketing, sales, operations of product die wil begrijpen wat Google toont voor een specifieke zoekopdracht, in een specifieke markt, op een specifiek moment — dit zijn je hulpmiddelen.

Een snelle uitleg van wie ervan profiteert en hoe:

Use Case	Who Benefits	Key Parameters
SEO ranktracking over meerdere landen	SEO- en marketingteams	gl, hl, uule, pws
Concurrentiemonitoring per datum	Strategie- en operationsteams	tbs, q met site:
Ad-monitoring in specifieke markten	Paid media-teams	gl, hl, udm
Lokale SEO-audits (stadniveau)	Lokale ondernemers	uule, gl
Contentonderzoek / trendtracking	Contentteams	tbs (datumfilters), lr
Zoekdata in AI/LLM-apps voeden	Product- en datateams	Meerdere parameters + gestructureerde extractie

Drie grote verschuivingen maken 2026 wezenlijk anders:

1. num=100 is niet langer betrouwbaar. De oude truc voor resultaten per pagina werkt sinds september 2025 niet meer consistent. Google heeft het niet formeel uitgefaseerd; een woordvoerder zei dat het nooit formeel werd ondersteund.
2. ccTLD-redirects zijn een migratie, geen afgeronde overgang. Google kondigde in april 2025 aan dat landcode-domeinen (google.co.uk, google.de, enz.) geleidelijk zouden doorverwijzen naar google.com. Google heeft geen voltooiingsbericht gepubliceerd, dus ga er niet van uit dat elke locale al identiek werkt.
3. AI Overviews hebben de SERP veranderd. Google meldt dat AI Overviews meer dan 2,5 miljard maandelijkse gebruikers en 200+ landen en gebieden bereiken. Reverse-engineered udm-modi kunnen in sommige situaties de resultaatweergave veranderen, maar zijn geen gegarandeerde schakelaar voor AI Overviews.

Als je workflows niet op deze wijzigingen zijn bijgewerkt, krijg je waarschijnlijk ongemerkt vertekende of misleidende resultaten.

Google Search URL-parameters spiekbriefje (2026)

Voordat we dieper ingaan: de onderstaande snelle referentietabel is de meest actuele lijst die ik heb kunnen samenstellen. Sla hem op.

Parameter	What It Does	Example Value	Status
q	Zoekopdracht (ondersteunt operators binnenin)	q=best+crm+software	✅ Actief
hl	Interface-taal	hl=en, hl=ja	✅ Actief
gl	Land-/marktcontext	gl=us, gl=jp	✅ Actief
lr	Resultaten beperken tot een contenttaal	lr=lang_en	✅ Actief
cr	Resultaten beperken tot een hostland	cr=countryUS	✅ Actief
start	Paginatie-offset	start=10 (pagina 2)	✅ Actief
num	Aantal resultaten per pagina (vroeger)	num=100	⚠️ Niet formeel ondersteund; sinds sept 2025 onbetrouwbaar
udm	Contextuele contentmodus	udm=14 (klassiek web)	⚠️ Reverse-engineered; verschilt per context
tbm	Zoekverticale	tbm=isch (afbeeldingen)	⚠️ Nog waargenomen; samen met udm testen
tbs	Tijdfilters, sortering, verbatim	tbs=qdr:w	✅ Actief
safe	SafeSearch-instelling	safe=active	✅ Actief
filter	Filteren van dubbele resultaten	filter=0	✅ Actief (waargenomen)
nfpr	Auto-correctie uitschakelen	nfpr=1	✅ Actief (waargenomen)
pws	Personalisatie uitschakelen	pws=0	✅ Actief
uule	Geo-targeting op stads-/DMA-niveau	uule=w+CAIQICI...	✅ Actief (reverse-engineered)
as_q, as_epq, as_eq, etc.	Velden van het Advanced Search-formulier	Diverse	✅ Actief
as_sitesearch	Beperken tot een domein (Advanced Search)	as_sitesearch=example.com	✅ Actief
as_filetype	Beperken tot een bestandstype (Advanced Search)	as_filetype=pdf	✅ Actief
ie, oe	Input-/output-encoding	ie=UTF-8	✅ Actief (zelden nodig)
kgmid, si, ibp	Knowledge Graph-entiteit / feature view	Diverse	⚠️ Contextafhankelijk (niet voor algemeen gebruik)
ei, ved, sxsrf, sclient	Sessies / tracking / telemetry	Diverse	🔒 Intern (negeren)
gbv	Basic HTML-weergave (vroeger)	gbv=1	❌ Onbetrouwbaar in 2026

Verwijder ei, ved, sxsrf en sclient uit URL’s die je opslaat of deelt. Dit zijn sessie- en telemetrygegevens die Google automatisch toevoegt — niet relevant voor het opbouwen van zoek-URL’s.

Kern Google Search URL-parameters die nog werken

Ik heb elk van deze live getest medio 2026. Dit zijn de parameters die je het vaakst zult gebruiken.

q — je zoekopdracht

De parameter q bevat je zoektermen. Spaties worden gecodeerd als + of %20. Hierin leven Google’s gedocumenteerde zoekoperators — ze horen in de q-waarde, niet als aparte URL-parameters.

Enkele voorbeelden:

• Exacte frase: q=%22google+search+url+parameters%22
• Beperkt tot site: q=site%3Aexample.com+pricing
• Bestandstype: q=filetype%3Apdf+annual+report+2026
• Gecombineerd: q=site%3Acompetitor.com+intitle%3Apricing+after%3A2026%2F01%2F01

URL-encodeer altijd de volledige querywaarde. Aanhalingstekens, dubbele punten en schuine strepen moeten correct worden gecodeerd om te voorkomen dat de URL kapotgaat.

hl — interface-taal

hl bepaalt de taal van Google’s interface (knoppen, labels, kopjes zoals "Mensen vragen ook") en beïnvloedt welke resultaten Google prioriteert. Het gebruikt ISO 639-1-codes zoals en, fr, de, ja, of BCP 47-tags zoals en-gb of pt-br.

hl dwingt niet af dat alle resultaatdocumenten in die taal zijn. Het is een sterk signaal, maar Google kan nog steeds resultaten in andere talen tonen als die erg relevant zijn. Voor beperking op contenttaal gebruik je liever lr.

gl — land / geolocatie

gl simuleert het land van waaruit je zoekt, met ISO 3166-1 alpha-2-codes (us, gb, jp, de). Met ccTLD’s die geleidelijk doorverwijzen naar google.com is gl nu de belangrijkste manier om landspecifieke resultaten te krijgen.

Dezelfde zoekopdracht met verschillende gl-waarden kan compleet andere resultaten, featured snippets en local packs opleveren. Bijvoorbeeld: q=best+bank&gl=us en q=best+bank&gl=jp tonen heel andere banken.

Tip: combineer gl altijd met hl voor nauwkeurige gelokaliseerde resultaten. gl=jp met hl=en geeft Japan-marktresultaten in een Engelse interface — handig voor internationale SEO-audits.

lr en cr — taalrestrictie en landrestrictie

Deze twee worden voortdurend door elkaar gehaald. Het verschil is belangrijk:

• lr=lang_en beperkt resultaten tot pagina’s die in het Engels zijn geschreven (contenttaal)
• cr=countryUS beperkt resultaten tot pagina’s die in de Verenigde Staten worden gehost (serverlocatie / landassociatie)
• gl=us simuleert zoeken vanuit de Verenigde Staten (beïnvloedt ranking, lokale resultaten, advertenties)

Zowel lr als cr zijn beschikbaar via Google’s Advanced Search-formulier. Wees voorzichtig met combineren — lr=lang_en + cr=countryJP betekent "alleen Engelstalige pagina’s gehost in Japan", en dat is een erg kleine set. Meer hierover in het gedeelte over conflicten.

start — paginatie

start=10 vraagt om resultaten vanaf positie 11 (pagina 2), start=20 voor pagina 3, enzovoort. Omdat num=100 niet meer betrouwbaar is, is elke 10 opschuiven de veiligste standaard — maar Google kan paginering nog steeds herschrijven of beperken.

De oude truc num=100&start=0 om een volledige pagina van 100 resultaten op te halen werkt niet meer. Als je scripts nog num bevatten, haal die weg — hij wordt stilzwijgend genegeerd.

pws — personalisatie uitschakelen

pws=0 vraagt Google om accountgebaseerde personalisatie uit te zetten. Dit is essentieel voor SEO-ranktracking, omdat je resultaten wilt die niet worden beïnvloed door je eigen zoekgeschiedenis, geklikte resultaten of accountvoorkeuren.

Let op: pws=0 vermindert personalisatie, maar schakelt niet alle contextfactoren uit. Google zegt dat resultaten nog steeds kunnen variëren op basis van tijd, locatie, taal en apparaat. Een volledig "neutrale" Google-SERP bestaat niet.

safe en filter — SafeSearch en filteren van duplicaten

• safe=active zet SafeSearch aan; safe=off zet het uit. Let op: accountinstellingen, beheerregels, netwerkconfiguraties of regionale wetgeving kunnen deze parameter overschrijven.
• filter=0 schakelt Google’s filtering van dubbele resultaten uit. Handig als je alles wilt zien wat Google heeft, inclusief bijna-duplicaten die normaal worden samengevoegd.

nfpr — auto-correctie uitschakelen

nfpr=1 voorkomt dat Google je zoekopdracht geforceerd herschrijft wanneer het denkt dat je iets verkeerd hebt gespeld. Dit is handig voor het volgen van merknamen met ongewone spelling, technische termen of opzettelijk fout gespelde zoekopdrachten waarop concurrenten zich richten.

Let op dat nfpr=1 alleen de geforceerde herschrijving onderdrukt. Voor bredere controle — het uitschakelen van synoniemen, spellingswijzigingen en andere automatische aanpassingen — gebruik je tbs=li:1 (verbatim-modus), die ik hieronder bij tbs behandel.

De tbm-naar-udm-migratie: wat veranderde en wat je nu moet gebruiken

Dit is een van de grootste parameterwijzigingen van de afgelopen jaren — en ook een van de makkelijkste om te overschatten.

tbm is al meer dan tien jaar een veelgebruikte manier om te wisselen tussen Google’s zoekverticals — afbeeldingen, nieuws, video, shopping. Google heeft daarnaast een numeriek udm-systeem geïntroduceerd met overlappende en extra modi. Omdat Google geen stabiel consumentenregister heeft gepubliceerd, moet je dit zien als een contextuele mapping en niet als een nette, volledig afgeronde vervanging.

De volledige tbm-naar-udm-mappingtabel

De mappings hieronder combineren waargenomen UI-gedragingen en live spotchecks van 12 augustus 2026. Verschillende waarden werden in anonieme verzoeken gestript of herschreven, dus elke rij moet worden getest in het account, de regio en de client waar hij wordt gebruikt:

Old Parameter	Old Value	New Parameter	New Value	Status
tbm=lcl	Places/Local	udm=1	Places/Local	⚠️ Contextafhankelijk
tbm=isch	Images	udm=2	Images	⚠️ Contextafhankelijk
tbm=vid	Videos	udm=7	Videos	⚠️ Contextafhankelijk
tbm=nws	News	udm=12	News	⚠️ Contextafhankelijk
—	—	udm=14	Classic web (geen AI Overviews)	🆕 Nieuw, geen tbm-equivalent
—	—	udm=18	Forums	🆕 Nieuw, geen tbm-equivalent
tbm=shop	Shopping	udm=28	Shopping	⚠️ Contextafhankelijk
tbm=bks	Books	udm=36	Books	⚠️ Contextafhankelijk
—	—	udm=39	Korte video’s	🆕 Nieuw, geen tbm-equivalent
—	—	udm=50	AI Overview-modus	🆕 Nieuw, geen tbm-equivalent

Google heeft geen stabiel udm-register gepubliceerd — dat is een belangrijke kanttekening. Deze waarden zijn reverse-engineered op basis van het gedrag van Google’s eigen interface. URL-acceptatie verschilt per account, regio, client, cookies en testgroep. In mijn tests werden sommige udm-waarden gestript in anonieme HTTP-verzoeken, maar werkten ze prima in interactieve browsersessies. Ga er niet van uit dat elke waarde universeel werkt.

Wat doet udm=14 (en waarom SEO’ers het waarderen)

udm=14 is in de SEO-community een soort cultfavoriet geworden. Android Central beschreef het als een manier om een klassieke webresultatenweergave op te vragen zonder AI Overviews. In veel sessies levert het een traditionele SERP met blauwe links op, maar het is geen officiële of universele garantie.

Waarom is dat belangrijk? Als je rankings volgt of SEO-audits uitvoert, kunnen AI Overviews organische resultaten onder de vouw duwen en het moeilijker maken om posities goed te beoordelen. udm=14 kan een schoner beeld geven wanneer Google het respecteert.

Dat gezegd hebbende: udm=14 werkt niet gegarandeerd in elke context. In live spotchecks van 12 augustus 2026 haalde Google soms udm-waarden weg of herschreef ze, afhankelijk van de context van het verzoek. Het resultaat hangt af van sessie, account, regio, client en experimentgroep.

udm=50 is waargenomen in AI Mode-/AI-result-contexten, maar je moet het niet omschrijven als een gegarandeerde manier om voor een willekeurige query een AI Overview af te dwingen.

Wat je moet doen: update workflows van tbm naar udm

Mijn advies:

• Nieuwe implementaties: behandel udm als een experimentele/contextuele input en bouw fallbacks in.
• Bestaande workflows: ondersteun en test zowel tbm als udm waar relevant, in plaats van aan te nemen dat de migratie al afgerond is.
• Nooit beide combineren: wanneer tbm en udm allebei in één URL staan, is het gedrag onvoorspelbaar. In mijn tests haalde Google soms beide weg en gaf het een gewone zoekopdracht terug. Meer hierover in het conflicten-gedeelte.

De volledige tbs-syntax: aangepaste datumbereiken, sorteren op datum en verbatim

tbs is een van de krachtigste parameters in de Google Search URL-toolkit, en de meeste gidsen gaan nauwelijks verder dan de basis. Hij regelt tijdsfilters, sortering op datum, verbatim-modus en meer — allemaal verpakt in één door komma’s gescheiden waarde.

Standaard tijdsfilters

tbs Value	Meaning	Example URL Fragment
qdr:h	Afgelopen uur	&tbs=qdr:h
qdr:d	Afgelopen 24 uur	&tbs=qdr:d
qdr:w	Afgelopen week	&tbs=qdr:w
qdr:m	Afgelopen maand	&tbs=qdr:m
qdr:y	Afgelopen jaar	&tbs=qdr:y

Dit zijn de basisfilters die de meeste gidsen behandelen. Maar tbs kan veel meer.

Aangepaste datumbereiken

Resultaten uit een specifieke periode nodig? Gebruik de syntax 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

Dit filtert resultaten die Google aan data koppelt tussen 1 januari en 1 juni 2026. Onmisbaar voor concurrentieonderzoek — bijvoorbeeld: "wat publiceerden concurrenten over pricing in Q1 2026?" Vergeet niet de volledige waarde te URL-encoden, want dubbele punten en schuine strepen moeten gecodeerd worden.

Een praktische opmerking: Google’s datumkoppeling is niet altijd accuraat. De datum die in zoekresultaten verschijnt is Google’s beste inschatting, niet per se de echte publicatiedatum. Controleer datums altijd op de doelpagina.

Sorteren op datum en verbatim-modus

Hier gaat deze gids verder dan andere artikelen.

sbd:1 sorteert resultaten op datum (nieuwste eerst). Op zichzelf is dat handig, maar niet spectaculair. De truc is dat je het kunt combineren met tijdsfilters in één tbs-waarde:

&tbs=qdr:m,sbd:1

Dan krijg je resultaten van de afgelopen maand, gesorteerd op datum — nieuwste eerst. Dat is de snelste manier om te zien wat er net over een onderwerp is gepubliceerd. Ik gebruik deze combinatie voortdurend bij het monitoren van content van concurrenten.

li:1 zet verbatim-modus aan — de URL-tegenhanger van het klikken op Google’s "Verbatim"-tool in de zoekinterface. Verbatim-modus schakelt auto-correctie, synoniemen, spellingswijzigingen en andere automatische aanpassingen van de zoekopdracht uit.

Het verschil tussen li:1 en nfpr=1 zit in de scope:

• nfpr=1: onderdrukt alleen geforceerde spellings-/query-herschrijving (bijv. voorkomt dat Google "teh" naar "the" verandert)
• tbs=li:1: schakelt alle automatische aanpassingen uit — spelling, synoniemen, gerelateerde termen, personalisatie-aanpassingen

Je kunt zelfs meerdere tbs-waarden stapelen. Bijvoorbeeld tbs=qdr:m,sbd:1,li:1 geeft resultaten van de afgelopen maand, gesorteerd op datum, met verbatim matching. In mijn tests werkt deze combinatie, maar ik raad aan om het voor jouw specifieke zoekopdrachten te verifiëren, omdat tbs niet-gedocumenteerde syntax is.

Hoe je een uule-code maakt voor geo-targeting op stadniveau

Als gl een landelijke zoomlens is, dan is uule een microscoop op stadsniveau. Voor lokale SEO — bijvoorbeeld checken hoe je bedrijf rankt in Denver versus Dallas, of wat een zoeker in Shibuya in Tokio ziet — is gl alleen niet precies genoeg.

Geen enkel topartikel legt eigenlijk uit hoe je een uule-code construeert — ze noemen wel dat de parameter bestaat en gaan dan verder. Hieronder de volledige uitleg.

Wanneer gebruik je gl vs. uule vs. cr?

Parameter	Granularity	Typical Use Case	Requires Encoding?
gl=us	Country-level	Snelle simulatie van een land	No
cr=countryUS	Country-level (restrict)	Filteren op hostland	No
uule=w+CAIQICI...	City/DMA-level	Lokale SEO-rankcontrole	Yes

Het uule-coderingsalgoritme (stap voor stap)

De parameter uule gebruikt een gecodeerd named-location-signaal. De constructie is reverse-engineered, niet officieel door Google gedocumenteerd, maar de SEO-community heeft het breed gevalideerd.

De veiligere aanpak is om een kleine Protocol Buffers-payload te coderen in plaats van te vertrouwen op de vaak gekopieerde shortcut (die kan falen bij niet-ASCII-tekens). Zo werkt het:

1. Haal de canonieke Google-locatienaam op. Google publiceert geografische doelen met canonieke namen via de Google Ads API geographic targeting data. Voorbeeld: New York,New York,United States
2. Codeer de naam als UTF-8-bytes.
3. Bouw een kleine protobuf-payload met de naam en de byte-lengte.
4. Base64url-codeer de payload en zet w+ ervoor.

Hier is een Python-fragment dat dit doet:

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

Als je dit in een URL zet, zorg er dan voor dat de letterlijke + in w+ correct wordt ge-encodeerd als %2B door je URL-bibliotheek. De meeste URLSearchParams- of urllib.parse.urlencode-implementaties doen dit automatisch.

Een correct geconstrueerde uule is nog steeds maar één locatie-signaal. Het overschrijft IP-adres, accountinstellingen, apparaat of experimentgroep niet. Gebruik het als richtinggevend hulpmiddel voor lokale SEO-checks, niet als garantie voor exacte city-level rankings.

Wanneer Google Search URL-parameters stilletjes botsen

Parametercombinaties kunnen stilletjes mislukken: Google kan één input negeren, de URL herschrijven of een andere weergave teruggeven. De conflictchecks hieronder zijn het waard om in elke zoeklink-workflow op te nemen.

Geen enkel ander artikel behandelt parameterinteracties. Maar als je zoek-URL’s bouwt met meerdere parameters — en dat doe je waarschijnlijk — moet je weten welke combinaties goed samenwerken en welke elkaar juist tegenwerken.

gl + uule: welke wint?

Wanneer beide aanwezig zijn, geeft uule een specifieker locatie-signaal dan gl. Als je gl=uk instelt en een uule gebruikt die naar Tokio wijst, krijg je resultaten beïnvloed door Tokio, niet door het VK.

Aanbeveling: als je uule gebruikt, laat gl dan weg of zet gl op het land waarin je uule-stad ligt. Stuur geen tegenstrijdige signalen.

tbm + udm: gebruik niet beide

In mijn tests haalde Google, wanneer tbm en udm samen in dezelfde URL stonden, soms beide parameters weg en gaf het een gewone webzoekopdracht terug. Het gedrag verschilt per sessie en account.

Aanbeveling: gebruik alleen udm voor nieuwe implementaties. Als je legacy workflows moet ondersteunen, gebruik dan één van de twee — nooit allebei.

lr + cr: dubbele filtering kan nul resultaten geven

Dit is een subtiele valkuil. lr=lang_en beperkt tot Engelstalige content. cr=countryJP beperkt tot pagina’s die in Japan worden gehost. Combineer ze en je vraagt om "Engelstalige pagina’s gehost in Japan" — een heel klein deel van het web.

Aanbeveling: gebruik één van de twee, tenzij je specifiek de overlap nodig hebt. Als je ze combineert, verwacht dan veel minder resultaten.

num + start: kapotte paginatie

Oude scripts die num=100&start=0 gebruiken, geven nu stilletjes maar ongeveer 10 resultaten terug. De num-parameter wordt niet langer gerespecteerd, maar veroorzaakt geen fout — hij wordt gewoon genegeerd.

Aanbeveling: verwijder num uit alle URL’s. Pagineer met start in stappen van 10 en dedupliceer resultaten over de pagina’s heen.

Snelle conflictreferentie

Combination	What Happens	Recommendation
gl + uule	uule geeft een specifieker signaal	Stem land en stad op elkaar af, of laat gl weg
tbm + udm	Onvoorspelbaar — beide kunnen worden gestript	Gebruik alleen udm
lr + cr	Sterke vernauwing, vaak bijna nul resultaten	Gebruik één van de twee
num + start	num genegeerd, slechts ~10 resultaten terug	Verwijder num, pageer met start
nfpr=1 + tbs=li:1	Verwante maar niet identieke controls	Test je specifieke zoekopdracht
hl + lr	Interface-taal ≠ contenttaalrestrictie	Bewust gebruiken; hl is geen contentfilter

Van Google Search URL-parameters naar gestructureerde data-extractie

Op dit punt heb je een precieze Google-zoek-URL — juiste zoekopdracht, juist land, juiste periode, klassieke webresultaten. De volgende stap is het gestructureerd ophalen van data uit die resultaten.

Of je nu een rank tracker bouwt, concurrenten monitort of zoekdata in een onderzoeksworkflow stopt: de juiste resultaten zien is maar de helft van het werk. Je hebt titels, URL’s, snippets, posities en datums nodig in een spreadsheet of database.

Een gerichte Google-zoek-URL bouwen (alles combineren)

Een volledig voorbeeld met meerdere parameters:

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

Uitleg:

• q=site%3Acompetitor.com+intitle%3Apricing — pagina’s op competitor.com met "pricing" in de titel
• hl=en — Engelse interface
• gl=us — Amerikaanse marktcontext
• tbs=qdr:m,sbd:1 — afgelopen maand, gesorteerd op datum
• udm=14 — klassieke webresultaten (geen AI Overviews)
• pws=0 — personalisatie uit

Je kunt dit programmatisch opbouwen met 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'

Of met Python:

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)

Anonieme HTTP-verzoeken naar Google leveren vaak JavaScript-shells zonder server-gerenderde resultaten, of waarschuwingen voor ongebruikelijk verkeer — precies waar browsergebaseerde extractie een voordeel heeft.

SERP-data extraheren zonder zelf een parser te schrijven

Google’s HTML parsen is kwetsbaar werk. De DOM-structuur verandert vaak, class-namen zijn geobfusceerd en wat je in de browser ziet, is niet altijd hetzelfde als wat je in een ruwe HTTP-response terugkrijgt.

Een eenvoudiger aanpak voor niet-ontwikkelaars: open je zorgvuldig samengestelde zoek-URL in Chrome en gebruik daarna een browsergebaseerde extractietool om gestructureerde data van de zichtbare pagina te halen. Bij Thunderbit hebben we onze Chrome-extensie precies gebouwd voor dit soort workflows — je kunt AI Suggest Fields gebruiken om kolommen zoals resultaatstitel, doel-URL, snippettekst en zichtbare positie te herkennen en die vervolgens zonder parser naar een spreadsheet te extraheren.

Dat is niet de enige route. Codegebaseerde aanpakken werken ook, vooral als je op grote schaal of herhaald moet extraheren. Maar voor ad-hoc onderzoek, audits en eenmalige concurrentieanalyse voorkomt browsergebaseerde extractie volledig de kwetsbaarheid van HTML-parsing.

Wanneer je beter een officiële API gebruikt

De responsible-use melding — en die is belangrijk.

Google’s Terms of Service verbieden geautomatiseerde toegang die beschermingsmaatregelen omzeilt, en Google Search Help classificeert search scrapers en software die geautomatiseerde queries verstuurt om rankings te bepalen expliciet als geautomatiseerd verkeer. Een Google-scraper op productieschaal draaien brengt risico op IP-blokkades, CAPTCHA’s en mogelijke juridische problemen met zich mee.

Voor grootschalige, productieve zoekdatabehoeften is een officiële API de betere route. Google’s Custom Search JSON API sluit voor nieuwe klanten — bestaande gebruikers hebben tot 1 januari 2027 om over te stappen, met 100 gratis queries per dag en daarna $5 per 1.000 queries. Google raadt Vertex AI Search aan voor gecontroleerde site search.

Voor sites die je zelf bezit, is de Search Console Search Analytics API de first-party bron voor klikken, vertoningen, CTR en gemiddelde positie — zonder scraping.

Zie kennis over URL-parameters als een diagnose- en onderzoekstool: uitstekend voor precieze zoeklinks, handmatige audits en om te begrijpen wat Google toont. Niet als vervanging voor officiële API’s op schaal.

Google Search-operators: de parameters binnen je query

Zoekoperators zitten in de q=-parameter, maar zijn onmisbare partners van URL-parameters. De tabel hieronder behandelt de operators die Google momenteel documenteert plus een paar die in de praktijk nog steeds werken:

Operator	What It Does	Example
site:	Beperken tot een domein	q=site:example.com+SEO
filetype:	Beperken tot een bestandstype	q=filetype:pdf+annual+report
intitle:	Woord moet in de titel staan	q=intitle:pricing+SaaS
inurl:	Woord moet in de URL staan	q=inurl:blog+marketing
-	Term uitsluiten	q=apple+-fruit
""	Exacte frase	q=%22google+search+url+parameters%22
OR	Een van beide termen	q=scraping+OR+crawling
before:	Resultaten vóór een datum	q=AI+before:2026-01-01
after:	Resultaten na een datum	q=AI+after:2025-06-01
related:	Vergelijkbare sites	q=related:hubspot.com

De echte kracht zit in het combineren van operators binnen q met URL-parameters eromheen:

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

Dit vindt pagina’s op competitor.com met "pricing" in de titel, gepubliceerd na januari 2026, gesorteerd op datum, in de Amerikaanse markt, met klassieke webresultaten. Een heel precieze query voor concurrentie-informatie, volledig opgebouwd met URL-parameters en operators.

Google zegt dat site:-resultaten niet gegarandeerd volledig zijn — beschouw een site:-query dus niet als een uitputtende inventaris van geïndexeerde pagina’s.

Verantwoord gebruik: Google’s Terms of Service en rate limits

Korte maar belangrijke context.

Google’s Terms of Service verbieden misbruik en het omzeilen van beschermingsmaatregelen. Google Search Help noemt search scrapers en geautomatiseerde rankingsoftware expliciet als voorbeelden van geautomatiseerd verkeer. Overtreding kan leiden tot IP-blokkades, CAPTCHA’s, accountbeperkingen en mogelijk juridische stappen.

Kennis over URL-parameters gebruik je het best voor: handmatig precieze zoek-URL’s bouwen, bookmarkbare zoeklinks voor je team maken, kleinschalige audits in een browser uitvoeren en begrijpen hoe Google’s zoekinterface werkt. Voor geautomatiseerd werk op productieschaal gebruik je Google’s officiële API’s — of een gelicentieerde externe provider van zoekdata zoals Brave Search API.

Bij Thunderbit is onze browserextensie gebouwd voor door de gebruiker geïnitieerde extractie van zichtbare pagina’s — niet voor geautomatiseerde Google-queries op grote schaal. Dat is een belangrijk verschil.

Belangrijkste conclusies: jouw Google Search URL-parameters toolkit voor 2026

De verkorte versie:

• Gebruik gl + hl voor lokalisatiesignalen en vertrouw tijdens Google’s redirect-migratie niet alleen op ccTLD’s
• Test waar relevant zowel udm als tbm — geen van beide is een stabiele, versiegebonden consumenten-API
• udm=14 kan klassieke webresultaten zonder AI Overviews opvragen, maar Google kan het strippen of herschrijven
• Gebruik uule voor geo-targeting op stadniveau met de bovenstaande protobuf-coderingsformule
• Beheers tbs voor nauwkeurige datumfilters (cdr:1,cd_min:...,cd_max:...), sorteren op datum (sbd:1) en verbatim zoeken (li:1)
• Let op parameterconflicten: gl vs. uule, tbm vs. udm, lr vs. cr
• num=100 is onbetrouwbaar en was nooit formeel ondersteund — gebruik start in stappen van 10 als veiligere standaard
• Voor gestructureerde SERP-data gebruik je browsergebaseerde tools zoals Thunderbit voor ad-hoc werk, of officiële API’s voor productiegebruik
• Respecteer Google’s Terms of Service — URL-parameters zijn een onderzoekstool, geen scrape-licentie

Google blijft parameters zonder aankondiging wijzigen. Ik houd deze referentie actueel terwijl dingen verschuiven — sla hem op en kom terug.

Meer leren

• 9 Beste SEO API's voor 2026 (met echte cost-per-request data)
• Hoe je zoekmachine-scraping onder de knie krijgt: een complete gids
• Top 27 tools om website-rankings te analyseren en monitoren
• Hoe je web scraper-paginatie gebruikt voor efficiënte extractie
• Wat is search automation? Voordelen, tools en strategieën

FAQs

Wat doet udm=14 in een Google-zoek-URL?

udm=14 kan een klassieke webresultatenweergave zonder AI Overviews opvragen, daarom is het populair bij SEO-professionals. Het is reverse-engineered en geen officieel gedocumenteerde Google-overeenkomst, en Google kan het strippen of herschrijven afhankelijk van sessie, account, regio, client en experimentgroep.

Werkt de num-parameter nog in 2026?

Vertrouw er niet op. Google ondersteunde num=100 sinds september 2025 niet meer betrouwbaar, en een woordvoerder zei dat de parameter nooit formeel werd ondersteund. Gebruik start in stappen van 10 als veiliger standaard voor paginatie, en controleer het aantal teruggegeven resultaten, omdat Google de response nog steeds kan herschrijven of beperken.

Hoe simuleer ik een Google-zoekopdracht vanuit een specifieke stad?

Gebruik de uule-parameter met een gecodeerde stadsnaam. In het coderingsgedeelte hierboven staat het protobuf-gebaseerde algoritme en een Python-voorbeeld. Je hebt de canonieke Google-locatienaam nodig (beschikbaar via Google Ads geographic targeting data), die je codeert naar een uule-waarde zoals uule=w+CAIQICIeNew+York,New+York,United+States.

Wat is het verschil tussen gl, lr en cr?

Deze drie parameters sturen verschillende aspecten van geografische en taal-targeting aan. gl simuleert je zoeklocatie op landniveau (beïnvloedt ranking en lokale resultaten). lr beperkt resultaten tot pagina’s die in een specifieke contenttaal zijn লেখা/geschreven. cr beperkt resultaten tot pagina’s die in een specifiek land worden gehost. Ze kunnen gecombineerd worden, maar tegenstrijdige combinaties (zoals lr=lang_en + cr=countryJP) maken je resultaten drastisch smaller.

Kan ik meerdere tbs-waarden in één URL combineren?

Ja — scheid ze met komma’s binnen één tbs-parameter. Bijvoorbeeld, tbs=qdr:m,sbd:1 filtert op de afgelopen maand en sorteert op datum (nieuwste eerst). Je kunt er ook li:1 aan toevoegen voor verbatim-modus: tbs=qdr:m,sbd:1,li:1. De tbs-syntax is niet gedocumenteerd, dus test je specifieke combinaties om zeker te weten dat ze werken zoals verwacht.