Most “AI Assistant Traffic” Is Spoofed: How To Verify Bots, Protect Your Site, And Measure What Matters In AI Search
User-agents lie. If you’re making AI Search decisions based on “ChatGPT-User” or “Googlebot” counts in analytics, you’re likely acting on spoofed traffic. Here’s how to verify crawlers by IP ranges, separate demand vs. training vs. retrieval, and set up a practical monitoring + execution loop with AYSA.
For most businesses, “AI assistant traffic” sounds like a new growth channel. The problem: a user-agent string can say anything—and far too many tools and dashboards treat those self-declared names as facts.
A recent investigation shared by Duane Forrester on Search Engine Journal is a wake-up call: the gap between “claimed bot identity” and “verified bot identity” can be massive—even on a brand-new site with modest traffic. That gap changes how you measure AI visibility, how you interpret Crawl spikes, and how you protect your site from scanners hiding behind trusted names.
This is an editorial resource based on that core idea (verify bots with proof, not labels), expanded into a practical playbook you can hand to an SEO, a developer, or an ops lead. I’ll also share how AYSA fits into the loop: monitor, prepare changes, request approval, then execute—without letting spoofed data steer your strategy off a cliff.
Concise summary
- User-agents are claims. A request that says “Googlebot” or “ChatGPT-User” is not proof it’s Google or OpenAI.
- Verification requires evidence. The most reliable method is matching the visitor IP to the vendor’s published IP ranges (and sometimes reverse DNS).
- AI bot activity isn’t one thing. Separate demand fetch (live user-triggered), retrieval Crawling (Indexing for answers), and training crawling (model training). These have different business implications.
- Most businesses are measuring the wrong layer. They’re counting noisy bot labels instead of verified crawls and downstream outcomes (citations, mentions, leads, conversions).
- Action beats awareness. Build a verification baseline from your logs, defend against spoofing, and focus on the metrics you can control.
Key takeaways (what to remember after you close this tab)
- Never optimize for an unverified bot name. Treat it like an anonymous visitor until proven otherwise.
- Add a third bucket: “Unverifiable.” Not every non-match is fake; sometimes the proof source is missing or incomplete.
- Expect Googlebot spoofing. It’s historically the most impersonated Crawler identity—and the presence of “Googlebot” in logs is not the same as “Google crawled my site.”
- Assume spoofing has a security angle. Many impersonators aren’t trying to Index you; they’re probing for sensitive files and misconfigurations.
- Measure outcomes separately from fetches. A verified crawl is an input. Citations, rankings, and revenue are outputs.
Table of contents
- Why this changed: AI search made bot traffic feel like a growth metric
- The uncomfortable truth: user-agents are claims, not proof
- What “AI bot traffic” actually is: demand fetch vs. retrieval crawl vs. training crawl
- Why Googlebot often looks “worse” in logs (and why that’s not new)
- Where verification data comes from (official sources you can use)
- A practical verification method (without turning your team into security researchers)
- Edge cases: when IP verification isn’t enough (Common Crawl and reverse DNS)
- The measurement gap: why Gemini can be hard to isolate in logs
- What to measure (and what to stop measuring)
- SME scenario: the ecommerce brand that “got 500 ChatGPT hits” (but nothing moved)
- Agency implications: reporting, retainers, and credibility in the AI era
- Where AYSA fits: monitoring + approved execution, built for noisy reality
- What to do next (a step-by-step action list)
- Sources and further reading
Why this changed: AI search made bot traffic feel like a growth metric
For years, most businesses treated crawler traffic as a technical detail. You might glance at it when you had an indexing issue, a site slowdown, or a weird spike in 404s. Otherwise, crawlers were background noise.
AI assistants changed that psychology. Now, teams want to see:
- Is ChatGPT “looking at” our site?
- Is Claude crawling us?
- Are we being pulled into answers?
- Are we “training the model”?
Those are reasonable questions. But the moment you start using unverified bot labels as a proxy for demand, visibility, or brand authority, you’re exposed to two kinds of failure:
- Strategic failure: you optimize for a signal that isn’t real.
- Operational failure: you miss that the “AI assistant” is actually a scanner probing for sensitive endpoints.
The fix isn’t complicated—but it does require discipline. Verification is the difference between “interesting story” and “business-grade measurement.”
The uncomfortable truth: user-agents are claims, not proof
When a bot hits your website, it typically includes a user-agent string like:
- Googlebot
- ChatGPT-User
- GPTBot
- ClaudeBot
- CCBot
Many analytics tools and log dashboards display this as if it’s an identity verification. It isn’t. It’s a self-reported label—like a stranger showing up wearing a delivery uniform. The uniform is easy to buy; it doesn’t prove they work for the company.
The only way to treat bot identity as “real” is to validate it with independent evidence—most commonly: the source IP address matching a published range owned/used by that operator.
This is the core insight in Forrester’s write-up: once you validate IPs against official lists, what looked like meaningful AI demand can shrink fast—and “Googlebot” can turn out to be mostly impersonation too.
What “AI bot traffic” actually is: demand fetch vs. retrieval crawl vs. training crawl
One reason this topic is so confusing is that people say “AI bot” as if it’s one creature. In reality, there are multiple behaviors that look similar in logs but mean different things for your business.
1) Demand fetch (live, user-triggered)
This is the fetch that happens during a real user session: an assistant pulls a page in real time to ground an answer. In the source article, these were described as agent names ending in -User (e.g., “ChatGPT-User”).
Why it matters: this is the closest thing to “AI referral traffic,” even if it doesn’t show up like classic referrals. It can be a sign you’re being used as a source right now.
What it doesn’t tell you: whether you were cited, whether your brand was mentioned, or whether the user ever saw your domain name.
2) Retrieval crawl (indexing for answers)
Retrieval is about building a current index that can be referenced when answering questions. This is less “someone asked a question” and more “we need to keep our index fresh so we can answer questions quickly.”
Why it matters: it affects whether your content is even eligible to be pulled into AI answers in the near term.
3) Training crawl (collecting data for model training)
Training crawls can be the most strategically consequential—and the least measurable—because they’re not about sending you traffic next week. They’re about building future models that may answer questions without fetching you again.
Why it matters: training can influence future “model memory” (in loose, non-technical business terms): how well an AI system understands your product category, your brand, your definitions, your unique data, and your authority signals over time.
What it doesn’t tell you: almost everything you’d like to know. A fetch is not a guarantee of inclusion, attribution, or future mentions.
The business takeaway: don’t collapse these into one “AI bot traffic” number. You’ll make the wrong decisions because each class has a different job and different payoff timeline.
Why Googlebot often looks “worse” in logs (and why that’s not new)
If you run verification and discover that a huge percentage of “Googlebot” requests are not actually Google, you didn’t discover a new phenomenon—you discovered a long-standing internet reality: Googlebot is one of the most spoofed identities on the web.
Why? Because impersonating Googlebot can help a bad actor:
- Slip past naive filters that allow “Googlebot” without verification
- Blend into the noise of legitimate crawling
- Probe endpoints and attempt to find misconfigurations
Google has long told site owners to verify Googlebot via published information rather than trust the user-agent name alone. In the source article, verification was done by comparing request IPs to Google’s published crawler IP ranges (not by trusting the label).
The operational takeaway: your “Googlebot requests” line item is a “claims to be Googlebot” line item until verified.
Where verification data comes from (official sources you can use)
The good news: major operators publish the technical proof you need. The source article referenced several official JSON endpoints used to verify whether an IP belongs to a crawler.
Here are the same primary sources (use these as verification leads; don’t rely on scraped lists):
- OpenAI (ChatGPT-User): OpenAI ChatGPT User Bot JSON
- Anthropic (Claude bots): Claude Crawling Bot JSON
- Perplexity (Perplexity-User): Perplexity User Bot JSON
- Google (common crawlers IP ranges): Google Common Crawlers IP Ranges
- Common Crawl (CCBot): Common Crawl Bot JSON
Two important notes:
- These lists can change. Treat them as live configuration inputs, not hardcoded constants.
- Some operators can be messy. The SEJ piece explicitly flagged that Perplexity may fetch from IPs outside its published ranges in some cases, which makes strict “in list = real, not in list = fake” less clean for that one operator.
A practical verification method (without turning your team into security researchers)
You don’t need a massive security stack to do credible bot verification. You need a repeatable process and a willingness to treat “unverifiable” as a legitimate state.
The minimum viable workflow
- Pull access logs for a defined period (start with 14–30 days).
- Extract candidate bot requests (filter by user-agent strings you care about: Googlebot, GPTBot, ClaudeBot, ChatGPT-User, etc.).
- For each operator, fetch their official IP range list (JSON endpoints above).
- Compare each request’s source IP to the operator’s published ranges.
- Bucket outcomes into:
- Verified: IP matches the published ranges
- Spoofed: list loaded successfully, IP does not match
- Unverifiable: list failed to load, record missing, reverse DNS needed, or other ambiguity
- Investigate outliers (high volume spoofing, suspicious paths, repeated probing attempts).
Why “Unverifiable” is not a cop-out
Most teams make one of two mistakes:
- Everything that doesn’t match is called fake (overconfident, can be wrong when lists are incomplete).
- Everything that claims a bot name is treated as real (naive, easy to exploit).
The third category is what keeps you honest: “I can’t prove it yet.” In the SEJ investigation, that restraint was essential to correctly chasing down Common Crawl impostors rather than guessing.
What to look for in spoofed requests
Spoofed “AI assistant” or “Googlebot” requests often reveal themselves by behavior. For example, the source article observed fake “assistant” requests probing sensitive filenames (like environment configuration and secrets files). You may also see:
- Requests to common admin paths (
/wp-admin,/admin) - Requests for configuration files (variants of
.env,config, YAML/JSON secrets) - High-frequency hits to many URLs with no apparent crawl pattern
- Odd HTTP methods or headers (depending on your logging)
If you see this, treat it as a security signal, not an SEO curiosity.
Edge cases: when IP verification isn’t enough (Common Crawl and reverse DNS)
Some crawlers are best verified with more than “IP in list.” The SEJ piece highlighted Common Crawl as a stubborn case because requests could appear without a clean match to published ranges, leading to an “unverifiable” bucket that required manual follow-up.
When IP range checks don’t resolve the question, here’s a pragmatic escalation path:
1) Reverse DNS validation
Some operators can be validated by reverse DNS patterns (i.e., what hostname the IP resolves to). If reverse DNS doesn’t resolve at all, that’s not proof of spoofing—but it is a reason to avoid granting trust.
2) Confirm in public datasets (when applicable)
Common Crawl publishes public indexes; you can check whether your domain appears in recent crawls. (If you need this, use Common Crawl’s own documentation and index interfaces; I’m not adding a specific link here beyond what was provided in the research context.)
3) WHOIS / ASN ownership checks
Even without deep security tooling, looking up who owns the IP (or which ASN it belongs to) can quickly tell you if the traffic comes from commodity hosting providers versus known crawler infrastructure.
The point isn’t to become a forensic lab. The point is to have a credible path to “close the loop” when verification isn’t clean.
The measurement gap: why Gemini can be hard to isolate in logs
One of the most important strategic points in the source article is also one of the most frustrating: you can’t always measure what you care about with the same clarity across vendors.
In Forrester’s write-up, Google’s ecosystem was described as harder to separate into distinct “Gemini” fetchers because Google uses permissioning (e.g., the Google-Extended robots token) rather than a uniquely identifiable crawler that shows up as “Gemini” in logs.
Business impact:
- You may be able to verify Googlebot activity.
- You may not be able to conclusively attribute that activity to a specific AI product workflow via logs alone.
This is a measurement reality, not a conspiracy. But it means your AI visibility strategy can’t rely exclusively on bot logs. You need downstream outcome monitoring (citations, mentions, rankings, conversions) and strong technical hygiene.
What to measure (and what to stop measuring)
Once you accept that user-agents lie, the next question becomes: “What should I measure instead?” Here’s a straightforward measurement ladder—starting with what’s most defensible.
Level 1: Verified crawler activity (input metrics)
- Verified crawl counts by operator (Google, OpenAI, Anthropic, etc.)
- Verified crawl distribution by site section (blog, product pages, docs, locations)
- Crawl errors and response codes for verified crawlers
- Time-to-first-byte and performance for verified crawlers (slow sites can get undercrawled)
These are operational signals: “Are legitimate systems able to fetch our content cleanly?”
Level 2: AI visibility outcomes (business-adjacent metrics)
Logs don’t answer: “Did we get used?” For that, you need broader monitoring. Depending on your business, that includes:
- Brand and product mentions in AI answers (tracked with consistent query sets)
- Citations/links when they exist
- Presence in AI-driven SERP features (where applicable)
- Landing page engagement changes aligned with AI discovery patterns (careful: attribution is imperfect)
Level 3: Revenue outcomes (the only metric that can’t be spoofed by a crawler name)
- Qualified leads
- Calls and bookings
- Ecommerce purchases
- Pipeline influenced (for B2B, with sober attribution)
What to stop doing
- Stop reporting “AI assistant visits” from unverified user-agents as if they indicate demand or brand reach.
- Stop treating Googlebot counts as synonymous with indexing success. Indexing is an outcome; crawling is an input.
- Stop making sitewide changes based on a single noisy signal. Especially changes that reduce accessibility (blocking, cloaking-like behavior, overly aggressive bot rules).
SME scenario: the ecommerce brand that “got 500 ChatGPT hits” (but nothing moved)
Let’s make this real with a scenario I see constantly in modern SEO operations.
The setup
An ecommerce brand selling specialty skincare notices a spike in server logs. Their analytics tool groups traffic by user-agent and shows:
- “ChatGPT-User: 500 requests”
- “Googlebot: 3,000 requests”
The founder asks the marketing manager: “Are we showing up in AI answers now?” The manager—wanting to deliver good news—assumes yes and shifts the content plan toward “AI-friendly” FAQ pages, reducing investment in product detail pages and UGC reviews.
What’s actually happening (the common failure mode)
After verification, the team discovers:
- Most “ChatGPT-User” requests did not match official IP ranges.
- A large portion of “Googlebot” requests were also not verifiable as Google.
- The suspicious requests disproportionately hit endpoints like
/wp-json, odd query strings, and common config paths.
In other words: the team optimized their content strategy based on what was mostly scanner noise.
The business cost
- Opportunity cost: weeks spent building content that didn’t improve conversions.
- Reporting risk: leadership was told “AI visibility is up,” then saw no revenue change.
- Security risk: probing attempts might have been early indicators of vulnerability discovery.
The correct response
A healthier play would have been:
- Verify bots first (and bucket into Verified/Spoofed/Unverifiable).
- Harden basic security controls (rate limits, WAF rules, sensitive file protections).
- Measure AI outcomes separately (citations/mentions and actual business KPIs).
- Then optimize content based on what’s verified and what’s driving value.
Agency implications: reporting, retainers, and credibility in the AI era
If you’re an agency, bot spoofing isn’t just a technical curiosity—it’s a credibility issue.
AI-era reporting has a new standard
In 2015, it became unacceptable to report “rankings only” without tying them to business outcomes. In 2026, it’s becoming unacceptable to report “AI traffic” without verification.
If you’re sending a monthly deck that says:
- “ChatGPT visits up 200%”
- “Googlebot crawls up 80%”
…and those numbers are based on user-agent strings without IP validation, you’re building your narrative on sand.
What agencies should change immediately
- Add a verification appendix to technical reporting (method + sources used).
- Separate crawl inputs from visibility outputs. Crawls are operational; mentions/citations are strategic.
- Use spoofing as a value add. Showing clients “here’s what’s fake, here’s what’s real” is a trust builder.
Why execution matters more than decks
In the AI search era, many SEO wins look like:
- Improving crawl efficiency and performance
- Fixing duplication and canonicalization
- Clarifying entities and structured data
- Strengthening content architecture so systems can retrieve the right page
Those require changes—not just insights. Which leads to AYSA.
Where AYSA fits: monitoring + approved execution, built for noisy reality
At AYSA, our view is simple: the modern web is too noisy for “look at this chart” SEO. You need a system that:
- Monitors what matters
- Prepares changes safely
- Gets human approval
- Executes correctly
1) Monitor: build a baseline you can trust
Start with monitoring that distinguishes signal from noise. This editorial is about bot verification, but the broader idea is consistent: create a baseline, track deltas, and don’t let spoofable metrics drive strategy.
AYSA’s monitoring is designed to support that “baseline first” mindset: AYSA Monitoring
2) Prepare: convert findings into safe, reviewable actions
When you identify problems (crawl traps, broken internal linking, inconsistent canonicals, messy faceted URLs, thin category pages), the next step is a concrete plan with changes that can be reviewed.
That’s the operating model behind AYSA’s tooling and workflows: AI SEO Tools
3) Approved execution: the missing layer in most “AI SEO” tools
Most automation fails because it either:
- Does nothing beyond recommendations, or
- Pushes changes without the approvals businesses need
AYSA’s model is: prepare → ask for approval → execute accepted website changes. That’s how you scale technical SEO and AI search readiness without shipping risky updates.
4) Visibility is not just Google anymore
If you’re building for AI answers, you’re building for multi-engine visibility—Google plus multiple assistants and retrieval systems. The strategy lives here: AI Search Visibility
5) Adoption needs to be practical
SMEs don’t need a 12-month transformation project. They need a plan they can start this week, with clear pricing and clear operational ownership: AYSA Pricing
For ongoing education and playbooks like this, see: AYSA Blog
What to do next (a step-by-step action list)
This is the part to forward internally.
Step 1: Decide what you’re trying to learn
- Are you trying to measure live demand fetches from assistants?
- Are you trying to measure retrieval eligibility (being crawled/indexed)?
- Are you trying to understand training exposure?
Don’t lump them together. Pick your question, then pick the right measurement.
Step 2: Pull logs and build a first baseline
- Collect 14–30 days of access logs.
- Filter requests by key bot user-agents you care about.
- Count requests, unique IPs, and URL paths hit.
Step 3: Verify with official IP ranges
- Use the official JSON endpoints (OpenAI, Anthropic, Perplexity, Google, Common Crawl) referenced above.
- Bucket into Verified / Spoofed / Unverifiable.
Step 4: Investigate “Unverifiable” intelligently
- Run reverse DNS checks where applicable.
- Perform IP ownership checks (WHOIS/ASN).
- Look at behavior: what paths were requested?
Step 5: Protect the site (without breaking legitimate crawling)
- Do not blanket-block based on user-agent alone.
- Consider rate limits and WAF rules that target suspicious patterns (credential/config probing).
- Ensure sensitive files are not accessible by design (this is basic hygiene, but it still gets missed).
Step 6: Separate “fetch” metrics from “outcome” metrics
- Track verified crawl trends as operational signals.
- Track AI visibility (mentions/citations) as strategic signals.
- Track revenue KPIs as the deciding layer.
Step 7: Build an execution loop
If verification shows legitimate crawling but outcomes aren’t improving, focus on execution:
- Improve information architecture so retrieval systems land on the right page.
- Strengthen entity clarity (consistent naming, structured data where appropriate).
- Reduce duplication so crawlers don’t waste budget on near-identical URLs.
- Ship changes via an approved workflow.
What to do next (quick checklist)
- Today: Pull 14 days of logs and quantify “AI assistant” + “Googlebot” user-agents.
- This week: Verify using official IP ranges; build Verified/Spoofed/Unverifiable breakdown.
- This week: Audit spoofed bot paths for security risk (sensitive file probes, admin probing).
- Next 30 days: Create outcome monitoring for AI mentions/citations, separate from crawls.
- Ongoing: Use a monitoring + approved execution system (like AYSA) to turn findings into safe site improvements.
Sources and further reading
- Search Engine Journal (Duane Forrester): 81.8% Of My ‘AI Assistant’ Traffic Was Fake. The Googlebot Number Was Worse
- OpenAI crawler verification (ChatGPT-User IP ranges): OpenAI ChatGPT User Bot JSON
- Anthropic crawler listing (Claude bots): Claude Crawling Bot JSON
- Perplexity crawler verification (Perplexity-User IP ranges): Perplexity User Bot JSON
- Google crawler IP ranges (common crawlers): Google Common Crawlers IP Ranges
- Common Crawl crawler IP ranges (CCBot): Common Crawl Bot JSON
Related AYSA resources
- AI search visibility (AEO/GEO readiness)
- AI SEO tools (turn insights into action)
- Monitoring (baselines, deltas, ongoing checks)
- Pricing (fit, scope, adoption)
- AYSA blog (playbooks and operating models)
Continue the AI search topic inside AYSA.
Use these pages to connect the article with AI SEO tools, AI visibility monitoring, AI Overviews and approved website execution.
Turn this topic into a website action plan.
Use these AYSA hubs to move from reading to technical fixes, AI visibility monitoring, research, glossary context and approval-first SEO execution.
