ChatGPT Sites is live for every paid subscriber.

What launched, verified

From the launch announcement and thread: Sites is available now to paid subscribers as part of the ChatGPT Work release; the announcement's own example site (a map visualization built "last night") lives at an openai.chatgpt.site subdomain. We fetched it within hours of launch: it serves publicly, HTTP 200, no ChatGPT account required to view. Rollout is staged: some Plus users reported not seeing the feature on day one, the docs hedge that availability "can depend on your plan, region, and workspace settings", and OpenAI's help center was explicit that Sites was not available in the EEA, Switzerland, or the UK at launch — an exclusion lifted on 20 July 2026, when Sites quietly reached all three for Plus and Pro accounts. The team calls this "still only just the start". The docs also settle update semantics: you save versions and deploy them, updates keep the same URL, and "every Sites deployment URL is a production deployment". Genuine replace-in-place.

Since launch day, the docs have filled in two early unknowns. Custom domains are documented: connect an apex domain or subdomain you already own by updating DNS records, where the feature is available, though not in Enterprise workspaces at launch. And built-in analytics is documented: total unique visitors and page views, plus both over time, though not for sites owned by an Enterprise workspace. Two more landed on 20 August 2026: a Site's ChatGPT-hosted address can now be changed without redeploying, with the old address redirecting including routes and query parameters, and Enterprise owners can add workspace members as co-editors who publish later versions to the same URL. Still absent, verified as of 22 August: any API, MCP, or agent surface, and any documented export.

What changed from Codex Sites

Two things, both big. Availability: Codex Sites was a beta for team plans; the June signal that individual plans were coming "ASAP" took five weeks to land. Visibility: Codex Sites could not be viewed outside your authenticated workspace, which was its defining limitation. ChatGPT Sites flips that: with public publishing enabled, a site is on the open web. If you found our "can you make a Codex site public?" status post before today, the answer there was no; for ChatGPT Sites it is yes, and that post now says so.

Collaboration, and what it did not change

On 20 August 2026 Sites gained collaborative editing. OpenAI's developer account put it plainly: "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." URL renaming landed in the same drop. The docs now define three roles: owner (audience settings, editor management, analytics, versioning, first publish), editor (open, change, save versions, publish updates once the owner has published), and visitor (read-only on the live site). Sites shared with you appear in a "Shared with you" section.

Read the qualifying line carefully, because it decides who this is for: collaborators must be "active members of the same workspace". This is multiplayer building, not multiplayer viewing. The audience model is untouched, and it is still the same four options it was in July. Which means the gap people were already naming in public did not move. Two days before the collaboration launch: "ability to more than one more user using chatgpt Sites in Plus Plan. I only see option for Private or anyone with link" (@zshansyd, 12 August). The day after: "why are these the only options for sharing chatgpt sites?" (@bee_human_, 13 August). And a month earlier, the request the launch did answer: "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" (@anukshi13, 31 July).

So the shape is now clear. Sites is very good at a team building something together and then showing it to the world or to their own colleagues. It has no answer for the third audience: one named person outside your company who should see this and nobody else, without signing up for anything. That is a separate question with a separate answer.

The Cloudflare underneath

The launch thread confirmed Sites is "a collaboration between OpenAI and Cloudflare", and community digging identified Cloudflare Workers with SQLite and Durable Objects. Notably, Sites can reportedly export a Wrangler project of your site for hosting on your own Cloudflare account: a real portability story if it holds, though still absent from the docs. It is also a second consecutive datapoint (after Cloudflare Drop, launched the day before) that the biggest players are converging on the same shape: AI makes HTML, it needs a URL instantly, and Cloudflare is becoming the substrate either way.

Tested from London: the new URL editing

Sites reaching the UK made a first-person test possible, so on 22 August we ran one from London on a personal account: asked ChatGPT Work to build a deliberately minimal two-page probe site, published it, renamed it, and watched what the redirect actually does. What we found, in the order we found it:

• The build took 7 minutes 50 seconds for two near-empty pages. Sites scaffolds a Next.js application, patches it, spawns a deployment-monitoring subagent, and creates a checkpoint before handing back a URL. It is a real pipeline, not a file upload.
• Sites only exists in the Work surface. Asked in a plain chat, ChatGPT states the Sites capability is not exposed there and declines. The Chat-mode assistant in our test then volunteered that it did have publishing access to Stacktree via the installed connector, but would not substitute it for a test aimed at Sites — which is both correct and a neat illustration of where each product lives.
• URLs are now user-namespaced. Our probe published at redirect-probe.stevysmith.chatgpt.site — a per-account subdomain, not the launch-era {name}.openai.chatgpt.site shape.
• Publishing defaults to private, and a personal plan gets exactly two modes: "Only you" and "Anyone with the link". No passcode, no email gate, no invited viewers outside a workspace — the sharing model the FAQ above describes, confirmed in one dropdown.
• The new URL change works as documented, with one caveat. We renamed the site and requested the old address with a deep route and a query string: /about?q=carried came back as a redirect to the new host with both the route and the parameter intact. The caveat: it is an HTTP 307 temporary redirect. For a permanent rename, a 301 or 308 is what tells crawlers and caches the move is real; a 307 keeps old links working for humans while leaving search engines pointed at the old address indefinitely.
• The settings page shows more than the docs do: custom domains offered on a personal account, an environment-variables panel ("Add API keys and other environment variables your site needs"), an analytics tab, and site deletion. Still nowhere to be found: any API, MCP, or export surface.

What is still unknown

• Gates without accounts. The private modes (invitation and workspace scoped) require signed-in viewers; no password or email-domain gate exists for account-free recipients, and no expiry is documented.
• API or agent access. Created and managed in ChatGPT; the docs note there is no standalone CLI management view, and no public API or MCP surface exists for programmatic publishing.
• Limits, indexing, export. Exact site counts and sizes ("plan-specific usage limits apply", unspecified), search-engine indexing behavior, and the community-reported Wrangler export: none documented yet.

Sites or a publish primitive

For a paid ChatGPT subscriber who wants a live app from a conversation, Sites is now the shortest path there has ever been, and public publishing removes its old dealbreaker. The choice that remains is sharper than it was at launch, because custom domains no longer separate the two. What does: who the viewer is, and who the publisher is. Sites viewers are either the whole internet or invited accounts; there is no gate a client can pass without one. And the publisher is a chat session, not an API. If the thing you are publishing is a deliverable to share with a client without a login, needs an expiry or a password, or gets published and revised by an agent over an API rather than a conversation, that is the other half of the category: pages as deliverables, private by default, with a read on how they landed. That is the half Stacktree covers: publish over MCP or the API, unguessable by default, passcode and email-domain gates a client passes without an account, and revisions that keep the same URL. Both halves just got very real.