There’s a shortcut going around. You point a tool at your Lovable or Bolt prototype, it screenshots the rendered page, dumps the markup into a single WordPress page template, and hands you back something that loads in a browser and looks identical. “Migrated to WordPress.” Technically true. Practically useless.
I know it’s useless because I’ve watched what happens about a week after delivery, when the client actually opens the editor for the first time.
The frozen-markup problem
Here’s the scene. The client logs into WordPress, full of intentions. They want to change the hero headline. Maybe swap “Book your appointment” for “Reserve your slot.” Small thing.
They open the page and find one enormous HTML blob sitting in a single block. No hero block. No heading block. No structure at all — just a wall of nested divs that happened to render correctly once. To change three words, they have to go spelunking through markup and pray they don’t break the layout. They don’t add the service they wanted to add. They don’t reorder the testimonials. They close the tab.
The site is now a museum piece: beautiful, untouchable, and quietly going out of date from the moment it shipped. The first time the business needs to change — new pricing, a new location, a seasonal promo — they’re back to paying a developer, or worse, back to where they started.
That’s the real cost of a clone. It isn’t wrong on day one. It’s wrong on day thirty, when the thing a website is for — changing as the business changes — turns out to be impossible.
The prototype is the spec, not the deliverable
The mental shift that fixes this is small to say and large to execute: treat the prototype as a specification, not as the thing you ship.
A clone asks, “How do I make WordPress output these exact pixels?” A rebuild asks, “What was this prototype trying to be, and how do I express that natively in WordPress?” Same destination, completely different artifact.
Concretely, that means every part of the prototype gets translated into the right WordPress primitive:
- Every section becomes a real block. The hero is a hero block. The pricing grid is a columns block with editable cards. A marketer can select the headline and type. Nothing breaks because nothing was glued together.
- Every list becomes a real custom post type. If the prototype showed a list of services, staff, or properties, that’s not hardcoded markup – it’s a
serviceCPT with fields. Add the eighth service the same way you added the first: a new entry, not a code change. - Every color, font, and spacing step becomes a token in
theme.json. The design system lives in one file the editor reads. Off-brand choices become literally unavailable in the picker.
The output looks the same. But now it edits like a site that was always meant to live in WordPress — because, structurally, it is one.
Pixel-perfect is easy. Pixel-perfect and editable is the actual job.
Why “looks the same” was never the bar
It’s tempting to grade a migration on the screenshot test: put the old and new side by side, see if they match. Clones pass that test. That’s exactly why the test is misleading.
The honest bar is the editor test: hand the site to a non-technical person six months from now and ask them to make a routine change. Add a team member. Update the hours. Launch a landing page for a new offer. If they can do it without calling you, the migration worked. If they can’t, you sold them a screenshot with extra steps.
A website is not a deliverable that’s finished on launch day. It’s an asset the business will operate for years. The rebuild is what makes it an asset instead of a liability with good production values.
The part nobody sees, and why it’s the whole point
The frustrating thing about doing this properly is that the value is invisible at handoff. A clone and a rebuild can demo identically. The difference only shows up later — in the changes that don’t require a developer, the off-brand colors that can’t get introduced, the new pages a junior hire ships without breaking anything.
That invisibility is exactly why the shortcut keeps winning sales it shouldn’t. So I’ll say the quiet part plainly: if you’re moving a prototype to WordPress and the result can’t be edited by the people who’ll actually run it, you haven’t migrated anything. You’ve reframed a static export and called it a platform.
We rebuild because the prototype was always meant to be the start of a living site — not the last good day it ever had.
Lowpable rebuilds vibe-coded apps from Lovable, Bolt, and v0 into production WordPress — native blocks, real custom post types, design tokens, the works. Zip in, zip out. See a live demo or get a quote.