I Tested the Popular Lovable-to-WordPress Converters: None of Them Build Real WooCommerce (Here's the Proof)
Context: Why I Needed to Move a Lovable Project to WordPress
For a lot of marketing agencies, shipping sites "fast" probably looks like the win. But building websites with AI comes with a bigger implication than that: it's rarely just a landing page. Most businesses need a site that converts, that actually works, and that's easy for a non-technical team to manage day to day.
WordPress has spent years optimizing for exactly that audience — non-coders who default to it for everything from landing pages to full ecommerce. That's also why page builder plugins like Elementor, WPBakery, or Avada became so popular. The problem is those builders tend to bolt on an irrational amount of weight to a site, which is what sent me looking for something better suited to an AI-driven workflow.
I had a project built in Lovable that needed to become a real WordPress site — not a mockup that looks good in a demo, but something a client could actually work with every day: a block editor for the marketing team, WooCommerce that genuinely works, a cart, checkout, all of it, without dragging in the dead weight of a traditional page builder.
The obvious question before hand-writing PHP was: does a tool already exist that automates this? Several promise exactly that — upload your Lovable ZIP, and in minutes you get an installable WordPress theme. Before dismissing them, I tried them.
How These Tools Claim to Work
What the marketing promises
The pitch is nearly identical across all of them: upload your project export (Lovable, v0, Cursor, Claude), the tool "parses" the layout, styles, and structure, and hands you back a .zip with an installable WordPress theme. No code. Minutes, not days.
What their own documentation actually says
This is where it's worth reading the fine print, because these companies are actually upfront about it — they just don't put it in the headline. On its dedicated Lovable conversion page, WPConvert.ai states outright that dynamic app logic, authentication, databases, and backend API flows aren't carried over, and recommends planning for WordPress plugins or custom code for that after install.
On WooCommerce specifically, they're just as clear: the tool converts design and page structure, and product catalogs can be imported into WooCommerce — but any other app logic or tooling has to be rebuilt manually after conversion. The catalog comes across; the cart, custom checkout, and any dynamic behavior don't.
It's not an isolated case. WP Pro Converter — a generic HTML-to-WordPress converter, not Lovable-specific — admits in its own FAQ that sites built with a framework like React, Angular, or Vue will need manual adjustments to the generated code before it works properly. And its cheapest tier (Express, no AI involved) is explicitly a visual clone — no real Gutenberg blocks at all.
Translated: what these tools do is take the already-rendered HTML — the static, final output — and map it onto a WordPress template. They don't convert your application logic. They don't turn your React components into real Gutenberg blocks. They don't touch WooCommerce behavior beyond the catalog. All of that is, literally, left for "after you install the theme."
That's not an unfounded criticism — it's what these companies describe themselves, in their own FAQs and product pages. The problem is that detail lives three scrolls below the "Convert now" button.
The Proof: I Converted the Same Kind of Project My Own Way
Instead of stopping at theory, I did the full conversion by hand for the same type of project (React + Lovable, with e-commerce), and documented every decision along the way.
The starting point
I created a design in Google Stitch with the following prompt:
Hi, could you help me create a website design for a page selling beauty products. The idea is for the products to be shown as a carousel. The colors should be skin-tone and burgundy, with an elegant font, and the project is called redwine.
The initial idea was to build a simple site with real conversion power — this was just a design base I put together as an example.
You can see the original design in Lovable here, and the earlier exploration I did in Google Stitch here.
Real Gutenberg blocks, not a React wrapper
Instead of wrapping React components in an iframe or leaving them as static HTML, every visually distinct section of the site (hero, collections, about, newsletter, footer) became a real dynamic Gutenberg block: block.json, edit.js for the editor, and a PHP render_callback that generates the HTML server-side. That means the marketing team can edit content, reorder blocks, and change attributes from WordPress's native editor — they're not staring at a static black box.
Real FSE, not fixed templates
Full Site Editing with theme.json for design tokens (colors, typography, spacing) ported directly from the original project, plus templates/ and parts/ in block HTML. No old-school header.php or footer.php — and no static HTML forcibly injected into a single generic template.
WooCommerce that actually works, not a shortcode taped on
This is the biggest gap. Depending on the target WordPress version (≥6.5 or <6.5), the implementation uses native WooCommerce blocks (product-collection, add-to-cart-form) or the classic [products] shortcode. The side cart runs on vanilla JavaScript plus a custom REST API (register_rest_route()), not React Context — because the moment you leave the Lovable world, continuing to depend on React for cart state is dragging unnecessary technical debt into a CMS that doesn't need it.
None of the automatic converters I tested come close to this. At best, they give you a product page that looks right but sells nothing — you still have to install WooCommerce afterward, configure products by hand, and rebuild the cart from scratch.
🔗 See it live — the theme running on a real WordPress install, with functional WooCommerce, right here: live demo. Not a screenshot — the actual site.
Direct Comparison
| Automatic converters | Real conversion (my approach) | |
|---|---|---|
| Gutenberg blocks | Static HTML injected into a template | Dynamic blocks with PHP render_callback |
| WooCommerce | Not included — "install plugins afterward" | Classic shortcode or native Blocks depending on WP version |
| Cart | Not supported | Custom REST API, no React dependency |
| Block editor (Inspector) | Not applicable | Yes, via @wordpress/components |
| Auth / business logic | Lost entirely | Migrated explicitly, case by case |
| Time | Minutes | Days (depending on complexity) |
| Result | A mockup that resembles a theme | A production-ready functional theme |
Why the Difference Matters (and Who It Matters To)
If you're migrating a personal landing page with no business logic, an automatic converter will probably save you time, and the result will be perfectly acceptable — I'm not saying these tools are useless.
The problem shows up when the project has e-commerce, authentication, or any logic that depended on Lovable's backend. In that case, an automatic converter doesn't give you a WordPress theme — it gives you a screenshot of your site disguised as one. It looks identical in the first screenshot, but the moment a customer tries to buy something, everything collapses.
For agencies and freelancers delivering sites to clients, this is dangerous: the time "saved" on conversion gets paid back later, when the client discovers — usually in production, usually at the worst possible time — that the cart doesn't exist.
How I Did It (Technical Summary)
Broadly, the process looked like this:
- Fully analyze the Lovable project: routes, components per page, state management, API calls, e-commerce logic.
- Extract design tokens (colors, typography, spacing) into
theme.json. - Identify which sections become blocks and which are static layout parts (header, footer).
- Build each block with its own build pipeline (
wp-scripts+ Vite for Tailwind). - Assemble the FSE templates and wire up WooCommerce according to the target WordPress version.
- Build the side cart with vanilla JS and the custom REST API.
- Package the whole process as a reusable skill for converting any Lovable project to WordPress — using DeepSeek V4 Flash (OpenCode GO subscription) for planning, and BigPickle (free) to execute the theme build, all from inside OpenCode.
It's a process measured in two days, not minutes — but the result is a site a WordPress developer can actually maintain without undoing anything first.
Why This Is Worth It
You might be reading this and thinking: if I can already build the whole stack with AI, what's the benefit of moving it to WordPress at all? It's not obvious at first, but for a platform that's eventually going to need ecommerce, starting on WordPress cuts deployment costs from day one — any shared hosting will run it. You already have a builder optimized for building on top of itself, and if you want to add more features later, you follow the same logic without going back to Lovable — you just keep iterating with the same agent, now on top of WordPress.
To be clear: I'm not saying AI does all the work for you. The point is planning the project properly through Spec Driven Development (SDD).
On top of that, the Google Lighthouse numbers are notably good — since this isn't a virtual-DOM site like a typical React app, SEO and performance processing end up more optimized. Here's a screenshot of the site's metrics:
As you can see, it just needs a bit more iteration to hit 100% across the board.
Conclusion
Automatic conversion tools have their place: quick prototypes, landing pages with no backend logic, validating an idea before investing in a real conversion. What they don't do — and they say so themselves, in their documentation, just not in the headline — is build a real WordPress site with functional WooCommerce.
If your project has e-commerce, authentication, or any piece of business logic, you need a conversion done by someone who understands both the source stack and WordPress at an architectural level. If that's you — or if you're interested in the skill itself plus guidance on how to implement it — book a call with me.
