ChatGPT Sites can turn a written description into a hosted website, but the quality of the result depends on how clearly you define the job and how carefully you test the output. The safest workflow is to build one useful experience, inspect it on desktop and mobile, save a version, and only then publish it.
Before you start
Confirm that Sites is available in your ChatGPT account. OpenAI is rolling out the public beta by plan and region, and workspace administrators can restrict public publishing. If @Sites or the website-building option does not appear, check ChatGPT Sites availability by plan and region before troubleshooting the browser.
Prepare four things before opening a project:
- The audience you are building for.
- The one task the site should help them complete.
- The content and sources the page must use.
- The interactions that must work, such as navigation, a calculator, or a form.
This prevents a vague prompt from producing a visually polished page with unclear purpose.
Start a site
Open ChatGPT Work on the web or Work/Codex in the desktop app. Ask for a website explicitly or mention @Sites. OpenAI recommends using the word “website” when you want the Sites workflow rather than a general code response.
A useful first prompt could look like this:
Build a responsive website for independent coffee shops comparing three monthly inventory plans. The main audience is an owner checking costs on a phone. Include a concise comparison table, an editable cost calculator, an FAQ, and a contact link. Use the supplied prices exactly and do not invent testimonials.
The prompt defines the audience, decision, required feature, and factual boundary. You can add brand colors, typography, source material, and accessibility requirements after the basic task works.
Review the first version
Do not publish from the first preview. Check the site as a visitor would:
- Does the first screen explain what the site is for?
- Can the main task be completed without instructions?
- Do navigation links and buttons work?
- Does the page remain readable on a narrow screen?
- Are prices, dates, names, and claims supported by your source material?
- Is any form actually connected to a destination?
- Are error, loading, and empty states understandable?
Ask ChatGPT to fix one group of issues at a time. A request such as “make it better” gives the system too much room to change content that was already correct. A narrower instruction such as “keep the copy and calculations unchanged, but fix the mobile table overflow” is easier to verify.
Save a version before publishing
OpenAI says every Sites deployment URL is a production deployment. There is no separate staging URL described in the documentation. Save a known-good version before publishing or making a large change, then preview the important paths again.
For an interactive project, test at least one normal case, one empty or invalid input, and one edge case. For a content site, check the title, description, headings, links, image credits, and legal pages.
Publish and choose access
Use the publish control and choose the sharing option allowed by your account. Depending on plan and workspace settings, a site may be limited to invited people, people in a workspace, or anyone with the link. Enterprise public publishing is disabled by default and must be allowed by an administrator.
After publishing:
- Open the public URL in a private browser window.
- Test it without relying on your signed-in session.
- Check the main path on a phone and desktop.
- Verify that restricted or private information is not exposed.
- Keep the saved version until the new deployment is confirmed.
If you plan to use your own address, review custom domains, beta limits, and privacy before changing DNS records.
Updating an existing site
Sites projects retain a link to their ChatGPT project through the project metadata described by OpenAI. Return to that project to request changes, review them, and deploy a new version.
Write update requests as acceptance criteria. For example:
Add a fourth pricing plan using the values in the attached table. Keep the existing URLs and visual hierarchy. Update the comparison table and calculator, then list the exact pages changed.
This makes factual changes easier to audit. For time-sensitive information, include a visible updated date and recheck the primary source before publishing.
Common mistakes to avoid
Publishing untested generated claims
Generated copy can sound confident even when a fact was not supplied. Remove unsupported numbers, endorsements, security claims, and legal promises.
Treating a visual form as a working form
A form can look complete without sending data anywhere. Submit it yourself and confirm the destination, validation, success message, and privacy disclosure.
Putting secrets in the prompt
Do not paste API keys or passwords into prompts, client-side code, or public files. OpenAI documents a dedicated secrets area for supported use.
Assuming a public URL is ready for large traffic
Sites is a beta with plan-based limits. Test the project and keep another hosting option in mind if availability is important.
Official sources
The workflow and publishing behavior above come from OpenAI’s ChatGPT Sites help article and Sites developer guide. For a broader overview, see what ChatGPT Sites is and how it works.
FAQ
What should I type to start ChatGPT Sites?
Ask for a website explicitly or use @Sites, then describe the audience, task, required content, and important interactions.
Can I preview a site before publishing?
Yes. Preview and test the project before using the publish control.
Can I undo a bad update?
Saving a known-good version before a major edit gives you a safer point to return to.
Is a published ChatGPT Site automatically public?
Sharing depends on the option you select and the controls allowed by your plan or workspace.
Can I manage Sites from the standalone Codex CLI?
OpenAI’s developer guide says Sites management is handled in ChatGPT web or desktop, not through the standalone Codex CLI or IDE extension.
Should I publish a generated privacy policy unchanged?
No. It must describe the services and data collection the site actually uses.