Public by Link Should Not Mean Searchable: A Founder Visibility Contract for AI Sharing

Claude share pages appeared in Google and Bing results this week. The evidence does not show that private-by-default chats were extracted from Anthropic's internal database or that random share URLs were guessed. The affected material had been made accessible through public links, and some links had become discoverable to search engines. The incident matters because many users understand “anyone with the link” as a narrow handoff to a client, teammate, or friend—not as permission to create a searchable publication.

That gap is now a product decision for every AI app builder that lets users share a conversation, report, agent run, prototype, dashboard, recording, or generated document. An unguessable URL can reduce accidental discovery, but it is still a bearer credential: whoever receives it can open it, forward it, paste it into a public page, or expose it through another system. Search indexing is only one amplification path.

For nontechnical founders and small teams, the launch question is therefore not “Do we have a Share button?” It is: Does the product make the intended audience, discovery paths, included content, lifetime, revocation limits, and verification evidence clear before a user creates the link?

This guide provides a four-state visibility model, a reusable visibility contract, a share-screen design, a fictional customer-research scenario, five launch tests, an incident-removal receipt, and boundaries for when link-only sharing is appropriate. It does not claim that every indexed Claude page contained genuine information, that every search engine behaves identically, or that noindex makes sensitive content private.

What the Claude indexing event establishes—and what remains unknown

Anthropic's official chat-sharing guide says chats are private by default. When a user creates a shared snapshot, anyone with the link can view all messages sent before sharing, including Artifacts; later messages remain private unless the chat is unshared and shared again. Free, Pro, and Max users can review and revoke shared chats in Privacy settings. Team and Enterprise chat sharing is restricted to the organization.

That product description establishes the intended access rule. It does not answer the separate discovery question: how could a person who was never sent the link find it?

The bounded conclusion is:

• Some user-created public-link content became searchable.
• A page can be reachable without being listed in a publisher's sitemap.
• Blocking crawler access in robots.txt is not the same control as requesting that a reachable page stay out of an index.
• A user who intentionally creates a link may still misunderstand how broadly that link can travel.

Define four visibility states instead of one “public” switch

Most share-link failures begin in the data model, not the warning copy. A single boolean such as isPublic forces several different user intentions into one state.

Use four explicit states:

“Public by link” is sometimes called unlisted sharing. The term should describe discoverability, not promise secrecy. A link can escape through a recipient, a public forum, browser history, screenshots, analytics, referrer data, a preview bot, or an integrated service. It is less discoverable than a listed page, but it is not access-controlled in the same way as authentication.

The distinction between public and publicized is not merely wordplay. Google researchers' paper Public vs. Publicized describes evidence that people may not expect technically public content to be amplified beyond the narrow context where they disclosed it. Product copy should account for that mental model rather than assuming a user understands web infrastructure.

Make the state name visible on the share screen, on the shared page, in the owner's content list, and in audit records. If the backend stores only “public,” better microcopy cannot recover the lost intent.

Understand what a capability URL can and cannot protect

A capability URL is a URL whose possession grants access to a resource. The unguessable token in the path acts like a bearer credential. This pattern is useful because a recipient can open a resource without creating an account, but the security boundary is the link itself.

The W3C's Good Practices for Capability URLs recommends HTTPS, expiration where appropriate, revocation, unguessable identifiers, safe referrer behavior, and clear explanations of what recipients can do. It also asks product teams to consider whether account-based access would be more appropriate. An unguessable identifier helps prevent enumeration; it does not prevent a legitimate recipient from forwarding the URL or a third-party system from storing it.

Treat these as separate controls:

• Token entropy reduces guessing and enumeration.
• Authentication proves something about the viewer.
• Authorization checks whether that viewer may access this resource.
• Expiration limits the future lifetime of a link.
• Revocation stops the origin from serving the resource through that link.
• noindex asks supporting search engines not to show the page in results.
• Removal requests accelerate cleanup after an index already contains a URL.
• Data minimization reduces the harm if every other control fails.

Build a visibility contract before you build the share dialog

The reusable artifact for this launch is a visibility contract. Complete one row for each shareable object type, because a public prompt snapshot and an interactive app with persistent storage do not carry the same risk.

The contract separates a product promise from an implementation detail. A founder can decide, for example: “Research reports are public by link for seven days; they contain only the rendered answer and citations; uploaded interview transcripts are excluded; viewers may view and download but not write; pages carry noindex; owners can revoke; revocation returns 410; and the product warns that recipients may copy the content.”

Engineering can then map that statement to database fields, middleware, response headers, storage, UI, logs, and tests. If the team cannot complete the contract in plain language, it is too early to generate a public URL.

Design the share moment as a publication decision

The final click should summarize the effect, not hide it behind a generic confirmation.

A useful share panel has six parts:

1. Name the state. Use “Restricted,” “Anyone with the link,” or “Publish to the web.” Do not use the same button label for all three.
2. Show the audience in one sentence. For link-only access: “Anyone who receives this link can view and forward this snapshot. It will not require sign-in.”
3. Preview the exact payload. Show the included turns, generated files, Artifact version, title, author identity, comments, data source labels, and interactive storage behavior. Let the user remove items.
4. Show discovery separately. State whether the product will add the page to a profile, directory, gallery, sitemap, recommendation surface, or search-eligible publication feed.
5. Choose lifetime and power. Provide expiry where the use case permits it, and distinguish view from download, remix, execution, commenting, or shared writes.
6. Explain revocation honestly. “Revoking stops this link at our service. It cannot delete copies already downloaded, imported, screenshotted, embedded, indexed, or archived elsewhere.”

W3C's Privacy Principles supports this approach: relevant explanations should appear in context and in plain language; withdrawal should be as easy as granting consent; services should consider audience norms and users' expectations; and one person's decision to share data about others does not imply those other people consented.

Apply a content boundary before creating any public URL

AI conversations are unusually risky share objects because one screen may blend user prompts, model output, retrieved documents, tool results, filenames, customer names, hidden instructions, and generated code. “The attachment itself is excluded” does not mean the conversation contains no attachment-derived information.

Use a pre-share boundary with three results:

• Block: credentials, authentication links, private keys, payment data, raw health records, children's data, protected legal material, nonpublic security findings, or content the product cannot lawfully disclose.
• Require review: customer names, employment material, contracts, unpublished strategy, source code, location, private contact information, screenshots, retrieved snippets, or content about another person.
• Allow with preview: synthetic examples, public documentation, deliberately public templates, sanitized demos, or content the owner is authorized to publish.

For interactive AI output, also inspect behavior:

• Does the Artifact call external services when opened?
• Can it reveal prompts or embedded configuration?
• Does it use shared persistent storage?
• Can one viewer see another viewer's writes?
• Can a recipient cause billable model or tool calls?
• Can viewers upload data that becomes visible to others?

Treat search controls as defense in depth, not privacy

If a page is intended to be public by link but not searchable, send a page-level directive:

HTTP/1.1 200 OK
X-Robots-Tag: noindex, nofollow
Cache-Control: private, no-store
Referrer-Policy: no-referrer

For HTML, the product can also place in the document head. Use an HTTP header for non-HTML outputs such as PDFs.

Google's official [noindex documentation](https://developers.google.com/search/docs/crawling-indexing/block-indexing) says the crawler must be allowed to fetch the page in order to see a meta tag or X-Robots-Tag. If robots.txt blocks the URL, Google may never see noindex, and the URL can still appear based on links elsewhere. This creates a counterintuitive implementation rule: do not rely on robots.txt alone for link-only HTML pages, and test the response that crawlers actually receive.

The header bundle above has different jobs. noindex addresses cooperating search indexes. nofollow reduces link-following signals but does not protect the page. no-store asks compliant caches not to store the response; it does not erase recipients' copies. no-referrer reduces leakage of the capability URL through outgoing navigation; it does not prevent deliberate forwarding.

None of these makes sensitive content private. Google's content-control guidance says confidential content should be password-protected. For higher-risk objects, require authentication and authorization, then add the headers as secondary protection.

A concrete scenario: sharing customer-research synthesis

Imagine a three-person startup using an AI app builder to create a customer-research assistant. It imports interview transcripts, groups objections, and produces a visual synthesis for a product adviser. The founder clicks “Share,” copies a link, and sends it in a private message.

The generated page does not include the uploaded audio files. It does include direct quotes, participant first names, employer names, pricing objections, and a generated “churn risk” table. The URL is unguessable and no profile lists it. The page has no expiry, no noindex, and no clear content preview. The adviser later pastes the link into a public community thread to provide context for a question. A search crawler discovers the thread and indexes the report.

This is not a story about an attacker guessing a token. Each actor performed an understandable action under a different mental model:

• The founder thought “share with adviser.”
• The product implemented “anonymous bearer link forever.”
• The adviser thought “link I can cite.”
• The search engine saw “reachable page linked from public web.”

For a public case study, the product creates a different object: anonymized findings, consent-confirmed quotes, no raw transcript access, a publication title and canonical URL, and explicit opt-in to search discovery. One source workspace can support both outcomes, but they must not share the same state or button.

Run five launch tests against the promise

Do not approve sharing from a screenshot. Test the complete visibility contract with synthetic content and a second account.

1. Audience test

Create one object in each supported state. Verify signed-out, unauthorized, invited, organization, and owner behavior. Attempt access after role removal. Test object IDs that differ by one character to detect enumeration. Confirm that viewer powers match the contract.

2. Payload test

Create a conversation containing a synthetic attachment, tool result, hidden instruction, identifier, comment, and later message. Share it. Compare the rendered page and network responses with the preview. Confirm which version updates, whether attachments can be downloaded, and whether later turns remain excluded.

3. Discovery test

Inspect HTML and headers as a crawler would. Confirm noindex is present on every public-by-link format, absent only for explicit publication, and not hidden behind authentication or client-side code that a crawler cannot evaluate. Verify the link is absent from sitemaps, public profiles, galleries, feeds, analytics dashboards, error messages, and generated social metadata unless the user chose publication.

4. Leakage test

Open the page and inspect third-party requests, embeds, preview generation, outgoing links, referrer behavior, logs, support tooling, and analytics. The share token should not be sent as a query parameter or event property. Confirm that a viewer cannot cause one tenant's data to appear in another tenant's page.

5. Revocation test

Revoke the link. Verify the origin immediately returns 404 or 410, embeds stop loading, stored viewer sessions do not preserve access, and the object disappears from the owner's active-share list. Then recreate a link and confirm it uses a different token. Record the limits: a downloaded, imported, screenshotted, or independently archived copy may survive.

The launch gate passes only when the implementation matches the words shown to the user. A noindex tag without a payload preview, or an expiry selector without server enforcement, is not a pass.

Use an incident-removal receipt when a link escapes

Revocation is the first response, not the whole response. Use a short incident receipt so the team can prove what it contained and what was removed.

Google's removal documentation says a temporary Search Console removal lasts about six months. Permanent prevention requires removing or updating the content, password-protecting it, or serving noindex; the documentation also warns that noindex does not stop direct access or search engines that do not support it. Check other search engines separately.

If the content included credentials, revoke them. If it included personal or customer data, involve the appropriate privacy, security, legal, and customer owners. Do not describe an indexed link as contained until the origin is closed, material search results are rechecked, and known downstream copies are addressed or explicitly recorded as unresolved.

Avoid the six most common misreadings

Know where link-only sharing fits—and where it does not

Public-by-link sharing is a reasonable default when the content is low sensitivity, the recipient should not need an account, the owner understands forwarding risk, the payload is minimized, and expiration or revocation limits the exposure.

Prefer restricted authenticated sharing when the object contains customer data, internal strategy, source code, identity, health, financial, employment, children's, legal, security, or regulated material; when viewer identity matters; when actions or shared writes are possible; or when access must be audited per person.

Prefer explicit publication when discovery is the goal: public templates, galleries, educational examples, documentation, portfolios, or community resources. Publication should have its own preview, content policy, moderation path, canonical URL, metadata, search controls, author choice, and durable deletion process.

Some products should not share the AI conversation at all. Export a redacted answer, a signed report, a static image, or a new sanitized object instead. If the value is the result rather than the raw reasoning path, minimizing the share object often creates a clearer and safer product.

This framework is not a substitute for qualified privacy, security, legal, accessibility, child-safety, employment, health, financial, or regulatory review. The right control depends on the data, audience, jurisdiction, product promise, and consequences of exposure.

A 48-hour founder checklist

• Inventory every object that can create a link.
• Assign each object to private, restricted, public-by-link, or published.
• Disable sharing for any object whose audience or payload is unknown.
• Add a payload preview and a plain-language audience statement.
• Confirm the owner can list and revoke every active link.

• Complete the visibility contract for each shareable object.
• Add noindex and appropriate cache/referrer controls to public-by-link responses.
• Add expiry and token rotation where the use case supports them.
• Run audience, payload, discovery, leakage, and revocation tests.
• Create the incident-removal receipt and name its owner.

• Require authentication for sensitive or identity-dependent sharing.
• Verify published objects are the only share objects eligible for deliberate search discovery.
• Test with a second tenant, a signed-out browser, and real production headers.
• Review old links after product changes; do not assume a new default updates existing objects.
• Re-run the gate whenever attachments, tools, persistent storage, embeds, remixing, or viewer actions are added.

References

1. Anthropic: Share and unshare chats
2. Anthropic: Publish and share Artifacts
3. WIRED: Private Claude chats exposed in Google and Bing search results
4. Axios: Google search is indexing public Claude Artifacts
5. [Google Search Central: Block Search indexing with noindex](https://developers.google.com/search/docs/crawling-indexing/block-indexing)
6. Google Search Central: Remove your site information from Google
7. Google Search Central: Control what you share with Google
8. W3C: Good Practices for Capability URLs
9. W3C: Privacy Principles
10. OWASP: Authorization Cheat Sheet
11. Google Research: Public vs. Publicized—Content Use Trends and Privacy Expectations