Claude-User

Claude-User is one of three distinct automated agents Anthropic operates to access the public web, and it is directly tied to the Claude assistant rather than separate from it. Anthropic’s documentation describes it plainly: when someone asks Claude a question that requires information from a specific webpage, Claude may fetch that page in real time using the Claude-User agent. This applies whether the request comes through claude.ai directly or through a third-party product or autonomous agent built on the Claude API that gives Claude the ability to retrieve a URL on a user’s behalf — the same shared identity covers both surfaces.

This distinguishes Claude-User sharply from Anthropic’s other two agents. ClaudeBot performs broad, scheduled crawling to collect content that may contribute to future model training. Claude-SearchBot proactively indexes content to improve the quality of Claude’s search-style answers. Claude-User does neither of those things — it fetches a page only because a specific person’s specific question, in that moment, needed that specific page, and Anthropic states plainly that this traffic does not feed model training. Anthropic has been explicit that it does not currently publish IP ranges for any of its three agents, since its infrastructure runs on shared service-provider IP space rather than a dedicated, publishable range — a materially different verification posture than IP-list-backed crawlers, and one that shapes how site owners should (and shouldn’t) try to control this traffic. In DataDome’s taxonomy this sits with autonomous-agent traffic: automated, but triggered by and accountable to an individual user’s real-time request rather than running on a bulk or scheduled basis.

• Answering a user’s question about a specific page. The core function — a person asks Claude about a URL, a product page, a documentation article, or similar, and Claude-User fetches that exact page to inform the response.
• Supporting third-party agents built on the Claude API. Any application or autonomous agent that gives Claude the ability to retrieve a specific webpage in response to a user’s request uses this same agent identity, regardless of whether the end product is Anthropic’s own or a developer’s.
• User-directed web visibility. Anthropic states that allowing Claude-User access means a site’s content can be retrieved and referenced when a user specifically asks about it — a direct, attributable form of traffic distinct from passive indexing.
• Respecting crawl preferences per request. Because each fetch corresponds to an actual user query rather than a scheduled sweep, well-behaved Claude-User traffic should appear as targeted, sparse hits on specific pages rather than broad site traversal.

Because Anthropic does not publish IP ranges for this agent, and its traffic pattern (a single fetch of a specific URL) is simple to imitate, impersonation risk here centers on the absence of a network-level check rather than anything unusual about the agent’s own behavior:

• User-agent spoofing with no IP list to cross-reference. A scraper adopting the Claude-User string faces no additional verification barrier beyond the string itself, since there’s no published range to compare against — a materially weaker check than crawlers with documented IP infrastructure.
• Conflation with ClaudeBot for blocking decisions. Some third-party guidance incorrectly suggests IP-based blocking as a control for Anthropic’s agents; since Anthropic states plainly that it doesn’t publish IP ranges and that blocking by IP can interfere with its ability to read robots.txt at all, an IP-based rule aimed at this traffic is unreliable and can produce unpredictable results.
• Bulk scraping disguised as user-triggered fetches. Because Claude-User’s legitimate pattern is sparse and page-specific, a high volume of rapid, broad requests under this identity is inconsistent with genuine behavior and more likely spoofed or unrelated bulk activity.
• Confusing this agent with unrelated legacy tokens. Older, now-deprecated identifiers (Claude-Web, Anthropic-AI) sometimes still appear in third-party bot lists or in stale robots.txt configurations; treating them as equivalent to Claude-User can lead to misapplied rules.

Spoofed traffic under this identity cannot alter Claude’s own outputs or trigger any action inside Anthropic’s systems — the effect of impersonation is entirely local to the site receiving the traffic, typically noise in logs or a false read on how much genuine Claude-User activity a site is actually seeing.

If Claude-User is appearing in your logs, it means a real person asked Claude a question that required your specific page, and Claude fetched it to inform its answer. A few things worth understanding:

• Traffic is inherently sparse and request-driven. Unlike a scheduled crawler, there’s no baseline volume to expect — activity tracks how often users ask Claude about your specific content.
• It’s a positive visibility signal, not incidental traffic. Anthropic frames blocking this agent explicitly as a trade-off against being retrieved in response to real user-directed queries — allowing it is the mechanism by which a site’s content can surface in a live Claude answer.
• It doesn’t overlap with training or search indexing. A site can allow Claude-User for user-initiated fetches while still blocking ClaudeBot (training) or Claude-SearchBot (proactive indexing) independently, since each uses its own robots.txt token.
• No IP-based signal is available, by Anthropic’s own account — this shapes what “verification” can realistically mean for this specific agent.

1. Check the user-agent string. The documented value is Claude-User/1.0 with a contact reference, appearing within a broader browser-like string: Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Claude-User/1.0; +Claude-User@anthropic.com).
2. Do not attempt IP-based verification or blocking. Anthropic’s own documentation states it does not currently publish IP ranges for this agent, and explicitly warns that blocking by IP address may not work correctly or persistently, since doing so can also interfere with the bot’s ability to read your robots.txt file.
3. Evaluate request pattern against the documented behavior. Genuine Claude-User traffic should look like isolated, specific-page fetches correlated with plausible user interest, not broad or repeated traversal of a site.
4. Distinguish it from Anthropic’s other two agents by token, not by inference. ClaudeBot, Claude-User, and Claude-SearchBot are separate, independently controllable identities — a hit under one doesn’t imply anything about the others.
5. Watch for deprecated identifiers. Claude-Web and Anthropic-AI are legacy tokens no longer used by current Anthropic infrastructure; treat any current traffic under those strings with more scrutiny, not less.
6. Report suspected malfunctioning or spoofed traffic to Anthropic directly. Anthropic’s support article provides a contact channel for exactly this purpose and asks that reports come from an email tied to the domain in question, so the report itself can be verified.

Blocking Claude-User is a direct trade-off against your content being retrievable when a real user asks Claude about it — Anthropic states this outcome explicitly rather than leaving it implied. Reasonable grounds to restrict it include:

• the site owner does not want any content surfaced through Claude in response to user queries, regardless of the training/search distinction;
• the site distinguishes between allowing Claude-User (user-initiated visibility) while still blocking ClaudeBot (training data collection) — a common and fully supported split, not a reason to block all three together;
• observed traffic under this identity shows a pattern inconsistent with sparse, query-driven fetching, suggesting spoofed or unrelated bulk activity rather than genuine Claude-User behavior; or
• specific paths (account areas, checkout flows, admin sections) should never be fetched regardless of the requester’s identity.

Because there’s no IP range to enforce a block against, robots.txt is effectively the only reliable control Anthropic itself endorses for this agent — and Anthropic is explicit that circumventing it via IP blocking risks breaking robots.txt readability entirely, undermining even the block you’re trying to set.

• Use robots.txt as the primary and only reliable control, applied per subdomain:

User-agent: Claude-User
Disallow: /

• Scope by path if you want partial access, allowing general content while excluding sensitive areas:

User-agent: Claude-User
Disallow: /account/
Disallow: /checkout/
Allow: /

• Use Crawl-delay if rate is the concern rather than access itself, since Anthropic documents support for this non-standard directive:

User-agent: Claude-User
Crawl-delay: 1

• Do not rely on IP-based rules. Per Anthropic’s own guidance, this can fail to reliably block the agent and may prevent Anthropic’s systems from reading your robots.txt file at all — undermining the control you’re trying to establish.
• Set the rule independently from ClaudeBot and Claude-SearchBot if your goal is nuanced — for example, allowing user-initiated visibility while opting out of training data collection.
• Report unexpected or malfunctioning traffic directly to Anthropic through the channel in its support documentation rather than assuming every hit under this string is necessarily genuine.

Claude-User should be understood as a real-time, user-triggered fetch tied directly to an individual’s question to Claude — not bulk crawling, and not unrelated to the assistant itself. Because Anthropic does not publish IP ranges for this agent, network-level verification isn’t available, and any control decision has to rest on robots.txt compliance and behavioral pattern (sparse, page-specific fetches) rather than a source-IP match. Sites that want granular control can safely allow Claude-User while blocking ClaudeBot and Claude-SearchBot independently, since Anthropic treats all three as separately addressable identities.