Current-check note — 4 September 2026: OpenAI’s Creating and managing ChatGPT Sites page is the primary source for the product facts in this guide. The source packet did not provide an exact publication or update date; the Help Center currently displays a relative update age. Availability, limits and workspace controls can change during the public beta, so check the live experience before committing a launch.
Bottom line: ChatGPT Sites can turn a prompt, a set of files and a defined brief into an interactive website or lightweight app that you can preview, edit, publish and share. For a marketer, that makes it useful for a campaign prototype, internal launch tracker, event microsite or client-facing proof of concept. It is not a reason to skip content review, accessibility checks, analytics planning, legal review or a proper production change process. OpenAI says every deployment URL is a production URL, so treat the deploy step as a release—not as a harmless preview.
The right mental model is a fast site-building surface with workspace and publishing boundaries. Start with a bounded reader or business job, give ChatGPT only the approved material it needs, review the generated site in context, save a version, and deploy only when the content, tracking and access decisions are written down.
What ChatGPT Sites does
OpenAI describes ChatGPT Sites as a way to create, preview, publish and share interactive websites and lightweight apps. You can start in Work on ChatGPT web, or in Work or Codex in the ChatGPT desktop app. A prompt can ask for a website and include the content, files, data, links and constraints that should shape the result. You can also mention @Sites when you want to make the site-building intent explicit.
The examples in the current Help Center documentation include dashboards, project trackers, launch calendars, internal portals and reports. Those examples matter for marketing because they map to real operating jobs: an editorial calendar that a team can check, a campaign brief that has one current version, a lead-generation prototype for a discovery session, or an event page that needs to be reviewed quickly. The useful outcome is not “AI made a pretty page.” It is a page with a defined audience, an owner, a source of truth and a clear next action.
Sites is different from ChatGPT site tools and WebMCP. The existing WP2627 owner covers tools that a website exposes to ChatGPT inside a browser, including permission and prompt-injection boundaries. Sites is the creation and deployment surface itself. A Site can contain a page or lightweight app; a site tool is an action supplied by another website you opened. If the decision is about model quotas or Codex usage rather than site publishing, use DMT’s Codex usage and limits guide instead.
Availability is conditional
The current Help Center page describes public-beta availability for ChatGPT workspaces, Plus and Pro accounts. It also says rollout may not have reached every account. Free and Go accounts are not listed as eligible, and the page says Sites is not available at launch in the EEA, Switzerland or the United Kingdom. Workspace settings add another layer: Business workspaces have Sites enabled by default in the documentation, while Enterprise administrators must enable it through role-based controls. Public publishing is off by default in Enterprise.
Those are product boundaries, not a guarantee that a particular employee or client can see the same controls. Before you promise a delivery date, check the actual plan, region, workspace, role and desktop-app version. Sites is not available in the ChatGPT Classic app. Beta usage limits apply across the account’s Sites and can change; reaching a limit may prevent a new Site or extra storage, even though existing Sites can still be edited or managed.
| Question | What the current OpenAI documentation says | Marketer’s operating response |
|---|---|---|
| Who can use it? | Public beta for workspaces, Plus and Pro, subject to rollout and workspace controls. | Test the exact account, role and region before making it part of a client workflow. |
| Can an Enterprise member publish publicly? | Public publishing is off by default and needs administrator enablement. | Get the workspace owner’s decision before building a public launch plan. |
| Are limits fixed? | No. Beta limits are plan-specific, apply across Sites and may change. | Keep a fallback delivery path and do not assume a new Site can be created on launch day. |
| Is a deployment a draft? | No. Every deployment URL is a production URL. | Run content, tracking, access and rollback checks before deploying. |
Choose a marketing job that fits the surface
Sites is a sensible candidate when speed and collaboration matter more than a large content model or a complex commerce stack. Good first jobs include:
- Campaign prototype: turn an approved brief, offer, audience definition and message hierarchy into a reviewable page before the main site build.
- Event or launch microsite: present dates, speakers, agenda, resources and registration links in one place while the team validates the message.
- Internal launch tracker: give owners one view of milestones, creative status, approvals, risks and links. Keep sensitive customer data out of the prompt unless the workspace and handling rules allow it.
- Client proof of concept: demonstrate an information architecture or interaction idea without implying that the prototype is the final production website.
- Lightweight calculator or report: expose a bounded interaction using approved inputs and explain what the output means, what it does not mean and who owns the result.
Do not treat a generated Site as automatically suitable for a checkout, regulated claim, high-volume content system or a customer-data repository. If you sell goods or services or collect payments, OpenAI’s Help Center says you are responsible for connecting and maintaining any third-party payment processor and for fulfillment, refunds, support, warranties, taxes and related obligations. A hosted page does not move those responsibilities to OpenAI.
Build from a brief, not a vague prompt
The quality of the result starts before the first prompt. Write a one-page brief with the intended audience, the decision the visitor should make, the source documents, the allowed claims, the desired sections, the call to action, the success event and the constraints. State what the Site must not do. For example, an event page may show the approved schedule and link to a registration system, but it should not invent speaker credentials, promise availability or accept payment until those integrations have been separately approved.
Ask for a first version that is easy to inspect. Request semantic headings, short paragraphs, descriptive links, accessible labels, visible error states, a mobile layout and a clear content owner. Ask it to show assumptions and to mark any missing source data. A prompt such as “build a beautiful landing page” hides the decisions that matter. A bounded prompt such as “build a private event-page prototype from this approved brief, use only these claims, include a registration link, and list every missing field before publishing” produces a better review object.
For the broader marketing workflow, DMT’s ChatGPT for Digital Marketing guide provides context on using AI across research, content and measurement. Keep the Sites-specific page focused on the build and release boundary rather than recreating a general AI-marketing overview.
Review the generated Site like a production change
OpenAI’s documentation says a Site can be previewed and refined before deployment, but it also warns that deployment URLs are production URLs. That means the preview is your QA environment and the deploy action is your release boundary. Use a checklist with named owners:
- Source review: compare every factual claim, date, price, eligibility statement, testimonial and product promise with the approved source. Remove invented statistics and unsupported guarantees.
- Reader review: ask a person who matches the target audience to complete the page’s main task. Record confusion, dead ends and missing proof.
- Content and accessibility: check heading order, link purpose, keyboard focus, contrast, alt text, form labels, error messages, language and mobile wrapping.
- Technical review: test every link, button, form, calculation, data state and external handoff. Check the page at the real deployment URL, not only in the preview.
- SEO review: define the title, description, canonical intent, indexability decision, structured data and internal links. Do not assume that a generated page has the metadata or crawl controls your search plan needs. DMT’s technical SEO guide covers crawl, render and monitoring checks that belong in this review.
- Measurement review: decide which events are signals and which are business outcomes. Confirm the analytics destination, consent treatment, UTM convention, form handoff and data owner before launch.
- Approval and rollback: save a reviewed version, name the approver, record the deployment time and define how to remove or replace the Site if the brief changes.
Do not use a platform-reported visit, click or generated page as proof that a campaign worked. Tie the Site to a measurement plan and reconcile it with the downstream system. If the page supports a paid campaign, the ChatGPT Ads product-feed guide is a separate implementation owner; this article only covers the Site’s creation and release workflow.
Deployment, domains and version control
When you deploy, ChatGPT generates a Site URL. OpenAI’s Help Center explicitly says every deployment URL is a production URL. Save a version before deploying if you need to review changes without updating the live Site. A small team should keep a release receipt with the version, source brief, approver, intended audience, links, tracking checks, access setting and rollback decision.
Custom domains are available only where the relevant account and workspace support them. Sites does not register a domain for you: you must already own the domain and be able to change its DNS records. The documented setup involves adding the apex domain or subdomain, copying the DNS records and values provided by Sites, changing them at your domain provider, then refreshing the status. Keep DNS ownership with the person who already controls the domain, and record the change in the normal domain-change log.
Do not point a valuable campaign domain at an unreviewed preview. First confirm the desired URL, redirects, canonical behavior, analytics, consent notice, privacy copy, brand requirements and removal plan. If the Site is an internal portal, verify whether its access model matches the sensitivity of the information it displays. If it is public, verify what visitors can submit and where that data goes.
Privacy, workspace governance and brand boundaries
The Help Center documentation says a Site can include information from prompts, instructions, conversation context, uploaded or referenced files, site code, generated artifacts, hosted URLs, access settings, storage, metadata, logs and operational data needed to host, secure, debug or enforce policy. That list is a reminder to minimize inputs. Do not paste passwords, recovery codes, unnecessary customer records or confidential client material into a Site brief.
For Business and Enterprise/Edu customers, the current documentation says OpenAI does not use conversations with ChatGPT or information accessed from Sites to train models by default. For Free, Go, Plus and Pro, training behavior can depend on the “Improve the model for everyone” setting. This is not a substitute for your organization’s data-protection review. Confirm the workspace policy, lawful basis, retention expectation, access list and deletion process that apply to the project.
OpenAI’s ChatGPT Sites terms also place responsibility on the Site owner and prohibit design or statements that could lead people to believe an independent Site is created, supported, certified or endorsed by OpenAI without agreement. Use your own brand assets and claims. A ChatGPT-built page should not borrow OpenAI logos or imply a partnership simply because the build tool is ChatGPT.
A repeatable ChatGPT Sites launch workflow
Use this sequence for a first marketing test:
- Check eligibility: confirm plan, region, workspace, role and whether public publishing is enabled.
- Define the job: write the audience, desired decision, source of truth, prohibited claims, success event and owner.
- Create a private first version: include only the approved files, links and constraints; ask for missing-data and assumption notes.
- Review in preview: test the main path on desktop and mobile, inspect content, accessibility, links, forms and data handling.
- Run the measurement and SEO pass: verify event names, UTM conventions, metadata, internal links, consent and the handoff to the system of record.
- Save the reviewed version: preserve the version, source brief, review receipt and approval owner.
- Deploy deliberately: treat the production URL, custom-domain DNS and public access setting as release changes.
- Monitor and retire: reconcile the intended events with downstream outcomes, update the owner and remove the Site when its job ends.
If the team also relies on scheduled work, keep that workflow separate. DMT’s ChatGPT Work scheduled-tasks guide covers saved prompts, notifications and approval boundaries; a scheduled task does not automatically inherit a Site’s permissions, browser state or domain access.
ChatGPT Sites for marketers: FAQ
Is ChatGPT Sites a replacement for WordPress?
Not by default. It can be a useful lightweight site or prototype, but the right choice depends on content volume, editorial workflow, SEO controls, integrations, commerce, accessibility and governance requirements. Treat it as a candidate surface and test the actual requirements.
Can I publish a campaign page straight from a prompt?
You can ask ChatGPT to create and deploy a Site when your account and workspace permit it, but the deployment URL is production. Complete source, content, technical, measurement, access and approval checks first.
Will a ChatGPT Site rank in Google?
The existence of a Site does not guarantee crawling, indexing, rankings or traffic. Inspect the deployed page’s metadata and crawl behavior, make the indexability decision explicit and measure actual Search Console and analytics outcomes. Do not turn a builder capability into an SEO promise.
Can a Site collect payments?
OpenAI’s Help Center says payment collection can use a third-party processor, but the Site owner remains responsible for configuring and maintaining it and for fulfillment, refunds, support, warranties, taxes and related obligations. That is a business and compliance decision, not an automatic ChatGPT feature.
What should an Enterprise admin decide?
Decide who can create, edit, share and publish; whether public publishing is enabled; what information may be used; how access is reviewed; who owns a Site after launch; and how an expired Site is removed. Make the decision visible in the workspace runbook.
What the current evidence does not establish
- It does not establish that Sites is available to every account, role, region or workspace.
- It does not establish fixed beta limits or a guaranteed deployment capacity.
- It does not guarantee search indexing, rankings, conversion rate, uptime, speed or accessibility without testing the deployed page.
- It does not transfer payment, tax, fulfillment, privacy, legal or brand responsibility to OpenAI.
- It does not make a generated page an endorsed OpenAI property or permit unapproved use of OpenAI branding.
ChatGPT Sites is most useful when the team treats speed as an input to a disciplined release process. A clear brief, approved source set, private review, measurement plan and named owner turn a generated page into a manageable marketing asset. Without those controls, a fast deployment is simply a fast way to publish the wrong claim, expose the wrong data or create a URL no one knows how to retire.
Editorial note: Product facts in this evergreen candidate were checked against OpenAI’s current Help Center, OpenAI Academy and ChatGPT Sites terms on 4 September 2026. The public-beta boundaries and limits may change. Marketing workflow recommendations are DMT guidance, not an OpenAI performance or compliance guarantee. No media was generated for this packet.
Source notes
- OpenAI Help Center: Creating and managing ChatGPT Sites — primary product, availability, deployment, custom-domain, payment and data-handling source; exact page update date was not exposed in the source packet.
- OpenAI Academy: ChatGPT Sites — official examples for internal sites and lightweight apps; published 2 June 2026.
- OpenAI: ChatGPT Sites Terms — official brand and owner-responsibility boundaries; accessed 4 September 2026.
- TechRadar: AI website builders in 2026 — competitor framing accessed 4 September 2026; not authority for OpenAI product facts.
