ChatGPT Sites Explained: Features, Hosting, SEO Limits, and the Best Use Cases

Key Takeaways

• ChatGPT Sites is OpenAI's integrated AI website builder and managed hosting platform, not merely a tool that generates HTML or React code.
• Users can create websites, dashboards, lightweight apps, interactive reports, internal tools, and browser games through natural-language prompts.
• Sites combines development, previewing, version management, production deployment, access control, analytics, database storage, file storage, secrets, and optional user authentication.
• Structured application data can be stored in a D1 relational database, while images, documents, audio, video, and other uploaded files can use R2 object storage.
• Public Sites can offer Sign in with ChatGPT for saved progress, personalized views, user-owned records, and identity-aware features.
• Custom domains are supported where available, although availability depends on the account, plan, region, and workspace configuration.
• Public beta limits are plan-specific and dynamic. OpenAI does not currently publish a universal bandwidth, traffic, deployment, or monthly storage allowance.
• ChatGPT Sites is highly competitive for prototypes, internal applications, interactive tools, and game validation, but it is not yet a proven replacement for established programmatic SEO infrastructure.

What Is ChatGPT Sites?

ChatGPT Sites is a managed website creation and hosting service built directly into ChatGPT Work and Codex. It allows a user to describe a desired website, attach supporting files or visual references, review the generated application, request changes, save versions, and publish the result without configuring a separate hosting provider.

A typical AI website builder generates code and sends the user to another platform for deployment. ChatGPT Sites attempts to cover the entire workflow:

1. Understand the website requirements.
2. Generate the interface and application logic.
3. Run and inspect the project.
4. Present a private preview.
5. Refine the website through follow-up prompts.
6. Save a deployable version.
7. Publish it through OpenAI-managed hosting.
8. Manage access, domains, environment variables, storage, and analytics.

This makes Sites closer to an integrated application platform than a conventional no-code page builder.

When Was ChatGPT Sites Released?

ChatGPT Sites first appeared as a preview in the Codex desktop application on June 2, 2026. The initial release focused on creating, saving, deploying, and inspecting websites hosted by OpenAI.

On July 9, 2026, OpenAI expanded Sites through ChatGPT Work and introduced broader public publishing. This made it possible to share a Site publicly through a URL rather than limiting it to members of a business workspace.

The public beta rollout included Pro, Pro Lite, Business, Enterprise, Edu, and later Plus accounts. Free and Go accounts were excluded from the initial public beta.

Availability can still vary because of:

• Gradual account rollout
• Geographic restrictions
• Workspace policies
• Administrator permissions
• Public publishing controls
• Plan-specific feature limits

If @Sites appears in the ChatGPT composer, the account has access to the native Sites workflow.

What Can ChatGPT Sites Build?

ChatGPT Sites supports substantially more than static landing pages. The platform can create both content-driven websites and stateful applications.

Common website types include:

• Marketing landing pages
• Product showcase websites
• Personal portfolios
• Event guides
• Interactive reports
• Launch calendars
• Project trackers
• Internal company portals
• Data dashboards
• Calculators and simulators
• Searchable resource libraries
• Submission and voting systems
• Training and onboarding hubs
• Daily puzzle games
• Browser-based 2D and 3D games
• Persistent leaderboards
• Lightweight customer-facing applications

OpenAI showcase projects demonstrate React, TypeScript, Three.js, React Three Fiber, WebGPU, physics engines, responsive interfaces, persistent game progress, and generated visual assets. The practical ceiling is therefore much higher than that of template-based AI page generators.

Core ChatGPT Sites Features

How the Creation and Publishing Workflow Works

A Site can be started by mentioning @Sites or explicitly asking ChatGPT to build a website. A strong request should define the audience, core task, content, behavior, storage requirements, and publication constraints.

The recommended workflow is:

1. Define the product clearly

Specify:

• Who will use the Site
• What problem it should solve
• The primary user journey
• Required pages and interactions
• Mobile and accessibility requirements
• Whether data must persist
• Whether visitors can upload files
• Whether authentication is necessary
• Who should be allowed to access it

2. Review the generated preview

Test more than the visual design. Review:

• Navigation
• Forms
• Validation
• Empty states
• Error states
• Responsive behavior
• Keyboard controls
• Touch interactions
• Database writes
• File uploads
• Sign-in and sign-out
• Access restrictions

3. Request precise revisions

Broad prompts such as make it better produce unpredictable changes. Better instructions identify a component, breakpoint, user action, and expected result.

4. Save a version

Saving creates a deployable candidate without necessarily updating the live production website. For local source projects, the saved version can be associated with the Git commit used during the build.

5. Deploy only after approval

Deployment publishes the saved version to the selected audience. Because deployment URLs are production URLs, changes should be saved and reviewed before deployment.

D1 Database and Persistent Application Data

ChatGPT Sites uses D1 for structured data that must remain available between visits. D1 is described as a relational, SQLite-compatible database.

Appropriate D1 use cases include:

• User profiles
• Saved game progress
• Daily puzzle results
• Leaderboards
• Bookmarks
• Comments
• Form submissions
• Event listings
• Status records
• Configuration
• Searchable file metadata

Each Site currently has a documented D1 storage limit of 10GB.

Temporary interface preferences do not always need a database. A dismissed banner, selected theme, or temporary filter can often remain in browser storage. Persistent business records, user progress, and shared application state should use server-side storage.

R2 File and Object Storage

R2 is intended for larger file objects, including:

• Images
• Avatars
• PDF documents
• Audio
• Video
• Downloadable resources
• User-uploaded attachments
• Generated media assets

Applications that need searchable uploads can combine the two storage systems:

• Store file bytes in R2.
• Store the filename, owner, type, timestamps, permissions, and searchable fields in D1.

OpenAI currently describes R2 as having no fixed per-Site storage limit. However, public beta account limits can still prevent additional storage from being added. No fixed limit should therefore be interpreted as elastic beta capacity, not guaranteed unlimited hosting.

Sign in with ChatGPT and User Identity

A public Site can remain accessible to anonymous visitors while offering optional Sign in with ChatGPT.

This enables:

• Personalized dashboards
• Saved preferences
• Individual game progress
• User-owned records
• Private collections
• Account-specific submissions
• Identity-aware leaderboards

After successful authentication, Sites can forward the verified email address and, when available, the profile name to server-side application code.

Authentication and authorization must remain separate. Knowing a visitor's identity does not automatically mean that the visitor should be allowed to read or modify a record. Every protected database operation should verify ownership or role permissions on the server.

Hosting, URLs, and Custom Domains

A published Site receives an OpenAI-managed production URL, commonly using a subdomain associated with chatgpt.site.

Where custom domains are available, users can connect:

• An apex domain such as example.com
• A subdomain such as app.example.com

The domain must already be registered. Sites provides DNS records that must be added through the domain registrar or DNS provider.

Important custom-domain limitations include:

• OpenAI does not register the domain.
• The owner must control its DNS settings.
• Availability depends on the account and workspace.
• Enterprise workspaces did not support custom domains at launch.
• DNS verification and certificate provisioning may require time.

Built-In Analytics

Sites automatically records basic traffic information without requiring an analytics SDK.

The current analytics interface includes:

• Unique visitors
• Page views
• Visitor trends over time
• Adjustable date ranges
• Adjustable reporting granularity

This is useful for answering whether anyone is visiting and whether usage is increasing. It is not a complete replacement for advanced analytics.

Missing or undocumented capabilities include:

• Search query data
• Acquisition channel attribution
• Conversion funnels
• Event-level product analytics
• Session recordings
• Search Console integration
• Cohort retention
• Revenue attribution

Enterprise-owned Sites may not have access to the same built-in Site analytics view.

Is ChatGPT Sites Good for SEO?

ChatGPT Sites can publish public websites and connect custom domains, but its long-term SEO suitability remains uncertain.

The official documentation does not currently establish comprehensive support for:

• Large XML sitemaps
• Sitemap indexes
• Editable robots.txt rules
• Canonical URL management
• Hreflang
• Bulk redirects
• Programmatic page generation
• Incremental static regeneration
• Structured-data management at scale
• Custom caching policies
• Search-engine log analysis
• AdSense-specific verification
• ads.txt
• Large multilingual content architectures

A small public landing page, event guide, calculator, or interactive tool may still rank if it is crawlable, useful, fast, and connected to a custom domain. The uncertainty becomes more serious for directories or programmatic SEO projects containing thousands of URLs.

Before using Sites for an SEO-dependent project, verify:

• Whether public pages render useful HTML without client-side delays
• Whether Googlebot can crawl all important routes
• Whether page titles and descriptions can be customized
• Whether canonical tags are correct
• Whether a sitemap can be generated and submitted
• Whether Search Console ownership can be verified
• Whether analytics and consent scripts can be installed
• Whether redirects survive future deployments
• Whether source code can be exported or migrated

For large SEO websites, an established stack such as Astro, Next.js, Cloudflare, Vercel, or a conventional server remains more predictable.

ChatGPT Sites vs Base44, Lovable, Vercel, and Cloudflare

ChatGPT Sites offers the shortest path from a ChatGPT conversation to a hosted interactive result. Vercel and Cloudflare still provide more infrastructure visibility, automation, portability, and control for mature production systems.

Best Use Cases for ChatGPT Sites

Internal dashboards

Sites is well suited to operational dashboards, weekly business reviews, project status pages, and searchable internal resources. Access can remain limited to selected users or the workspace.

Daily browser games

A daily guessing game can combine:

• Daily puzzle rotation
• Local streaks
• D1-backed global scores
• Sign in with ChatGPT
• Shareable emoji results
• Mobile and keyboard controls

This is particularly useful for validating whether a game loop is engaging before investing in independent infrastructure.

Interactive reports

A static document can be converted into filters, charts, calculators, scenario comparisons, and drill-down views. The result is easier to explore than a long PDF or spreadsheet.

Event and travel guides

Sites can produce event calendars with date filters, transportation information, ticket details, weather alternatives, accessibility labels, maps, and saved favorites.

Product prototypes

A founder can test a calculator, AI directory, comparison tool, submission workflow, content portal, or lightweight SaaS concept before building the final architecture.

Advanced Prompt Template

A production-oriented prompt should request requirements, testing, review, and controlled deployment rather than only visual generation.

@Sites

Build a public, mobile-first website for the specified audience and use case.

Requirements:
- Define the primary user journey before implementation
- Create responsive desktop, tablet, and mobile layouts
- Include accessible labels, keyboard navigation, focus states, and sufficient contrast
- Use D1 only for data that must persist between visits
- Use R2 for uploaded file contents and D1 for searchable file metadata
- Keep authentication and authorization checks in server-side code
- Add loading, empty, validation, failure, and success states
- Configure page titles, descriptions, canonical URLs, social metadata, and structured data
- Test navigation, forms, database writes, uploads, authentication, mobile layout, and console errors
- Keep the Site private during review
- Save a version before deployment
- Do not publish until the final version has been reviewed

After implementation, report the supported routes, storage bindings, environment variables, test results, limitations, and publication checklist.

Common Problems and Mistakes

Publishing the first generated version

AI-generated applications can contain broken links, weak error handling, inaccessible controls, or incorrect assumptions. The first version should be treated as a prototype.

Confusing preview with deployment

A saved version is a reviewable candidate. A deployed version is live production output. Publishing should remain a deliberate step.

Putting secrets in prompts

API keys and tokens should be stored in the Site settings as hosted secrets. They should not appear in prompts, attachments, source files, screenshots, or .openai/hosting.json.

Trusting client-side authorization

Hiding a button does not protect data. Every protected read and write must be checked by server-side code.

Assuming unlimited hosting

R2 may have no fixed documented storage cap, but account-level beta limits still apply. A high-traffic Site may be restricted if it exceeds the plan's current allowance.

Building unsupported infrastructure

Some private networks, databases, background services, frameworks, and hosting patterns are not supported. Compatibility should be confirmed before migrating an existing production application.

Collecting personal data without disclosures

A Site that collects identity information, uploads, comments, or form submissions may need a privacy policy, consent controls, moderation procedures, and a deletion process.

Security, Privacy, and Commercial Restrictions

The Site creator remains responsible for the website, its functionality, uploaded content, visitor submissions, and legal compliance.

Important restrictions include:

• Do not process protected health information.
• Do not directly process payment-card data.
• Do not target children below the applicable minimum age.
• Do not distribute malware or enable phishing.
• Do not impersonate individuals or organizations.
• Do not expose confidential workspace information through public publishing.
• Moderate visitor-submitted content where necessary.
• Use an external payment provider for ecommerce transactions.

Sites did not support data residency or inference residency at launch. Deployed code, database records, stored files, generated artifacts, and logs may therefore be processed outside a preferred residency region.

OpenAI may also display platform attribution in a Site footer or toolbar. A public Site should not imply that OpenAI endorses the website or operates the underlying business.

Should Businesses Use ChatGPT Sites in Production?

The answer depends on the consequences of failure and the importance of infrastructure control.

Good production candidates include:

• Short-lived campaign tools
• Public calculators
• Event guides
• Interactive reports
• Small internal portals
• Prototype communities
• Browser game experiments
• Low-risk resource libraries

Projects requiring more caution include:

• High-traffic advertising websites
• Large programmatic SEO directories
• Financial transaction systems
• Healthcare applications
• Applications with strict residency requirements
• Systems requiring long-running background workers
• Products that depend on private network access
• Applications requiring guaranteed infrastructure portability

A practical strategy is to use Sites for validation and early users, then migrate proven products to dedicated infrastructure when traffic, compliance, SEO, observability, or operational requirements justify the transition.

Conclusion

ChatGPT Sites turns ChatGPT into a complete lightweight website and application platform. Its most important advantage is not simply faster code generation; it is the removal of multiple deployment decisions that normally separate an idea from a usable public application.

The combination of AI development, managed hosting, D1, R2, authentication, version management, analytics, access controls, and custom domains makes Sites highly competitive for prototypes, internal tools, interactive reports, and browser games.

However, public beta limits, incomplete SEO controls, unclear high-traffic allowances, runtime restrictions, and uncertain portability prevent it from replacing established production infrastructure in every scenario.

The best next step is to build one focused Site with a real user journey, test storage and authentication, connect a custom domain if available, measure public traffic, and evaluate migration options before committing a large or SEO-dependent project to the platform.