How to use ChatGPT Sites: From prompt words to hosted website publishing and security checks

Mon, 13 Jul 2026 07:39:00 +0800

ChatGPT Sites is a managed website building workflow in ChatGPT: it can create, host, modify and share websites, web applications or mini-games. It is suitable for quickly making internal tools, demo pages and lightweight product prototypes, but it cannot be used as a “one-click go online without checking after generation” tool - each deployment URL is the address of the production environment.

This article is based on [OpenAI official Sites document] (https://learn.chatgpt.com/docs/sites) to organize a practical process from requirement description to release acceptance. Sites is currently a public beta feature, and actual availability is affected by plan, region, and workspace settings.

First distinguish: Sites, Codex and ordinary ChatGPT dialogue

Sites’ responsibility is to manage hosting projects and releases. You can enter through “More > Sites” on the ChatGPT Work web page, or use it on the ChatGPT desktop side. Codex CLI and IDE extensions can edit and test local projects, but there is no independent Sites management interface; when you need to create, save, deploy or adjust access permissions, you still return to the ChatGPT web or desktop.

This means that a sound division of labor is:

Use Codex to check the code, dependencies and build results locally;
Use Sites to generate a hosted version or connect to a compatible local project;
Review content and data processing in Sites preview;
After confirming the audience and permissions, deploy the production URL.

Don’t confuse Sites with ChatGPT Project. A Site is a hosted product that can be continuously opened, modified, configured, and shared; it persists after the initial Work task ends.

Before creation: Write the requirements into acceptable prompt words

At a minimum, the prompt should describe the audience, page purpose, core interactions, and data sources. It’s usually not enough to just say “make a project management website”. It’s better to add who uses it, what to save, and how to control permissions.

For example, the following prompt clearly states the functional boundaries and acceptance conditions:

1
2
3

为运营团队创建一个项目需求看板。成员可以提交需求、查看负责人、更新状态并按状态筛选。
仅限工作区成员登录；需求记录必须在刷新页面后保留。
先生成可审查版本，不要发布；同时列出需要我确认的数据字段和权限设置。

The last sentence is important: it explicitly requires saving the version first rather than going live. If it is just a display landing page, it should also indicate “no persistent data required” to prevent the system from introducing unnecessary storage for temporary UI state.

Choose the right data and identity capabilities

According to official documentation, Sites can access different capabilities based on product form:

need	Competencies that should be clearly stated
Landing page, content station	No need to persist state by default
User records, progress, scores	D1 relational database
Upload pictures, documents, audio and video	R2 object storage
Upload files and their searchable metadata	D1 saves metadata, R2 saves files
For internal employee use only	Workspace authentication
Public facing and login required	Authentication-enabled Site

The criterion for persistent data is simple: whether the user expects to see it the next time they visit. Temporary display states such as theme colors and closed banners are generally not required; orders, form records, uploaded files, and game scores are.

Practical operations: describe, review, modify, save

A repeatable workflow is as follows:

Describe Site: Enter clear requirements and attach reference documents, brand materials or existing projects;
Review Preview: Check whether the page text, interaction, and data are as expected;
Iterative modification: Select Edit in the preview and describe the changes in natural language; add screenshots or files if necessary;
Save version: Let ChatGPT build a deployable version, but not publish it yet;
Deploy version: Only after confirming the content, permissions and audience, the approved saved version is required to be deployed.

“Save version” and “Deploy version” are two stages. For local projects, the saved version will be associated with the Git commit used for building, so check the workspace status before committing to avoid bringing unverified changes online.

If you want to bring an existing project online, you can ask this question:

1
2

检查当前项目能否生成兼容的 Sites 部署产物；修复必要的兼容性问题，
保存一个可审查版本并说明改动。不要部署，等我确认后再发布。

Four checks before publishing

Release is not a final button press, but a round of acceptance. Check at least the following:

Content and Behavior: Whether the page uses correct information, and whether forms, filters, jumps and error states are available;
Data and files: Whether the uploaded content, database records and access scope meet expectations;
Access Rights: Prioritize the narrowest sharing scope, such as only yourself, invited members, workspace members, and finally “anyone with the link”;
Real access test: Open the shared production URL and confirm whether it can be accessed with the permissions of the target audience.

Workspace administrators can restrict public sharing. Even if a shared link is obtained, visitors will only have browsing permissions and will not automatically have permission to edit the Site.

Don’t give the key to the prompt word

Runtime environment variables and keys should be added, updated, or removed in Sites’ settings. Do not put keys in prompts, attachments, site content, .openai/hosting.json, or Git commits.

Local projects should still use .env and .env.example to manage variable names required for the development environment; .env.example only retains key names and safe examples, not real values. After changing the managed environment variables, you need to redeploy the reviewed version before the new configuration can take effect in the production environment.

For projects connected to local source code, .openai/hosting.json is used to record managed project associations and optional storage bindings, such as the binding name of project_id, D1, or R2. It’s not a secret profile.

FAQ

Why can’t I find Sites?

Sites is still in public beta and availability is tied to plan, region, and workspace settings. First confirm that you are using ChatGPT Work web client or ChatGPT desktop client; if it is not visible in the managed workspace, then confirm the functions and sharing policies with the administrator.

Can I manage releases using just the Codex CLI?

cannot. Codex CLI can modify and test local projects, but creating, saving, deploying and managing Sites must be completed on the ChatGPT web or desktop.

Why do I find that the content is incorrect after “deployment is successful”?

Because the deployment URL is already the production address. Next time, ask to save the reviewable version first, check the preview and source code changes before deploying; if it is already online, tighten the access scope immediately, then fix and release a new reviewable version.

Conclusion

The value of ChatGPT Sites is to put “conception, generation, hosting, and iteration” into the same workflow, but the release responsibility remains with the user. Fixing the process as “clear requirements → save version → preview review → least privilege sharing → real access acceptance” can significantly reduce the risks of direct exposure of prototypes, improper data configuration and key leaks.

Deployment on KnightLi Blog