How to Convert an AI Build into a WordPress Theme (Step-by-Step)

AI build to WordPress CMS

How to Convert an AI-Built Frontend into a WordPress Theme

You prompted a site into existence in an afternoon. Lovable, v0, bolt.new, Figma Make, Claude Code, Replit, Rocket or builder.io gave you a working React frontend that looks the way you wanted. Then the question arrives that none of those tools answer: how does this become a WordPress site your marketing team can actually edit?
 
The honest answer used to be "a developer rewrites it". WordPress renders PHP; every one of those tools emits React. That single mismatch is why an AI build cannot simply be dropped into a theme folder, and it is the step transjt automates. Here is the whole path, start to finish.
 

Before you start: the one stack requirement

Everything else in this guide is mechanical. This part is the one that decides whether your conversion is clean or painful.
 
Ask your AI tool for React with Vite, without server-side rendering. WordPress serves pages through PHP, so there is no Node runtime on the far side to execute a server layer. What that means per tool:
 
  • Lovable already outputs React with Vite. Nothing to change.
  • v0 defaults to the Next.js App Router with server components. Ask for a plain React and Vite build instead.
  • bolt.new, Replit and Rocket scaffold full-stack apps by default, including API routes and a database layer. The frontend ports either way, but that server layer has to come out first.
  • Figma Make and builder.io produce React from your design. Choose a React and Vite export where the option exists.
  • Claude Code follows an explicit instruction reliably. State the constraint in your first prompt and you avoid a refactor later.
If your project already has a server layer, it is usually salvageable: the components themselves convert, and it is the routing and server actions that need removing.
 

Step 1: Build the frontend in your AI tool

Work exactly as you normally would. Prompt, preview, refine, repeat until the interface is right. Nothing about the conversion asks you to change how you design or how you iterate.
 
The only thing worth doing differently is stating the stack constraint up front rather than discovering it at the end.
 

Step 2: Get the code into GitHub

GitHub is the bridge. transjt reads your repository, so whatever your tool calls this step, the destination is the same:
 
  • Lovable and Replit have built-in Git integrations that push for you.
  • bolt.new pushes directly to a repository from the editor.
  • v0, Figma Make, Rocket and builder.io export code that you commit yourself.
  • Claude Code works in your repository already, so there is no export step at all.
This is also the moment your project stops depending on the platform that generated it. From here the destination is hosting you control, and the commit history records which build produced which theme.
 

Step 3: Connect the repository to transjt

Authorize GitHub in your transjt project and select the repository, and a branch if you want to convert from something other than main. transjt reads the component tree and works out which parts become PHP templates and which become editable content regions, before it writes anything.
 

Step 4: Choose WordPress and review the preview

Pick WordPress as the target CMS and check the live preview against your original design. Confirm, and transjt writes a theme folder: semantic PHP templates and native markup, with no page-builder plugin required to render any of it.
 
Typically this takes under an hour from a synced repository to an installable theme. It scales with the number of distinct page templates rather than total pages, so twenty blog posts sharing one layout convert as quickly as one.
 

Step 5: Install the theme, and update the plugin

The theme installs through the WordPress admin like any other. One thing to check before your first export: the transjt WordPress plugin on that site must be current. Running a recent transjt release against an older plugin is the most common source of avoidable errors, and it takes thirty seconds to rule out.
 

What you actually get

A theme folder you own outright. Readable PHP templates you can open, review and keep in version control, compiled styles that carry your spacing and type scale across, and content that lives in the WordPress editor where the person who wrote it can change it without touching the repository.
 
That last point is the one that matters six months later. In a React build, every copy change routes back to a developer. As a theme, it does not.
 

Updating after you regenerate

Change the design in your AI tool, push to the same repository, and re-run transjt. Content your team has already edited inside WordPress lives in the database and survives a re-conversion, so you are updating the theme rather than resetting the site.
 

When this is the right approach

Converting is worth it when the site has to outlive the prototype: when marketing needs to ship landing pages without a deploy, when SEO needs server-rendered pages, when the plugin ecosystem solves your next three problems, or when you simply want to own the output rather than rent it.
 
If you are still iterating on an idea, stay in the AI tool. The moment the thing has to be operated by other people, it belongs in a CMS.