The short answer
ChatGPT Sites is not a preview. OpenAI's own documentation puts it plainly: "Sites lets ChatGPT create, host, refine, and share websites, web apps, and games." It gives the result an address, lets you connect a domain you own, and hands the site a database. If you already pay for ChatGPT and the work starts in a ChatGPT conversation, that is the shortest path there is, and we are not going to pretend otherwise.
Birta is the answer to a different question: where should the site live so that it does not depend on which assistant made it. Any agent with access to your files publishes to it, every version keeps its own address for someone to mark up, and what gets served is your files.
Sites is in public beta, and its own docs describe features as available "where supported" and "at launch". Everything quoted here comes from learn.chatgpt.com/docs/sites on that date, so verify anything decision-critical before you rely on it.
Compare the operating model
| ChatGPT Sites | Birta | |
|---|---|---|
| Who can build the site | ChatGPT, on Plus, Pro, Business, Enterprise or Edu | any agent that can read your files, ChatGPT included |
| What it serves | websites, web apps and games, with a database | static files, nothing executed on the server |
| Database and storage | D1 up to 10 GB, R2 with no stated limit | none; the page is files |
| Open to the internet | only when public publishing is enabled, and in Enterprise an admin must turn it on | publishing is what makes a site public |
| Custom domain | apex or subdomain you own, where available; not in Enterprise at launch | apex or subdomain you own, on Solo |
| Review before it ships | save a version, then deploy; "every Sites deployment URL is a production deployment" | every version has its own address, and remarks are marked on the page itself |
| Enquiry form | build it yourself against the database | the agent declares a form, submissions land in the panel |
| Exporting the files | the documentation does not describe it | the files are yours, and a version downloads as an archive |
| Cost of publishing | a paid ChatGPT plan | free to publish; own domain on Solo |
Two rows in that table are theirs, not ours, and they matter. Sites runs applications and we do not. A page with a database behind it, a game keeping scores, a tool that stores what people submit: that is inside their boundary and outside ours. If your idea needs to remember anything, this comparison is already over.
Stay with ChatGPT Sites when the work never leaves the conversation
Four cases where it is the better fit.
You already pay for ChatGPT and the site is small. The tool is there, the site appears in your Sites list, and it stays there after the chat that made it ends. No connection to set up, nothing new to learn.
The thing you built is an app, not a page. A dashboard reading from a database, a calculator that saves results, a game with state. Their D1 database and R2 storage are built for exactly that.
You want it visible only inside your organisation. Their access tiers go from owner and workspace admins through selected groups to anyone in the workspace, which is a finer grid than a public address with a password.
ChatGPT is the only assistant you use. If nothing else in your week touches your files, the fact that Birta works with Claude Code or Cursor buys you nothing.
Choose Birta when the site should not belong to one assistant
A different agent is doing the work. This is the plainest difference. Sites is built into ChatGPT, so the site is made where ChatGPT is. Birta is a host with a connection, so Claude Code, Cursor, Codex, Claude Cowork or ChatGPT itself all publish to the same project. If your habits change next quarter, the site does not move.
A client has to look and comment. Their model is two stages, saving a version and deploying it, and their documentation is explicit that "every Sites deployment URL is a production deployment". Here a version has its own address that a person with no account opens, marks remarks directly on the page, and keeps using after the site is published. Review happens on the rendered page rather than on the live one.
The site has to be plainly public. With Sites, reaching the open internet is a setting that has to be on, and in Enterprise workspaces public publishing is off by default until an admin enables it. If your page is a shopfront, that is a dependency on somebody else's policy. Publishing here is what makes a site public; there is no switch in front of it.
You want the files back. OpenAI's documentation does not describe exporting or downloading a Site's files. That is an absence in the docs rather than a stated restriction, so do not read it as a prohibition, but do check it before you put something you would hate to rewrite inside a beta. On Birta the published site is the files you gave it, and any saved version downloads as an archive.
Publishing should not require a subscription to an assistant. Sites needs a paid ChatGPT plan. Getting a page live here does not need a paid anything.
Follow one update from request to live site
The difference in shape is easier to see on a single change. Suppose the price on your page is wrong.
- Step 1Say what changedOne sentence to whichever agent you use.
- Step 2Get a version addressA page you or a client can actually look at.
- Step 3Read the remarksMarked on the page, by someone with no account.
- Step 4PublishSame address as before; the old version stays.
On Sites the same change is a conversation with ChatGPT and a deploy, which is fewer steps and is genuinely faster when you are the only person who needs to approve it. The step that does not exist there is the third one: somebody else looking at a rendered page that is not yet the live site, and writing on it.
That is the whole trade. Fewer steps when you work alone, one more step that earns its keep the moment anyone else has an opinion.
Know when neither one fits
If the site needs a server you control, background jobs, or a real backend beyond a database behind a page, both of these are the wrong shelf. And if what you have is a document rather than a site, publishing it as a web page is a decision worth making deliberately rather than by default.
Run a reversible fit test
Publish the same page both ways and wait a week. It costs a page and a subscription you probably already have.
Put your real content in it, send the link to the person who actually has to approve things, and see which loop annoys you less. Then ask the question that decides it: if you stopped using ChatGPT next month, what happens to this site? If the answer is "nothing, it keeps serving", either tool is fine. If the answer makes you pause, you have found which one you need.
Publish from whichever agent you already use
One connection, and the site stops depending on which assistant built it.