ChatGPT Sites: create a site with AI and connect it to WordPress

Choose a project suited to ChatGPT Sites

ChatGPT Sites is ChatGPT’s website creation and hosting tool. You can start from a description in ChatGPT or Codex, then request changes after trying the first version. The service can host a showcase site, dashboard, form, calculator, game or compatible existing web project. Its appeal is bringing creation, revision and publishing into the same space. Content preparation, checks and audience choice remain in your hands.

For example, an association already owning a WordPress blog could prepare a festival microsite. It could display the program, direct visitors to articles and offer a budget calculator without accounts or a database. Another project might store volunteering requests. In that case, decide which information to keep, who can read it, how to retrieve it and how long it remains useful. Two interfaces looking similar on screen may therefore require different hosting choices.

The first criterion is what visitors need to accomplish. To present a few pages, start with short navigation and information you already publish. If someone must recover their input on another visit, plan data retention. If the need is to keep an existing WordPress site’s themes, plugins and database running, first assess its hosting environment and use Sites for a complementary project if that separation meets your need.

Check access and prepare work in French

Documentation presents Sites as a public beta. Access depends on subscription, region and workspace settings. The hosting schedule describes allowances for Plus, Pro and Business and refers Enterprise organizations to their contracts. In an Enterprise workspace, creation and public publishing may require different permissions. Check options visible in the account that will remain site owner. A colleague’s access or a menu appearing in another account does not verify your access.

ChatGPT offers a web interface and desktop application for managing Sites. On the web, the flow may begin with an @Sites mention or an explicit site-creation request. Work from a local repository can be prepared in Codex. Hosting management operations are documented in ChatGPT on the web and in the application. Menu locations may evolve. If the option is missing, first check the selected account and workspace, then owner or administrator permissions.

State in the brief that headings, buttons, error messages and confirmations must be in French. BlogPasCher’s French pages illustrate a published result. The consulted documentation does not provide an exhaustive list of guaranteed languages for the Sites interface, support or generated text. For a bilingual site, request separate URLs and check pages, dates and messages in each language. On a form, switch language after an error and verify that the message and entered value remain understandable.

Give the AI an example you can verify

Start with a task you know how to test. For a budget calculator, specify fields, formula, units, rounding and an expected result. For a showcase site, provide page titles, calls to action and information visitors must find without creating an account. Supply public or fictional examples. Ask for any missing information to be flagged. You can then correct one rule, text or layout at a time and verify each change’s effect.

Here is a brief to adapt. “Create a French microsite for a fictional festival. Provide access to the program, a practical-information page and a calculator. The calculator multiplies a whole number of participants by 12 euros and displays a message if the quantity is zero. Show the total and its unit without horizontal scrolling on a phone. Prepare a version for review before publishing.” This brief defines a path, calculation rule and error state. The three expected results still need testing in the prepared version.

AI helps produce and modify the site. If you want to add an assistant answering visitors after publication, describe that as a separate need. Then check answer sources, the service used, costs and data processing. Assisted creation provides no information about the cost or model of a possible assistant integrated into your site.

1. Try 3 participants. The expected result is 36 euros. Check the value, label and how to modify the input.
2. Repeat with 0, an empty field and nonnumeric input. Check that the message helps correct the field and an old total does not create confusion.
3. Try keyboard navigation and a phone. Review links and useful alternative text. If the version changes, repeat these same three cases before sharing.

Decide where an existing WordPress site belongs

A classic WordPress installation runs PHP and stores content and settings in MySQL or MariaDB. It may depend on scheduled tasks, a store engine, a theme and many plugins. Sites’ documented scope ranges from static files to compatible JavaScript or TypeScript web applications. The consulted documentation describes neither execution of full PHP/MySQL WordPress nor native import of a WordPress installation. A WXR export, SQL backup or plugin archive prepares WordPress recovery in an appropriate environment.

A first approach keeps WordPress for the blog and places a tool on a separate subdomain, such as a calculator, event or temporary catalog. Link the tool from the WordPress menu and add an explicit return to articles. Choose one primary page for each piece of content and test direct links and forms before announcing the tool. This approach suits a microsite performing a self-contained task.

A second approach reuses a selection of public content for a static showcase. Inventory URLs, media, forms and functions changing over time. Determine how pages are rebuilt after updates and where old links should lead. If a page depends on a session, WooCommerce order or WordPress-computed search, record the dependency before considering replacing it with a new page.

A third approach keeps WordPress as a source and builds a web interface reading authorized data. Start with public content and a small inventory, then compare titles, dates, images and links with the source. For restricted data, have server-side permissions, compatible access methods and propagation of permission changes checked. An HTTPS API may serve as an interface where environment and permissions allow. Plan an understandable result if the source becomes inaccessible.

BlogPasCher is a real example of Sites publishing on a custom domain. The portal publishes French WordPress guides and illustrates an editorial site using its own domain. A selection of WordPress tutorials and hosting a WordPress installation are separate needs. If your goal is to retain an existing store, verify PHP, database and plugin compatibility with the CMS hosting provider.

Separate files, responses and access permissions

For an information page, content may be delivered with the site. If the site must save responses or state, documentation describes D1 as a relational database for records and R2 as object storage for files. A request might have a tracking row in D1 and an attachment in R2. Define which information belongs to the site, who validates it and how to retrieve it if the project changes owner or provider.

Distinguish site audience from data permissions. A public page may offer optional login for some functions. A workspace-restricted site uses that workspace’s rules. If someone should read only their own records, enforce the rule when accessing or changing data. A preview opened under the creator’s account does not verify what a visitor sees. Try the scenario logged out, with an authorized account and with an account lacking access to the record.

Connections to visitors’ applications depend on workspace-specific conditions. Check that the source is available to the intended audience and the site responds correctly to denied access or an unavailable connection. For a showcase, a link to a public resource may suffice. For a data copy, document update frequency and content ownership. A saved version retains the site state to deploy. Plan retention or export of visitor-created records separately.

Save a version, publish and connect the domain

Saving a version prepares a result for review. Deploying publishes a version for the selected audience. Documentation states that every deployment URL is a production URL. To let people try a change before publication, request a saved version and specify who may view the preview. Once published, open the link as a visitor, try the main path and check that the expected version is displayed.

To use a custom domain when available, you must already own the domain or subdomain and be able to edit its DNS zone. In Site settings, enter the desired name, record supplied records and apply those values with the provider managing the zone. Return to Sites settings to check domain status. Domain registration occurs separately. On an Enterprise account, check custom-domain and public-publishing availability with the administrator.

In the management interface, documentation describes tracking unique visitors and page views over a period. This view is documented for sites outside Enterprise workspaces. For traffic origin, per-visitor paths or business events, check measurements available for the project and define data you actually need to collect.

1. Choose the name serving the microsite and list names already used for WordPress and email.
2. If WordPress must remain on the main domain, prepare a dedicated subdomain. Keep a copy of existing DNS settings and identify exactly which entries to add or change for Sites.
3. Check HTTPS access, desired address variants and a direct link to a deep page. Also test a return link to WordPress. If replacing existing URLs, check each main address’s destination.

Budget creation and hosting separately

In the official schedule consulted on November 11, 2026, creation and changes count toward Codex usage associated with the plan. Hosting is advertised as free through December 31, 2026. From January 1, 2027, OpenAI plans to charge hosting overages beyond Plus, Pro and Business allowances. The schedule lists respectively 125 credits per month, 375 credits per month and 125 credits per seat. Sites share their plan’s allowance. Enterprise terms follow the organization’s agreement. Check terms displayed in your account and the schedule effective on the publication date.

Proposed 2027 unit prices are expressed in credits. Traffic is counted in requests, including page and resource loads. One visitor may trigger several requests. The schedule proposes 16 credits per 100,000 requests and 25 credits per custom domain per month, excluding domain registration. An empty database already incurs base charges under the schedule. Then add record and file storage according to volume. Prepare two budgets: an ordinary month and a launch month with more requests.

For a fictional example of 100,000 monthly requests, one custom domain and an empty database, the proposed schedule yields approximately 66 credits before the plan allowance and additional storage. The calculation adds 16 traffic credits, 25 domain credits and 25 database credits. If you already have two active Sites, compare combined usage with the shared allowance. Also check domain renewal, any external services and maintenance time. A credit estimate alone does not determine the amount payable.

Perform a check before adopting Sites

A small team may adopt Sites for an event page, simple catalog or work tool if it can review content, verify actions and maintain data. A store or membership site requires an inventory of dependent functions. Open the site from a visitor’s perspective, reproduce payment or contact paths with test data and record dependencies to handle in WordPress or a specialized service. Check who will own corrections after publication.

1. Record the audience, main action and function that must absolutely remain available. Choose a visible test result for each.
2. Record owner access, intended URL, data to retain and variable charges. Decide who monitors availability and responds when a visitor reports an error.
3. Keep the reviewed version and dependency inventory. After publication, compare the three expected results with public pages and check links to WordPress.

Distinguish a code version from a data backup

Before first publication, request a list of data visitors will modify: form responses, files, accounts or reservations. For each, identify location, read permissions and recovery method. A site version recovers its code and interface; it must not be treated as an automatic snapshot of every record created since.

Prepare a test with a fictional response. Find it in the designated location, then verify deletion with the authorized account. If returning to an older interface, check that it still understands current data before using it publicly. For a simple calculator without retention, explicitly state that inputs are not saved if that behavior was verified. This distinction helps choose a static page, an application with storage or retaining WordPress for existing functions.

Related comparisons