In July 2026, users discovered that using Google’s site search syntax could batch retrieve shared conversation records from Claude users. The reason was that Claude’s sharing feature generated public web pages rather than private links; although these pages had robots.txt protection, they lacked the critical noindex meta tag, causing search engines to index both the URLs and their content. The search results exposed sensitive information such as users’ cryptocurrency wallet keys and Social Security numbers. Anthropic has since urgently fixed the issue by adding the noindex tag to prevent further indexing. This is not an isolated case—OpenAI’s ChatGPT and xAI’s Grok previously experienced identical privacy vulnerabilities.

Author and source: Leiphone

From cryptocurrency private keys to personal identification information, Reddit is sparking a frenzy of snooping on others.

Embodied intelligence enters the greasy kitchen

A Robot's Work Diary Under a Million Visitors

Dr. Mu Wei, former Vice President of Covariant AI and CTO of Zhoupu Data, has been appointed CTO of ShuTu Technology.

The founding team has just been unveiled, and the company’s funding and shareholder lineup have also come to light.

Beta Infinity will target the trillion-dollar consumer robotics blue ocean market.

26 years for embodied intelligence is like 23 years for large language models.

On July 26, 2026, a Reddit user posted in the community that using the Google site search syntax site:claude.ai/share could retrieve tens of thousands of shared conversation records from Claude users.

After the user clicks the "Share" button in Claude, the system generates a public webpage that requires no login or identity verification, rather than a private link accessible only to specified recipients.

These pages are fundamentally no different from regular web pages on the internet and meet the conditions for being crawled and indexed by search engine spiders. Yet, the vast majority of users who have used the sharing feature have never received any related risk warnings.

The post quickly went viral on overseas social platforms, and controversy over the "share equals public" mechanism design continues to escalate, with a series of privacy leak cases emerging that far exceeded public expectations.

As more people joined the search, some highly dramatic cases were uncovered. Suddenly, searching through other users’ chat logs became a major pastime in the community. People sifted through others’ private messages, occasionally discussing and reflecting on them, all while enjoying the process.

Among the retrieved content, the risks associated with these two types of information are the most prominent.

One is cryptocurrency asset information. Some users found a wallet and password belonging to an individual. Following the chat logs, netizens located the corresponding wallet, which contained only $2.73. Even more ironically, well-intentioned netizens tried to alert the user about the leaked key but could not find any contact information in the entire conversation—this user may still be unaware that their wallet key has been exposed to the entire internet in this manner.

Second is core identity information. Users have confirmed that they found complete conversations containing Social Security Numbers (SSNs) in search results. If this type of information falls into the hands of cybercriminals, it could directly lead to identity theft, financial fraud, and other tangible harms.

In addition, the retrieved content includes various types of private information, such as project documents from verified professionals, legal consultation dialogues, personal resumes, and adult-oriented content. A large amount of private information intended for limited circulation has entered public search engine indexes without any barriers.

Why can't robots.txt prevent indexing?

After the incident escalated, attentive netizens dug up Claude's robots.txt file and found it clearly specified Disallow: /share/*, meaning crawlers were formally prohibited from accessing the /share path.

If there are clear rules, why was the conversation still indexed by search engines? This is the most critical technical detail of this incident.

To clarify this issue, first distinguish between two concepts: crawling and indexing:

• robots.txt is used to communicate with crawlers: do not actively scrape content from pages under this path. It can only prevent crawlers from actively fetching pages via internal website links, but it has no enforceable power and cannot prevent search engines from including the URL itself in search results.
• Search engines discover a link through another path: via external links from publicly accessible web pages. Whenever a user shares a Claude link on Reddit, X, public forums, GitHub documentation, or any other publicly accessible page that crawlers can reach, Google will discover the /share link when crawling that page.

Even if robots.txt blocks crawlers from reading the page content, Google will still include the URL in search results, just without displaying a snippet. The only way to completely prevent a page from appearing in search results is through the noindex meta tag in the page’s HTML, which directly instructs search engines not to index this page.

At the time of the incident, all of Claude’s shared pages were missing this critical noindex configuration. The platform relied solely on robots.txt for partial protection, lacking an effective anti-indexing mechanism. According to community users’ investigations, a similar minor indexing incident occurred with Claude in September 2025, when Google estimated that fewer than 600 conversations had been indexed and subsequently removed—but this did not prompt the platform to fully implement comprehensive protective configurations.

Another issue with this incident is: through what path did Google discover these share links composed of random UUIDs?

Some netizens have clearly pointed out that brute-forcing billions of character combinations is nearly impossible; the core pathway must be external links. The prevailing theory is that some users posted sharing links on public forums, social platforms, open-source project documentation, or other publicly accessible pages that web crawlers can reach, and Google discovered the corresponding /share links while crawling these pages.

Some netizens have suggested that Google’s communication products, such as Gmail and Google Chat, might be potential sources of the link. However, this claim remains a community speculation and is currently unsupported by evidence.

In response to this incident, Anthropic also implemented an emergency fix. Users tested and found that executing the site:claude.ai/share command now returns a "No matching documents found" result from Google. The general consensus is that the platform has urgently added noindex tags to all shared conversation pages to prevent further indexing.

However, fixes have inherent delays: caches from other search engines like Bing and Brave update on independent schedules, and previously crawled historical pages will not disappear immediately.

OpenAI and Grok's privacy oversights

In fact, this type of indexing configuration issue is not unique to Anthropic.

Several years ago, ChatGPT’s shared conversations feature experienced an identical privacy design flaw. After the incident, OpenAI hastily added a noindex configuration to the page and included a risk warning in the sharing popup, but the underlying design of the sharing mechanism remained unchanged.

Today, Anthropic is facing a similar issue, fundamentally because both leading vendors have adopted the same security design approach.

Grok, a competitor in the same space, also fell into the exact same trap. In 2025, hundreds of thousands of shared conversations on the Grok platform were bulk-collected by Google, sparking a privacy controversy of equal scale.

Following the incident, xAI implemented multi-layered preemptive defenses at the architectural level, such as forcibly adding noindex tags to all shared pages and simultaneously tightening the site-wide robots.txt crawling rules; both protections were deployed together, establishing clear restrictions at both the crawler scraping and result indexing stages.

The core advantage of this solution is that protection is built in upfront, rather than relying on users' habits for security. However, across the industry as a whole, the underlying design logic behind such issues has not been universally corrected.

How to address the shortcomings in index configuration and sharing design

The repeated occurrence of similar vulnerabilities on OpenAI and Anthropic has also prompted the community to reflect on industry-standard product design approaches.

The conversation sharing feature facilitates content dissemination and drives product growth, so manufacturers typically prioritize user experience; however, privacy protection measures such as reverse indexing and tiered permissions are often hastily implemented as temporary patches only after security incidents occur and public opinion escalates.

Many netizens have called for the platform to build a more comprehensive security system from the ground up. Most ordinary users do not understand web technologies like noindex or web crawler caching, making it difficult for them to recognize the risks hidden in shared links.

From a product technology perspective, the currently viable optimization approaches are relatively mature and cost-effective to implement. The most fundamental layer is to set noindex as the default configuration for sharing pages, thereby blocking search engine indexing at the source.

On this basis, risk can be further minimized through permission design, such as adding login verification, allowing users to set access passwords and custom expiration times for links, making the scope and duration of sharing more controllable.

Alongside the sharing action, provide a straightforward risk warning using plain language—clearly state that the link may be indexed by search engines, so users understand its public nature before clicking.

These adjustments do not require major changes to the product architecture but effectively bridge the gap between users' privacy expectations and the product's actual mechanisms.