User Agent

What a user agent is — the HTTP header crawlers and browsers use to identify themselves, the robots.txt token vs. the full string, and how to verify a bot is real.

First published: Jun 24, 2026 · Last updated: Jul 18, 2026 · Advanced
demand #2 in Crawling#5 in How Search Works#42 in Technical SEO#58 on the site
2 evidence signals on this page

A user agent is the HTTP header every client — browser, crawler, or bot — sends to identify itself. Two things get confused: the full user-agent *string* in the request header, and the short user-agent *token* (Googlebot, bingbot, Google-Extended) you target in robots.txt. The token is a substring of the string (RFC 9309); some tokens, like Google-Extended, have no request string at all. The string is trivially spoofed — Google says its own is 'often spoofed' — so never trust it for access control. Verify Googlebot/Bingbot by reverse DNS plus a forward lookup, or against published IP ranges. And watch the gotchas: AdsBot and Google-Safety ignore `User-agent: *`, version numbers and wildcards in the token line are ignored, matching is case-insensitive, and serving different content to a bot UA than to users is cloaking.

TL;DR — A user agentA user agent is the HTTP request header a client (browser, crawler, or bot) sends to identify itself. For crawlers, a short user-agent token — a substring of that string — is what robots.txt rules actually target. is the HTTP request header any client sends to identify itself; it’s optional, client-filled metadata, not authenticated identity. Its value is the user-agent string. Separate from that is the user-agent tokenA token is the smallest unit of text (or image/audio/video) an LLM processes — roughly 4 characters, or about ¾ of an English word. A context window is the maximum number of tokens (input plus output) a model can hold at once, like its short-term memory. (product token) used in robots.txt — RFC 9309 says it SHOULD be a substring of the string, a strong convention with documented exceptions (Google-Extended has no request string at all). Matching is case-insensitive, version numbers/wildcards in the token line are ignored, the most-specific group wins, and same-token groups merge but never merge with *. The string is trivially spoofed — Google calls its own “often spoofed” — so verify by reverse + forward DNS (behind any proxy/CDN, use the real client IP) against googlebot.com/google.com/googleusercontent.com for Google or search.msn.com for Bing, or match published IP ranges — and even a verified request only proves a request arrived, not that the page was indexedStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed., retrieved, or used for AI training. AdsBot and Google-Safety ignore User-agent: *. Chrome is also freezing detail out of browser UA strings (User-Agent reduction); Client Hints are the structured but opt-in replacement, and neither substitutes for crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. verification. User-agent adaptation can be legitimate, but deceptively showing crawlersA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. materially different content can be cloaking.

Evidence for this claim HTTP User-Agent is a request field containing product information supplied by the client; it is descriptive text and not proof of identity. Scope: HTTP semantics for User-Agent. Confidence: high · Verified: IETF RFC 9110: User-Agent Evidence for this claim robots.txt User-agent matching is defined by the Robots Exclusion Protocol and controls crawler access, not authentication or general HTTP content negotiation. Scope: RFC 9309 robots matching behavior. Confidence: high · Verified: IETF RFC 9309: Robots Exclusion Protocol

The header, the string, and the token

Three things, and keeping them straight is most of this topic.

  • The header. User-Agent is an HTTP request header. Every client sends it: your browser, curl, a crawler, a bot. Per RFC 9110 (the core HTTP semantics standard), it’s an optional field the client fills in — client-supplied descriptive metadata, not an authenticated identity the server has verified.
  • The string. The header’s value — a freeform line describing the software, version, renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. engine, and sometimes the OS.
  • The token. The short identifier used in robots.txt User-agent: lines to target a crawler — Googlebot, bingbot, Google-Extended.

The relationship is the part that trips people up. RFC 9309 (the formal Robots Exclusion Protocol standard) says the token “SHOULD be a substring of the identification string that the crawler sends… in the case of HTTP, the product token SHOULD be a substring in the User-Agent header.” That’s a SHOULD, not a MUST — a strong convention the standard recommends, not a hard requirement every crawler is mechanically bound to. Google-Extended (below) is the clearest example of a documented exception to it. Don’t read the substring rule as universal just because Google follows it for most of its own tokens. The token is part of the string when a provider does supply one; you target the token in robots.txt and read the string in your logs.

Google’s own framing of how its bots identify themselves is useful here: “Google’s crawlers identify themselves through three things: the HTTP user-agent request header, the source IP address of the request, and the reverse DNS hostname of the source IP.” Note that the user-agent is only one of the three — the other two are how you actually verify it.

Google-Extended: a token with no string

The cleanest illustration of token ≠ string is Google-Extended. It controls whether Google can use your content for Gemini training and groundingGrounding is anchoring an AI model's answer to source documents it retrieves at the moment you ask — not to the patterns frozen into its weights during training. Retrieval-Augmented Generation (RAG) is the most common way to do it. — and it has no dedicated HTTP request user-agent string at all. The crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. itself is done with existing GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. strings; Google-Extended exists only as a robots.txtA plain-text file at the root of a host that tells crawlers which URLs they may and may not request. It controls crawling, not indexing — a blocked URL can still be indexed if it's linked from elsewhere. control token. You’ll never see “Google-Extended” in a request header in your logs.

The practical consequence: blocking Google-Extended affects only AI-training use of your content — it does not stop GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. from crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. and indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. you for Search. They’re separate decisions controlled by separate tokens. (For the broader picture of the bots reading your site, see AI crawlersAI crawlers are bots from AI companies that fetch web pages to train language models, build AI-search indexes, or answer live user questions. They come in three categories, each with its own user-agent tokens and its own robots.txt controls. and crawler.)

Googlebot’s user-agent strings

Googlebot is “evergreen” — it runs on a recent version of Chrome, and the Chrome version in its string updates periodically (it has since December 2019). That’s why the version appears as a W.X.Y.Z placeholder:

Googlebot Smartphone (mobile):

Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)

Googlebot Desktop:

Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Googlebot/2.1; +http://www.google.com/bot.html) Chrome/W.X.Y.Z Safari/537.36

Two things to internalize. First, don’t hardcode the versionW.X.Y.Z changes, and matching on it will break. Match the stable token Googlebot instead. Second, you can’t separate mobile from desktop in robots.txtA plain-text file at the root of a host that tells crawlers which URLs they may and may not request. It controls crawling, not indexing — a blocked URL can still be indexed if it's linked from elsewhere.. Both variants share the one Googlebot token, so a robots.txt rule applies to both.

Google’s crawler tokens

Google runs a whole family of crawlers and fetchers, each with its own token. The ones you’ll meet most:

Crawlerrobots.txt tokenNotes
GooglebotGooglebotSearch, Images, Video, News, Discover — mobile + desktop share this token
Googlebot ImageGooglebot-ImageGoogle Images
Googlebot VideoGooglebot-VideoVideo Search
Googlebot NewsGooglebot-NewsUses various Googlebot strings
Google StoreBotStorebot-GoogleShopping
Google-InspectionToolGoogle-InspectionToolPowers Search testing tools
GoogleOtherGoogleOtherInternal research/fetching
Google-ExtendedGoogle-Extendedrobots.txt-only — Gemini training, no request string

And the ones that break the usual rules — the special-case crawlers that ignore User-agent: *:

  • AdsBot (AdsBot-Google) and AdsBot Mobile (AdsBot-Google-Mobile) — they don’t obey the wildcard. To block them you must name them explicitly.
  • AdSense (Mediapartners-Google) — same; ignores the global *.
  • Google-Safety — used for malware/abuse detection; it ignores robots.txt entirely.

The implication is the one people miss: User-agent: * does not block AdsBot or Google-Safety. If you “block all bots” with a wildcard and assume AdsBot is gone, it isn’t. (This is exactly the kind of surprise that lands a page in indexed though blocked by robots.txtA Google Search Console Page Indexing status: the URL was excluded from indexing because your robots.txt disallows crawling it. Usually intentional and benign — robots.txt blocks crawling, not indexing. territory — see robots.txt for the full control story.)

Bingbot’s user-agent strings

Bing rebuilt BingbotBingbot is Microsoft Bing's primary web crawler — the bot that discovers, fetches, and renders pages to build the Bing index. That index also powers Yahoo, DuckDuckGo, Ecosia, and Microsoft Copilot, so Bingbot's reach is far wider than Bing's own search-market share.’s string in 2022 to reflect that it renders with Microsoft Edge. The current strings:

Bingbot Desktop:

Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm) Chrome/W.X.Y.Z Safari/537.36

Bingbot Mobile:

Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)

The robots.txt token is just bingbot. The thing to watch: post-2022, Bingbot’s string looks almost exactly like a real Chrome/Edge browser — the only tell is the bingbot/2.0 fragment inside it. If you have any logic that filters or detects bots by UA, that change matters.

How robots.txt actually matches a token

A few rules govern which group of rules a crawler obeys (per Google’s robots.txt spec and RFC 9309):

  • Most-specific match wins. Google “determines the correct group of rules by finding… the group with the most specific user agent that matches the crawler’s user agent.” A Googlebot group beats a * group for Googlebot.
  • Same-token groups merge — but never with *. Multiple groups naming the same agent are combined into one. A specific-agent group and the * group are not merged; * is only the fallback when nothing specific matches.
  • Case-insensitive. Field name and value both — Googlebot, googlebot, GOOGLEBOT are equivalent.
  • Version numbers and wildcards in the token line are ignored. Per Google, “both googlebot/1.2 and googlebot* are equivalent to googlebot.” You cannot write User-agent: Googlebot* to match a family — the * there does nothing.

So a User-agent: line takes a token and matches it as a plain (case-insensitive) substring of the crawler’s identity — no version pinning, no wildcards inside it.

Why you can’t trust the string — and how to verify

The user-agent string is freeform text. Anything can set it. One line of curl will claim to be Googlebot, and plenty of tools and malicious bots do exactly that to slip past blocks. Google says so in its own Googlebot docs: “the HTTP user-agent request header used by Googlebot is often spoofed by other crawlers.” As I’ve put it in my Googlebot guide, “Many SEO tools and some malicious bots will pretend to be Googlebot. This may allow them to access websites that try to block them.”

So never make an access or content decision on the string alone. Verify instead.

One prerequisite before either method: get the real source IP. If your site sits behind a reverse proxy, load balancer, or CDN, the address in your default access log may be the proxy’s IP, not the crawler’s — you need the original client IP (usually forwarded in a header like X-Forwarded-For, configured correctly at your proxy) or neither verification method below means anything.

Method 1 — reverse + forward DNS (best for spot checks). Google’s two steps:

  1. “Run a reverse DNS lookup on the accessing IP address from your logs, using the host command. Verify that the domain name is either googlebot.com, google.com, or googleusercontent.com.”
  2. “Run a forward DNS lookup on the domain name retrieved in step 1… Verify that it’s the same as the original accessing IP address from your logs.”

For Bingbot, the same two-step dance, but the hostname must end in search.msn.com (not a Bing-branded domain — a common surprise). Commands are in the Scripts tab.

Method 2 — published IP ranges (best at scale). Google doesn’t publish a static allowlist for hardcoding (“these IP address ranges can change”), but it does publish machine-readable CIDR JSON files you can match against (common-crawlers.json and the broader crawler files). Bing now publishes its ranges too. I built a Googlebot IP verification tool for exactly this — paste in IPs and it classifies them. Bing Webmaster ToolsMicrosoft's free portal for monitoring and improving how a site appears in Bing search — the peer to Google Search Console, plus IndexNow instant indexing, richer backlink data, and keyword volumes. Because Bing's index also feeds Microsoft Copilot, it doubles as a window into AI-search visibility. has a built-in “Verify Bingbot” tool as well.

DNS is better for a one-off log check; IP-range matching is better for verifying at volume. Use whichever fits — but use one of them. And treat both the expected hostnames and the range files as current as of today, not permanent — Google and Bing have changed these paths before (the IP-range JSON files moved and were renamed since this article was first written), so re-check the live verification doc if a lookup that used to work stops matching.

A UA match is not proof of downstream outcomes

Even a fully verified request — real Googlebot IP, forward-confirmed reverse DNS, everything checks out — only proves one thing: that request reached your server. It’s tempting to round that up into a much bigger claim, but each of these is a separate fact requiring separate evidence:

  • Request received — a request with that user agent hit your server. (What log verification actually proves.)
  • Identity confirmed — the request really came from the crawler it claims to be. (What reverse DNS / IP-range matching adds on top.)
  • Content fetched and rendered — the crawler successfully rendered the page (no errors, no blocked resources). Not guaranteed just because a request landed.
  • Indexed — the URL made it into the search index. A successful fetch doesn’t guarantee indexing.
  • Used for retrieval, citation, or training — for AI crawlers especially (Google-Extended, GPTBot, and the rest), a crawl is not proof your content was retrieved for a specific answer, cited, or used in model training. Those are separate, mostly unobservable steps downstream of the crawl.

A verified Googlebot hit in your logs is real signal — just don’t stretch it further than what it actually shows.

TIP Verify the IP before trusting a crawler user agent

The verifier combines published ranges with forward-confirmed reverse DNS where the operator supports them. Some bots publish neither, so an unverifiable result is not proof of identity.

Paste the source IP or a log line into my Googlebot Verifier before allowlisting, blocking, or serving different content to a claimed crawler. Googlebot Verifier Free

  1. Take the source IP from server logs, not from a user-supplied header.
  2. Compare the claim with current published ranges and forward-confirmed reverse DNS.
  3. Base access decisions on the evidence tier and recheck rules as operator ranges change.
A familiar user-agent string is not identity; the network and DNS evidence must support the claim.

Web Bot Auth: where verification is heading

In 2026 Google began experimenting with Web Bot Auth“an experimental cryptographic protocol used to authenticate requests sent by bots.” The idea is to “move beyond easily spoofed headers to a verified identity and decouple agent identity from IP addresses.” Bots cryptographically sign their requests; sites verify the signature against Google’s published public keys, and signed requests carry a Signature-Agent header. Google’s own caveat matters: “We don’t sign every request of a particular agent. Be sure that you fall back to the established methods of bot verification.” So it’s additive, not a replacement — reverse DNS and IP ranges remain your baseline today.

Browsers are getting harder to parse from the UA string too

Everything above is about crawlers, but the same “don’t over-trust the string” lesson applies to browsers, and it’s getting stronger. Chrome has been rolling out User-Agent reduction: freezing or coarsening parts of its UA string (full browser version, OS version, device model) instead of reporting them exactly, so the string can’t be used to fingerprint a specific user. Google’s own framing: “The granularity and abundance of detail can lead to user identification. The default availability of this information can lead to covert tracking.” Practically, that means UA-string parsing for exact browser/OS/device version — analytics, device detection, bug triage — is increasingly unreliable and will only get more so.

The replacement Chrome recommends is User-Agent Client Hints (UA-CH): structured data the browser sends only when a server explicitly asks for it. Low-entropy hints (browser brand, major version, mobile flag) go out by default; high-entropy hints (exact version, platform version, device model) require the server to opt in via an Accept-CH response header first — an explicit negotiation, not a broadcast. Two caveats before you lean on it: it’s a Chrome/Chromium-family mechanism, not something every browser sends, and even where it’s supported, “the value may be blank, not returned, or populated with a varying value.” Client Hints solve the browser-string problem; they are not a crawler-verification mechanism — Google and Bing still verify their own crawlers via DNS and IP ranges, not Client Hints.

User-agent targeting and cloaking

The tempting move — “detect Googlebot by its UA and serve it something special” — is both technically fragile and a policy violation.

Fragile, because Google doesn’t crawl with one UA. You’d have to correctly handle Googlebot (mobile and desktop), Google-InspectionTool, AdsBot, GoogleOther, and more, from rotating IPs — practically impossible to whitelist cleanly.

A policy violation, because serving different content to a crawler than to users is cloaking: “presenting different content to users and search engines with the intent to manipulate search rankings and mislead users.” The penalty ranges from algorithmic demotion to full deindexingDeindexing means getting a URL to stop appearing in Google's search results. There's no single delete button — the right method depends on whether you own the page, whether removal is temporary or permanent, and whether the content should still exist.. Note the line: legitimate adaptation (responsive layouts, content negotiation) is fine — it’s swapping the content itself between bots and users that crosses into cloaking.

For where the user agent sits in the bigger pipeline, see crawling (the hub) and crawler. For controlling what those bots are allowed to fetch, see robots.txt.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.