For the complete documentation index, see llms.txt. Every page on this site is also served as Markdown: append `.md` to any URL, or send `Accept: text/markdown`.
Skip to content
Attensira LogoAttensira
Book a demo

Bots

AdsBot-Google-Mobile: allow it or block it?

AdsBot-Google-Mobile is the mobile half of Google's ad quality check: it reads the landing pages behind your Google Ads as a phone renders them. Allow it on any host a campaign points at. Google states the robots.txt wildcard is ignored for it, so only a group naming the token reaches it, and an AdsBot-Google rule does not cover it.

Start freeBook a demo

7 days free · card required

AI traffic · attensira.com30 days to 4 Oct 2026

0requests filed as AdsBot-Google-Mobile · 30 days

of 143,601 AI crawler requests from 7 operators

Advertising bots on the board, beside attensira.com's rule for each
AgentAI requests, 30 daysattensira.com robots.txt
AdsBot-Google-Mobile (this page)0Not reached
AdsBot-Google0Not reached
Mediapartners-Google0Not reached
OAI-AdsBot0Wildcard

None of the 4 had a request filed in the window. User agents as sent, not checked against address lists.

Analyst agentAnalyst · reads the AI traffic boardAI traffic board, read over the Attensira MCP, and our live robots.txt · · n=143,601 AI requests
Karl-Gustav KallasmaaKarl-Gustav Kallasmaa, Founder & CEOLast updated

How do I allow or block AdsBot-Google-Mobile in robots.txt?

Paste this into the robots.txt at the root of your domain. Only a group that names the token reaches it; your * group does not. Beside it, the group attensira.com serves AdsBot-Google-Mobile today.

robots.txt · for your sitepaste-ready
# The wildcard group does not reach this agent. Name the# token.User-agent: AdsBot-Google-MobileDisallow: /staging/ # Blocking it entirely stops mobile ad quality checks on# your own landing pages.
Example · a group to paste, written for the token AdsBot-Google-Mobile
attensira.com/robots.txtnot reached

it ignores the User-agent: * group

As served at attensira.com/robots.txt ·

We do not name AdsBot-Google-Mobile, and its operator states it ignores the User-agent: * group, so no rule in our file reaches it. Only a group that names AdsBot-Google-Mobile would.

Read the whole file, or write yours with the robots.txt generator.

Who runs AdsBot-Google-Mobile, and what is it for?

Google runs it, and we file it under product operations. Checks ad landing pages, or reads pages that show ads, for an ad product. Separate from search indexing, so a rule here is an advertising decision.

From Google’s documentation, read .

Why doesn't your wildcard rule reach AdsBot-Google-Mobile?

Because Google documents an exception. It gives AdsBot-Google-Mobile as the robots.txt token for the AdsBot Mobile Web crawler and states that the global user agent (*) is ignored3. The reason Google gives for the category is that AdsBot ignores the global user agent with the ad publisher's permission: the crawl exists because of a commercial relationship you entered.

The predictable result: someone writes User-agent: * with Disallow: / on a staging or paywalled host, this agent keeps arriving, and a ticket gets opened about a bot ignoring robots.txt. It is documented behaviour. Name the token and it stops.

Whether it should stop is a separate question. Google documents rules addressed to it as affecting Google Ads' ability to check web page ad quality1. Blocking a landing page from the agent that evaluates landing pages is a decision about your own ad spend, made in a file most people edit for search reasons. The robots.txt block above scopes the rule to a staging path rather than the whole site.

How do I verify that a visit really came from AdsBot-Google-Mobile?

A user-agent header is free text, so a log line naming AdsBot-Google-Mobile is a claim until you check it.

Look up the visiting IP, confirm the hostname ends in one of the suffixes in the record, then look that hostname up and confirm it returns the same IP, or match the IP against the published ranges.

A special-case crawler: it resolves under rate-limited-proxy-*.google.com, not googlebot.com, and is listed in special-crawlers.json. A header that gets past ad blockers and bot mitigation on landing pages is worth forging, so verify before granting an exception, and forward-resolve the hostname back to the original address.

Why can't your reports tell the two AdsBots apart?

Because one token is a prefix of the other. AdsBot-Google is the desktop check, with a different header, and its token is the first thirteen characters of this one. Any log filter, firewall rule or report that matches AdsBot-Google as a substring silently includes AdsBot-Google-Mobile.

That matters because mobile and desktop ad quality are exactly what you want separated. A landing page problem that exists only on phones disappears in a merged row. Match whole tokens, longest first, and keep the two agents in different rows.

The robots.txt side runs the other way. The tokens are separate, so a group naming AdsBot-Google does not govern the mobile check. If you allow or scope one, write the matching group for the other.

Side by side, they differ only in what they check and the header they send:

  • Checks

    AdsBot-Google-Mobile
    Mobile web landing pages
    AdsBot-Google
    Desktop landing pages

  • Header

    AdsBot-Google-Mobile
    Android Chromium preamble plus token
    AdsBot-Google
    Bare AdsBot-Google (+http://www.google.com/adsbot.html)

  • Wildcard group

    AdsBot-Google-Mobile
    Ignored, per Google
    AdsBot-Google
    Ignored, per Google

  • Verification

    AdsBot-Google-Mobile
    Special-case mask on google.com5
    AdsBot-Google
    Special-case mask on google.com
VerificationGoogle
Reverse DNS ends in
*.google.com
IP range file
special-crawlers.json
Researcher agentResearcherTranscribed from Google documentation ·

What user-agent string does AdsBot-Google-Mobile send?

Match the token, never the version. A rule pinned to a version stops matching silently the next time the operator ships.

The version in this string changes; check Google’s page before relying on the exact text.

Why did old AdsBot-Google-Mobile rules stop matching?

Google publishes the current agent as an Android string on a Nexus 5X preamble, ending in a compatible clause that names AdsBot-Google-Mobile and Google's mobile AdsBot help page, with the Chrome version written as the literal placeholder W.X.Y.Z2. The placeholder is Google's notation for a version that changes; no request sends it.

Google also lists an iPhone-based agent with the same token under retired special-case crawlers, stated to be no longer in use and noted only for historical reference4. Old firewall rules pinned to that header still exist. One of the two published strings has already expired, and every rule that pinned it failed without an error. That is the strongest argument for matching the bare token AdsBot-Google-Mobile instead of any full header.

Is AdsBot-Google-Mobile an AI or search crawler?

No. In the four-way job taxonomy of the AI crawler guide, it is product operations. It does not index, does not train and does not lead to citations. Its volume follows your mobile ad campaigns, so in a crawler report it belongs in its own row next to AdsBot-Google, not in any total read as interest in your content.

What can Attensira show you about AdsBot-Google-Mobile?

AI traffic, on Growth and Business, groups fetches by operator and declared purpose at the edge, so ad checks are not mistaken for AI crawling. It reports user agents as sent; matching whole tokens and checking the special-case mask stay yours. See crawler logs and the robots.txt generator.

User-AgentGoogle
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; AdsBot-Google-Mobile; +http://www.google.com/mobile/adsbot.html)
Researcher agentResearcherTranscribed from Google documentation ·

Should I allow AdsBot-Google-Mobile in my situation?

Concrete cases, and what each one implies for this agent.

  • A wildcard disallow on a staging or paywalled host did not stop AdsBot-Google-Mobile.

    Address the token by name for that host, having first checked no live campaign points at it.

    Google states that the global user agent is ignored for this crawler, so the wildcard never applied. Naming the token works, but ad quality checks are how a landing page you are paying for gets evaluated — so the rule belongs on hosts no campaign uses, not on the ones that matter.

  • Your log filter matches AdsBot-Google and you cannot tell the two agents apart in reporting.

    Match whole tokens, not substrings, and keep AdsBot-Google-Mobile in its own row.

    AdsBot-Google is a prefix of AdsBot-Google-Mobile, so a naive substring filter silently merges the mobile checker into the desktop one. Google documents them as separate rows with separate headers, and a merged row hides which surface an ad quality problem is on.

  • You found an old iPhone-shaped AdsBot-Google-Mobile string in a firewall rule and want to know whether to keep it.

    Match the bare token instead of either full header.

    Google lists the iPhone-based agent under retired special-case crawlers, noted only for historical reference, while the current Android-based agent carries the same token. A rule pinned to a full header is a rule that expires whenever Google changes the preamble, and it does so without producing an error.

What else do people ask?

Why doesn't my wildcard Disallow stop it?
Google states that the global user agent, the asterisk, is ignored for this crawler, and explains that AdsBot ignores the wildcard with the ad publisher's permission. Name AdsBot-Google-Mobile in its own group and it follows that group.
Does a rule for AdsBot-Google cover the mobile agent?
No. AdsBot-Google-Mobile is a separate robots.txt token with its own group. The reverse trap is in logs - AdsBot-Google is a prefix of AdsBot-Google-Mobile, so a substring filter for AdsBot-Google silently counts both.
Should I keep an old iPhone-based AdsBot-Google-Mobile rule?
No. Google lists the iPhone-based agent under retired special-case crawlers, no longer in use and noted only for history. A firewall rule pinned to that header matches nothing today. Replace it with a match on the bare token.

Where do these facts come from?

5 claims on this page, each with the page it was read from; last checked . The numbers in the text point here.

  1. Google documents that crawling preferences addressed to the AdsBot-Google-Mobile user agent affect Google Ads' ability to check web page ad quality.

    developers.google.com · retrieved

    “affect Google Ads' ability to check”

  2. Google publishes AdsBot-Google-Mobile's User-Agent in HTTP requests as "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; AdsBot-Google-Mobile; +http://www.google.com/mobile/adsbot.html)".

    developers.google.com · retrieved · changes often, check the source

    “(compatible; AdsBot-Google-Mobile; +http://www.google.com/mobile/adsbot.html)”

  3. Google documents AdsBot-Google-Mobile as the robots.txt user agent token for the AdsBot Mobile Web crawler and states that the global user agent (*) is ignored.

    developers.google.com · retrieved

    “The global user agent (*) is ignored.”

  4. Google lists an iPhone-based AdsBot-Google-Mobile agent under retired special-case crawlers, which it states are no longer in use and are noted only for historical reference.

    developers.google.com · retrieved

    “The following special-case crawlers are no longer in use, and are only noted here for historical reference.”

  5. Google documents the special-case crawlers' reverse DNS mask as rate-limited-proxy-***-***-***-***.google.com and publishes their IP ranges in the special-crawlers.json object.

    developers.google.com · retrieved

    “The special-case crawlers' reverse DNS mask matches rate-limited-proxy-***-***-***-***.google.com”

Want whatever it takes to win the answer?

Start freeBook a demo

7 days free · card required