Shared Claude conversations and Artifacts turned up in Google and Bing search results over the weekend of July 25–26, 2026, readable by anyone who found the link, no login required. The cause was not a breach: sharing is user-initiated. For the shared-conversation URLs, a robots.txt rule blocks the very fetch a compliant crawler needs in order to read the noindex header on those pages, and as of our July 29 check it still does.
How Disallow and Noindex Cancelled Each Other Out
We fetched the evidence ourselves on July 29. claude.ai/robots.txt lists, under User-Agent: *, a line reading Disallow: /share/*. Requesting claude.ai/share/<id> returns HTTP 200 with x-robots-tag: none, Google’s equivalent of noindex, nofollow. Both instructions sit on the same URL pattern, cancelling each other out.
Disallow tells a compliant crawler not to request the page, so it never reads the noindex header sitting on it. A URL discovered through an external link can still enter the index, built from the link and its context rather than a fetch. Search Engine Journal reported the same conflict on July 27, quoting Google’s John Mueller: “even pages blocked by robots.txt can appear in search results if other pages link to them.”
Why the Same URL Can Answer Differently
The share-page response also carries vary: User-Agent, so the server can hand different content to different callers on the same URL. Checking headers in a browser is not checking what Googlebot received; verification requires requesting the page with the crawler’s own user agent. On July 25 a Reddit user posted that site:claude.ai/share surfaced numerous publicly accessible conversations. VentureBeat independently verified that multiple third-party Claude Artifacts appeared in Google Search results and were accessible without authentication.
Why doesn’t noindex work with a robots.txt disallow?
A robots.txt line reading Disallow: /share/* tells a compliant crawler not to fetch matching URLs at all. The x-robots-tag: none header on those same pages only takes effect if the crawler retrieves the page and reads it, and Disallow prevents exactly that retrieval. If another page links to the URL, it can still enter the index from the link alone, with the noindex instruction never delivered.
| Directive | What the crawler does | What ends up in the index |
|---|---|---|
robots.txt Disallow: /share/* |
Skips fetching the URL entirely | URL can still appear, sourced from external links, no page content read |
x-robots-tag: none on the page |
Would drop the URL from the index, if read | Nothing changes; the header is never delivered |
| Both set on the same URL, as shipped here | Obeys Disallow, never requests the page | URL can be indexed from link signals alone; noindex is inert |
The fix is sequence, not more directives: allow the crawl, let the crawler read the noindex, confirm removal, then reintroduce any Disallow.
The Governance Reading: Vendor Hygiene Is Not a Control
Sharing here was user-initiated: as reported by VentureBeat, cybernews, TNW and AI Weekly, indexed pages reportedly included a patient’s medical report, clinical trial results with patient names, documents naming children, employee reviews, internal company files, and, per other outlets, access codes, resumes and API keys. We confirmed only the robots.txt and header state, not page content; this attribution should be read accordingly.
The analytics-world equivalent is a customer export, a raw GA4 table, or client PII pasted into an LLM before someone clicks share. The control is not trusting a vendor’s noindex to hold; it is a written policy that an LLM share link is a permanently public URL the moment it exists. That is closer to treating crawler access as a negotiated, auditable resource, the shift already underway in Cloudflare and beehiiv’s crawler-control tooling, than to assuming an unread header will do the job.
Our Reading: A Pattern, Not an Accident, and a Limit on the Fix
In our reading, this is the second time in about a year the same failure mode has surfaced: a share feature ships as a growth surface first, a privacy surface second. Forbes reported an earlier episode where Google estimated just under 600 conversations indexed before removal; that figure belongs to the earlier incident only, with no comparable count here. Anthropic told TechCrunch that share links surface in search only when posted somewhere crawlers can already reach, and that private-message links are not indexed, a statement that neither admits nor denies the header conflict.
Google began removing results by July 26; nothing published shows removal is complete, and nothing is known about Bing’s handling of the same URLs. De-indexing removes a page from a search index, not from the web, and whether other copies exist is an open question this record does not answer. The dynamic mirrors the publisher side, where sites weighing an opt-out from Google’s index have learned that crawler control is not index control, the same gap running in reverse. No regulator inquiry, complaint, victim or lawsuit has been reported here.