Google Search URL Parameters: The List and How to Use It

Get Google results for the country, language and page you choose, as JSON, in one prompt. Paste this into your agent:

Set up https://monid.ai/SKILL.md, and then use Monid to run the Google search "google search url parameters" for region us and language en on pages 1 and 2, and give me a table with the page, rank, title and URL of every organic result.

One prompt runs the search per page. 1 min setup · 10-20 hrs saved.

You are looking for the Google search URL parameters: which ones change the country, the language, the page or the view, and which ones still do anything. This guide lists the parameters that matter, shows how to get the same effect without building URLs by hand, and covers what we saw when we ran live Google searches on 2026-10-16. It runs through Monid, the OpenRouter for agent tools: one key, one balance, every tool priced per call.

What is the easiest way to get Google search results with the URL parameters you need?

Monid. Install it once, add a key, and your agent runs a Google search with the country, language and page as plain fields, and gets organic results back as typed JSON, with no URL to build and no HTML to parse.

• Pay per call. Each search is billed on its own, at $0.001 a call (Verified 2026-10-16 on the search tools page). Buy calls as you need them: no monthly plan and no minimum top-up. Discovery and inspection are free; only a run bills.
• One install, every API. The same key and the same balance call the search endpoint and every other tool on Monid, such as a page reader for the results you want to open.
• Lives inside your agent. Install the CLI, add your key, run the prompt above, and the tool is there whenever your agent needs it, on demand, with nothing to keep running. Your agent reads SKILL.md and learns the rest, so setup is about a minute.

At that price, ten pages of one query cost $0.01 (Verified 2026-10-16).

📖 See also SERP API for AI agents: the same key also fetches the text of the results you want to open.

Which Google search URL parameters still work?

q, hl, gl, start, udm and tbs work, and num does not. Google stopped honouring num, the parameter that asked for 100 results on one page, in September 2025.

Two pairs look alike and are not. gl and hl describe the searcher: who is asking and in which interface language. cr and lr describe the documents: where a page is hosted and what language it is written in. Setting gl=de gives you what a German searcher sees, English pages included. Setting lr=lang_de gives you German-language pages whoever asks.

Which udm values did Google hand out on 2026-10-16?

udm is the display mode, and the tab links in a live result page carry its values. On our run of 2026-10-16 the tabs were: Images udm=2, Shopping udm=28, Short videos udm=39, AI Mode udm=50, Videos udm=vids and Forums udm=forums. The plain web view that people share as udm=14 is the one that strips the AI features and leaves a list of links. Google does not publish this list, so the values you see in a tab link today are the values to use today.

Which parameters are safe to build on?

q, hl, gl and start are the core. The others are conventions the developer community mapped, and a convention can change without notice, as num did. Through an endpoint, the country, language and page are fields in a schema and the endpoint writes the URL.

How do you set country, language and page without building the URL?

Pass them as fields. The Google results endpoint from mrscraper takes query, region, language and page, and builds the URL itself. We ran it three times on 2026-10-16.

For agents

Grab an API key at app.monid.ai, then paste this to your agent and hand it the key:

set up https://monid.ai/SKILL.md

It learns the whole discover, inspect, run workflow itself. More in the agent quickstart.

For humans

npm install -g @monid-ai/cli
monid keys add -k <your-api-key> -l main

Inspect, then run one

monid inspect -p mrscraper -e /serp/google
monid run -p mrscraper -e /serp/google -i '{"query":"google search url parameters","region":"us","language":"en","page":1}' -w

The endpoint takes the query as a body field, so a POST body goes in with -i.

Loop it over pages

Change page and keep everything else fixed. Three pages of one query:

for p in 1 2 3; do
  monid run -p mrscraper -e /serp/google -i "{\"query\":\"google search url parameters\",\"region\":\"us\",\"language\":\"en\",\"page\":$p}" -w > "page-$p.json"
done

Each page is one billed call, so those three files cost $0.003 (Verified 2026-10-16 at $0.001 a call).

Prefer one call to the older Strale search?

api.strale.io offers /x402/google-search, which takes a query and an optional country:

monid run -p api.strale.io -e /x402/google-search -w \
  --query '{"query": "best web scraping api", "country": "us"}'

It also takes language and num_results (default 10, maximum 20). It is priced at $0.1188 a call (Verified 2026-10-16), so the mrscraper endpoint is the one to loop over many queries and pages.

Can you build the Google search URL and fetch it yourself?

Yes, building the URL takes five lines, and fetching one page is easy. The cost sits in everything after the URL.

from urllib.parse import urlencode

def google_url(q, gl="us", hl="en", start=0):
    return "https://www.google.com/search?" + urlencode(
        {"q": q, "gl": gl, "hl": hl, "start": start})

print(google_url("google search url parameters", start=10))

The input.original_url field that came back on our runs shows the same shape: https://www.google.com/search?q=google%20search%20url%20parameters&gl=de&hl=de for the German run. After the URL you own the fetch (proxies, consent pages, blocks), the parser for a page layout that Google changes without notice, and the repair work each time it does.

Monid is the better route for anything you run more than once: the fetch and the parsing sit behind one call, the country, language and page are fields in a schema, and the response is JSON with a rank on each row. A call is $0.001 (Verified 2026-10-16).

📖 See also Free web search API for agents: when fetching and parsing is the part you want to avoid.

What does a Google results response look like, and what can you build with it?

The response is one JSON object per page with the organic rows, the page metadata and the paging links. These are the fields that came back on 2026-10-16:

{ "general": { "query": "google search url parameters", "results_cnt": 9, "search_time": 4.73,
               "language": "en", "location": "us", "page_title": "google search url parameters - Google Search" },
  "input": { "original_url": "https://www.google.com/search?q=google%20search%20url%20parameters&gl=us&hl=en" },
  "navigation": [ { "name": "Images", "link": "https://www.google.com/search?...&udm=2&..." } ],
  "organic": [ { "link": "https://brightdata.com/blog/web-data/google-search-url-parameters",
                 "source": "Bright Data", "title": "Google Search URL Parameters: 2026 Full List",
                 "description": "Google search parameters are key-value pairs ...", "rank": 1, "global_rank": 1 } ],
  "pagination": { "current_page": 1, "next_page": 2, "next_page_start": 10 },
  "people_also_ask": [ { "question": "What are Google search parameters?", "rank": 1, "global_rank": 10 } ],
  "sponsored": [], "ai_mode": null,
  "results": [ { "url": "...", "title": "...", "description": "...", "relevance": "high" } ] }

Each organic row also has an icon that is a base64 image, so drop it before you store rows. results repeats the organic rows with a relevance of high, medium or low. pagination lists the following pages with their start offsets, and navigation holds the tab links with their udm values. On page one for the US run, people_also_ask held four questions; sponsored was empty and ai_mode was null on all three runs.

What you can build with it

• A rank tracker. One call per keyword and page, stored with the date, region and language. Rank tracking: the hard part is not the fetch covers what to store with each row.
• A localized SERP comparison. Run the same query with different region and language and diff the URLs. It shows what a searcher in another country sees without a VPN.
• A People Also Ask harvest. Collect the questions Google attaches to a query and turn them into a content list.

What goes wrong when you page through Google results?

Four things show up when you read pages instead of one result list. All four are from the 2026-10-16 runs, and the same shape on Bing needs the same checks.

Why does a page have 9 organic results, not 10?

Because the endpoint returns the organic rows Google rendered on that page, and on both US pages that was nine. results_cnt said 9 on the first page, the second page and the German page. A check that expects 10 rows per page will alert on every page. Compare the count against a floor you measured yourself, for example 7, and alert when a page falls below it, since the failure to catch is a page that returns a few rows or none while the call itself succeeds.

Why do rank and global_rank restart on every page?

Because both are positions within the page. On page 2 the organic rows were ranked 1 to 9 again, with global_rank also 1 to 9, and on page 1 global_rank counted the People Also Ask slots too (10, 12, 14, 16). The start for the page is in pagination. Store page, rank and start as separate columns and compute your own running position, because the response will not give you one.

Why does the response not say which page it is?

It does say current_page, but the field read 1 on our page 2 run, and input.original_url was identical on both pages, with no start in it. The page you asked for lives in your request, not in the response. Write the page you sent into the stored row.

Why does the same query return different results in another country?

Because region and language change the result set, not just the interface. The German run (region de, language de) and the US run returned nine organic rows each, and no URL appeared on both page-one lists. A position measured with one pair of values is not comparable to a position measured with another, so store the region and language with every row and never mix them in one series. Each call took 6.5, 6.9 and 9.8 seconds on the wall clock, and the endpoint's median run time is about 9.6 seconds per monid inspect, so run pages in parallel when a list is long. Deep checks multiply the call count: since num stopped working, 100 results is ten calls, or $0.01 per query at $0.001 a call (Verified 2026-10-16). Fifty keywords to a depth of ten pages is 500 calls, or $0.50.

Which endpoint should I use for which job?

Prices Verified 2026-10-16 with monid inspect. The first row is the one we ran, and the one to loop over keywords and pages; current figures are on monid.ai/tools. The second and third were inspected, not run: the Strale call is priced at $0.1188 a call, and the context.dev search bills per result with a minimum request of 10 results, so its bill follows the number of results you request. It accepts Google-style operators such as site: and intitle: in the query, which is the route when you want results for retrieval rather than for ranking.

When is another route a better fit?

You are checking one query once. Open the browser and type the URL. Building a parameter layer for a question you ask twice is over-engineering.

You need your own site's positions. Search Console reports your own queries, clicks and average position from Google itself, free, for properties you verify. An endpoint is for what Search Console cannot show: other sites, other countries, other result pages.

You need a guarantee about a parameter. Most of what is in the table above is convention, and num is the proof that a convention can end without notice. If a changed parameter would be a customer incident, check the shape of every response (row count, rank range, region and language echoed back) rather than trusting that a request succeeded.

And the disclosure: we resell this endpoint. The most useful things in this post are free: store the region, language and page with every row, and alert on a count rather than on an error.

Conclusion

The quickest way to get Google results for a given country, language and page is one search call per page through Monid: $0.001 a call (Verified 2026-10-16), one key for this and every other tool, about a minute to set up and ready inside your agent whenever you need it. Building the URL yourself works for one query, and costs a fetch layer, a parser and the upkeep once you run more.

Two things matter more than the parameter list. Google's own page and your stored rows are only comparable if the region, language and page are the same, so keep them as columns. And a short page does not throw an error: we got 9 organic rows on every page we ran, with rank restarting on each one, so assert on the shape of the response rather than on the success of the call.

How we estimated the time saved: a URL builder, a fetch layer and a parser for the results page take roughly 6 to 12 hours, plus 4 to 8 hours for the first month of repairs as the page layout changes. That is 10 to 20 hours. The 1 minute is the install, key and first call once you already have a Monid key.

Free next step: run monid inspect -p mrscraper -e /serp/google, read the schema and the price, then make one call with your own query and compare the original_url it echoes with the URL you would have built.

FAQ

Published August 2026.