Updated July 27, 2026. The product’s official name is ChatGPT Sites; the article also uses the shorter search term GPT Sites. The feature is in public beta, and access depends on your plan, region, and workspace settings.
If GPT Sites is available in your account and you need a landing page, portfolio, event page, internal portal, dashboard, or lightweight web app, this is currently the simplest and fastest path from idea to a live URL. You describe the task in plain language, ChatGPT creates the site, shows a private version, applies edits, and publishes the finished version. There’s no need to separately choose a website builder, move the design into code, set up hosting, or configure deployment.
This is the editorial conclusion of AI Dawn based on the product design, not an independent speed test. For a large e-commerce store, a complex SaaS, unusual infrastructure, or a project with strict data requirements, custom development may still be the better choice.
In short: start your prompt with the word
websiteor mention@Sites, describe the audience, goal, pages, visitor actions, and constraints. Check the mobile version, copy, forms, and access, save the version, then ask to publish the site and provide the URL.
Contents
- What GPT Sites Is
- Why It’s the Shortest Path to Publishing
- What Kinds of Sites You Can Build
- How to Build a Site with GPT Sites
- Ready-to-Use Prompt for Your First Site
- What to Check Before Publishing
- How to Publish a Site and Manage Versions
- How to Connect Your Own Domain
- Access, Data, and Security
- When GPT Sites Isn’t a Good Fit
- GPT Sites vs. a Traditional Website Builder
- FAQ
- Bottom Line
What GPT Sites Is
GPT Sites is the common name for ChatGPT Sites, an OpenAI feature for creating, hosting, refining, and publishing websites, web apps, and games. In the official Sites documentation OpenAI suggests using it when you want to turn a prompt or a compatible local project into a hosted web product without a separate deployment process.
This is an important difference from the old “ask ChatGPT to write HTML” workflow. Before, the model could generate code, but then the user still had to:
- save the files;
- understand the project structure;
- find hosting;
- set up a build process;
- upload the code;
- get a domain or technical address;
- repeat everything after edits.
In Sites, that chain is built into one workspace. You keep the conversation going: “make the headline shorter,” “add a calculator,” “check the mobile version,” “save this version,” “publish it and give me the link.”
Why It’s the Shortest Path to Publishing
The speed here doesn’t come from AI typing code faster than a human. The main savings come from eliminating handoffs between different tools and people.
AI Dawn describes this as a model of “five launch gaps”:
| Gap | Typical Process | What GPT Sites Changes |
|---|---|---|
| Idea → text | the brief is handed to a copywriter | ChatGPT suggests the structure and draft in the same conversation |
| Text → interface | content is moved into a layout | the text becomes part of the page right away |
| Interface → code | a developer builds the design | a working version is created from the description |
| Code → hosting | you have to choose a platform and configure the build | hosting is included in Sites |
| Hosting → link | deployment and access are set up separately | after deployment, Sites returns a live URL |
This model is an editorial way to explain the product, not an OpenAI metric. But the underlying flow is confirmed in the documentation: Sites creates a project, stores versions, deploys the selected version, and provides a production address.
The conversational editing flow is especially useful. In a builder, the user has to find the right block, adjust spacing, move sections, and configure states. In GPT Sites, you can describe the result you want: “keep one call to action on the first screen, put three benefits below it, and show the form after the examples section.”
What Kinds of Sites You Can Build
GPT Sites works best for a focused project with a clear audience and one main action.
| Task | What to Build | Primary Action |
|---|---|---|
| Service launch | landing page | submit a lead |
| Personal brand | portfolio | view work and get in touch |
| Event | registration page | study the program and register |
| lead magnet | calculator or quiz | get a quote |
| Team Work | internal portal | find documents, owners, and statuses |
| Project Management | dashboard or tracker | update and filter records |
| Training | interactive guide | go through the steps and save progress |
| Idea Validation | prototype | show the scenario to first users |
OpenAI Academy recommends starting with a small task for a specific group: a launch tracker, a weekly dashboard, a calculator, an onboarding page, or a project hub. That scale is easier to test and improve.
Sites can do more than display static content. According to the official documentation, for saved records and progress you can request a relational database; for uploaded files, object storage; and for a public site, optional sign-in via ChatGPT. It’s best to name the needed features in the first prompt so the system immediately chooses the right project format.
How to Create a Website with GPT Sites
The process consists of seven steps.
1. Open Sites
In the ChatGPT web app, open the Sites workspace or go to website creation from the chat. In the desktop app, the feature may also be available in ChatGPT or Codex workspaces. If Sites doesn’t appear, check your plan, region, app version, and workspace settings.
2. Define the outcome
Don’t start with button colors. First answer five questions:
- who will visit the site;
- what problem it solves;
- what the visitor should understand in the first 10 seconds;
- which single action is the main one;
- which assets and constraints are required.
Weak prompt: “Make a beautiful website for an agency.”
Working prompt: “Create a one-page website for e-commerce store owners who need support automation. On the first screen, explain the result, then show three scenarios, implementation stages, FAQ, and a contact form. Keep the tone businesslike, without promises of guaranteed savings.”
3. Start Sites mode
Add the word website to your prompt or mention @Sites. This is the marker the official documentation recommends for explicitly starting the Sites workflow.
4. Provide the materials
Attach anything that can’t be reliably invented:
- product name and description;
- logo and brand colors;
- actual prices;
- contact information;
- photos and rights to use them;
- reviews with permission to publish;
- legal documents;
- links to existing pages;
- a data table, if you need a dashboard.
Don’t upload secret keys, passwords, or private customer data. Sites has separate settings for environment variables and secrets.
5. Review the first version
Look at the site through the eyes of a new visitor, not the author:
- is the offer clear without context;
- is the main button visible;
- do the texts match the real terms;
- do the links, forms, filters, and calculations work;
- is the page readable on mobile;
- are there any invented clients, numbers, or certifications.
6. Make revisions based on results
A revision should describe the observed problem and the desired outcome.
| Instead of | It’s better to write |
|---|---|
| “Make it more modern” | “Remove two decorative blocks, enlarge the headline, and keep only one button on the first screen” |
| “Improve the copy” | “Cut the first screen to 35 words and state the result for the customer in the first sentence” |
| “Fix the mobile version” | “On a 390 px screen, remove horizontal scrolling, make the buttons full width, and keep them at least 44 px tall” |
| “Add trust” | “Add a block with the workflow and sources; don’t invent reviews, clients, or awards” |
7. Save the version and publish
When the result is ready for review, ask to save the version. After the final check, ask to deploy that exact version and provide the production URL. OpenAI separates version saving from publishing: this lets you prepare a launch candidate without updating the public site too early.
Ready-to-use prompt for your first site
Copy the template and replace the data in square brackets:
@Sites, create a website for [audience]. Website goal: [what the visitor should understand and do]. Product or project: [short description]. Main action: [leave a request / register / get a quote].
Structure: first screen with a concrete result and one primary button; the audience’s problem and who the solution is for; three key benefits without unverified promises; a 3–5 step workflow; use cases or examples; an FAQ with five questions; a final call to action and contact information.
Requirements: responsive version for phone, tablet, and laptop; clear navigation and accessible controls; fast first screen without unnecessary animation; title, description, one H1, and a logical H2/H3 structure; Open Graph, canonical, robots.txt, and sitemap.xml, if supported.
Don’t invent prices, reviews, clients, awards, or statistics. Use only the attached materials and clearly mark any missing data. First show a brief site outline. Then create the first version, check the main scenarios, and list what I need to confirm before publishing.
For a portfolio, replace the scenario block with projects. For an event, add the agenda, speakers, and registration form. For an internal tool, describe roles, fields, filters, access permissions, and which data should persist between visits.
What to check before publishing
A finished URL does not yet mean a finished website. The minimum review takes one pass through four groups.
Content
- the company name, pricing, and contact details are correct;
- the page has one clear H1;
- the hero section explains what is being offered and to whom;
- there are no made-up facts;
- all external materials can be published;
- forms and data collection include the necessary explanations.
Interface
- menus and buttons work;
- there is no horizontal scrolling at 390 px width;
- text does not overlap;
- interactive elements are keyboard accessible;
- the contrast makes the text readable;
- loading and error states are clearly explained.
Functions
- the form actually sends data;
- the calculator handles boundary values correctly;
- filters and search return the expected result;
- uploaded files are saved where promised;
- restricted sections are not accessible to outsiders;
- after refreshing the page, the needed data does not disappear.
Publishing
- the correct audience has been selected;
- the public link opens without your account if the site is meant to be publicly accessible;
- the approved version has been saved;
- secrets did not end up in the text, code, or attachments;
- the custom domain points to the right project;
- after deployment, the main flow was checked again.
OpenAI Help also recommends checking content, links, files, forms, interactive behavior, audience, and handling of personal information before granting access.
How to publish a site and manage versions
Sites has two different actions:
- Save version. The system builds a version that can be reviewed and deployed later.
- Deploy version. The system publishes the selected build and returns a live URL.
Each deployment URL is a production URL. That is why, for changes to an already live site, it is safer to save a new version first, review it, and then deploy it.
Example command:
Save the current version without publishing. Check the mobile layout, all links, the lead form, and the absence of secrets. Show the issues you find. After my confirmation, deploy this saved version and give me the production URL.
After publishing, the site can be reopened in Sites, the changes described, a new version saved, and the deployment updated. You can also change the visitor scope separately: keep access limited to the owner and administrators, open it to selected people or groups, the entire workspace, or the internet — the available options depend on the account and the organization’s policy.
How to connect your own domain
Where custom domains are available, Sites lets you connect a root domain or a subdomain. OpenAI does not register domains: the domain must already belong to you.
Steps:
- open the site settings;
- choose add domain;
- enter the domain or subdomain;
- copy the DNS records provided;
- add them at your registrar or DNS provider;
- after a few minutes, refresh the status in Sites;
- open the address and check HTTPS and the main page.
If you do not have your own domain, the published site can run on a technical subdomain associated with ChatGPT Sites. In the ChatGPT Sites terms OpenAI gives, as an example, an address ending in chatgpt.site.
Access, data, and security
The simplicity of launch does not remove responsibility from the owner. If the site collects names, email addresses, files, or other personal data, the owner is responsible for the legality of processing, informing visitors, obtaining consent, and having a privacy policy when required.
Practical rules:
- keep access closed until testing is complete;
- choose the narrowest appropriate audience;
- do not insert API keys or passwords into prompts;
- store secrets in environment settings;
- do not publish client data without a valid basis;
- do not use images or text without rights;
- check what data the form saves;
- explain to visitors the purpose of signing in through ChatGPT;
- do not accept payment card data inside your own Sites code.
According to the documentation, a public site can remain open without sign-in, while ChatGPT-based authentication is added separately for personalized features. In Enterprise, public publishing may be disabled by default by an administrator.
When GPT Sites is not a fit
Sites is a good choice, but not for every web project.
| Scenario | Why a different approach is needed |
|---|---|
| Large e-commerce store | catalog, payments, inventory, returns, and integrations require a specialized platform and validation |
| Complex SaaS | may require unsupported infrastructure, background processes, and a custom architecture |
| A system with strict data residency requirements | OpenAI notes that Sites does not support data residency at launch |
| A project involving payment card data or protected health information | such data cannot be processed through Sites in the stated form |
| A nonstandard private network or database | some networks, databases, frameworks, and hosting methods are not supported |
| Maximum infrastructure control | Managed hosting is convenient, but it gives you less control than your own environment |
| The feature is not available on your plan or in your region | you will need a different builder or a standard deployment |
There is also a middle-ground option: build or adapt a compatible project locally, then use Sites for hosting and publishing. The documentation allows you to start not only from a prompt, but also from an existing compatible project.
GPT Sites or a standard website builder
The choice depends on the type of work.
| Criteria | GPT Sites | Standard no-code builder | Custom development |
|---|---|---|---|
| Getting started | plain-language description | template selection and block assembly | brief and team work |
| Revisions | conversation about the result | manual editing | task for a developer |
| Hosting | included | usually included | configured separately |
| Interactivity | you can request an app, data, and files within the available limits | depends on widgets | determined by the architecture |
| Code and infrastructure control | limited by the Sites environment | usually limited by the platform | maximum |
| Best-fit scale | a focused website or lightweight app | a standard marketing website | a complex long-term product |
Choose GPT Sites, if the top priority is getting a working first version fast, discussing changes in plain language, and publishing the result right away.
Choose a standard builder, if the team already knows it, needs precise manual control over blocks, and the whole project fits within the platform's capabilities.
Choose development, if you need custom infrastructure, complex integrations, strict data requirements, high load, or a long-term product architecture.
FAQ
Are GPT Sites and ChatGPT Sites the same thing?
In this article, yes. GPT Sites is used as a short search-friendly variant. OpenAI's official name is ChatGPT Sites.
Can I create a website without knowing code?
Yes. You can start with a plain-language description. Code may be needed to verify or custom-fine-tune a complex project, but it is not required for a first focused website.
Do I need separate hosting?
No, if the project is published through Sites: hosting is part of the workflow. After a successful deployment, the system returns a production URL.
Can I connect my own domain?
Yes, where the feature is available. You need to buy the domain in advance and add the DNS records provided by Sites through your registrar.
Is GPT Sites available to everyone?
No. As of July 27, 2026, the feature is in public beta. Access depends on your paid plan, region, rollout stage, and workspace settings. You should check the current status in your account interface.
How long does it take to build a website?
OpenAI does not promise a single time frame. A simple page requires fewer iterations than an app with a database, files, and sign-in. So it is more accurate to talk about shortening the process rather than promising a website in a fixed number of minutes.
Can I update the website after publishing?
Yes. Ask for changes, review the new version, save it, and deploy the update. Do not replace the published version before testing it.
Is GPT Sites good for SEO?
It lets you build a content website, but SEO still needs to be checked: one H1, title and description, clear URLs, canonical tags, internal linking, indexability, sitemap, speed, and useful content. The availability of specific technical settings depends on the project and the Sites environment.
Can I create a lead form or calculator?
Yes, these are typical lightweight app tasks. Before publishing, check form submission, data storage, calculation edge cases, and notifying the user about data processing.
Conclusion
GPT Sites turns website creation into a conversational task: describe the audience and the result, look at a working version, ask for fixes, and publish the chosen build. For a landing page, portfolio, project page, dashboard, or small tool, this shortens the path more than simple code generation because hosting and deployment are already part of the process.
Start with one website and one primary action. Use a ready-made prompt, do not let the system invent facts, check the mobile version and forms, save the approved build, and only then deploy it publicly.
If the task already involves complex commerce, special infrastructure, or sensitive data, treat GPT Sites as a prototyping tool or choose a different technical environment.