Share a ChatGPT Site With Clients Without Workspace Seats
ChatGPT Sites can now give named clients view-only access without adding them to your workspace or making the Site public. Here is the workflow.
On September 3, 2026, ChatGPT Sites added named external viewers. You can now send a private, live Site to a client without making the URL public or adding that person to your workspace.
The client preview no longer needs a client seat
This is a small sharing control with a useful business consequence.
Before this release, the awkward part of a client preview was access. The Site could stay inside your workspace, where the client was not a member, or it could be published to the internet. Teams that wanted a private review had to move the preview into another tool, add the reviewer to an internal workflow, or accept a public URL.
The new path sits between those choices. A Site owner adds a named outside person by email. That person signs in with the invited account and can use the live Site, but cannot edit it or publish a new version. The invitation also does not turn that person into a workspace member.
That last line is the budget change. The external viewer adds zero workspace memberships. If you were paying for workspace access only so a client could inspect a Site, that seat is no longer part of this preview path.
This is not anonymous link sharing. The viewer has to prove they are the person you invited by signing in to the matching account. It is closer to a guest pass with a name on it than a link anybody can forward and open.
The access model in plain English
ChatGPT Sites now has distinct jobs for the people around a project.
The important split is between audience and authority. Audience controls who can open the Site. Authority controls who can change or publish it. Named external sharing expands the audience without moving edit or publish authority outside your team.
It also leaves public publishing as a separate switch. An Enterprise admin can allow selected roles to invite external visitors while keeping public publishing disabled. Business workspace creators get external viewers as part of the wider Sites permissions, while Enterprise and Edu inviters need the external-visitor permission enabled for their role.
What changed in the business math
There is no honest universal dollar figure here. OpenAI's current Sites pages do not publish a separate external-viewer fee or a named-viewer limit, and beta limits are shown inside the product by plan.
The useful calculation is your own:
Potential monthly preview saving = the monthly cost of workspace seats bought only for outside reviewers + the monthly cost of a separate private-preview tool you can actually retire.
Do not count both parts automatically. If the client still needs to edit, comment, approve, compare versions, or work elsewhere in your workspace, this feature does not replace that workflow. The release gives them view-only Site access. It does not document a client approval system.
The time saving is easier to see. Your team can build, deploy, restrict, and show the Site on the same product surface. There is no extra export to keep in sync just to put a preview behind named access.
Where this fits tomorrow
An agency showing a landing page
An agency lead can deploy the proposed landing page, invite the client's marketing owner, and keep the wider internet out. The client sees the actual interactive Site. The agency keeps the only edit and publish controls that matter.
The payoff is not merely privacy. The preview can stop consuming an internal seat or another hosted copy if that was the agency's workaround and the recipient only needs to inspect the work.
A consultant delivering an interactive report
A solo consultant can turn a report or lightweight dashboard into a Site and invite the buyer by email. The buyer can use the result without becoming part of the consultant's workspace.
Keep comments and formal acceptance in the system named in the contract. View-only access proves who may open the Site, but it does not create an approval trail by itself.
A product lead collecting outside review
A product lead can show a prototype to outside counsel, an executive adviser, or a research partner before public release. Each reviewer gets named access, while the product team keeps changes and publishing inside the workspace.
This works best when the reviewer needs to experience the flow. If they need to rewrite copy or move components, use a workspace editor or the design tool where that work already happens.
An Enterprise admin separating preview from publication
An Enterprise admin can enable Allow members to invite external visitors for the roles that handle client review without also enabling public publishing. Those are separate permissions in the workspace controls.
That gives the team a narrower policy: approved people can invite named outsiders, but they still cannot make a Site public unless the public-publishing control also allows it.
How to share a private client preview
This is a settings workflow, not a technical integration.
Check that the sharing control is available
Open the Site and select Share. If the outside-email option is missing in an Enterprise or Edu workspace, ask the owner or admin to check Workspace settings, then Permissions & roles, the relevant role, Early access, and Sites. The role needs permission to invite external visitors.
Review the deployed version
Confirm the Site contains only material the recipient should see. This sharing path applies to a live Site, and every deployment URL is a production URL even when its audience is restricted.
Invite the named viewer
Enter the client's email in the sharing control, confirm view-only access, save it, and check that the person appears in the access list.
Test the recipient path
Ask the client to open the Site while signed in with the account that received the invitation. Test the view from that account instead of assuming your owner's view represents what they will see.
Remove access when the review ends
Remove the viewer from the Site's sharing controls. Then check the remaining audience settings, because a public or workspace-wide setting can still provide access after a direct invitation is removed.
The honest limits
The external viewer cannot edit or publish. That boundary is the point, but it also means feedback still needs somewhere to go.
Removing a named viewer is not a universal kill switch. If the Site is also available to the workspace or anyone on the internet, that other audience setting may keep it reachable.
There are plan and rollout limits too. Sites is in public beta for ChatGPT workspaces, Plus, and Pro accounts. It is not available on Free or Go, or in the EEA, Switzerland, or the United Kingdom at launch. Enterprise availability also depends on the permissions your admin has enabled.
The compliance boundary matters more than the convenience. ChatGPT Sites does not support data residency or inference residency at launch. OpenAI also says Sites must not process Protected Health Information or payment-card data, except when card data is handled only by a third-party payment processor. A named viewer is an access control, not permission to put restricted material into the Site.
Who should act now
Use this now if you already build Sites and your outside reviewer only needs to see and use the result. Agencies, consultants, and product teams can replace the public-preview compromise with named access.
Wait if your account does not show the control, your admin has not approved outside invitations, or your review requires inline comments, guest edits, version comparison, or formal approval. Keep the review tool that provides those jobs.
You are unaffected if you only publish public Sites, work entirely with people inside the same workspace, use Free or Go, or operate where Sites has not launched.
Join the newsletter for plain-English breakdowns of the platform changes that alter real work.
Sep 6, 2026
Prefer this site in Google
Mark omidsaffari.com as preferred and Google lifts it in Top Stories, AI Overviews and AI Mode for you.
