Google Search URL Parameters: What Still Works in 2026

Sometime around September 2025, a bunch of SEO tools and custom scripts quietly broke. The culprit? Google stopped reliably honoring the num=100 parameter that power users had relied on for years to pull 100 results per page. There was no formal deprecation notice — just a spokesperson telling Search Engine Land that the parameter was "not formally supported." Around the same period, Google introduced more udm modes alongside older tbm verticals, announced that country-code domains would gradually redirect to google.com, and reported AI Overviews reaching over 2.5 billion monthly users.

If you've been building search URLs, tracking rankings, or automating research using Google's URL parameters, there's a decent chance some of your workflows are silently degraded right now. At Thunderbit, we reviewed current Google documentation, recent change announcements, reverse-engineered references, and live spot checks to separate stable controls from contextual ones. The result is a dated, test-before-deploy reference for the Google search URL parameters that matter in 2026, including tbm/udm mappings, the uule encoding formula for city-level geo-targeting, and parameter conflicts that can save hours of debugging.

What Are Google Search URL Parameters?

Google search URL parameters are the key=value pairs that appear after the ? in a Google search URL. They control everything from what you're searching for, to which country's results you see, to whether you get images, news, or classic blue links.

A typical Google search URL breaks down like this:

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

• Base URL: https://www.google.com/search
• ? begins the query string
• q=best+crm+software is the search query (spaces encoded as +)
• & separates each parameter
• hl=en sets the interface language to English
• gl=us tells Google to show results as if you're in the US
• tbs=qdr:m filters to results from the past month

A distinction worth making: search operators like site:, filetype:, and intitle: go inside the q= value. They're part of your query. URL parameters like gl, hl, and tbs are separate keys in the URL that control how Google processes and displays results. Both matter, and they work together — but they're different animals.

Google has never published a single, versioned specification for these parameters. Some come from the Advanced Search form, some from the Custom Search API, and some are reverse-engineered from observing Google's own URLs. That means the article you're reading is based on live testing and documented behavior, not an official API contract.

Why Google Search URL Parameters Matter in 2026

URL parameters aren't just a developer concern. Anyone in SEO, marketing, sales, operations, or product who needs to understand what Google shows for a specific query, in a specific market, at a specific time — these parameters are your toolkit.

A quick breakdown of who benefits and how:

Use Case	Who Benefits	Key Parameters
SEO rank tracking across countries	SEO & Marketing teams	gl, hl, uule, pws
Competitor monitoring by date	Strategy & Ops teams	tbs, q with site:
Ad monitoring in specific markets	Paid media teams	gl, hl, udm
Local SEO audits (city-level)	Local business owners	uule, gl
Content research / trend tracking	Content teams	tbs (date filters), lr
Feeding search data into AI/LLM apps	Product & Data teams	Multiple params + structured extraction

Three big shifts make 2026 materially different:

1. num=100 is no longer dependable. The old results-per-page trick stopped working reliably in September 2025. Google did not formally deprecate it; a spokesperson said it had never been formally supported.
2. ccTLD redirects are a migration, not a completed switch. Google announced in April 2025 that country-code domains (google.co.uk, google.de, etc.) would gradually redirect to google.com. Google has not published a completion notice, so do not assume every locale behaves identically yet.
3. AI Overviews changed the SERP. Google reports AI Overviews reaching over 2.5 billion monthly users and 200+ countries and territories. Reverse-engineered udm modes can change the result surface in some contexts, but they are not a guaranteed AI Overview switch.

If your workflows haven't been updated for these changes, you're probably getting degraded or misleading results without realizing it.

Google Search URL Parameters Cheat Sheet (2026)

Before the deep dive, the quick-reference table below is the most up-to-date list I've been able to put together. Bookmark it.

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

Strip ei, ved, sxsrf, and sclient from any URLs you save or share. They're session and telemetry state that Google attaches automatically — irrelevant for constructing search URLs.

Core Google Search URL Parameters That Still Work

I've tested each of these live as of mid-2026. They're the ones you'll reach for most often.

q — Your Search Query

The q parameter carries your search terms. Spaces are encoded as + or %20. This is where Google's documented search operators live — they go inside the q value, not as separate URL parameters.

A few examples:

• Exact phrase: q=%22google+search+url+parameters%22
• Site-restricted: q=site%3Aexample.com+pricing
• File type: q=filetype%3Apdf+annual+report+2026
• Combined: q=site%3Acompetitor.com+intitle%3Apricing+after%3A2026%2F01%2F01

Always URL-encode the entire query value. Quotes, colons, and slashes all need proper encoding to avoid corrupting the URL.

hl — Interface Language

hl controls the language of Google's interface (buttons, labels, "People also ask" headings) and influences which results Google prioritizes. It uses ISO 639-1 codes like en, fr, de, ja, or BCP 47 tags like en-gb or pt-br.

hl does not force all result documents into that language. It's a strong signal, but Google may still show results in other languages if they're highly relevant. For content-language restriction, use lr instead.

gl — Country / Geolocation

gl simulates the country you're searching from, using ISO 3166-1 alpha-2 codes (us, gb, jp, de). With ccTLDs gradually redirecting to google.com, gl is now the primary way to get country-specific results.

The same query with different gl values can return completely different results, featured snippets, and local packs. For example, q=best+bank&gl=us and q=best+bank&gl=jp will show you very different banks.

Pro tip: always pair gl with hl for accurate localized results. Using gl=jp with hl=en gives you Japan-market results in an English interface — useful for international SEO audits.

lr and cr — Language Restrict and Country Restrict

These two get mixed up constantly. The distinction matters:

• lr=lang_en restricts results to pages written in English (content language)
• cr=countryUS restricts results to pages hosted in the United States (server location / country association)
• gl=us simulates searching from the United States (affects ranking, local results, ads)

Both lr and cr are available through Google's Advanced Search form. Be careful combining them — lr=lang_en + cr=countryJP means "only English-language pages hosted in Japan," which is a very narrow set. More on this in the conflicts section.

start — Pagination

start=10 asks for results starting from position 11 (page 2), start=20 for page 3, and so on. Because num=100 is no longer dependable, incrementing start by 10 is the safer default—but Google may still rewrite or constrain pagination.

The old num=100&start=0 trick for pulling a full page of 100 results no longer works. If your scripts still include num, remove it — it's being silently ignored.

pws — Disable Personalization

pws=0 requests that Google turn off account-based personalization. This is essential for SEO rank tracking, where you want results that aren't skewed by your own search history, clicked results, or account preferences.

A word of caution: pws=0 reduces personalization but doesn't eliminate all contextual factors. Google says results can still vary by time, location, language, and device. There's no such thing as a truly "neutral" Google SERP.

safe and filter — SafeSearch and Duplicate Filtering

• safe=active turns on SafeSearch; safe=off turns it off. Note that account settings, admin policies, network configurations, or regional laws may override this parameter.
• filter=0 disables Google's duplicate-result filtering. Useful when you want to see every result Google has, including near-duplicates it would normally collapse.

nfpr — Disable Auto-Correction

nfpr=1 prevents Google from forcibly rewriting your query when it thinks you've misspelled something. This is useful for tracking branded terms with unusual spelling, technical jargon, or intentionally misspelled queries that competitors target.

Note that nfpr=1 only suppresses the forced rewrite. For broader control — disabling synonym expansion, spelling changes, and other automatic modifications — use tbs=li:1 (verbatim mode), which I cover in the tbs section below.

The tbm to udm Migration: What Changed and What to Use Now

This is one of the biggest parameter changes in recent years—and one of the easiest to overstate.

tbm has been a common way to switch between Google's search verticals — images, news, video, shopping — for over a decade. Google has also introduced a numeric udm system with overlapping and additional modes. Because Google has not published a stable consumer registry, treat this as a contextual mapping rather than a clean, completed replacement.

The Complete tbm-to-udm Mapping Table

The mappings below combine observed UI behavior and live spot checks dated August 12, 2026. Several values were stripped or rewritten in anonymous requests, so every row should be tested in the account, region, and client where it will be used:

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 has not published a stable udm registry — that's a critical caveat. These values are reverse-engineered from observing Google's own UI behavior. URL acceptance varies by account, region, client, cookies, and experiment cohort. In my testing, some udm values were stripped in anonymous HTTP requests but worked fine in interactive browser sessions. Don't assume every value works universally.

What udm=14 Does (and Why SEOs Love It)

udm=14 has become something of a cult favorite in the SEO community. Android Central described it as a way to request a classic web-results surface without AI Overviews. In many sessions it produces a traditional blue-link SERP, but it is not an official or universal guarantee.

Why does this matter? If you're doing rank tracking or SEO audits, AI Overviews can push organic results below the fold and make it harder to assess ranking positions. udm=14 can give you a cleaner view when Google honors it.

That said, udm=14 is not guaranteed to work in every context. In live August 12, 2026 spot checks, Google sometimes stripped or rewrote udm values depending on the request context. Your mileage will vary by session, account, region, client, and experiment cohort.

udm=50 has been observed in AI Mode/AI-result contexts, but it should not be described as a guaranteed way to force an AI Overview for an arbitrary query.

What to Do: Update Your Workflows from tbm to udm

My recommendation:

• New implementations: Treat udm as an experimental/contextual input and build fallbacks.
• Existing workflows: Support and test both tbm and udm where relevant rather than assuming a completed migration.
• Never combine both: When tbm and udm are both present in a URL, behavior is unpredictable. In my tests, Google sometimes stripped both and returned a plain query. More on this in the conflicts section.

The Full tbs Syntax: Custom Date Ranges, Sort-by-Date, and Verbatim

tbs is one of the most powerful parameters in the Google search URL toolkit, and most guides barely scratch the surface. It handles time filtering, date sorting, verbatim mode, and more — all packed into a single comma-separated value.

Standard Time Filters

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

These are the basics that most guides cover. But tbs can do much more.

Custom Date Ranges

Need results from a specific time window? Use the cdr:1,cd_min:MM/DD/YYYY,cd_max:MM/DD/YYYY syntax:

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

This filters results to those Google associates with dates between January 1 and June 1, 2026. It's invaluable for competitive research — for example, "what did competitors publish about pricing in Q1 2026?" Just remember to URL-encode the full value, since colons and slashes need encoding.

A practical note: Google's date association isn't always accurate. The date shown in search results is Google's best guess, not necessarily the actual publication date. Always verify dates on the destination page.

Sort by Date and Verbatim Mode

This is where the guide covers ground that no competing article does.

sbd:1 sorts results by date (newest first). On its own, that's useful but not remarkable. The trick is that you can combine it with time-range filters in a single tbs value:

&tbs=qdr:m,sbd:1

This gives you results from the past month, sorted by date — newest first. It's the fastest way to find what's just been published on a topic. I use this combination constantly when monitoring competitor content.

li:1 enables verbatim mode — the URL equivalent of clicking Google's "Verbatim" tool in the search interface. Verbatim mode disables auto-correction, synonym expansion, spelling changes, and other automatic query modifications.

The difference between li:1 and nfpr=1 comes down to scope:

• nfpr=1: Only suppresses forced spelling/query rewriting (e.g., stops Google from changing "teh" to "the")
• tbs=li:1: Disables all automatic modifications — spelling, synonyms, related terms, personalization adjustments

You can even stack multiple tbs values. For example, tbs=qdr:m,sbd:1,li:1 gives you past-month results, sorted by date, with verbatim matching. In my testing, this combination works, though I'd recommend verifying with your specific queries since tbs is undocumented syntax.

How to Build a uule Code for City-Level Geo-Targeting

If gl is a country-level zoom lens, uule is a city-level microscope. For local SEO — checking how your business ranks in Denver vs. Dallas, or what a searcher in Tokyo's Shibuya district sees — gl alone isn't precise enough.

No top-ranking article actually explains how to construct a uule code — they mention the parameter exists and move on. The full breakdown follows.

When to Use 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

The uule Encoding Algorithm (Step-by-Step)

The uule parameter uses an encoded named-location signal. The construction is reverse-engineered, not officially documented by Google, but it's been widely validated by the SEO community.

The safer approach is to encode a small Protocol Buffers payload rather than rely on the commonly-copied shortcut (which can fail with non-ASCII characters). Here's the process:

1. Get the canonical Google location name. Google publishes geographic targets with canonical names through the Google Ads API geographic targeting data. Example: New York,New York,United States
2. Encode the name as UTF-8 bytes.
3. Build a small protobuf payload with the name and its byte length.
4. Base64url-encode the payload and prepend w+.

Here's a Python snippet that does this:

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

When you put this in a URL, make sure the literal + in w+ is properly encoded as %2B by your URL library. Most URLSearchParams or urllib.parse.urlencode implementations handle this automatically.

A correctly constructed uule is still just one location signal. It doesn't override IP address, account settings, device, or experiment cohort. Use it for directional local SEO checks, not as a guarantee of exact city-level rankings.

When Google Search URL Parameters Silently Conflict

Parameter combinations can fail silently: Google may ignore one input, rewrite the URL, or return a different surface. The conflict checks below are worth adding to every search-link workflow.

Zero competing articles cover parameter interactions. But if you're building search URLs with multiple parameters — and you probably are — you need to know which combinations play nicely and which ones fight.

gl + uule: Which One Wins?

When both are present, uule provides a more specific location signal than gl. If you set gl=uk and a uule pointing to Tokyo, you'll get Tokyo-influenced results, not UK results.

Recommendation: If you're using uule, either omit gl entirely or set gl to the country that contains your uule city. Don't send contradictory signals.

tbm + udm: Don't Use Both

In my testing, when both tbm and udm are present in the same URL, Google sometimes strips both and returns a plain web query. The behavior is inconsistent across sessions and accounts.

Recommendation: Use only udm for new implementations. If you must support legacy workflows, use one or the other — never both.

lr + cr: Double Filtering Can Return Zero Results

This is a subtle trap. lr=lang_en restricts to English-language content. cr=countryJP restricts to pages hosted in Japan. Combine them and you're asking for "English-language pages hosted in Japan" — which is a very small subset of the web.

Recommendation: Use one or the other unless you specifically need the intersection. If you do combine them, expect dramatically fewer results.

num + start: Broken Pagination

Old scripts using num=100&start=0 now silently return only ~10 results. The num parameter is no longer honored, but it doesn't throw an error — it just gets ignored.

Recommendation: Remove num from all URLs. Paginate using start in increments of 10 and deduplicate results across pages.

Quick Conflict Reference

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

From Google Search URL Parameters to Structured Data Extraction

At this point you have a precise Google search URL — right query, right country, right date range, classic web results. The next step is getting structured data out of the results.

Whether you're building a rank tracker, monitoring competitors, or feeding search data into a research workflow, seeing the right results is only half the job. You need titles, URLs, snippets, positions, and dates in a spreadsheet or database.

Building a Targeted Google Search URL (Putting It All Together)

A complete example combining multiple 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

Breaking it down:

• q=site%3Acompetitor.com+intitle%3Apricing — pages on competitor.com with "pricing" in the title
• hl=en — English interface
• gl=us — US market context
• tbs=qdr:m,sbd:1 — past month, sorted by date
• udm=14 — classic web results (no AI Overviews)
• pws=0 — personalization off

You can construct this programmatically with 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'

Or with 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)

Anonymous HTTP requests to Google often return JavaScript shells with no server-rendered results, or unusual-traffic warnings — which is exactly where browser-based extraction has an edge.

Extracting SERP Data Without Writing a Parser

Parsing Google's HTML is fragile work. The DOM structure changes frequently, class names are obfuscated, and what you see in the browser isn't always what you get in a raw HTTP response.

A simpler approach for non-developers: open your carefully constructed search URL in Chrome, then use a browser-based extraction tool to pull structured data from the visible page. At Thunderbit, we built our Chrome extension to handle exactly this kind of workflow — you can use AI Suggest Fields to identify columns like result title, destination URL, snippet text, and visible position, then extract them into a spreadsheet without writing a parser.

This isn't the only path. Code-based approaches work too, especially if you need to handle large-scale or repeated extraction. But for ad-hoc research, audits, and one-off competitive analysis, browser-based extraction avoids the fragility of HTML parsing entirely.

When to Use an Official API Instead

The responsible-use callout — and it matters.

Google's Terms of Service prohibit automated access that bypasses protective measures, and Google Search Help explicitly classifies search scrapers and software that sends automated queries to determine rank as automated traffic. Running a production-scale Google scraper puts you at risk of IP blocks, CAPTCHAs, and potential legal issues.

For production-scale, high-volume search data needs, the better path is an official API. Google's Custom Search JSON API is closing to new customers — existing users have until January 1, 2027 to transition, with 100 free daily queries and $5 per 1,000 queries after that. Google recommends Vertex AI Search for controlled-site search going forward.

For sites you own, Search Console's Search Analytics API is the first-party source for clicks, impressions, CTR, and average position — no scraping required.

Think of URL-parameter knowledge as a diagnostic and research tool: great for building precise search links, running manual audits, and understanding what Google shows. Not a replacement for official APIs at scale.

Google Search Operators: The Parameters Inside Your Query

Search operators live inside the q= parameter, but they're essential companions to URL parameters. The table below covers the ones Google currently documents plus a few that still work in practice:

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

The real power comes from combining operators inside q with URL parameters outside it:

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

This finds pages on competitor.com with "pricing" in the title, published after January 2026, sorted by date, in the US market, with classic web results. That's a very precise competitive intelligence query built entirely from URL parameters and operators.

Google says site: results are not guaranteed to be complete — don't treat a site: query as an exhaustive inventory of indexed pages.

Responsible Use: Google's Terms of Service and Rate Limits

Brief but important context.

Google's Terms of Service prohibit abusive access and bypassing protective measures. Google Search Help specifically calls out search scrapers and automated ranking software as examples of automated traffic. Violating these terms can result in IP blocks, CAPTCHAs, account restrictions, and potentially legal action.

URL parameter knowledge is best used for: manually constructing precise search URLs, building bookmarkable search links for your team, running small-scale audits in a browser, and understanding how Google's search interface works. For production-scale automated work, use Google's official APIs — or a licensed third-party search data provider like Brave Search API.

At Thunderbit, our browser extension is built for user-initiated, visible-page extraction — not high-volume automated Google querying. That's an important distinction.

Key Takeaways: Your 2026 Google Search URL Parameters Toolkit

The condensed version:

• Use gl + hl for localization signals and do not rely only on ccTLDs during Google's redirect migration
• Test both udm and tbm where relevant — neither is a stable, versioned consumer API
• udm=14 may request classic web results without AI Overviews, but Google can strip or rewrite it
• Use uule for city-level geo-targeting with the protobuf encoding formula above
• Master tbs for precise date filtering (cdr:1,cd_min:...,cd_max:...), date sorting (sbd:1), and verbatim search (li:1)
• Watch out for parameter conflicts: gl vs. uule, tbm vs. udm, lr vs. cr
• num=100 is unreliable and was never formally supported — use start in increments of 10 as a safer default
• For structured SERP data, use browser-based tools like Thunderbit for ad-hoc work, or official APIs for production scale
• Respect Google's Terms of Service — URL parameters are a research tool, not a scraping license

Google continues to change parameters without announcement. I'll keep the reference current as things shift — bookmark it and check back.

Learn More

• 9 Best SEO APIs for 2026 (With Real Cost-per-Request Data)
• How to Master Search Engine Scraping: A Complete Guide
• Top 27 Tools to Analyze and Monitor Website Rankings
• How to Use Web Scraper Pagination for Efficient Extraction
• What Is Search Automation? Benefits, Tools, and Strategies

FAQs

What does udm=14 do in a Google search URL?

udm=14 can request a classic web-results surface without AI Overviews, which is why it is popular among SEO practitioners. It is reverse-engineered, not an officially documented Google contract, and Google may strip or rewrite it depending on session, account, region, client, and experiment cohort.

Is the num parameter still working in 2026?

Do not rely on it. Google stopped reliably honoring num=100 in September 2025, and a spokesperson said the parameter was never formally supported. Use start in increments of 10 as a safer pagination default, and verify the returned result count because Google can still rewrite or constrain the response.

How do I simulate a Google search from a specific city?

Use the uule parameter with an encoded city name. The encoding section above provides the protobuf-based algorithm and a Python code example. You'll need the canonical Google location name (available from Google Ads geographic targeting data), which you encode into a uule value like uule=w+CAIQICIeNew+York,New+York,United+States.

What's the difference between gl, lr, and cr?

These three parameters control different aspects of geographic and language targeting. gl simulates your search location at the country level (affects ranking and local results). lr restricts results to pages written in a specific content language. cr restricts results to pages hosted in a specific country. They can be combined, but contradictory combinations (like lr=lang_en + cr=countryJP) will dramatically narrow your results.

Can I combine multiple tbs values in one URL?

Yes — separate them with commas within a single tbs parameter. For example, tbs=qdr:m,sbd:1 filters to the past month and sorts by date (newest first). You can also add li:1 for verbatim mode: tbs=qdr:m,sbd:1,li:1. The tbs syntax is undocumented, so test your specific combinations to confirm they work as expected.