We rebuilt this website off Divi with an AI agent
The migration you’re considering is the one we already ran on ourselves.
No demo, no cherry-picked example. This exact site — the one you’re reading — was rebuilt by Claude inside a Pete Panel playground. Here’s precisely how it went.
This website ran on the Divi page builder for years. Working inside a disposable Pete Panel dev playground, Claude rebuilt it as a native Full-Site-Editing block theme — the homepage, the key pages, and twenty-nine more pieces of content — converted and verified one at a time, packaged as an installable .zip, with the Divi theme kept one command away as rollback. It shipped to production. That’s not a case study we borrowed; it’s the site you’re on right now.
Where we started: years on a page builder
Like a lot of WordPress sites, this one grew up on Divi. It worked — but it carried the usual page-builder tax: heavy runtime on every page, content locked inside shortcodes, and a design that was hard to move anywhere else. We wanted native Gutenberg blocks: lighter HTML, faster loads, full Site Editor compatibility, and no lock-in. The problem is that “just switch themes” doesn’t exist for a builder site. The content is entangled with the builder, so migrating means rebuilding — and rebuilding by hand is exactly the kind of slow, error-prone slog people avoid for years.
The setup: hand the job to an agent, safely
We didn’t point an AI at production — nobody should. We cloned the live site into a Pete Panel dev playground: an isolated Docker copy on a Mac, an agentic WordPress environment where Claude gets what a senior developer gets — real WP-CLI, files, database, and logs. If a run went sideways, the fix was to delete the playground and clone again. Production kept running the whole time, untouched.
The run: /retheme, one page at a time
The whole migration was one command — /retheme — but underneath, it’s a disciplined process, not a magic button. Claude inventoried the Divi theme and, crucially, the real work list: not “the homepage,” but every page the main menu links to. It extracted the palette, fonts, and spacing into a block theme’s theme.json, rebuilt the header, footer, and section layouts as block templates and reusable patterns, and then converted each page’s content into native blocks — in menu order, one at a time. Each page was render-verified before the next began, so any regression pointed straight at the page just touched.
Where the brief was thin, it stopped and asked — a design gate, not a guess. The Divi theme stayed installed but inactive the entire time, as both the “before” reference and an instant one-command rollback. The run ended where it should: an installable theme .zip and a per-page checklist of page → HTTP status → verified.
What we didn’t fake
Honesty matters more than hype here, so: this wasn’t fully hands-off, and it shouldn’t have been. Claude did the heavy lifting — the extraction, the block conversion, the section-by-section rebuild — and we held the gates: design direction when it mattered, and the final call on what shipped. That’s the model, not a limitation. The agent moves fast on a safe copy; a human approves the irreversible steps. The result wasn’t a lucky one-shot; it was a repeatable process that has since run on a Genesis golf-club site and an 11-page Divi WooCommerce store, live checkout included.
The result — and why it’s the whole point
The site you’re reading is now a native block theme: no page-builder runtime, cleaner markup, and full Site Editor support — deployed to production in Pete format, on our own cloud. If we were going to ask you to run an AI-assisted migration on your production WordPress site, the least we could do was run it on ours first. We did. This page is the receipt.
Frequently asked questions
Did an AI really rebuild the whole site?
Yes — Claude did the extraction, block conversion, and section-by-section rebuild of the homepage, the key pages, and 29 more pieces of content, inside a Pete Panel playground. Humans set the design direction at the gates and approved what shipped. The agent did the work; we held the keys.
Was production ever at risk?
No. All the work happened on a disposable copy in an isolated Docker dev playground. The live site kept running untouched, and the Divi theme stayed installed as an instant rollback until we chose to switch.
Can I run this on my own Divi site?
That’s the point of shipping it. Spin up a free dev playground, clone your site in, and run /retheme — the same process that rebuilt this one. The step-by-step is in our Divi-to-block-theme guide.
How long did it take?
A site this size is an afternoon’s work with the page loop running, plus your review at the design gate and before deploy — versus the days of manual rebuilding a builder-to-blocks migration usually takes.
Run the same migration on your site.
Spin up a free dev playground, clone your site, and hand it to Claude — verified page by page, rollback always one command away.