ChatGPT Sites can now be shared privately. The viewer still signs in.

What shipped in September

OpenAI's Help Center release notes added "Share Sites with people outside your workspace" on 3 September 2026: "Eligible Site owners can now share a live ChatGPT Site with named people outside their workspace, without making the Site public." The announcement from @ChatGPT followed on 11 September, bundling five updates, three months and "over 5M sites" after launch: invite teammates to edit, save and publish a shared Site; invite specific people to a private Site without making it public; deploy in half the time; ask ChatGPT to inspect a Site's database, which editors can view too; and connect your own custom domain. Collaboration and custom domains were already in the docs in August. Private sharing is the new one, and it is the one this post is about.

The Sites docs now list 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; and anyone on the internet, "only when public publishing is enabled". The Help Center folds the second and third into one line, "Selected active users or groups, and named external viewers". Either way, "a new Site is limited to its owner and workspace admins until you change its access", and every option except the last is an identity check.

What DevDay added on 29 September

Nothing that changes the answer at the top. The keynote restated the model. From Simon Willison's live blog: "You can also build ChatGPT Sites and share them with specific other people. (I admit I thought they had that feature already.)" His notes from the Sites session add "Sites default to private" and a figure of "8m sites", up from the 5M in the September post. The Sites docs we re-read on 30 September still say invited visitors "must sign in with the account that received access".

Two DevDay launches do touch sharing:

• Sites with connected data. A Site can now load data from each visitor's own connected apps, but the docs say this "requires a workspace where the feature is enabled and a Site that is private to that workspace", and connected features "require membership in the Site's workspace". The Help Center is direct about outside viewers: "Permission to view a Site, including an invitation as an external viewer, does not independently authorize connected-app access." External viewers don't become workspace members, so an invited client gets the Site without the connected features.
• ChatGPT Space pages. Pages share through their own controls, on Pro, Business and Enterprise. On a personal plan you invite people by email with view or edit access, and "share by link where that option is available". The Space docs don't say a person without a ChatGPT account can open a shared page, and the 29 September release note describes collaborators "each person using their own ChatGPT".

How the invite works, step by step

From the Sites docs, condensed and quoted where the wording matters:

1. Open a Site you own and select Share.
2. "To keep the Site private, set Who has access to Only those invited."
3. Enter the viewer's email address. On a personal Site the control is "Enter an email address".
4. Review the recipient's Viewer access, then select Invite.
5. "Confirm that the viewer appears in the saved access list. 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." To revoke, remove them from the sharing controls, then check the rest of the audience, because "removing one invitation doesn't remove access the person has through public, workspace, or group sharing." In Enterprise an admin has to turn on Allow members to invite external visitors to sites, a permission separate from public publishing; Business workspaces have no separate toggle. OpenAI's Sites page adds that invitations are "rolling out on eligible plans and may require approval".

This is a real improvement over the July model. Our earlier post on sharing a Site with a client said the only private audiences were accounts inside your own workspace, and that a client "either needs a seat or gets a URL anyone can open". The seat is no longer required, and that post now says so.

The sentence that decides it

"For limited sharing, invited visitors must sign in with the account that received access."

That is the whole mechanism, and both the Sites docs and the Help Center carry it. The invite is an entry on an access list keyed to an email address, and the check at the door is a sign-in with that account. It is the same identity check the workspace options use, extended to one more identity. It is not a link that carries its own permission. The Help Center FAQ says the same from the viewer's side: "A Site must be shared with you, available to your workspace, or published publicly before you can access it."

People in the 11 September thread landed on the same point within the hour. One reply asked the question directly: "Do people still need to be logged in to ChatGPT? If so it's not really viable." Another, with the most likes of any sceptical reply, read "share privately" as private from everyone except OpenAI. In the product lead's feedback thread the day before, a developer described wanting "super simple multi-user auth, e.g. only this list of gmail folk can access", finding that a Pro account could not do it, and hand-rolling authentication on a public Site instead. That is the shape of the demand: a list of people, no accounts, no public URL. Private sharing answers the first part of it.

What the Sites docs still don't offer

We searched the Sites docs, the enterprise Sites guide, the Help Center articles and OpenAI's Sites page again on 30 September. None of them mentions any of these:

• A passcode. Nothing a recipient types to get in. Every audience short of the open internet is an identity check.
• An email-domain gate. The docs describe no way to say "anyone at client.com". You name people one at a time, and each of them signs in.
• An expiry. No date after which the link stops working. Asked for one in the feedback thread ("Sites with expiry date and auto delete. Would be useful for polls or survey"), the product lead suggested having Codex add a scheduled task that disables the Site or swaps in a "poll closed" page. Workable, and not a setting.
• A signed-out route to a private Site. The only audience the docs describe that opens without a sign-in is "Anyone on the internet", and none of the five is a link-only mode. Our London test in August found the personal-plan menu offered "Only you" and "Anyone with the link", and the address it gave us was built from readable names (see below), not an unguessable token. The docs now add invited viewers, who sign in.

One more gap matters for client work. The invite flow ends with "Share the Site's link", the same link for every viewer, and the built-in analytics count unique visitors and page views. The Sites docs don't describe a way to see which of three invitees opened it, short of building that into the Site.

Your Site URL can show your username

When we published a test Site from a personal account on 22 August, it went live at redirect-probe.stevysmith.chatgpt.site: the Site name, then the account name. OpenAI's own showcase Sites have the same shape, for example frame-studio-motion.openai.chatgpt.site. No official page documents the hosted address format, so look at yours before it goes to a client.

What the Sites docs do say about changing it:

• "Where URL editing is available", the Site owner opens the Site's settings, selects Change URL and enters "an available name". It needs at least five characters of lowercase letters, numbers and single hyphens, starting with a letter and not ending in a hyphen.
• "The URL change doesn't create another deployment. The previous address redirects to the new one, including routes and query parameters."
• The Help Center release note of 20 August 2026 limits this to "Site owners on Plus and Pro", and only the owner, not an editor, can change a Site's name or URL.
• A rename "doesn't add, remove, or change a custom domain". Custom domains are a separate setting: "where custom domains are available", you connect an apex domain or subdomain you already own, though not in Enterprise workspaces at launch.

The docs don't say whether a rename changes the account part of the address.

The database line worth reading twice

"Explore your data: ask ChatGPT to inspect your Site's database. Editors can view it, too." Two replies to the announcement flagged the same thing independently: database access shared with every teammate you invite as an editor is a larger grant than "collaborative editing" suggests. The docs agree in plainer words: "Editors can read the Site's live database data." Invited viewers are not editors, so this does not apply to them. But if the reason you want a private Site is that it holds real data, the permission to keep straight is "Can edit", not "Can view".

When invited viewers are the right tool

Plenty of cases, and it is worth being fair about them. A co-founder who already lives in ChatGPT. A stakeholder at a partner company who has a Plus account and is happy to sign in. A dashboard with a live database that a handful of named people should be able to poke at, where a sign-in is a feature rather than a hurdle. Anything where the viewer is technical, already a ChatGPT user, and the Site is an app rather than a document. Sites builds full applications with a database and server logic, and private sharing gives those apps a real audience short of the open internet. Use it.

When the reader is a client

The case that does not fit is the one where you are sending finished work to someone who did not ask to create an account. A proposal, an audit, a quarterly report, a design review: the reader is a client, the content is theirs, and the relationship is that you make it easy for them. Asking them to sign up for ChatGPT so they can read a PDF you could have emailed inverts that. The person who wanted "only this list of gmail folk" did not want those people to have ChatGPT accounts. He wanted a list.

That is the case Stacktree is built for, and it starts from the link rather than from an identity provider. Every published page is an unguessable private URL, and a client opens it with no account. If the content needs a gate, you add a passcode they type, on every plan, or from Solo a company email gate they pass with a one-time magic link, still with no account created. From Solo, each recipient can get their own named link, so you know who opened what and can revoke one person without touching the rest. Clients can leave comments on the page itself, you can add a one-minute video of the page, and from Solo a client can have a branded space that holds all their pages (one on Solo, ten on Studio). Any agent can publish over MCP or a single curl, then revise the page in place on the same URL.

Two products, two questions. Sites answers "how do a few named ChatGPT users get into my app?" and now answers it well. The question a deliverable asks is "how does one person outside the building read this with no friction, and how do I know they did?" Private sharing moved the first question forward in September, and DevDay did not change the answer to the second.