How to share a ChatGPT Site with a client

The four options, and what each costs

Straight from the documentation, a Site can be visible to owner and workspace admins only, to selected active users or groups and named external viewers, to anyone in the workspace, or to anyone on the internet when public publishing is enabled. Read those as two categories rather than four settings. The first three are the same mechanism with a widening list: the viewer proves who they are by signing in to a ChatGPT account you have named. The fourth removes the check entirely.

For internal work that is a good model. For client work it half-fits. Since September the client no longer needs to join your workspace, but they do need a ChatGPT account on the invited address and the willingness to sign in to read a proposal. For a client who lives in ChatGPT that is nothing. For one who does not, you are asking them to do the admin so you can send them something.

Worth noting what else falls on the wrong side of that line. In Enterprise workspaces, public publishing is off by default, custom domains are not available at launch, and analytics is not available for Enterprise-owned Sites. The organisations most likely to have external client relationships get the fewest of the tools for serving them.

What collaboration and private sharing added

On 20 August 2026 OpenAI added editors. The announcement: "Add teammates as editors to your ChatGPT Sites so you can build and publish together. Collaborators can push changes to the same project while Codex handles git management and CI behind the scenes." Three roles are documented. The owner controls audience settings, editor management, analytics, versioning and the first publish. An editor can open the site, make changes, save versions and publish updates once the owner has published once. A visitor gets read-only access to the live site.

This is a real feature and it solves a real request. A month before it shipped: "ChatGPT sites are a great way to share and present work (as opposed to ppt or docs) but it still doesn't solve the collaboration aspect for me. Wish I could do it sites itself." Now you can.

What it did not touch, at the time, was the audience. The docs qualified collaborators as "active members of the same workspace", so the new roles lived entirely inside the boundary that was already there. People noticed. Eight days before the launch: "ability to more than one more user using chatgpt Sites in Plus Plan. I only see option for Private or anyone with link." The next day: "why are these the only options for sharing chatgpt sites?" Both were accurate for three more weeks.

On 11 September 2026 OpenAI added the audience half: "Share privately: invite specific people to a private Site without making it public." The help center flow is enter an email, save, and "ask them to open the Site while signed in with the account that received access". That answers the 12 August request for anyone willing to sign in. What it did not add is a gate without an identity: no passcode, no email-domain rule, no expiry, and no per-recipient link. The private-sharing post walks through the mechanism and the replies.

The four workarounds

Publish publicly and rely on the URL. The most common choice, and the one most likely to be regretted. A public Site is on the open web: it can be indexed, forwarded, and read by anyone who ends up with the link. There is no expiry, and you cannot cut off one recipient without changing the address for everyone who has it.

Invite the client by email. The new route, and the right one for a client who already uses ChatGPT. Private, view-only, revocable per person. The cost is the sign-in: the client needs a ChatGPT account on that address and has to be logged in to open the link, every time. That is a hurdle for a client who does not use ChatGPT, and a hard stop for a shared inbox or a procurement contact who will not create accounts.

Add the client to your workspace. Technically correct and commercially awkward. It generally means a seat, an account your client did not ask for, and an onboarding conversation before they can read the thing you sent. For a one-off proposal it is more friction than the deliverable is worth.

Take the work elsewhere. Community reports at launch described being able to export a Wrangler project of a Site for self-hosting on your own Cloudflare account, though that is still not in the documentation. Exporting solves the gate problem by leaving, at the cost of the thing that made Sites appealing: asking for a change in the chat and having the live page update.

When public is genuinely fine

Plenty of the time. A demo, a prototype you want feedback on, a public-facing microsite, a conference talk companion, a little game to send round. If you would not mind a stranger reading it, an unlisted public URL is a sensible control and Sites is an excellent way to produce one.

The line is worth stating precisely, because the answer changes with the content rather than the audience. Pricing, scope, client data, anything under an NDA, anything with a named individual in it: those need a gate, not an unguessable string. A URL is a secret you cannot revoke, cannot expire, and cannot audit.

When you need a different tool

If the deliverable should reach one named person, without an account, and stop being readable later, you need a host whose access model starts from the link rather than from an identity provider. That is what a publish primitive does differently: the page is private by default and shared with a link a client just opens, a passcode or email-domain gate is one setting rather than a directory invitation, links expire, and each recipient can get their own link that can be revoked on its own without touching anyone else's.

The useful part is that these are not competing answers to the same question. Sites is for building something, together now, and showing it to your workspace or to everyone. The other half of the category is for sending finished work to someone outside the building and knowing how it landed. If your job is client delivery, you will keep hitting the boundary described above, and no amount of collaboration features will move it, because it is a decision about identity rather than a missing setting.