Clone Dora AI Website In Under 5 Minutes

Almost every Dora AI project that gets cloned to WordPress follows the same arc. The build phase is fast and enjoyable, the site ships, and then the second phase begins: someone needs to publish a post, a client asks for a second language, a plugin exists in WordPress that exists nowhere else, or the finance team notices a recurring platform bill for a page that has not changed in six months. Dora AI produces an animation-first visual builder that outputs an HTML, CSS and JavaScript bundle where scroll effects and 3D transforms are the centrepiece. That description matters more than any marketing claim, because it determines how much of the site can travel unchanged. The closer the output is to plain HTML and CSS, the smaller the gap between what you see on the platform and what you get in a theme. The audience is consistent too: designers and studios whose pitch is motion, and whose clients then ask for a CMS. None of them are trying to abandon the builder — they are trying to stop the finished result from depending on it. Cloning is the mechanism for that. The [vendor lock-in guide](/guide/prevent-ai-builder-vendor-lock-in) covers the strategic side; this page is the practical one.

Everything downstream depends on a complete export, so spend two minutes here rather than debugging later. With Dora AI, the source comes out of the export or publish menu, which produces a static bundle of the site as it is rendered for visitors. Before you upload, open the archive and confirm four things. First, a manifest file is present at the root — a `package.json` for a framework project, or an `index.html` for a static bundle. Second, `node_modules` is absent; it adds hundreds of megabytes and is reinstalled during the build anyway. Third, the folder containing your images is included and not empty. Fourth, the archive root is the project root, not a wrapper folder containing a wrapper folder. A GitHub export is usually cleaner than a manual ZIP because it respects `.gitignore`, and the converter accepts a repository URL directly. If your project has a lockfile, keep it: it pins the exact dependency versions the platform used, which removes an entire category of build surprises. The [export guides index](/guides) has platform-by-platform screenshots if you get stuck.

**Minute one.** Drop the archive into the [converter](/upload). Detection fingerprints the project, identifies it as a Dora AI build and selects the matching strategy. **Minute two.** Dependencies install and a production build runs in an isolated runner. Missing environment variables are filled with safe placeholders so a marketing page never fails to render because of an unused API key. **Minute three.** Route discovery runs. The exported bundle contains one directory per page with an index file, which is the friendliest possible input for route discovery. Declared routes, any sitemap and internal links are merged into a single list. **Minute four.** Each route is pre-rendered in a headless browser and captured after the page settles, so client-rendered text becomes crawlable HTML. Assets are resolved: media is exported alongside the markup in a single assets folder, already optimised, so almost nothing has to be fetched remotely. **Minute five.** Recurring header and footer markup is detected by frequency and split into `header.php` and `footer.php`; the rest becomes page templates. PHP syntax, link health and preview rendering are validated, and the theme ZIP is released together with a live WordPress preview you can click through before paying anything.

**Travels unchanged:** the HTML structure of every discovered page, all stylesheets including the compiled utility classes, fonts, images, favicons, SVGs, client-side scripts that do not call a platform API, meta titles and descriptions, Open Graph tags, and the internal link graph rewritten to WordPress URLs. **Rebuilt in WordPress:** forms, which keep their markup but need a form plugin behind them; search, which becomes native WordPress search; newsletter signups, which connect to your email tool; and any dynamic listing, which becomes a custom post type with a loop. **Stays behind entirely:** the visual animation editor itself, and any interaction that was configured in the canvas rather than expressed in the exported CSS. That third list is the honest part of this page. A conversion that claims to move authentication or a hosted database is selling you a problem for later. Presentation converts reliably; application behaviour is re-implemented with WordPress-native tools, and it is usually faster to do that than to port it. The [features page](/features) documents which parts are automated and which are flagged for you.

**The first:** scroll-linked animations depend on the platform's own runtime script, and if that script is not carried into the theme the page loads with every element stuck in its start state. This is the failure mode worth checking before you convert, because it is cheap to fix at the source and awkward to fix in a generated theme. Open the built output locally, confirm the affected pages render as you expect, and only then export. **The second:** heavy transform stacks are tuned for one viewport, so the mobile rendering needs an explicit review after conversion rather than a glance. This one usually survives conversion silently, which is worse — the theme installs, the preview looks fine, and the problem appears weeks later when someone opens the affected page on a phone or a crawler indexes a route you forgot existed. Both are handled defensively by the pipeline: unresolved asset references are matched by filename and hash, orphan routes are reported in the diagnostics rather than dropped, and the preview integrity check flags pages that render suspiciously empty. But a clean source always converts better than a repaired one, and five minutes of tidying beats an hour of theme editing. See [fix broken layouts after conversion](/guide/fix-broken-layouts-after-conversion) for the repair playbook.

Consider a motion design studio that delivered an award-shortlisted product page in Dora and had to hand the client a self-hosted WordPress theme with the animations intact. Here is what the week looked like. **Day one, morning.** They exported the project and ran a conversion. The preview showed every page correctly except the contact page, where the form rendered but obviously could not submit anywhere. Total elapsed time: eleven minutes. **Day one, afternoon.** They installed the theme on a staging site, connected the form to a WordPress form plugin, and moved three sections into blocks so the marketing lead could edit them without touching code. **Day two.** They mapped old URLs to new ones, added redirects for the two paths that changed, and ran a link audit. Nothing was broken, but two images had been pulled from a remote CDN and were now local, which shaved a second off the largest contentful paint. **Day four.** DNS switched. Rankings held. The platform subscription was cancelled at the end of the billing period, and the site has been running on ordinary hosting ever since. The [SEO migration checklist](/guide/seo-migration-checklist-ai-website-wordpress) is the same one they used.

Work through this in order and you will catch nearly everything that matters. 1. Install the theme ZIP through Appearance → Themes → Add New → Upload, then activate it. 2. Open every page and compare it side by side with the original in a second tab. 3. Check the site on a phone, not just a narrow browser window. 4. Click every navigation item, including the footer links. 5. Connect each form to a form plugin and send a real test submission. 6. Set permalinks to Post name and confirm the URLs match the originals. 7. Install an SEO plugin and verify 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 you point DNS. 12. Give your editor an account with the Editor role and let them 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.

A manual rebuild of a ten to fifteen page site by an agency runs into weeks and thousands of euros, and it produces a new implementation with new bugs in exchange for the old ones. A clone starts from the artefact that already passed design review, which deletes a whole approval round. The stronger argument is risk. When markup is preserved instead of reinterpreted, the visual regression surface is small and inspectable: you can diff the preview against the original page by page. That is simply not possible when a developer has rewritten components from a design file. Who should not clone? Anyone whose site is mostly application rather than content. If ninety per cent of the value is behind a login, keep it on Dora AI or a framework host and convert only the public marketing surface. That hybrid is common and completely reasonable — the [portability checklist](/guide/ai-website-portability-checklist) helps you draw the line, and the [pricing page](/pricing) shows the single per-conversion fee for the part you do move.

You can test the whole path for free. Export your Dora AI project, drop the archive into the [converter](/upload), and open the live 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 before trying again. From there, the [gallery](/gallery) shows finished conversions from other builders, the [technology page](/technology) explains the pipeline in depth, and the [security page](/security) documents how your upload is handled. Bring the site home: the design you already approved, on hosting you control, in a CMS your whole team can use.