Every AI share link is a public web page

You worked through a client proposal with Claude, and you want your co-founder to read the thread rather than a summary of it. There is a share button. You click it, a URL lands on your clipboard, you paste it into a direct message. That action feels like emailing a document to one named person. It is not. You published a page on the open web and then told one person the address.

Most of the time nothing happens, which is why the habit spreads. The failure, when it comes, is not a break-in. Nobody guesses your URL. Somebody pastes it into a ticket, a public issue tracker, a Discord server or a support thread, a crawler follows the link, and a conversation you thought of as private acquires a search result. This guide is for solo operators and small teams who use share links casually, several times a week, on free or paid consumer accounts. If you run your own site and are deciding how to serve noindex headers on your own pages, or you administer an enterprise tenant with data-loss tooling, you need a different reference than this one.

A share link authenticates nothing

The share features in the tools most people use describe themselves in similar terms, and it is worth reading their own words rather than the mental model you brought to the button. Claude’s documentation says that anyone with the link can view the chat snapshot [4]. Gemini’s help page is blunter: “Anyone with the link can read the chat, even if you didn’t share the link with them directly” [6]. OpenAI’s shared links FAQ makes the concession explicit, noting that shared link pages are “not intended for search-engine indexing, but this does not make a link private” [5].

Notice what none of them describe. There is no check on who is holding the URL, and no account is required at the other end [6]. The link stays live until you turn it off, which is the only event any of the three vendors describes as ending access [4][5][6]. The unguessable string in the address is the whole of the security model, and a secret that is designed to be copied and pasted is a secret with a short half-life. Your recipient forwards it to a colleague. The colleague pastes it into a shared document. Somebody quotes the document in a public forum. At each step the URL is doing exactly what URLs do, and at no step does the AI vendor learn that the audience has changed.

robots.txt was never the lock you assumed it was

The reassurance people reach for is that search engines have been told to stay away from these pages. Even where that instruction exists, it misreads what robots.txt is. RFC 9309, the Standards Track document that specifies the Robots Exclusion Protocol, states plainly that its rules “are not a form of access authorization”, and its security section adds that the protocol “is not a substitute for valid content security measures” and that “listing paths in the robots.txt file exposes them publicly and thus makes the paths discoverable” [3]. It is a sign on a door, not a lock, and the sign lists the rooms.

Google says the same thing in its own operating documentation, in a warning box: “Don’t use a robots.txt file as a means to hide your web pages … from Google Search results” [1]. The mechanism is spelled out immediately after. Google “won’t crawl or index the content blocked by a robots.txt file”, but “might still find and index a disallowed URL if it is linked from other places on the web”, so the address and the anchor text pointing at it can still appear in results [1]. Disallowing a path suppresses crawling of the content, not the appearance of the address.

The instruction that actually removes a page is noindex, delivered either as <meta name="robots" content="noindex"> in the page’s HTML or as an X-Robots-Tag: noindex HTTP header [2]. When Googlebot reads that rule, Google drops the page “entirely from Google Search results, regardless of whether other sites link to it” [2]. There is a trap in the combination, and it catches real engineering teams: if robots.txt blocks the page, “the crawler will never see the noindex rule, and the page can still appear in search results” [2]. Belt and braces do not stack here. The belt hides the braces.

What each tool actually does in September 2026

Claude shares a snapshot rather than a live feed. Messages sent before you shared are in the snapshot, all messages sent afterwards “remain private by default”, and the snapshot only updates if you unshare the chat and share it again [4]. A file you attached “is not included in the shared snapshot and remains private”, and raw data retrieved from MCP tool calls stays hidden too [4]. Plan matters more than most people realize: users on Team and Enterprise plans can only share chats with other members of the same organization, not publicly, which is a restriction the documentation applies to those plans alone [4]. To revoke, change the chat from Public to Private to disable the direct link, or go to Settings, then Privacy, then Shared chats [4].

ChatGPT keeps a list of every link you have generated, under Settings, then Data controls, then Shared links, then Manage, where you can delete an individual link or use the delete-all option under More actions [5]. Deleting the original conversation removes its shared link as well [5]. The FAQ is careful about the limit: deleting a shared link “stops future access to that link”, but “does not remove a conversation or task another person already saved” [5].

Gemini generates links on the g.co/gemini/share domain, which you can paste anywhere [6]. The public links you have created are listed under Settings, then “Your public links”, with a delete control on each one and a “Delete all links” option [6]. Once a link is deleted, anyone who tries to open it is told the chat no longer exists and sent to gemini.google.com [6]. Google’s own guidance on the same page is the plainest sentence any of these vendors has written on the subject: “do not enter confidential information in your conversations or any data you wouldn’t want a reviewer to see” [6].

Unsharing is a stop, not an undo

Every revoke control described above stops future visits. None of them reaches backwards. The recipient who already opened the page has the text on their screen and, quite possibly, in a copy that no longer depends on your link at all, a limit OpenAI states directly for its own product [5]. A search engine that already indexed the page has its own record, and the vendor’s control panel has no authority over that index.

That is the gap the July 2026 episode sat in. Cybernews reported on 27 July 2026 that Claude conversations shared with the “anyone with a link” option, including their artifacts, were turning up in Google results, and that the exposed material included résumés carrying real names and contact details, API keys and cryptocurrency wallet credentials, financial and tax records, and clinical trial records naming patients [8]. The report frames it as an avoidable privacy flaw rather than a breach, and the criticism it quotes is that a product minting one-click public links “should default those routes to no-index” [8]. Every one of those pages was already published, by an ordinary user pressing an ordinary button, and the only surprise was that a crawler had done the thing crawlers do.

Treat that as the general case rather than one vendor’s mistake, because the mechanism belongs to the web and not to any model. Any product that mints public URLs and relies on a robots rule to keep them quiet has the same exposure sitting in it, waiting for a link to escape [1][3].

Auditing the links you already made

Open each tool you use and read its list of live links, which is a specific screen in all three products: Settings, then Privacy, then Shared chats in Claude [4]; Settings, then Data controls, then Shared links in ChatGPT [5]; and “Your public links” under Settings in Gemini [6]. That panel is the only running log of what you have shared, because a share link leaves no marker in the conversation once it scrolls out of view. Delete everything whose purpose has passed. ChatGPT and Gemini both offer a delete-all control if the list is long [5][6].

Then check whether anything already escaped. Search your own name, your business name and your product names in Google, and repeat with each vendor’s share domain in a site: query. This finds the specific failure that robots rules cannot prevent, the page that got indexed because somebody linked to it from a crawlable place [1]. Do it once now and once a quarter, and add it to the exit routine when a contractor or an employee leaves, alongside revoking their accounts.

Getting a page out of Google once it is indexed

If the page is one you can control, remove the cause first. Google’s guidance on removals lists 3 durable options: remove or update the content, password-protect the page, or add a noindex tag [7]. For an AI share link you have exactly one of those levers, which is deleting the share so the page stops existing [4][5][6]. Do that before anything else, because the rest is cosmetic without it.

Google’s Removals tool speeds up the disappearance rather than causing it, and its effect expires: requests made in the Removals tool last about 6 months [7]. If the underlying page is still live when that window closes, the result can come back. Where the page is not on a site you control, which is the case for every AI vendor’s share domain, Google directs you to its separate process for removing personal information from Google rather than the site-owner tool [7]. Start that the same day you find the problem rather than the week after.

What still goes wrong

The controls in this guide manage links you created and remember. They do nothing about the copies. Once a page has been open in someone’s browser it can be saved, screenshotted, quoted or archived by parties who have no relationship with you or the vendor, and OpenAI says as much about its own shared links [5]. Removal is therefore best understood as reducing further circulation, not as retrieval. Anything genuinely sensitive should never have entered a shareable surface, which is why Google’s instruction not to put confidential information into these conversations in the first place is the only advice on this page that fully works [6].

The vendor behaviour described here is also a snapshot of September 2026. Sharing rules change with plans and product releases, and the plan-level restriction in Claude, where Team and Enterprise accounts cannot share publicly [4], is exactly the kind of detail that shifts. Read the linked support pages before you rely on any specific claim above, and re-check them when you change plan or move a team onto a new tier.

Finally, the audit only covers the tools you thought to check. The same mechanism applies wherever a product offers to turn something you made into a URL for someone else, and the settings panels in this guide cover 3 products out of however many you use in a week. The habit that protects you is not a list of settings. It is treating the share button as a publish button, every time, in every tool.