Google Search Params: The Complete 2026 Reference

The most popular advice about Google search params is also the advice most likely to break your pipeline: find a list online, copy every parameter, set num=100, and assume Google will return the same structure tomorrow. That approach treats Google Search as a static interface. It isn't. Parameters change, some are ignored, and others behave differently depending on the search vertical, locale, account state, and request pattern.

A reliable implementation starts with a smaller question: which parameters remain useful in 2026, which are unstable, and which should you stop trusting? This reference focuses on that distinction, with practical URL construction patterns, encoding rules, pagination tactics, localization controls, and safeguards for production SERP tooling.

Table of Contents

• Why Most Google Search Param Guides Are Outdated
  • Treat parameters as an active interface
• Understanding Google Search URL Structure and Encoding
  • Encode values, not the whole URL
• Core Query and Result Control Parameters
  • Reference table
• Vertical Search Parameters for Images News and More
  • Choose the vertical deliberately
  • Where udm fits
• Advanced Search Operators as URL Parameters
  • Operator syntax versus parameter syntax
• Localization and Regional Search Parameters
  • The four controls
• Pagination Patterns and Programmatic Considerations
  • A durable collection loop
• Respectful Scraping Practices and Legal Alternatives
  • If you collect directly
• Practical Code Snippets for Query Construction
  • Python
  • JavaScript
• Quick Reference Cheat Sheet for Google Search Params
  • Stable starting points
  • Keep out of new assumptions
  • Debugging checklist

Why Most Google Search Param Guides Are Outdated

A parameter appearing in a browser URL doesn't mean it remains a dependable automation control. Google can preserve a parameter for compatibility while changing its effect, ignore it in some contexts, or replace it with a newer control. The result is a common failure mode: a scraper still receives HTML, but the requested result count, vertical, or filter no longer matches the intended query.

The clearest recent example is num=100. Recent coverage identifies it as effectively killed in September 2025, while newer guidance points developers toward start, udm, tbs, and localization flags such as gl, hl, lr, and cr for reproducible collection and research. See the SERP scraping API guide for the broader engineering context around handling changing result pages.

Treat parameters as an active interface

Google's own URL structure documentation establishes the underlying query-string format, but it doesn't promise that every historical search parameter will remain a supported product control. That distinction matters. URL syntax can be stable while search behavior changes.

A practical classification looks like this:

• Stable controls: q, start, common localization flags, and documented URL encoding patterns are useful foundations.
• Context-sensitive controls: tbs, filter, tbm, and udm can work well, but their output depends on the search surface and query.
• Deprecated or unreliable controls: historical shortcuts such as num=100 shouldn't anchor a production workflow.

Practical rule: A parameter is production-ready only after you validate its effect on the exact Google surface, locale, vertical, and request path your system uses.

This living-reference mindset is more useful than a static checklist. Keep a small compatibility test suite that records the requested URL, the effective response, detected result count, vertical, locale, and any consent or CAPTCHA page. Run it whenever Google changes its result layout or your collector changes its request strategy.

Understanding Google Search URL Structure and Encoding

A Google Search URL is a base path followed by a query string. Each parameter uses a key-value pair, with the key and value separated by =. Additional parameters are joined with &, which matches Google's documented convention for URL parameters and common web encoding practice.

A minimal URL looks like this:

`

The raw query is google search params. In a form-style query string, spaces are commonly represented with plus signs. Percent-encoding is also valid for characters that have a special meaning in URLs, such as &, ?, #, brackets, and non-ASCII characters.

Encode values, not the whole URL

Build the URL from structured values instead of manually concatenating user input:

1. Start with `
2. Create a parameter map, such as q, start, and hl.
3. Encode each value with a standard URL encoder.
4. Join the encoded pairs with ampersands.
5. Parse the final URL again before sending it.

For example, a query containing an ampersand must protect that character:

`

Without encoding, Google could interpret the ampersand as the beginning of a separate parameter. A literal plus sign has a similar trap. If the query contains C++, encode the plus signs rather than allowing them to become spaces.

Multiple values for the same key can be represented with a delimiter such as a comma. Google's documentation describes comma-delimited values as a way to express multiple values for one parameter. Use that pattern only where the receiving parameter expects it, and don't assume repeated keys and comma-separated values are interchangeable.

For teams working with URL parsing, API endpoints and their meaning provides useful background on separating an endpoint from its query parameters. In practice, the safest approach is to let your language's URL library handle encoding and parsing rather than relying on string replacement.

Core Query and Result Control Parameters

The core parameters answer three operational questions: what should Google search, which result slice should it return, and how should the response be filtered? Some are dependable building blocks. Others need explicit testing before you make them part of a contract.

Reference table

q is the parameter every workflow needs. It can contain ordinary terms, quoted phrases, operators, or an encoded combination of all three:

`

start is the reliable pagination primitive. Treat it as an offset, not as a page number. A first request commonly uses start=0; subsequent requests advance the offset according to the pagination strategy your collector validates.

num deserves caution. Older guides commonly recommend num=100, but recent documentation on Google search URL parameters identifies that behavior as effectively removed in September 2025. Don't build a collector that assumes a large num value will produce a large page. Use successive start requests and validate the actual number of organic results returned.

tbs is a compact control for time filters and other advanced constraints. A URL such as ` can request a recent-results view, but your parser should verify that Google applied the requested filter rather than accepting the URL as proof.

filter=0 can request less aggressive duplicate filtering than the default behavior. That's useful for research, but it may expose similar pages that aren't meaningful independent results. source can identify how a search was initiated, yet it shouldn't be treated as a ranking or localization control. For rank tracking, store the complete request and response context in a system such as a SERP tracker API, rather than relying on one marker parameter.

Vertical Search Parameters for Images News and More

Web search is only one Google result surface. The parameter tbm, meaning “to be matched,” has long been used to select verticals. The value changes the result type while q remains the query.

Choose the vertical deliberately

Examples:

• Web: `
• Images: `
• News: `
• Videos: `
• Shopping: `

tbm is useful when you know which surface you need. It isn't a universal “search type” abstraction, because each vertical can have different markup, cards, filters, and pagination behavior. A parser built for web results should not be pointed at image or shopping HTML and expected to keep working.

Where udm fits

Newer guidance emphasizes udm for view selection in current Google workflows. It can appear alongside q, localization parameters, and pagination controls, but the exact effect should be verified against the response your system receives. Treat udm as an actively relevant view-selection control, not as a replacement for every historical tbm value.

The practical choice is comparative:

• Use tbm when you need a recognizable vertical selector and have a parser for that vertical.
• Test udm when the current result view or Google interface requires it.
• Keep web, image, news, video, and shopping collectors separate, even if they share URL-building code.

That separation prevents a small UI change in one vertical from corrupting every downstream dataset.

Advanced Search Operators as URL Parameters

Google's visible search operators remain useful because they express intent clearly. site:, filetype:, and inurl: can stay inside q, where they work naturally for human review and many automated requests:

`

Google also exposes advanced-search-style parameters that separate matching modes from the main query. This is valuable when a product has distinct fields for exact phrases, included alternatives, exclusions, site restrictions, or file types.

Operator syntax versus parameter syntax

A URL using separate fields might look like:

`

The as_q parameter can hold the main advanced-search query, while as_epq, as_oq, and as_eq express exact, alternative, and excluded terms. as_sitesearch is often easier to generate from a domain input than embedding site: into a free-text field. as_filetype similarly gives a UI or application a clean document-type field.

Operators are usually preferable when analysts need to copy, inspect, and modify a query in the browser. Parameter fields are preferable when your application exposes structured controls and must encode each input independently. Don't mix both representations casually. A site restriction in q and another in as_sitesearch can make debugging harder, especially when Google rewrites or broadens the request.

inurl: doesn't have to become a separate parameter. Keep it in q unless your implementation specifically needs a structured advanced-search field. Always encode the operator punctuation as part of the query value, not as raw URL syntax.

Localization and Regional Search Parameters

A Google result page isn't determined by the query alone. Interface language, geographic context, language restrictions, and country restrictions can each influence the response. For international SEO, record these values with every observation. Otherwise, two apparently identical requests may represent different search environments.

The four controls

• hl sets the interface language. Example: hl=de requests a German-language interface.
• gl sets a geographic country signal. Example: gl=de targets Germany.
• lr limits results by language, using a value such as lang_de.
• cr applies a country restriction, such as countryDE.

A Germany-oriented request could be:

`

For Japan, the analogous pattern uses hl=ja, gl=jp, lr=lang_ja, and a Japan country restriction. Brazil can use hl=pt-BR, gl=br, lr=lang_pt, and a Brazil country restriction. These combinations are starting points, not guarantees that every result will look exactly like a search performed from a physical location in that country.

hl changes the interface language, not necessarily the language of every organic result. gl supplies geographic context, while lr and cr narrow the eligible result set. Over-constraining all four can remove useful results or create a SERP that doesn't represent ordinary users in the target market.

Localization rule: Separate “what language does the interface use?” from “which market should the result set represent?” Store both questions as independent fields.

For higher-fidelity regional collection, request routing and location-aware infrastructure matter alongside URL parameters. The guide to proxies for Google covers that operational layer. Even then, validate the response language, local domains, result titles, and location indicators rather than trusting the query string alone.

Pagination Patterns and Programmatic Considerations

Pagination is where many SERP collectors fail. A request can return a valid HTTP response while Google serves fewer results than requested, changes the layout, inserts a consent page, or presents a CAPTCHA challenge. Your pipeline needs response validation, not just URL generation.

Use start as the pagination cursor. Begin with start=0, then advance by the offset your parser expects. A common pattern is start=10 for the next slice, but the collector must inspect the response because Google may omit results or render a different page structure.

A durable collection loop

1. Normalize the request. Sort or consistently order parameters, encode values, and remove accidental duplicates.
2. Check the cache. Cache identical normalized requests and reuse results when the business task allows it.
3. Send conservatively. Use controlled concurrency, meaningful delays, and backoff after errors or challenge pages.
4. Validate the response. Confirm that the page contains the expected result surface, query context, and pagination state.
5. Stop on degradation. A CAPTCHA, consent screen, empty result container, or unexpected redirect should enter a retry or review path, not become an empty SERP record.

Don't use num=100 as a substitute for pagination. Recent guidance identifies that shortcut as effectively dead after September 2025, so a collector that depends on it will under-collect or mislabel result positions. start gives you a more explicit control model, although it still doesn't eliminate Google-side variability.

Caching reduces repeated requests for the same query and locale. Store both the normalized request and the parsed response, and retain enough metadata to distinguish a real zero-result response from a blocked or degraded page. Rate limiting is a risk-control mechanism, not merely a performance setting. If your collector receives challenge pages, slow it down, respect the failure signal, and avoid immediately replaying the same request across every worker.

Respectful Scraping Practices and Legal Alternatives

Direct HTML collection gives you flexibility, but it also makes you responsible for request behavior, parsing failures, policy review, and data handling. Google's URL parameter guidance is useful for understanding parameter conventions, but it shouldn't be read as permission to send unlimited automated traffic.

For product teams, the first decision is access method:

• Official APIs: Use Google's supported search interfaces when their result scope and feature limits fit the product.
• SERP API providers: Outsource browser variation, proxy rotation, parsing, and challenge handling when those concerns aren't core to your business.
• Direct collection: Reserve it for controlled, policy-reviewed workflows where you can manage pacing, caching, and failure handling responsibly.

The Custom Search JSON API can be appropriate when its coverage and response model match your use case. It won't reproduce every interactive Google SERP feature, and its quotas, availability, and commercial terms should be checked directly before committing your architecture. A third-party SERP API may provide broader result controls, but you still need to evaluate its data rights, retention policy, geographic coverage, and reliability.

If you collect directly

Use a transparent user agent, honor applicable access rules, and don't try to bypass CAPTCHA challenges. Keep request rates conservative, use exponential backoff, and stop a worker when Google starts returning challenge or consent pages. Never treat a challenge response as an empty result set.

Legal analysis depends on jurisdiction, contract terms, the type of data collected, and how you use it. The guide to whether website scraping is legal is a useful starting point, but it isn't a substitute for counsel reviewing your specific workflow.

The engineering standard is simple: collect only what you need, minimize repeated requests, protect stored data, and provide a clear failure path. A smaller, well-governed dataset is more valuable than a large archive produced by an unstable or non-compliant collector.

Practical Code Snippets for Query Construction

URL construction should be boring. Let standard libraries handle encoding so a query containing spaces, ampersands, plus signs, or non-ASCII text doesn't corrupt the parameter boundary.

Python

from urllib.parse import urlencode, urlsplit, parse_qs

BASE_URL = "https://www.google.com/search"

def build_google_url(query, *, start=0, language=None, country=None,
                     vertical=None, extra=None):
    if not isinstance(query, str) or not query.strip():
        raise ValueError("query must be a non-empty string")
    if not isinstance(start, int) or start < 0:
        raise ValueError("start must be a non-negative integer")

    params = {"q": query, "start": start}

    if language:
        params["hl"] = language
    if country:
        params["gl"] = country
    if vertical:
        params["tbm"] = vertical
    if extra:
        params.update(extra)

    return f"{BASE_URL}?{urlencode(params)}"

def read_google_params(url):
    parts = urlsplit(url)
    if parts.path != "/search":
        raise ValueError("URL is not a Google search URL")
    return {key: values for key, values in parse_qs(parts.query).items()}

urlencode turns the parameter map into a properly escaped query string. The parser returns lists because a URL can contain repeated keys. That behavior is safer than assuming every parameter appears only once.

JavaScript

const GOOGLE_SEARCH_URL = "https://www.google.com/search";

function buildGoogleUrl(query, options = {}) {
  if (typeof query !== "string" || query.trim() === "") {
    throw new TypeError("query must be a non-empty string");
  }

  const start = options.start ?? 0;
  if (!Number.isInteger(start) || start < 0) {
    throw new TypeError("start must be a non-negative integer");
  }

  const params = new URLSearchParams();
  params.set("q", query);
  params.set("start", String(start));

  if (options.language) params.set("hl", options.language);
  if (options.country) params.set("gl", options.country);
  if (options.vertical) params.set("tbm", options.vertical);

  for (const [key, value] of Object.entries(options.extra ?? {})) {
    if (value !== undefined && value !== null) {
      params.set(key, String(value));
    }
  }

  return `${GOOGLE_SEARCH_URL}?${params.toString()}`;
}

function readGoogleParams(input) {
  const url = new URL(input);
  if (url.pathname !== "/search") {
    throw new Error("URL is not a Google search URL");
  }
  return Object.fromEntries(url.searchParams.entries());
}

URLSearchParams handles escaping and makes the final URL inspectable. In a larger collector, put retries and response validation around the HTTP client, not inside the URL builder. Keeping those responsibilities separate makes it easier to test whether a failure came from encoding, Google response behavior, or your parser.

Quick Reference Cheat Sheet for Google Search Params

A useful cheat sheet separates reliable inputs from historical shortcuts. The goal isn't to memorize every string Google has ever accepted. It's to know which controls deserve a test, which require a vertical-specific parser, and which should stay out of a new system.

Stable starting points

Keep out of new assumptions

• num=100: Recent guidance identifies this shortcut as effectively killed in September 2025. Use validated pagination instead.
• Unverified historical flags: A parameter copied from an old forum post may still appear in a URL while doing nothing useful.
• Undocumented layout assumptions: CSS selectors and result-card structures change independently of query syntax.

Debugging checklist

• Is the request using /search with a properly encoded query string?
• Did your encoder protect &, +, #, brackets, and non-ASCII characters?
• Did the response apply tbm, udm, tbs, or localization settings?
• Does the parser identify a real results page rather than consent or CAPTCHA content?
• Are you paginating with start instead of assuming num controls a large result set?
• Are you storing the exact request context with the parsed result?
• Did a locale, vertical, or filter change the DOM your parser expects?

For teams measuring rankings across markets, a most accurate SEO position tool can complement raw SERP collection by giving marketers a practical interface for checking positions. The underlying principle is the same: preserve query, location, language, vertical, and timestamp context so a position can be interpreted rather than merely recorded.

Google search params work best as a controlled interface, not a bag of undocumented switches. Build around q, validated pagination, explicit localization, vertical-aware parsing, and response checks, then rerun compatibility tests as Google changes the result experience.

Captapi provides a Google Search API that returns matching Google results through a REST call, with controls such as q, country, language, and result limit for application workflows. If you're building SERP research or data pipelines and want to avoid maintaining every scraping layer yourself, visit Captapi to review the API and start integrating.