Clone Webstudio Website In Under 5 Minutes

Cloning a Webstudio website is not screen-scraping and it is not a screenshot. It is the reconstruction of a rendered site — markup, stylesheets, scripts, fonts, images and route structure — into a WordPress theme that behaves the same way on your own server. Webstudio produces an open-source visual builder that outputs standards-based HTML and CSS instead of a proprietary runtime, with an optional Remix-based project export. That matters, because the closer the platform sits to plain HTML and CSS, the less repair work a clone needs. The five-minute figure in the title is honest, but it describes the conversion run, not the whole project. The pipeline pre-renders the declared routes, downloads every asset it can resolve, rewrites internal links, splits the recurring header and footer into template parts, and emits an installable theme. On a typical Webstudio marketing site with five to fifteen pages, that takes between two and five minutes. The half hour around it — checking the export, reviewing the preview, deciding what to rebuild as native WordPress — is where the judgement lives. A useful way to frame the job: you are moving the presentation layer, not the platform. Everything that was rendered as HTML travels. Everything that depended on Webstudio running in the background stays behind and needs a WordPress equivalent.

Start at the publish menu, where you either download the static site bundle or export the project as a repository you can build yourself. Download the project root, not a subfolder. This sounds obvious, yet a large share of failed conversions are simply an archive that starts one directory too deep, so the package manifest and the build configuration are missing and nothing can be built. Before you upload anything, open the archive and confirm three things exist: a manifest that declares the build command, a source directory with your pages in it, and a public or static folder with the images. If any of the three is absent, go back and export again from the root. It costs a minute and saves an hour. If Webstudio offers a repository connection, prefer it. A Git remote gives you a reproducible tree, a commit hash you can quote in a bug report, and no risk of a browser download truncating a large binary. The converter accepts a repository URL as readily as it accepts an archive, and the [ZIP upload flow](/upload) treats both the same way afterwards.

1. Export the project from Webstudio as described above. 2. Open the [converter on the homepage](/) and drop the archive into the upload area, or paste the repository URL. 3. The pipeline detects the builder fingerprint automatically; you can override it if you know the project was heavily customised. 4. Wait while routes are discovered, the production build runs, and each route is pre-rendered to HTML. 5. Open the free live WordPress preview and click through every page. 6. Download the theme ZIP and install it on your own hosting through the [theme installation guide](/plugin-guide). Steps one and two are yours. Steps three to five are the machine's. Step six is a two-minute upload in the WordPress admin. Nothing here requires PHP knowledge, but the preview step is not optional — it is the only place where you will notice, for example, that class names are generated from the design tokens and can change between publishes, so any custom CSS written against those names has to be re-checked after conversion.

Every builder has a signature failure. For Webstudio, the first one is that class names are generated from the design tokens and can change between publishes, so any custom CSS written against those names has to be re-checked after conversion. The pipeline compensates by cross-referencing every asset reference against the files that actually exist in the archive and mirroring anything it finds under both the referenced path and a normalised media path, but the result is worth verifying with your own eyes on the preview. The second is subtler: collection pages driven by the built-in CMS are rendered at publish time, meaning the export contains the rendered items but not the structure behind them. That is not a conversion bug; it is a property of the source project. The fix belongs in the export, not in the theme. Delete the stray route or link it properly before you convert, and the converted site stays tidy. Routing deserves its own note. In Webstudio, the static bundle mirrors the page tree with real directories and index files, which is the easiest possible input for route discovery. Anything that is only reachable by clicking a button that changes in-memory state — a tab, an accordion, a modal — is not a page and cannot become one automatically. If that content needs to rank in Google, give it a real URL first.

In Webstudio, images are exported already resized into multiple widths with a srcset, so the converted theme inherits responsive images almost for free. That single sentence explains most of the "missing images" reports we see. A converter can only fetch what it can resolve, so any picture that lives behind a signed URL or an authenticated bucket has to be downloaded manually and dropped into the theme's image directory before packaging. After conversion, decide deliberately where images should live. Keeping them inside the theme is fastest and survives a redeploy untouched. Moving them into the WordPress media library gives editors the ability to swap a photo without a developer. Most teams do both: structural graphics stay in the theme, editorial photography moves to the library. The [image optimization guide](/guide/wordpress-image-optimization) covers the sizing and format work that follows. One practical tip: run through the preview with the browser network panel filtered to images and sorted by status. Any 404 is a two-minute fix now and an embarrassing gap after launch.

**Freeze the design.** Convert a version you are happy with. Re-converting after every tweak wastes time and creates confusion about which theme is current. **Name your pages properly.** The route path becomes the WordPress page slug. `/our-work` is a URL you can live with; `/page-3` is not. **Write the meta tags in Webstudio first.** Titles and descriptions that already exist in the source travel into the theme, and you can refine them later with an SEO plugin. **Flatten anything experimental.** Half-built sections, commented-out components and placeholder text all convert faithfully, which is exactly the problem. **Decide what becomes editable.** Before conversion, list the blocks that marketing will want to change monthly. Those are the candidates for WordPress blocks, custom fields or a [custom post type](/guide/wordpress-custom-post-types) rather than hardcoded theme markup. **Check the target hosting.** PHP 8.1 or newer, sensible upload limits, and HTTPS. The [hosting guide](/guide/wordpress-hosting-guide) has the specifics.

**Converting the preview URL instead of the source.** A crawl of a live preview captures one rendered state. The project archive captures the whole application. Always prefer the source. **Ignoring the preview.** The free WordPress preview exists so that layout regressions are found before money changes hands. Skipping it is the single most expensive shortcut available. **Assuming forms will work.** They will not, because the endpoint they posted to belongs to Webstudio. Rebuild them with a WordPress form plugin — the [contact forms guide](/guide/wordpress-contact-forms-guide) walks through the mapping. **Changing URLs without redirects.** If the old site ranked, keep the paths identical or publish 301 redirects on day one. See the [SEO migration checklist](/guide/seo-migration-checklist-ai-website-wordpress). **Editing the parent theme directly.** Any later regeneration overwrites your changes. Use a [child theme](/guide/wordpress-child-theme-guide). **Launching without a backup.** Take one before installing the theme and one after, and read the [backup and recovery guide](/guide/wordpress-backup-recovery) once.

Consider a small agency with a dozen client sites on Webstudio that standardised on WordPress so every client could use the same maintenance and backup routine. The project had eleven public routes, a shared header with a six-item menu, a footer with three link columns, and roughly ninety images. The export took four minutes, mostly spent confirming that the archive really did start at the project root. The conversion run itself finished in under three minutes: route discovery found ten of the eleven pages immediately, and the eleventh — a case study reachable only from an in-page filter — had to be given a real path in the source and re-exported. In the preview, two problems surfaced. The first was a set of images that resolved to nothing, caused by exactly the behaviour described earlier: class names are generated from the design tokens and can change between publishes, so any custom CSS written against those names has to be re-checked after conversion. Re-running with the assets present in the archive fixed it. The second was a footer that appeared twice on one template, a duplication that already existed in the source markup. Total elapsed time from export to installed theme: under forty minutes, of which roughly five were the conversion. The remaining work — rebuilding the contact form, adding an SEO plugin, connecting analytics — took an afternoon and would have been required on any platform.

Be precise about this with stakeholders before you start. From a Webstudio project, the following does not travel: the Webstudio CMS collections, its form handling endpoint, and any variable-driven binding that resolved at publish time. None of it is lost in a meaningful sense; it simply has a different implementation in WordPress. Authentication becomes WordPress users and roles. Stored records become custom post types or a plugin's own tables. Server logic becomes a plugin, a REST endpoint or an external service called from the front end. The [REST API guide](/guide/wordpress-rest-api-guide) is the right starting point if the site needs to keep talking to an existing backend. The honest summary: the visual layer converts almost completely, and the application layer is a rebuild. Teams that plan for that split finish quickly. Teams that expect a full application port are the ones who feel disappointed.

☐ Export from the project root in Webstudio ☐ Verify the manifest, source folder and asset folder are present ☐ List every public URL that must exist after launch ☐ Give in-memory-only content a real route ☐ Confirm titles and descriptions are set per page ☐ Upload the archive to the [converter](/upload) ☐ Review every page in the free WordPress preview ☐ Check the network panel for missing images and fonts ☐ Download the theme and install it on a [staging site](/guide/wordpress-staging-environment) ☐ Install an SEO plugin and import the meta values ☐ Rebuild forms with a WordPress form plugin ☐ Recreate navigation as a WordPress menu ☐ Publish 301 redirects for any changed path ☐ Add analytics and consent handling ☐ Run a Lighthouse pass and act on the [speed guide](/guide/speed-optimization-guide) ☐ Take a full backup, then point DNS at the new host ☐ Submit the sitemap in Search Console and watch coverage for two weeks

A manual rebuild of a fifteen-page marketing site by an agency is typically two to four weeks and several thousand euros. The design is retyped, the CSS is re-authored, and the result is a new set of bugs in exchange for the old ones. A clone starts from the artefact that already passed design review, which removes an entire round of approvals. The cost argument is easy, but the risk argument is stronger. When the markup is preserved rather than reinterpreted, the visual regression surface is small and inspectable. You can diff the preview against the original page by page. That is not possible when a developer has rewritten the components from a Figma file. Agencies that want visual editing without accepting a closed hosting platform tend to reach the same conclusion in the same order: the builder was excellent for getting to a design, and WordPress is better for the decade that follows. Cloning is simply the bridge between the two. For a wider view of that decision, the [vendor lock-in guide](/guide/prevent-ai-builder-vendor-lock-in) and the [portability checklist](/guide/ai-website-portability-checklist) are worth twenty minutes.

You can test the whole path without paying anything. Export your Webstudio project, drop the archive into the [converter](/upload), and open the free live WordPress preview. If the preview looks right, download the theme; if it does not, you have lost five minutes and learned exactly which part of the source needs attention. When you are ready, the [pricing page](/pricing) shows the single per-conversion fee, the [features page](/features) details the QA and validation pipeline, and the [gallery](/gallery) shows finished conversions from other builders. Bring your site home — the design you already approved, running on hosting you control, in a CMS your whole team can use.