Sharing a chat creates a snapshot anyone with the link can open. Unsharing disables that link. Neither of those is the same as 'not indexable', and the difference caught a lot of careful people in July 2026. Here's the mechanism, where to check your own shares, and when you need noindex to be a property of the link itself.
Sharing a Claude chat is a good feature. You click Share, you get a link, and someone who isn't in your account can read what you built. For a demo, a teaching example, or a portfolio piece, that's the shortest path there is.
It's also worth understanding precisely, because in July 2026 a lot of careful people discovered their mental model was off by one step. Not about whether sharing makes something public — everyone knew that — but about what happens afterwards, and about the gap between "the link is off" and "it isn't in a search index."
That gap is the subject here.
Anthropic's help article, Share and unshare chats, is short and worth reading in full. The load-bearing sentences:
The chat snapshot includes all messages that were sent prior to sharing the chat, including any artifacts. All messages sent after sharing a chat will remain private by default.
So a share is a photograph, not a window. Keep talking to Claude in that conversation and your visitor doesn't see it — unless you unshare and share again, which updates the snapshot.
Two further details deserve more credit than they usually get. If you uploaded a file into the conversation, the documentation says the file itself is not included in the shared snapshot and remains private. And raw data retrieved from MCP tool calls stays hidden in the snapshot too. Both of those are cases where the obvious implementation would have been to include everything, and the decision went the other way. That's the kind of default that quietly prevents a lot of accidents.
Anthropic documents a log of it for free, Pro, and Max plans: Settings → Privacy → the Privacy settings section → Manage next to Shared chats. The modal lists each shared chat's title, the date you shared it, and the link, with an Unshare on each row. (Team and Enterprise organisations have separate sharing mechanics — worth checking the current article rather than assuming the same route.)
Open it once. Not because something is wrong, but because sharing is a small action taken in the middle of doing something else — a demo, a question in a group chat, a "look at this" six months ago — and a list is the only reliable way to know what's out there. Almost everyone who checks finds at least one they'd forgotten.
Unsharing revokes access to the snapshot you shared. The link stops serving the content. That part is clean and immediate.
What it doesn't do is reach anything outside Anthropic's system:
None of that is unusual. It's true of every share link on the internet, including ours. It's just easy to assume that pressing "unshare" wound the clock back further than it did.
Here's the genuinely useful part, and it's a technical lesson rather than a story about anyone.
In late July 2026 it emerged that a number of publicly shared Claude conversations were turning up in Google results. Search Engine Journal's write-up — titled, accurately, Indexed Claude Chats Show Why Disallow Is Not Noindex — reports the cause as two directives on the same URLs: robots.txt disallowed the share path, while the pages themselves served an x-robots-tag header meaning noindex.
That looks like belt and braces. It isn't. It's belt instead of braces, because the belt hides the braces.
Google's own documentation states it plainly:
For the
noindexrule to be effective, the page or resource must not be blocked by a robots.txt file, and it has to be otherwise accessible to the crawler.
And the consequence:
If the page is blocked by a robots.txt file or the crawler can't access the page, the crawler will never see the
noindexrule, and the page can still appear in search results, for example if other pages link to it.
Read those twice, because the rule inverts the intuition almost everyone starts with. To reliably keep a page out of search results, you have to let the crawler in. Blocking it doesn't strengthen the noindex — it makes the noindex unreadable, leaving Google with a URL it discovered through an external link and no instruction attached to it.
Anthropic's clarification in the coverage is also fair and worth repeating: share links become discoverable when they're posted somewhere publicly accessible, which is how a crawler finds the URL in the first place. A private link that nobody publishes is a different situation from one pasted into a public forum. And the fix on Anthropic's side landed quickly.
The reason to learn this isn't to score a point. It's that the same trap is sitting in a lot of robots.txt files right now, including on plenty of sites whose owners believe they've locked something down twice.
When the work is a deliverable rather than a demo, export the artifact and host it on a link that carries its own controls — noindex by default, password and expiry when you need them.
Everything above is about a share whose purpose is reach. If the purpose is delivery — one client, one review window, work that isn't public yet — then "not in search results" needs to be a property of the link from the moment it exists, not a setting you remember to check.
That's the choice we made deliberately, and it's the same one Google's documentation points at. The viewing domain's robots.txt says Allow: / — crawlers are welcome to fetch. Every document then carries the instruction where a crawler will actually read it: a noindex meta tag in the page and an X-Robots-Tag: noindex, nofollow, noarchive, nosnippet header on the response. Blocking the crawler would have been the more intuitive design and the less reliable one.
The unguessable URL does the other half of the job: there's no directory, no gallery, and nothing that links to your document, so there's no external link for a crawler to discover in the first place.
And when a document genuinely should be findable — a lead magnet, a public one-pager — that's an explicit per-document opt-in rather than a global setting, which is a distinction worth its own discussion.
noindex is not privacy. It is an instruction to search engines and nothing more. Anyone holding the URL can still open it. If the requirement is "only these people," the tools for that are a password you can change and an expiry you set when you send — controls aimed at humans, not at crawlers. Most real delivery situations want both layers, and it's worth being clear with yourself about which one you're actually relying on.
And Claude's share feature is the right tool for its job. For a public demo, a technique you're teaching, a conversation you want to link from a post — share the chat. It's faster than anything else and the reach is the entire point. Anthropic's controls for reviewing and revoking those shares are documented and easy to reach, which is more than a lot of share features offer.
The distinction to hold is just: am I publishing, or am I delivering? Publishing wants reach and Claude does it in one click. Delivering wants controls, and that's a different route worth setting up once.
Check your shared-chats list either way. It takes a minute, and it's the only way to answer the question in the title for your own account.
Grok's share button makes a public link, and xAI says plainly it can be indexed by a search engine. On Grok Business the same button does close to the opposite. Here's what the person on the other end receives, and the page where you revoke it.
Anthropic's docs are explicit: on Free, Pro and Max, publishing makes an artifact publicly available to anyone with the link. Org-only sharing is a Team and Enterprise feature. Here's what that means if you're an individual sending work to one named client.
Most expiry windows get set by guess — 7 days because that's the default, 'never' because that's reversible. The actual fit comes from matching the window to what the content references.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.