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, 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 narrower list: the viewer proves who they are by signing in to your workspace. The fourth removes the check entirely.

For internal work that is a good model. For client work it fails at the first step, because the whole point of a client deliverable is that the reader does not work for you. Asking a client to create an account and be added to your workspace so they can read a proposal inverts the relationship: 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 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 is the audience. The docs qualify collaborators as "active members of the same workspace", so the new roles live 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 are still accurate.

The three 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.

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.