QWE AI Academy Key takeaway: If you want a real link people can open today, don’t stop at “ChatGPT wrote me some HTML.” Use Sites in ChatGPT – describe the thing in Work, force a save version before any deploy, then widen access on purpose.
Two ways people try this. Method A: ask ChatGPT for a full page or app, copy the files out, and fight Netlify/Vercel/DNS yourself. Method B: stay inside ChatGPT Work (or Codex on desktop), mention a website or @Sites, let OpenAI host it, and share from the Sites panel. Method B wins when you need a durable URL, built-in storage, and access controls without babysitting a repo.
| Approach | What you get | Where it breaks |
|---|---|---|
| Method A – generate + self-host | Full control of stack and host | You own deploy, auth, storage, SSL churn |
| Method B – Sites end-to-end | Preview, host, share URL inside ChatGPT | Beta usage caps, runtime limits, plan gates |
OpenAI’s product page puts it in three beats: describe what you want, refine it, publish and share. After launch, the official ChatGPT account reported over 5 million Sites created in roughly three months (milestone coverage around that announcement wave), alongside collab edit, private invite, faster deploy, DB inspect, and custom-domain updates. Still public beta – limits and UI can shift – but usable today on the right plan.
Quick background (skip if you just want the clicks)
Sites is OpenAI’s hosted path for interactive sites, lightweight apps, and games – dashboards, trackers, portals, calculators, the small tools that used to die as a zip of code in chat. You build from Work on the web, or Work/Codex in the desktop app (OpenAI Help Center). As of the public beta docs, it’s on Plus, Pro, Business, Enterprise, and Edu – not Free or Go. No separate Sites fee during beta; usage sits under plan-specific limits shown in the product (those numbers aren’t a fixed public price list and may change).
I burned an evening on Method A first – pretty UI, zero hosting plan, classic “now what?” hangover. Switching to Sites felt almost unfair: same conversation, then a URL that didn’t evaporate when I closed the tab.
Method A vs Method B for Sites in ChatGPT
Keep Method A when Sites can’t host your stack or you must own infra for compliance. Docs call out unsupported frameworks, external DB patterns, background services, and hosting shapes on the Sites runtime. Sites also has no data residency or inference residency at launch (Help Center) – a hard stop for some regulated teams.
Everyone else? Method B. Preview, host, and share settings live in one loop. Payments only through a third-party processor you wire yourself; card data isn’t meant to hit Sites directly (same limits section). Pick B unless you have a hard reason not to.
Walkthrough: prompt → private preview → save → deploy
Do this in order. The order is the product.
- Open the right surface. On web, select Work. On desktop, Work or Codex – current app build, not an old Classic leftover.
- Describe a small, one-job site. Include the word “website” or tag
@Sites. State audience, what visitors do, what must persist, and who should see it later. - Attach constraints. Files, sample data, links, “must sign in with workspace account,” “keep rows between visits.” Vague prompts get pretty shells; specific ones get tools.
- Review the in-app preview. Click around like a stranger. Forms, empty states, mobile width.
- Iterate in plain language – one change at a time beats a laundry list.
- Save a version without deploying. Say it out loud to the model.
- Only then deploy and open Share.
@Sites Build a single-purpose website for our volunteer shift board.
Audience: 12 organizers who already use our ChatGPT workspace.
They should add shifts (date, role, owner), mark filled/open,
filter by weekend vs weekday, and keep data between visits.
Require workspace sign-in. Clean, mobile-friendly, no marketing fluff.
First: private preview only. When I say so, save a version - do not deploy yet.Every deployment URL is a production URL. That’s the line both the Help Center and learn.chatgpt.com Sites docs repeat. Save builds a reviewable candidate; deploy publishes it. Skip save and your half-finished board can already be a live link.
Pro tip: After the first good preview, type exactly: “Save a version but do not deploy. I need to review it first.” Only deploy when you’d be okay with a coworker opening it cold.
New Sites start limited to the owner and workspace admins until you change sharing. From Share you can move to selected people/groups, workspace-wide (where supported), or public if your plan/workspace allows it. Named external viewers are invite-by-email and view-only – they still sign in with the ChatGPT account that got the invite. No documented passcode-only or account-free private gate.
Branded address? Where custom domains are offered: Site settings → Add domain, paste the DNS records at your registrar, wait, refresh. You must already own the domain – Sites won’t register one – and custom domains aren’t available in Enterprise workspaces at launch (Help Center; this may have changed after your workspace ships updates, so recheck in-product).
Edge cases that bite after the honeymoon
- Production-by-default deploys. Treat deploy like “ship to customers,” not “refresh preview.” (Same rule as the walkthrough – it bites people who only skim features lists.)
- Beta usage is a running account-wide meter. Limits cover creating Sites, storage, and keeping high-usage Sites public. ChatGPT warns as you approach; hit the ceiling and new creates or public high-traffic status can stall, though you can still edit what exists. Exact numeric caps show in-product only and may change. Community threads after the multi-million Sites wave included people stuck on ~50% warnings with no clear “buy more headroom” button.
- Versions can pile up. Forum reports of triple-digit version counts (e.g. 162 versions ~1.9GB) with no confirmed UI to prune individual versions – only full Site delete. Delete is permanent; you type the slug to confirm (OpenAI Developer Community thread).
- Editors can ship after first publish. Can edit means they can publish later versions to the same URL without a separate owner-approval step. Owner still owns the access list, URL, secrets, and custom domain.
- Private ≠ anonymous. External invitees need the ChatGPT identity that received access. Client has no account and you refuse public mode? Sites may not fit.
Is a beta host with unpublished numeric caps the right home for your only customer funnel? Maybe not. For internal boards, workshop tools, and throwaway prototypes that need a real link by Friday, it’s hard to beat.
FAQ
Do I need to know how to code?
No. Plain language is enough on the Sites feature page. Code helps only when something weird breaks.
I’m on Plus – is Sites included, and what does it cost?
During public beta (as of current Help Center plan lists): Plus, Pro, Business, Enterprise, and Edu. Free and Go are out. Plus is $20/month per OpenAI’s Plus help article – there’s no separate Sites invoice in beta; you’re on the plan-specific usage meter inside Sites. Don’t see the feature? Check plan, workspace/region settings, and that you’re actually in Work.
Can teammates edit, and can I use my own domain?
Grant workspace members Can edit only if you’re fine with them publishing to the live URL after your first ship – there’s no mandatory owner approval on later publishes. Custom domains: you already own the domain, you set DNS, Enterprise had a launch carve-out. Secrets and domains stay owner-only.
Open Work right now, paste the shift-board prompt above (swap in your real job), and stop at “save a version – do not deploy.” When the preview survives a ruthless click-through, deploy once and copy the link to one teammate only. That single constrained loop teaches you more than another feature list ever will.