Clone A Plasmic Site In Under 5 Minutes

The honest answer depends on what the platform emits, not on what any converter claims. Plasmic produces a visual builder that sits on top of a real codebase, publishing either a hosted page or React components that your own Next.js or Gatsby project renders. Everything in that sentence that is presentation — structure, styling, typography, imagery, copy — moves into a WordPress theme without reinterpretation. Everything that is behaviour has to be rebuilt with WordPress-native tools. That distinction is the whole game. A rebuild starts from a screenshot and a memory of what everyone agreed on, then spends three weeks relitigating spacing decisions that were already settled. A clone starts from the finished artefact, so the design conversation simply never reopens. For product and marketing teams who wanted designers in the page editor without giving up a real Git-based codebase, the practical result is a site that looks identical, loads from hosting you control, and can be edited by anybody with a WordPress login. Begin at the [converter](/upload); read [how the technology works](/technology) first if you would rather see the mechanics than the pitch.

With Plasmic, the source comes from either the published site URL for a hosted project, or your own repository for a codegen project where Plasmic writes components into `plasmic/` folders. Two minutes of checking here saves an afternoon of confusion later, because a disappointing first conversion is nearly always a source problem rather than an engine problem. If you have an archive, confirm four things: a manifest at the root (`package.json` for a framework project, `index.html` for a static bundle), no `node_modules` folder, a populated image directory, and the archive root being the project root rather than a wrapper folder inside another wrapper. If you are converting from a live URL instead, confirm that the pages you care about load without a login, that your sitemap is published and current, and that no critical page is reachable only through a search box. Anything a logged-out visitor cannot see, a crawler cannot see either. Platform-specific screenshots live in the [guides index](/guides).

**Detection.** The upload is fingerprinted from configuration files, dependency names and folder shapes, which selects the Plasmic strategy rather than a generic one. **Build.** Projects that need compiling get a clean install and a production build in an isolated runner, with placeholder environment variables so an unused API key never blocks a marketing page. **Discovery.** Hosted projects expose page slugs through a published sitemap, while codegen projects declare routes in the host framework's pages or app directory, which is read directly. Declared routes, sitemap entries and discovered internal links merge into one de-duplicated list. **Render.** Every route opens in a headless browser and is captured once the page settles, so content that only exists after JavaScript runs becomes crawlable HTML. **Assets.** Images are uploaded to the Plasmic CDN and referenced by absolute URL, so each one is fetched, hashed, de-duplicated and rewritten to a local theme path. **Theme.** Repeating chrome is separated from unique content by frequency analysis, producing `header.php`, `footer.php`, page templates and template parts. PHP syntax, link health and preview rendering are all validated before the ZIP is released next to a live WordPress preview you can click through.

**The loud one.** Content is frequently fetched from the Plasmic CMS at request time, so a static capture freezes whatever the CMS held on conversion day and later edits stop appearing. You will notice this quickly, and it is cheap to handle at the source and awkward to repair inside a generated theme. Deal with it before you convert. **The quiet one.** Codegen projects mix generated components with hand-written ones, so a build that succeeds locally can fail in a clean runner when a hand-written file quietly depends on a global that only exists on the developer's machine. This is the expensive category, because the theme installs, the preview looks plausible, and the problem only surfaces weeks later when a crawler or a phone finds it. The engine defends against both. Unresolved asset references are matched by filename and by content hash across the entire tree, routes that render suspiciously empty are flagged by the preview integrity check, and orphan pages appear in the diagnostics rather than disappearing. Defence is not a substitute for a clean source — [fix broken layouts after conversion](/guide/fix-broken-layouts-after-conversion) is the repair playbook when something still slips through.

**Kept exactly:** page structure, stylesheets including compiled utility classes, self-hosted fonts, images, SVGs, favicons, client-side scripts that do not call a platform API, meta titles and descriptions, Open Graph and Twitter tags, and the internal link graph rewritten to WordPress permalinks. **Rebuilt in WordPress:** forms keep their markup but need a form plugin behind them; site search becomes native WordPress search; newsletter signups reconnect to your email tool; and repeating content types such as case studies, team members or resources become a custom post type with a loop. **Left behind:** the Plasmic CMS as a data source, the in-browser page editor itself, and any component whose props are supplied at runtime by your application code. Most tools hide that third list. Write it down before you start, decide which items genuinely matter to your business, and the migration finishes in days instead of stalling in week three on a surprise. The [features page](/features) states which stages are automated and which produce a warning for a human to act on.

Consider a B2B software company that used Plasmic so their designer could ship landing pages, then moved the whole marketing surface to WordPress when the engineering team stopped wanting a second deploy pipeline for marketing. **Day one.** They produced the source, ran a conversion and opened the preview. Every page rendered; the contact form displayed correctly but had nowhere to submit. Total elapsed time from export to preview: under fifteen minutes. **Day two.** The theme went onto staging. The form was wired to a WordPress form plugin, two hero sections became blocks so marketing could edit copy unassisted, and the navigation moved into a WordPress menu. **Day three.** URLs were mapped one to one, redirects covered the two paths that had to change, and a link audit came back clean. Images previously served from a remote CDN were now local, which measurably improved largest contentful paint. **Day five.** DNS switched during a quiet hour. Rankings held. The platform subscription was cancelled at the end of the billing period. The [SEO migration checklist](/guide/seo-migration-checklist-ai-website-wordpress) is the same list they worked through.

Work through these in order and you will catch almost everything that matters. 1. Install the ZIP via Appearance → Themes → Add New → Upload, then activate. 2. Open each page beside the original in a second tab and compare. 3. Test on a real phone rather than a narrow desktop window. 4. Click every navigation item, footer links included. 5. Connect each form to a plugin and send a genuine test submission. 6. Set permalinks to Post name so URLs match the originals. 7. Install an SEO plugin and confirm titles and descriptions carried over. 8. Submit a fresh sitemap in Search Console. 9. Add redirects for any URL that changed. 10. Run a speed test and enable caching. 11. Configure automated backups before touching DNS. 12. Create an Editor account and have a colleague publish something. The [plugin and installation guide](/plugin-guide) expands each step, and the [WordPress security guide](/guide/wordpress-security-guide) covers hardening once you are live.

Cloning wins when most of your site's value is content and presentation. It loses when most of the value sits behind a login. If your Plasmic project is genuinely an application — accounts, permissions, a live data layer — keep that where it is and convert only the public marketing surface. A hybrid setup, WordPress serving the content site and the platform serving the app, is common and entirely sensible. The [portability checklist](/guide/ai-website-portability-checklist) helps you draw that line without wishful thinking. The other reason to wait is an unfinished site: converting a half-built project yields a half-built theme. That said, an early conversion run purely to inspect the output costs nothing and often exposes a structural problem while it is still cheap to fix. The preview is free either way — [pricing](/pricing) covers what a finished conversion costs.

Get your Plasmic source, drop it into the [converter](/upload) and open the WordPress preview. If it looks right, download the theme. If it does not, you have spent five minutes and learned exactly which part of the source needs attention — which is a considerably better outcome than three weeks of a rebuild reaching the same conclusion. From there, the [gallery](/gallery) shows finished conversions, [best AI builder for WordPress conversion](/guide/best-ai-builder-for-wordpress-conversion) compares how cleanly each platform exports, and [prevent AI builder vendor lock-in](/guide/prevent-ai-builder-vendor-lock-in) explains how to keep your next project portable from the first commit.