ChatGPT Sites hosts what you build and gives you access controls — owner only, named workspace members, the whole workspace, or the public internet. There's no rung for one outside client. Here's the shape of that gap and the route round it.
You describe what you want, ChatGPT builds it, and it's live — a working page, hosted, with a URL. Then you go to send it to the client it was for, open the share settings, and the ladder reads roughly like this:
Read that list again with one specific person in mind: the client. They have no seat in your workspace. They're not going to get one for a single deliverable.
Every rung except the last is defined by workspace membership. The last one is the open internet.
This isn't a story about a product being bad at something. Sites is doing a sensible thing: it lives inside a workspace, so it uses workspace identity to decide who gets in. That's the same reasoning behind the fact that public publishing is off by default in Enterprise workspaces and has to be enabled by an admin — the product is being deliberately careful about the step from internal to open.
The awkwardness only appears for one particular audience: someone real, named, and outside your organisation. A client. A prospective client. A partner agency. A journalist under embargo. A candidate you're sending a take-home brief to.
For that person, the options collapse to two, and neither fits:
Add them to the workspace. Seats, admin approval, and a person who now has an identity in your organisation because you wanted them to look at one page for four minutes.
Make it public. The page is reachable by anyone with the address, indexable unless something says otherwise, and there is no expiry, no passphrase, and no way to close it later beyond turning it off entirely.
Neither of those is a delivery mechanism. They're the two ends of a switch that has no middle.
Worth saying plainly, because the rest of this page is about the other case.
If what you built is a demo you'd happily post about, a tool you want strangers to use, a public-facing page for a launch, or anything where being found is the goal — publish it and move on. It's the shortest path, it's free, it's hosted for you, and there's nothing to gain from routing around a feature that's doing precisely what you want.
The rest of this only matters when the audience is one specific person and the work isn't ready to be public. That's a narrower case than the internet implies. It also happens to be most of what agencies, consultants and freelancers do all day.
When you need the page as a file, don't go looking for an export button. Ask in the conversation:
"Give me the full HTML for this as a single self-contained file, with the CSS and JavaScript inlined."
You get the source. Save it as something.html. That's the whole move.
It's worth knowing even when nothing is stuck, because asking beats exporting: you can specify what you want. Inline the styles. Inline the scripts. Don't fetch fonts or libraries from a CDN, so it works in a locked-down corporate browser. An export gives you whatever it produces; a request gives you the file you need.
Then check it, and this takes ten seconds: open the file locally in a browser. If it renders and behaves, it's genuinely self-contained and it will run anywhere. If it's blank or unstyled, something load-bearing is still being fetched — hand it back and ask for those pieces inlined. The self-contained export checklist walks the specific things that tend to leak on the way out, and it applies to any AI tool's output, not just Claude's.
Some Sites won't survive the export, and it's better to find that out now than in front of a client.
If the page needs a server at request time — a database it reads, a login it checks, an API route, a call to a model while somebody is using it — then it isn't a page, it's an application, and lifting the HTML out gives you a shell. No host that serves static files will fix that, including this one.
That's not a workaround waiting to be found. If what you built genuinely needs a backend, it needs a real deployment, and Vercel, Netlify or Cloudflare will serve you far better than we would. Use them. They're excellent at exactly that, and pretending otherwise would waste your afternoon.
What travels cleanly is the enormous middle of what people actually build this way: reports, dashboards over data you baked in, calculators, proposals, one-pagers, prototypes, microsites, interactive explainers. Those are HTML, CSS and JavaScript, and they run on any host, in any browser, for anyone.
Drop the exported .html and get an unguessable, no-index link that opens for anyone you send it to — no account for them, no workspace seat, no sign-in wall.
Once the work is a file you hold rather than a hosted object inside a workspace, the access questions become yours to answer:
None of that is exotic. It's just the difference between access rules that belong to a platform and access rules that belong to you.
The same story is playing out across every AI tool that hosts what it builds, because they all inherit the identity model of the thing doing the building.
Claude's artifacts have their own version of it — a share toggle that's about a specific version rather than the artifact, an unpublish that turns out to be permanent for that artifact, and links that assume the reader has an account. The pattern behind all of them is the same one: the link your AI tool gave you assumes the reader is you.
That assumption is correct for the first audience these features were built for — yourself, then your team. It stops being correct at the exact moment the work becomes a deliverable.
If you're doing this regularly rather than once, sharing a Claude or ChatGPT artifact privately covers the whole flow end to end, and what your client actually sees is worth a read before the first one goes out — the experience on their side is the part you can't check from where you're sitting.
The steps take about ten seconds. The cost is less obvious: unpublishing permanently retires that artifact's ability to be published, and deletes its stored data. Here's how to do it, what it takes with it, and what to reach for when access only needs to end for now.
The normal delivery ritual is finish, then send — and every revision mints a new URL and another 'ignore my last email'. If your AI tool can publish and then update in place, the link can go out first and stay correct. Including when that's a bad idea.
Claude refuses to share your artifact and suggests publishing a new version — which often doesn't clear it. Here's the diagnosis that actually separates the two failures behind that message, and the export route that doesn't depend on the toggle working.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.