Google Search Parameters: 2026 URL Guide for Scrapers

This is the complete reference to Google search parameters — the flags you append to a search URL to control exactly what Google returns. Google’s search URL is effectively a public API: add the right parameters and you can simulate a user in Tokyo, filter to the past hour, or toggle AI Overviews on and off.

Most people never touch them. They type a keyword, hit Enter, and accept whatever the algorithm decides their IP deserves. For developers, SEOs, and data scrapers, that isn’t good enough — clean, location-specific data requires controlling the URL.

This guide is a working reference for Google search parameters: the anatomy of a search URL, the localization flags (gl, hl, uule), pagination after the num=100 deprecation, the AI and vertical selectors, and the server-side controls that decide what Google returns. Every Google search parameter below is one you can append today, with deprecated flags labeled as such. It’s the Google-specific layer of the broader Python web scraping toolkit.

The anatomy of a Google search URL: format and structure

A standard Google search URL looks like a mess of gibberish, but it follows a standard query string format:

https://www.google.com/search? + parameter=value + & + parameter=value

The most basic example:

https://www.google.com/search?q=coffee

• ? starts the query string.
• q stands for query — your keyword.

Everything else you add refines that query. Those additions — the Google search parameters this reference catalogs — turn a raw keyword into a precise, repeatable request.

The big three for localization

If you’re scraping Google Search results, the biggest challenge is geolocation.

Search for “pizza” from a server in Germany and you get German results. To see what a user in New York sees, you can’t rely on proxies alone. You have to tell Google exactly where you are.

1. gl (geo location)

Sets the country of the search results.

• Usage. &gl=us (United States), &gl=uk (United Kingdom), &gl=jp (Japan).
• Why use it. Forces Google to return results from that country’s index.

2. hl (host language)

Sets the interface language of Google.

• Usage. &hl=en (English), &hl=es (Spanish), &hl=fr (French).
• Why use it. Critical for parsing. If you don’t set it, Google may return the UI in the language of your proxy IP, breaking your CSS selectors.

3. lr (language restriction)

Restricts the actual search results to a specific language.

• Usage. &lr=lang_en
• Difference from hl. hl changes the buttons and menus; lr changes the blue links.

Cheat sheet for localization:

Parameter	Function	Example
q	The search term	q=best+vpn
gl	Country of origin	gl=us
hl	UI Language	hl=en
lr	Result Language	lr=lang_fr

The magic of uule

The gl parameter is fine for countries. But what if you need city-level precision? Say you want to track rankings for “plumber near me” specifically in Austin, Texas.

That’s where uule comes in.

It’s a base64-encoded string that represents a canonical location from Google’s own Geotargeting API. It lets you spoof your GPS coordinates without moving.

How it works:

1. Find the canonical name for your target city (e.g., “Austin, Texas, United States”).
2. Calculate a special length character.
3. Encode the name into base64.

The result looks like this: &uule=w+CAIQICIaQXVzdGluLFRleGFzLFVuaXRlZCBTdGF0ZXM

Append it to your URL and Google believes you’re physically in Austin.

Why this matters for SEO: local rankings vary wildly by zip code. A business ranking #1 in North Austin might be #10 in South Austin. Without uule, your rank tracking data is an average, not reality.

Note: tools like cloro’s SERP API handle uule generation automatically, so you don’t have to do the base64 math yourself.

What gl actually changes: AI search isn’t US-only

Most SEO advice — and most published AI-search statistics — quietly assume a US search. Flip gl (and hl) to another market and the SERP you parse can be structurally different, not just translated. The biggest divergence in 2026 is whether Google renders an AI Overview at all.

Across cloro’s own monitoring panel — the same seed queries run through Google’s AI-Overview surface in 15 countries over 30 days — the AI Overview trigger rate ranges from near-universal to exactly zero:

Country (gl)	AI Overview trigger rate	Avg. citations per answer
US	92.7%	10.2
Austria (AT)	92.9%	13.6
Japan (JP)	91.6%	8.0
Canada (CA)	91.5%	12.9
UAE (AE)	89.0%	7.0
Brazil (BR)	88.3%	9.5
Australia (AU)	88.2%	9.8
UK (GB)	76.1%	10.3
Poland (PL)	68.5%	9.6
Germany (DE)	66.6%	11.2
France (FR)	0.0%	—

cloro monitoring corpus, 30-day window, countries with >200 sampled results. The corpus skews toward commercial and conversational queries, so treat the rates as directional by market rather than a census of all Google traffic.

The full cross-country dataset — all 15 markets and the six-engine citation matrix — is in the AI Overviews Around the World research study.

The France result is not a sampling artifact — AI Overviews are effectively withheld in France (a regulatory posture around Google’s generative features), so &gl=fr returns a classic ten-blue-links SERP where &gl=us returns an AI-summarized one. If you scrape a fixed pipeline against gl=fr and expect an aioverview block, you’ll parse an empty field forever and never know why.

Two practical takeaways for anyone scraping across markets:

• Set gl and hl deliberately, per target market. gl=de&hl=de is a different SERP from gl=de&hl=en — language affects which sources Google cites, not just the UI chrome.
• Don’t hard-code “AI Overview always present.” Trigger rates run from ~93% (US/AT/JP/CA) down through the 60–70s (DE/PL) to 0% (FR). A parser that assumes the block exists will silently drop or crash on the markets where it doesn’t.

Even where AI Overviews do fire, the answer’s shape shifts by market: average citations per AI Overview answer range from ~7 (AE, IL) to ~13 (AT, CA) in the same panel — so “how many sources back the answer” is itself a cross-country variable, not a constant.

Controlling the AI

In 2026, Google is as much an answer engine as a search engine. It now injects AI Overviews (formerly SGE) at the top of many results. Sometimes you want to see them, sometimes you want to kill them.

The parameter for that is udm.

1. Force the “web” view (udm=14)

For the old Google (10 blue links, no AI, no maps, no fluff), use this parameter.

• Usage. &udm=14
• Use case. Extracting pure organic rankings without SERP feature noise.

2. Force “AI mode” (udm=50)

Less documented but useful. Forces Google into a conversational, AI-heavy interface, often triggering the Google AI Mode layout.

• Usage. &udm=50
• Use case. Monitoring Generative Engine Optimization (GEO) and seeing how Google’s Gemini model synthesizes your brand information.

Search verticals (tbm and udm)

Beyond the AI toggles, both udm and the older tbm parameter switch Google between search verticals. The long-standing tbm values still route reliably: &tbm=isch opens Image search and &tbm=nws opens the News tab. Google has been migrating these verticals onto udm numeric codes over the past two years. Treat any vertical udm value other than 14 (Web) and 50 (AI Mode) as empirically observed rather than officially documented, because the mapping has shifted more than once and can change without notice.

Filtering and time parameters

Sometimes you don’t want the best result. You want the newest one.

The tbs (to be searched) parameter is a container for advanced filters.

Time-based search (qdr)

Restrict results to a specific timeframe with tbs=qdr:X.

• Past hour. &tbs=qdr:h
• Past 24 hours. &tbs=qdr:d
• Past week. &tbs=qdr:w
• Past month. &tbs=qdr:m
• Past year. &tbs=qdr:y

If you’re monitoring a PR crisis or a product launch, you don’t care about articles from 2023. You need to see what’s being indexed right now.

Verbatim mode (li:1)

Google likes to “help” you by correcting your spelling or including synonyms. Sometimes you don’t want that.

• Usage. &tbs=li:1
• Effect. Forces verbatim search. Google searches for exactly what you typed, no fuzzy matching.

Custom date ranges (cdr)

For an exact window instead of a rolling one, use tbs=cdr:1 with explicit start and end dates.

• Usage. &tbs=cdr:1,cd_min:1/1/2024,cd_max:12/31/2024
• Format. Dates use M/D/YYYY, and the range is inclusive on both ends.

Sort by date (sbd)

• Usage. &tbs=sbd:1 sorts results by recency instead of by relevance.
• Note. It pairs naturally with qdr, so &tbs=qdr:w,sbd:1 returns the past week, newest first.

Advanced search operators

Parameters live in the URL; operators live in the search box (the q parameter). Operators like site:, filetype:, intitle:, and before:/after: narrow what Google matches, and they stack cleanly with every URL parameter above — e.g. q=site:cloro.dev&gl=us&hl=en.

This page owns the URL parameters. For the full operator list and how to combine them, see the dedicated Google search operators guide.

Pagination after the num=100 deprecation

For years, scrapers appended &num=100 to pull one hundred organic results in a single request. Google removed that shortcut in September 2025, and the change reshaped rank-tracking economics overnight. Values above ten are now ignored on the public web SERP, so a request for a hundred results quietly returns the standard ten.

The replacement is the start parameter, which sets the zero-based offset of the first result on the page.

start (result offset)

• Usage. &start=0 returns results 1–10, &start=10 returns 11–20, and &start=20 returns 21–30.
• Behavior. Each page still caps at ten organic links, so deep pages require sequential requests.
• Practical limit. Google rarely serves meaningful results past start=90, mirroring the old hundred-result ceiling.

Because pagination now costs one request per ten results, a scraping pipeline has to budget roughly ten times the request volume it needed before the deprecation. Set start explicitly rather than trusting a hidden default, and stop paginating once a page returns fewer than ten results.

Server-side result controls

Some Google search parameters never touch the visible query — they change how Google’s backend selects and filters results. These flags are shared between the public search URL and Google’s Custom Search JSON API, whose official parameter reference documents the canonical behavior of safe, filter, cr, and start.

safe (SafeSearch)

• Usage. &safe=active enables SafeSearch filtering, while &safe=off disables it.
• Why use it. Explicit values keep adult-content filtering consistent across proxies, since the default varies by region and account.

filter (duplicate filtering)

• Usage. &filter=0 disables Google’s duplicate and “omitted results” filtering, and &filter=1 is the default.
• Why use it. With filter=0 you see every indexed page, including the near-duplicates Google normally folds away — useful for coverage audits.

cr (country restriction)

• Usage. &cr=countryUS restricts results to pages Google associates with a given country.
• Difference from gl. gl sets the search origin, while cr filters the result set itself, so the two are often combined for tighter geo-targeting.

nfpr (no auto-correction)

• Usage. &nfpr=1 suppresses Google’s automatic spelling correction and the “showing results for” replacement.
• Why use it. When you scrape a deliberately rare or misspelled term, nfpr=1 stops Google from silently answering a different query.

ie and oe (character encoding)

• Usage. &ie=UTF-8&oe=UTF-8 sets the input and output encoding.
• Why use it. Pinning UTF-8 avoids garbled text when you scrape non-Latin scripts through a proxy that guesses a different charset.

Stacking parameters into one request

Google search parameters are order-independent, so ?q=...&gl=us&hl=en behaves the same as ?hl=en&gl=us&q=.... What matters is correct encoding. Spaces in the q value become + or %20, and reserved characters like &, #, and / inside a query must be percent-encoded, or Google reads them as parameter boundaries.

A realistic scraping URL stacks several flags at once:

https://www.google.com/search?q=running+shoes&gl=de&hl=de&udm=14&start=10&safe=off

Read left to right, that requests the classic web view of “running shoes” for a German user, in German, on the second page, with SafeSearch off. Build your URLs this way — one explicit parameter per behavior — and every field in your dataset traces back to a decision you made, not a default Google chose for you.

A complete Google search parameters cheat sheet

Keep this table handy — it collapses every Google search parameter in this guide into one reference. Deprecated flags are marked so you don’t build a pipeline on a dead parameter.

Parameter	Purpose	Example	Status
q	Search query	q=best+vpn	Current
gl	Country of search	gl=us	Current
hl	Interface language	hl=en	Current
lr	Result language	lr=lang_fr	Current
cr	Country restriction	cr=countryDE	Current
uule	Encoded precise location	uule=w+CAIQ...	Current
udm	Vertical / mode selector	udm=14 (Web), udm=50 (AI Mode)	Current
tbm	Legacy vertical selector	tbm=isch, tbm=nws	Current (legacy)
tbs	Time and advanced filters	tbs=qdr:w	Current
start	Pagination offset	start=10	Current
num	Results per page	num=100	Deprecated (Sep 2025)
safe	SafeSearch level	safe=off	Current
filter	Duplicate filtering	filter=0	Current
nfpr	Disable auto-correction	nfpr=1	Current
ie / oe	Character encoding	ie=UTF-8	Current

This is the shortlist that matters for scraping. Google’s URL also carries dozens of session and telemetry parameters, but those change constantly and are safe to drop from an automated request.

Why precision matters for scraping

When you’re searching Google by hand, you can correct mistakes as you go. When you’re building an automated system to monitor ChatGPT mentions or Google rankings, mistakes get expensive fast. Every Google search parameter you leave to chance is a variable in your dataset that you don’t actually control.

The cost of bad parameters:

1. Polluted data. If you don’t set gl=us, your “US rankings” report will be contaminated by the location of your proxy server (which might be in France).
2. Broken parsers. If you don’t set hl=en, Google might serve the page in Arabic because your rotating proxy is in Dubai, and your scraper looking for the English “People Also Ask” text will fail.
3. Missing AI features. Without udm, you might miss the AI Overview box that’s stealing 40% of your traffic.

The fix: don’t rely on defaults. Explicitly define every parameter in your request. Or use a tool that abstracts the complexity.

cloro’s SERP API is built on top of this infrastructure. When you ask cloro to track your brand in London, we handle the uule, gl, hl, and udm parameters automatically, so the data you get matches what a real user in that location would see.

Master the Google search parameters above and your scraped data finally matches what a real user sees. Stop guessing the URL. Start engineering it.