Build a WordPress website with AI, in the builder you already own.

Which edition each brief needs

Most people who set out to build a WordPress website with AI want to know early whether the free plugin is enough. It depends on the brief more than the size of the site.

• Business website: page content in Elementor or the block editor, menus, front page settings and the site header (build-site-header) work on Free, as do a block theme's footer and other template parts. Elementor Theme Builder footers and their display conditions, global classes and variables, other builders and form building need Pro.
• Landing pages: a single Elementor page is Free; shared classes, variables and reusable templates are Pro.
• WooCommerce store: reading products and editing an existing product's name, description, prices and stock is Free; creating a catalogue, variations and bulk changes are Pro.
• Blog and content system and portfolio site: post types, taxonomies and field groups come from Pro fields modules; posts, terms and per-post SEO fields are Free.
• Forms and lead capture: listing forms and entries is Free on several plugins; building them is Pro.
• Membership and events: every membership, course and events module is Pro.

Combining briefs into one project plan

A real site is often two or three of these at once: a business site with a blog, or a shop with lead capture. Run them in dependency order rather than all together. Design system and site structure first, because every later page references them. Then content models, because templates bind to their fields. Then pages and products. Forms and anything that touches people or money go last, when the pages they sit on have been reviewed.

Keep one handover document across the briefs: the IDs of everything created, every [CONFIRM] still open, every new global token, and every live setting you approved. That list is also what you re-check when the staging work is repeated on production.

Running a brief from ChatGPT

To build a WordPress website with ChatGPT, add GoBuildWP to ChatGPT as a custom MCP server with OAuth sign-in, then select it with @ in a new chat and paste one brief at a time. The ChatGPT connection guide walks through it. Use your site's OAuth endpoint, which ends in /wp-json/mcp/wppilot-oauth, or GoBuildWP Cloud at https://app.gobuildwp.com/mcp.

Two limits come from ChatGPT rather than the plugin. Whether you can add a custom MCP server at all depends on your ChatGPT plan and workspace policy, so check that before planning around it. On a direct connection, ChatGPT calls your site from OpenAI's servers, so a site on localhost or behind a staging password cannot be reached; use a public HTTPS staging copy. The editions, approvals and undo limits on this page are the same whichever client sends the brief.

Before the first brief: a pre-flight list

None of this is specific to GoBuildWP, but skipping it is how AI-assisted builds go wrong in ways that look like product failures.

• A staging copy of the site, with the same builder, theme and plugin versions as production.
• A dedicated connection for the agent. GoBuildWP only accepts a user with manage_options (a super admin on multisite), so a lower role cannot connect; narrow the agent with its own access token's scope and profile ceiling instead.
• A deliberate safety profile: Production Safe for anything resembling a live site, Developer Full Access only on staging and only if the brief needs plugin installation or code. Production Safe still allows deletes that carry a confirmation flag, which the AI client sets itself by default; turn on "A person approves" or the Pro approval queue if a person must approve them.
• A recent backup you have checked, separate from the change ledger.
• The facts the brief depends on, collected from the business rather than left for the model to fill.
• Time booked for review in the native editor and a browser at phone and desktop widths.

What a realistic schedule looks like

Every brief on this page is a sequence of governed calls, paced by a per-credential write limit, so the run takes as long as the work it describes. A short site arrives over a sitting you can watch in the change log; a large catalogue or a long archive of posts is a series of runs across several days. The model writing faster does not change that, because each call is checked and recorded before the next one starts.

In practice the agent's run is rarely the longest stage. Gathering facts, review and launch approvals take more of the calendar. Plan a whole-site project in weeks with review time in every one, not in minutes, and you will spend that time on the parts that need a person.

When to undo a run rather than fix it

If a run produced the wrong structure, fixing it page by page by chatting is slower and riskier than starting again. list-sessions shows each agent session with how many of its changes can still be undone. undo-session reverses the supported changes in a session newest first, and refuses the whole run if anything has touched those targets since. It stops at the first change that fails verification, and changes recorded as irreversible, such as a Divi Theme Builder template or a global attribute, block the run unless you explicitly allow a partial undo. Read its plan, fix the brief, then run it again. Reserve rollback-change for single writes, and keep undo for direction changes, not tidying.