After AI Generates a Page, How Do You Bring It into WordPress?

AI × WordPress Series · Part 3 of 8
If you have already decided to keep using WordPress, this article explains how to implement, reuse and maintain AI-generated pages.View the series contents

After AI generates a page, do not rush to copy the code. First decide what role WordPress plays in your site, then choose how to implement it.

Reading guide

01　Do not mistake an HTML prototype for a finished productA page that opens in a browser is not necessarily ready to launch, edit and maintain in WordPress.

02　Decide the bigger question first: does WP render the pages or only serve as the backend?This determines every choice that follows. Many people get stuck because they skip it.

03　If WP renders the frontend: implement by page typeMarketing pages, special modules and detail pages call for three approaches, rather than one approach for everything.

04　If WP is only the backend: what you have to take overThe other side of the convenience: what it costs and whether it suits you.

05　Assess the risks before changing a theme, and the complete process I now use

Common questions about bringing AI-generated pages into WordPress are really two sides of the same issue, so it is worth answering them together:

Reader A: I plan to build a site with WordPress and vibe-code the detail pages, but translating them into WP is a problem. Do I have to vibe-code everything once and then manually recreate it in WP? Is there a better way?

Reader B: I tried connecting a vibe-coded website through wpAPI, but I cannot use plugins. WP can only serve as a CMS.

A asks how to bring AI-generated pages into WP. B has already made the connection, only to discover that the WP plugins no longer work afterward. Together, these questions expose a premise most tutorials skip:

Before working out how to move the pages, decide what role WordPress plays in your site. Choose the wrong role and every subsequent step becomes awkward. That is how Reader B ended up in this situation.

This article avoids complicated technology and focuses on making that decision clear.

1. An AI-generated page is only a prototype before implementation

Using ChatGPT to organize requirements and Codex to generate a page has become very accessible. Give it a goal, a module structure, a reference style and some copy, and it can quickly produce HTML that looks complete.

But the easiest mistake is this: a page opening in a browser does not mean it is suitable for WordPress.

WordPress is not a blank webpage file. It has themes, plugins, editors and templates, plus the question of who will make changes later. So when you get an AI-generated page, do not start by asking how to copy in the code. Ask who will edit it, whether it is a one-off campaign page or something to reuse over time, and whether you need an entire page or just one module.

Above all of these is a more fundamental question, covered next.

2. Decide first: will WordPress render the pages, or only serve as the content backend?

This is the fork in the road. WordPress has two very different uses. Reader A assumes the first; Reader B has unknowingly stepped into the second.

Use 1: WordPress renders the frontend (traditional / integrated). When a visitor opens the site, WordPress itself assembles the page using themes, plugins and PHP, then sends it to the browser. Your SEO, form and cache plugins work within that rendering process. This is how the vast majority of WordPress sites operate.

Use 2: WordPress only serves as the content backend (headless). You build the frontend separately through vibe coding, for example with Next.js. WordPress sits behind it and supplies content as data through an API (wpAPI / REST or GraphQL). This is what Reader B did: connecting through wpAPI effectively turned WordPress into a headless CMS.

When Reader B says, "I cannot use plugins; WP can only serve as a CMS," that is not a configuration mistake. It is the definition of headless. Once WordPress stops rendering the frontend, plugins that depend on that rendering process, such as SEO, forms, page builders and caching, naturally stop working there. You have to reimplement their functions on the frontend. Even the Preview button breaks, because WordPress renders the preview too.

So before choosing blocks or a builder, answer this question:

Does your website actually need WordPress itself to render the frontend?

The decision is straightforward. Look at two things:

Do you benefit from SEO plugins? If your site relies on search traffic and plugins such as Yoast / Rank Math to generate metadata, structured data and sitemaps automatically, headless makes your work harder. In traditional WordPress, those plugins write SEO signals directly into the HTML Google crawls. With headless, you have to implement all of that on the frontend and confirm that the pages use server-side rendering (SSR) rather than purely client-side rendering, or crawlers may receive an empty page. For content sites and independently owned websites that rely on organic traffic, the traditional approach is usually more reliable.
Are the people editing content nontechnical? With traditional WordPress, the operations team can fill in fields, preview and publish in a smooth workflow. With headless, preview and editing experiences require extra work, and content teams can easily get stuck.

My preference is clear: if you run an SEO-driven content site or an independently owned website, and the people updating content are mainly your operations team, start with Use 1: WordPress renders the frontend. Headless is an option, but it exchanges frontend freedom for having to rebuild SEO and forms yourself and maintain two systems. For most people running their own websites, that trade-off does not add up.

Reader B's complaint that WP can "only serve as a CMS" actually gets to the heart of headless: wanting frontend freedom while retaining the benefits of plugins. Those two things do not automatically come together.

A related point about how we think about this: many people insist on keeping the WordPress backend, but what they really want is not WordPress itself. It is a backend where nontechnical people can fill in fields and edit content. WordPress is one option. There are also content backends designed specifically for code-based frontends: headless CMSs. But that is another technical route and another article. If you are already in the WordPress ecosystem, the rest of this article stays with WordPress.

If you have not decided whether to keep WordPress, first read In the AI Era, You May Not Need WordPress for Your Website at All, then return here to choose an implementation approach.

Once you have decided its role, break down the implementation. Section 3 is for people choosing Use 1, which includes most readers. Section 4 is for people choosing Use 2, like Reader B.

3. When WordPress renders the frontend: implement by page type

Back to Reader A's question: how do you bring an AI-written page into WP, and do you have to recreate it manually? No, but you also do not have to choose between hardcoding the whole thing and recreating it by hand. There is a better main route between those extremes.

Many people see implementation as a choice between two extremes:

Paste the code directly: the fastest option, but it can weld a one-off prototype into the system and make future changes difficult.
Recreate it manually: controllable, but it means throwing away almost all the AI-generated code and using it only as a design reference.

The better middle route is to turn the AI-generated HTML/CSS into a custom WordPress block. In plain terms, wrap that code in a container that connects it to the block editor. Titles, images, copy and selling points become fields in the backend. The operations team can change the content without touching code, while the frontend still renders the AI-designed style.

Choose by page type, but remember that Cases 1 and 3 below use the same underlying mechanism.

Case 1: A single marketing page

Homepages, service pages, campaign pages and landing pages often need copy changes, new images, CTA adjustments and additional case studies after launch.

First choice: custom blocks / block patterns. Have Codex produce an HTML/CSS prototype, then have a developer turn each module into a block. ACF Blocks is an accessible option for teams that are not purely frontend developers. This preserves almost all of the AI-generated visual design while letting the operations team fill in fields in the backend. A little more packaging work upfront pays off over time.
Alternative: recreate it with a page builder (Elementor / Brizy / native Gutenberg). Use this when the team has no developer to build blocks and the operations team needs frequent, flexible drag-and-drop editing. But recognize the costs: builders have their own DOM and styling systems, making pixel-perfect reproduction of the AI layout difficult. Their deep nesting and many generated divs can also hurt page performance and related technical SEO metrics. The more you care about SEO and clean pages, the stronger the case for blocks over builders.

Case 2: Just one special module

A flowchart, comparison table, pricing explanation, FAQ, case study display or CTA: perhaps only one module needs a distinctive treatment.

For a one-off experiment, asking Codex to write that HTML/CSS separately and embedding it directly is fastest. But check one thing first: the embedded content may not survive saving. If the module contains <script>, <iframe> or <style>, WordPress automatically filters those tags for accounts without the relevant permissions. Scripts and iframes may be stripped when a regular editor saves the page; in multisite environments, even administrators lack this permission by default. Before saving, confirm the account's permissions, whether this is multisite, and whether any security plugins apply additional filtering.

The rule is simple: direct embedding is fine for a one-off experiment. If it needs ongoing changes or reuse across multiple pages, make it a block as in Case 1. Copying HTML/CSS into every page makes styles hard to keep consistent, requires repeated mobile checks and leaves nontechnical editors afraid to touch it.

Case 3: Many detail pages of the same type

Product, case study, service and industry solution pages should never each be recreated manually from an AI page. They usually share a fixed structure: hero, introduction, benefits, use cases, process, case studies, FAQ and CTA. Repeated copying becomes messy as the page count grows.

The right approach has the same foundation as Case 1: use the AI page as a prototype and have a developer split it into WordPress templates, custom blocks and fields. ACF custom fields are a good fit. Adding similar pages then means filling in content rather than rebuilding them. Titles, introductions, images, benefits, specifications, case studies and FAQs all become fields maintained in the backend. The goal is not merely fast initial generation, but reuse afterward.

This resolves Reader A's concern about recreating everything manually: you are not hand-copying pages into WP. You package the AI design once into blocks and templates, then enter data from that point on. Codex can also write the blocks themselves. This is about as close as you can get to vibe coding inside WordPress.

Advanced option: let AI operate Elementor directly through MCP (early-stage and optional)

All three approaches above follow "AI generates it, then you figure out how to bring it into WP." A newer route skips the moving step: use MCP, a protocol that lets AI agents operate external tools, so AI can build the page directly in Elementor.

Community plugins already turn Elementor into an MCP server, including EMCP, mogacode and bvisible. Once connected, agents such as Claude / Cursor can call Elementor's native capabilities directly: add containers, place widgets, apply templates and change global design tokens. They can do most of what you can do in the editor.

The appeal is getting three benefits at once: AI generation speed, native Elementor pages that the operations team can continue editing normally, and traditional WordPress where SEO plugins keep working. This avoids the costs of headless and lowers the technical barrier of needing someone who can package custom blocks first. For an independently owned site already using Elementor, it is almost the most natural route.

But this is still early-stage technology. Understand three things before using it:

There are paid and open-source options; payment is not the only route. The free tier of the mainstream EMCP offering is sufficient to build pages, add widgets and create templates; paid plans buy surrounding conveniences and human support. Fully free, open-source options also exist, such as mogacode's agency edition, with backups before writes and automatic rollback. The core action of building pages is possible through free / open-source routes.
The ecosystem is changing rapidly. The main offerings are community plugins, rather than official Elementor products; its official AI agent has not yet formally launched. Names, interfaces and pricing have all changed. Tying a production site's workflow to an early-stage plugin creates lock-in and maintenance risks that deserve more attention than the subscription fee.
Verify every write. An MCP write interface may report success while silently discarding content because of plugin filtering or REST quirks. After building a page, read it back from WordPress itself and check it. This is the same kind of problem as tags being filtered in Case 2; it has not disappeared.

How to use it: first verify reliability on a test site with an open-source edition or free tier, then decide whether to invest further. Do not begin on your production site with the most expensive plan.

Another crucial point: MCP does not replace an upfront design specification; it is the channel for implementing that specification. MCP solves how to bring the design into Elementor, but page quality still depends on the design brief you give the agent. The ideal workflow is to document a design specification first, as described in Step 3 of Section 5, then give it to an agent connected to Elementor MCP. The agent uses Elementor's native capabilities to build a site that follows your specification and can be maintained in production. Fast generation, maintainability and preserved SEO can come together on this route for the first time, provided you accept its early-stage nature.

4. When WordPress is only the backend, as in Reader B's approach: what you have to take over

If you truly need the frontend freedom of vibe coding and choose headless, be clear about the consequences: WordPress is left with just one function, the content repository. The work plugins used to do for you below must now be implemented on your frontend.

SEO: metadata, canonicals, structured data, sitemaps and robots all have to be generated by the frontend, such as Next.js. SEO plugins on the WordPress side no longer do that work for the rendered site.
Confirm SSR: pages need server-side rendering, rather than a purely client-rendered shell. Otherwise search engines and AI crawlers may receive empty pages. This is the most common and most damaging SEO pitfall in headless setups.
Forms / preview / caching: forms must submit through an API or a third-party service; you need to build a preview workflow; caching belongs to your frontend hosting layer.

When is this route worthwhile? Roughly when you already have frontend development capabilities, need a high degree of frontend freedom, and have someone specifically responsible for properly reimplementing this SEO work. Otherwise Reader B's experience is typical: you think connecting an API is all it takes, then discover you need to rewrite half the website.

SEO here means more than regenerating metadata and sitemaps. It also includes indexing, 301 redirects and ongoing monitoring after launch. For a breakdown of responsibility, see After Leaving WordPress, Who Handles All the SEO Work?.

One sentence for Reader B: you have not done anything wrong; you have chosen a route that trades freedom for reimplementation. If your site depends on SEO and you do not want to rebuild that layer, returning to Use 1 in Section 3 will be much more comfortable.

5. Theme / template changes: treat them as engineering risks, and the complete process I now use

Whichever route you take, changes to theme files should be treated as engineering risks.

First distinguish the theme type: classic themes use .php templates, while the increasingly common **block themes (full-site editing)** use the Site Editor and theme.json. They work very differently, so do not apply old assumptions.

Before letting an agent change a theme, specify at least which file it will change, which pages it affects, where the data comes from, how to roll back a mistake and whether there is a test environment to verify it first. In particular, do not edit the parent theme directly. Theme updates overwrite manually changed files. Put changes in a child theme or traceable custom code instead. Without a test site, backups and rollback, do not let AI modify production directly. This is about WordPress engineering risk, rather than whether AI can write code.

The complete process I now use:

Define the role. Answer the question in Section 2 first: does WordPress render the frontend, or only act as the backend? Most independently owned sites should choose the former.
Clarify the page's purpose. Who is it for, what need does it address, and what do you want the user to do?
Prototype → document a specification → use that specification upfront. If you do not yet have a fixed design style, let Codex generate a few HTML prototypes to explore it. Check information flow, visual hierarchy, whether the CTA feels natural, mobile readability and the completeness of the SEO structure. But do not start every page from scratch. Once you have made enough pages of the same type, extract the recurring colors, spacing, components and layouts into a design specification file. Then have Codex read it before generating subsequent pages. Prototyping becomes an asset defined once and reused over time, rather than repetitive work on every page.
Implement by type, for Use 1. Prefer blocks / templates for marketing and detail pages; directly embed one-off modules. Fall back to a builder for marketing pages when operations needs strong self-service editing and there is no developer to build blocks. If you already use Elementor and want a simpler workflow, an agent connected to Elementor MCP can implement the specification directly, but first verify reliability on a test site. See the advanced option at the end of Section 3.
Test theme changes on a test site first. Use theme.json for block themes, and prepare backups and rollback.

Conclusion

Return to the two questions at the start.

Reader A, on bringing pages into WP: you do not need to recreate them manually. Package AI pages as custom blocks and templates, then let the operations team fill in fields in the backend. This is the main route that combines implementation, reuse and maintainability.

Reader B, on plugins no longer working after connecting an API: your configuration is not wrong. You chose headless, which turns WordPress into a content repository. The price is rebuilding SEO, forms and preview on your frontend. Content sites that depend on SEO are generally better served by letting WordPress keep rendering the frontend.

Both answers depend on the same decision: define WordPress's role before choosing the implementation. Codex addresses how quickly you can generate a page. WordPress addresses whether you can edit, maintain and reuse it after launch. Do not conflate the two.

Next time you use Codex to build a page, include two things in the requirements: which role applies to the page, frontend rendering or backend only, and who will edit it later. Decide how you will use it before deciding how to implement it.

Continue reading

Next: In the AI Era, You May Not Need WordPress for Your Website at All

Previous: Building an Export Business Website Quickly: Which Steps Can AI Save You, and Which Can It Not? · Start here if you have an existing site · View the full series

Bring AI-generated pages into your website

Share the pages you have created and how you need to manage their content or connect them to WordPress and other website features.

Discuss page integration