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: allow it or block it?

AdsBot-Google is the agent Google Ads uses to check the quality of the landing pages behind your ads. Allow it if you advertise with Google: blocking it degrades the assessment of pages you pay to promote. Google states it ignores the robots.txt wildcard with the advertiser's permission, so only a group naming AdsBot-Google reaches it.

Start freeBook a demo

7 days free · card required

AI traffic · attensira.com30 days to 4 Oct 2026

0requests filed as AdsBot-Google · 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 (this page)0Not reached
AdsBot-Google-Mobile0Not 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 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 today.

robots.txt · for your sitepaste-ready
# AdsBot-Google ignores the wildcard group. To reach it# you must name it. Blocking it degrades the quality# assessment of your own ad landing pages.User-agent: AdsBot-GoogleAllow: / # The mobile check is a separate token and needs its own# group.User-agent: AdsBot-Google-MobileAllow: /
Example · a group to paste, written for the token AdsBot-Google
attensira.com/robots.txtnot reached

it ignores the User-agent: * group

As served at attensira.com/robots.txt ·

We do not name AdsBot-Google, 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 would.

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

Who runs AdsBot-Google, 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 does AdsBot-Google ignore your wildcard rule?

Because Google says it does, with your permission as an advertiser. Google documents its special-case crawlers, and gives AdsBot as the example, as ignoring the global robots.txt user agent with the ad publisher's permission3. So:

  • User-agent: * with Disallow: / does not stop AdsBot-Google.
  • User-agent: AdsBot-Google with Disallow: / does.

Almost everyone assumes the opposite: that the wildcard is the broad net and a named group the narrow exception. Here the named group is the only thing that reaches the agent at all. The reason is contractual rather than technical. The advertiser is the site owner, and the ads relationship includes permission to check the pages being promoted. A site that "blocked everything" has not blocked this, and that is documented behaviour, not a crawler misbehaving.

What does blocking AdsBot-Google cost you?

It costs you, not Google. Google documents AdsBot-Google as affecting Google Ads' ability to check web page ad quality1. It is checking pages you are paying to send people to. Denying the check degrades the assessment of your own campaigns. The robots.txt block above therefore allows it, and names the mobile token too.

Its traffic is easy to recognise. It appears on advertised URLs and almost nowhere else, and it comes in bursts when campaigns change. If one landing page is fetched far more often than the article beside it, this is usually why.

Why can't you reproduce the landing page problems Google Ads reports?

Because the block is rarely deliberate, and it happens where nobody looks. Google's published header is AdsBot-Google: no Mozilla/5.0, no platform, nothing browser-shaped2. Heuristic bot filters and WAF rules drop exactly that shape. The consequence surfaces days later in the Google Ads console, in front of people with no reason to suspect a CDN rule.

When landing page problems cannot be reproduced by hand, check three places in order: the robots.txt group, the WAF or CDN bot rules, and any application user-agent allowlist. And remember that AdsBot-Google-Mobile is a separate token2; a fix for one leaves the other where it was. Its page is AdsBot-Google-Mobile.

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

A user-agent header is free text, so a log line naming AdsBot-Google 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.

Special-case crawlers resolve as rate-limited-proxy-*.google.com, not googlebot.com, and their addresses are in special-crawlers.json. An allowlist built on Googlebot's suffix rejects real AdsBot traffic, and it looks like an intermittent Google failure, not a rule you wrote. Follow any reverse lookup with a forward lookup back to the same address.

How is AdsBot-Google different from Googlebot?

They share an operator and almost nothing else that matters for your rules. AdsBot-Google checks ad landing pages, ignores the wildcard group and belongs to Google's special-case crawlers, which have their own reverse DNS form and range file4. Googlebot indexes for Search, obeys the wildcard group when it has no group of its own, and verifies under googlebot.com.

  • Job

    AdsBot-Google
    Ad landing page quality checks
    Googlebot
    Search indexing

  • Wildcard group applies?

    AdsBot-Google
    No, per Google
    Googlebot
    Yes

  • Reverse DNS

    AdsBot-Google
    rate-limited-proxy-*.google.com
    Googlebot
    googlebot.com

  • Range file

    AdsBot-Google
    special-crawlers.json
    Googlebot
    common-crawlers.json

Every row is a place where a rule written for one of them silently does the wrong thing to the other.

Is AdsBot-Google part of your AI or search traffic?

No. In the four-way job taxonomy of the AI crawler guide, it is product operations. It builds no index, feeds no model Google documents and produces no citation. A rise in its traffic reflects your own ad spend. Keep it in its own row of a crawler report, not inside a total that anyone reads as interest in your content.

VerificationGoogle
Reverse DNS ends in
*.google.com
IP range file
special-crawlers.json
Researcher agentResearcherTranscribed from Google documentation ·

How should you match it in logs?

AdsBot-Google carries no version number, which makes it one of the few tokens in this directory that is not volatile. Match the bare token case-insensitively. Decide deliberately whether your matcher should also catch AdsBot-Google-Mobile. A substring match will, and in a report about the mobile ad experience that is exactly wrong.

What can Attensira show you about AdsBot-Google?

AI traffic, on Growth and Business, groups crawler fetches by operator and declared purpose at the edge, so ad checks sit apart from the crawlers and agents that shape AI answers. It reports user agents as sent; the special-case verification stays yours. See crawler logs and the robots.txt generator.

User-AgentGoogle
AdsBot-Google (+http://www.google.com/adsbot.html)
Researcher agentResearcherTranscribed from Google documentation ·

Should I allow AdsBot-Google in my situation?

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

  • You blocked everything with a wildcard rule and AdsBot-Google kept arriving.

    That is documented behaviour. If you want it to stop, write a group naming AdsBot-Google.

    Google documents its special-case crawlers as ignoring the global robots.txt user agent with the ad publisher's permission, so a wildcard rule was never going to reach this agent. Only a specific group does — which is the inverse of how people expect wildcards to work, and worth knowing before you conclude a crawler is misbehaving.

  • Your Google Ads account is reporting landing page problems that your own testing cannot reproduce.

    Check whether AdsBot-Google is being rejected by a robots.txt group, a WAF rule or a user-agent allowlist.

    Google documents AdsBot-Google as what Google Ads uses to check web page ad quality, and publishes its header as the bare string "AdsBot-Google (+http://www.google.com/adsbot.html)" with no browser preamble. That shape is exactly what heuristic bot filters drop, and the resulting quality assessment failure surfaces in the ads console rather than anywhere a web team is looking.

  • You allowlisted verified Google crawlers by reverse DNS to googlebot.com and AdsBot traffic is still being rejected.

    Add the special-case crawler hostname form, rate-limited-proxy-***.google.com.

    Google documents a different reverse-DNS domain for special-case crawlers than for common crawlers, and publishes their addresses in a separate special-crawlers.json file. An allowlist built only around googlebot.com verifies Googlebot correctly and rejects a genuine AdsBot fetch, which looks like an intermittent Google failure rather than a rule you wrote.

What else do people ask?

What is AdsBot-Google?
AdsBot-Google is the agent Google documents as affecting Google Ads' ability to check web page ad quality. It fetches the landing pages behind your ads, which is why it appears on advertised URLs and almost nowhere else, often in bursts when campaigns change.
Why doesn't User-agent asterisk Disallow stop AdsBot-Google?
Google documents its special-case crawlers, with AdsBot as the example, as ignoring the global robots.txt user agent with the ad publisher's permission. A wildcard group does not reach it; a group that names AdsBot-Google does.
Does an AdsBot-Google rule also cover AdsBot-Google-Mobile?
No. AdsBot-Google-Mobile is a separate robots.txt token for the mobile ad quality check and needs its own group. A rule naming only AdsBot-Google leaves the mobile check unaddressed in either direction.

Where do these facts come from?

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

  1. Google documents AdsBot-Google as affecting Google Ads' ability to check web page ad quality, and AdsBot-Google-Mobile as the equivalent token for the mobile web ad quality check.

    developers.google.com · retrieved

    “Checks Google Ads web page ad quality”

  2. Google documents AdsBot-Google's user agent as "AdsBot-Google (+http://www.google.com/adsbot.html)", and AdsBot-Google-Mobile's as a Nexus 5X Chromium preamble ending in "(compatible; AdsBot-Google-Mobile; +http://www.google.com/mobile/adsbot.html)".

    developers.google.com · retrieved

  3. Google documents its special-case crawlers, giving AdsBot as the example, as ignoring the global robots.txt user agent with the ad publisher's permission.

    developers.google.com · retrieved

    “ignores the global robots.txt user agent (*) with the ad publisher's permission”

  4. Google documents special-case crawlers as using the reverse-DNS hostname form rate-limited-proxy-***-***-***-***.google.com and publishes their address ranges in special-crawlers.json.

    developers.google.com · retrieved

Want whatever it takes to win the answer?

Start freeBook a demo

7 days free · card required