Clone A Uizard Site In Under 5 Minutes

A rebuild throws away the only artefact that everybody already agreed on: the finished page. Someone signs off on the design, then a developer reinterprets it from a screenshot, and the next three weeks are spent arguing about spacing. Cloning inverts that. The markup and stylesheets that produced the approved page are carried into a WordPress theme unchanged, so the argument never happens. Uizard produces an AI design tool that turns sketches and prompts into screens, then exports either a static HTML/CSS bundle or React component code. That matters, because the honest answer to "can this be cloned" depends entirely on what the platform actually emits, not on marketing copy. Presentation — structure, styling, typography, imagery, copy — is portable by nature. Application behaviour is not, and any tool that pretends otherwise is setting you up for a bad month. The practical result for a designers and product people who prototype quickly and then need a real, publishable website out of the prototype is a site that looks identical, loads from hosting you chose, and can be edited by anyone with a WordPress login. Start at the [converter](/upload), or read [how the technology works](/technology) if you want the mechanics before the marketing.

With Uizard, the source comes from the export menu, where you choose an HTML or React export and receive a download containing markup, styles and the image assets used in the design. Spend two minutes verifying it before you upload; a bad export is the single most common reason a first conversion disappoints. For an archive, check four things: a manifest exists at the root (`package.json` for a framework project, `index.html` for a static bundle), `node_modules` is not included, the image folder is present and not empty, and the archive root is the project root rather than a wrapper inside a wrapper. For a live-site conversion, check instead that the pages you care about are reachable without logging in and that your sitemap is published. If the platform offers a Git connection, use it. A repository export respects `.gitignore`, keeps the lockfile that pins your exact dependency versions, and can be handed to the converter as a URL. Platform-by-platform screenshots live in the [guides index](/guides).

**Detection.** The upload is fingerprinted. Configuration files, dependency names and folder shapes identify it as a Uizard project and select the matching conversion strategy instead of a generic one. **Build.** If the project needs compiling, dependencies install and a production build runs in an isolated runner. Missing environment variables are substituted with safe placeholders so a marketing page never fails because an unused API key is absent. **Discovery.** There is no router: each exported screen is a standalone HTML file, and the converter treats the file tree as the route map. Declared routes, sitemap entries and internal links are merged into one list, then de-duplicated. **Render.** Each route is opened in a headless browser and captured after the page settles, so text that only exists after JavaScript runs becomes crawlable HTML. **Assets.** Assets ship inside the export folder as ordinary files, which is the cleanest possible case for a conversion. **Theme.** Repeating header and footer markup is detected by frequency and split into `header.php` and `footer.php`; everything else becomes page templates and template parts. PHP syntax, link health and preview rendering are validated before the ZIP is released alongside a live WordPress preview.

**One.** Exports are screen-oriented rather than site-oriented: each screen becomes its own document with absolutely positioned elements, which converts perfectly but is not responsive until the layout is revisited. This is cheap to handle at the source and awkward to repair inside a generated theme, so deal with it before you convert. **Two.** Duplicate screens created during design iteration are often included in the export, so the conversion discovers three near-identical pages where the site only needs one. This one tends to survive conversion quietly, which is the more expensive failure: the theme installs, the preview looks acceptable, and the problem surfaces weeks later when a crawler or a phone finds it. Both are handled defensively. Unresolved asset references are matched by filename and content hash, routes that render suspiciously empty are flagged by the preview integrity check, and orphan pages are reported in the diagnostics rather than silently dropped. Defensive handling is not a substitute for a clean source, though — see [fix broken layouts after conversion](/guide/fix-broken-layouts-after-conversion) for the repair playbook.

**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 URLs. **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 repeated content types such as case studies or team members become a custom post type with a loop. **Left behind:** prototype interactions such as screen-to-screen click-throughs, which need to become real links, and any component state that only existed in the prototype player. That third list is the part most tools hide. Write it down before you start, decide which items actually matter, and you will finish the migration in days rather than discovering a blocker in week three. The [features page](/features) documents exactly which stages are automated and which produce a warning for you to act on.

Take a two-person startup that designed their launch site in Uizard over a weekend, exported it, and needed a WordPress theme so a contractor could add a blog before their funding announcement. **Day one.** They produced the export, ran a conversion and opened the preview. Every page rendered except the contact form, which displayed correctly but had nowhere to submit. Elapsed time from export to preview: under fifteen minutes. **Day two.** The theme went onto a staging site. The form was wired to a WordPress form plugin, two hero sections were converted into blocks so marketing could edit copy without a developer, and the navigation was moved into a WordPress menu. **Day three.** URLs were mapped one to one, redirects were added for the two paths that had to change, and a link audit found nothing broken. Images that had been served from a remote CDN were now local, which improved the largest contentful paint measurably. **Day five.** DNS switched during a quiet hour. Search 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.

Do these in order and you will catch nearly everything that matters. 1. Install the ZIP through Appearance → Themes → Add New → Upload, then activate. 2. Open every page beside the original in a second tab and compare. 3. Test on a real phone, not a narrow desktop window. 4. Click every navigation item, including footer links. 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 switch on 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; the [WordPress security guide](/guide/wordpress-security-guide) covers hardening once you are live.

Cloning is the right move when most of your site's value is content and presentation. It is the wrong move when most of the value sits behind a login. If your Uizard project is genuinely an application — accounts, permissions, a live data layer — keep that part where it is and convert only the public marketing surface. A hybrid setup where WordPress serves the content site and the platform serves the app is extremely common and entirely reasonable. The [portability checklist](/guide/ai-website-portability-checklist) helps you draw that line honestly. The other case for waiting is an unfinished site. Converting a half-built project produces a half-built theme. That said, running an early conversion purely to see the shape of the output costs nothing and often reveals a structural problem while it is still cheap to fix. The preview is free either way — see [pricing](/pricing) for what a finished conversion costs.

Export your Uizard project, 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 precisely which part of the source needs attention. From there: the [gallery](/gallery) shows finished conversions, the [technology page](/technology) explains the pipeline in depth, and the [security page](/security) documents how your upload is stored and deleted. Bring the site home — the design you already approved, on hosting you control, in a CMS your whole team can already use.