How to share a ChatGPT Site with a client

The five options, and what each costs

A new Site "is limited to its owner and workspace admins until you change its access". From there, the Sites documentation lists five audiences: owner and workspace admins; selected active users or groups, where supported; invited external viewers, when external invitations are available; anyone in the workspace, where supported; and anyone on the internet, only when public publishing is enabled. The Help Center folds the second and third into one line, so you may see four. Either way, read them as two categories. The first four are the same mechanism with a widening list: the viewer proves who they are by signing in with an account you or your workspace have named. The last removes the check entirely.

For internal work that is a good model. For client work it half-fits. 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. That matters more now that OpenAI's Sites page pitches the product for "dashboards and client portals".

Worth noting what else falls on the wrong side of that line. In Enterprise workspaces, public publishing is off by default, inviting external viewers needs its own admin permission ("Allow members to invite external visitors to sites"), 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, restoring earlier versions 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.

Then OpenAI added the audience half. The Help Center release note, dated 3 September 2026, says "Eligible Site owners can now share a live ChatGPT Site with named people outside their workspace, without making the Site public", and @ChatGPT announced it on 11 September. The docs flow: open the Site, select Share, set Who has access to Only those invited, enter the email, select Invite, then "share the Site's link and ask them to sign in with the account that received access". External viewers "don't become workspace members or Site editors, and can't edit or publish the Site". The feature is still "rolling out to Sites users on Plus, Pro, Business, and Enterprise plans", and OpenAI's own FAQ says invitations "may require approval".

That answers the 12 August request for anyone willing to sign in. What the docs do not describe is a gate without an identity: no passcode, no email-domain rule, no expiry, and no per-recipient link. Nor does an invitation on its own open a Site's connected apps: the Help Center says permission to view a Site, "including an invitation as an external viewer, does not independently authorize connected-app access". 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. The Sites docs do not mention link expiry, and renaming the address does not cut anyone off, because "the previous address redirects to the new one, including routes and query parameters".

Invite the client by email. The new route, and the right one for a client who already uses ChatGPT. Private, view-only, and removable per person, though the docs warn that "removing one invitation doesn't remove access the person has through public, workspace, or group sharing". The cost is the sign-in: the client needs a ChatGPT account on that address and has to be signed in to open the link. 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.

Sharing a Space page with a client who has no ChatGPT account

If the deliverable is a document rather than an app, a ChatGPT Space page (Space replaced Library) looks like a lighter option. It has its own sharing controls, separate from a Site's external-viewer invitation, and it is on Pro, Business and Enterprise only, with Enterprise sharing an opt-in preview. The Space collaboration docs offer View, Comment and Edit access and say "available recipients and sharing options depend on your account and workspace". On a workspace plan you invite people or teams in your workspace. On a personal plan, OpenAI's Space page says you invite people by email, and "you can also share by link where that option is available".

What no official Space page says is whether someone without a ChatGPT account can open that link. The surrounding wording points towards needing one: troubleshooting says to "check that they are using the intended account and workspace", and the 29 September release note on Pages says collaborators work "with each person using their own ChatGPT". That is our reading of the docs, not a documented rule, so open the link in a signed-out browser before you send anything that matters.

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 (on every plan) or, from Solo, a company email gate is one setting rather than a directory invitation, links can expire, and from Solo each recipient can get their own named link that tells you who opened it and can be revoked without touching anyone else's. The client can also leave comments on the page without signing up.

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.