Overview

ChatGPT Sites lets workspace members create and share hosted Sites from ChatGPT. Workspace owners and admins can help determine who can create Sites, who can publish them, how Sites are shared, and how Sites should be reviewed or removed when needed.

This article is for ChatGPT Business, Enterprise, and Edu owners and admins. Available controls depend on your plan and workspace configuration.

Owner / admin responsibilities

Before enabling Sites broadly, decide who should be able to create Sites, whether public publishing should be allowed, what content can be published, and how your organization will handle support, review, takedown, and compliance questions.

Enable or limit Sites

Business workspaces have Sites enabled by default. Enterprise owners and admins can use role-based access controls (RBAC) to decide who can create Sites and who can publish them.

In Enterprise workspaces, public publishing is off by default. To enable it, turn on public publishing in Workspace settings, then grant the appropriate users or groups permission to create and publish Sites through RBAC.

If a workspace member cannot use Sites, check whether Sites is enabled for the workspace, whether the member is in an eligible role or group, and whether the member is signed in to the correct workspace.

Manage publishing and access

A Site can be limited to its owner and workspace admins, shared with active members of the workspace, or shared with selected active users or groups where supported. Public access is available only when public publishing is enabled and the member has permission to publish.

With co-editing a Site owner can give an eligible active member of the same workspace Can edit access. Editors can update and save a shared Site. After the owner publishes the Site for the first time, editors can publish later versions to the same Site URL.

Only the Site owner can manage who has access, change the Site name or URL, transfer ownership, or configure owner-only settings such as secrets and custom domains. The owner can change an editor to Can view or remove them. These changes stop the person from editing; whether they can still view the Site depends on its remaining audience settings.

Public sharing makes a Site available outside the workspace according to the audience selected in the publishing flow.

Available controls vary by plan and workspace configuration. Custom domains are not available in Enterprise workspaces at launch. If you cannot find or use a control, contact OpenAI Support.

External viewers

Site owners can share a Site with named people outside the workspace as viewers, instead of publishing the site to the broad internet. Sites creators in Business workspaces have this enabled, as a part of the overall Sites permissions in Workspace settings; in Enterprise workspaces, the the inviter needs the external-viewer invitation permission (see below). Workspace owners and admins can manage external viewers through the available Site access controls, in Workspace settings > Sites.

In Enterprise/Edu workspaces:

1. Go to Workspace settings > Permissions & roles.

2. Select the role that should be allowed to invite external viewers or choose workspace defaults.

3. Under Early access > Sites, make sure Sites is enabled for that role, or for the workspace.

4. Turn on Allow members to invite external visitors to sites for the selected role.

External viewers receive view-only access. They do not become workspace members or Site editors, and an invitation does not make the Site public. Public-publishing controls and external invitation permission are separate checks.

When granting or removing an external viewer, review the Site's existing audience. Removing a direct invitation may not remove access provided by another audience setting. Confirm the saved access list and the intended visitor experience after changes.

If the external invitation option is unavailable or a change does not take effect, confirm the selected workspace, the actor's role and invitation permission, and the surface being used. Contact OpenAI Support if the issue persists.

Data, compliance, and residency considerations

Sites can involve prompts, instructions, files, site code, generated artifacts, hosted URLs, storage, and logs needed to operate and secure the Site.

ChatGPT Sites does not support data residency or inference residency at launch. This includes deployed Sites, Site code, D1/R2 data and file storage, artifacts, and logs. Learn more in Data residency and inference residency.

Recommended workspace policy

• Give members clear guidelines for creating Sites that comply with your organization’s security, confidentiality, privacy, and other requirements.

• Define a policy for when public publishing is allowed.

• Require review before publishing sites that include confidential, sensitive, or third-party content.

• Decide who can approve public Sites and who can remove them.

• Document where members should report suspicious, malicious, infringing, or unsafe Sites.