Clone A TeleportHQ 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. TeleportHQ produces a visual builder with a real code export, producing static HTML/CSS or a framework project such as React, Vue or Next.js depending on the export target you pick. 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 teams who want a visual editor but refuse to be locked out of their own code 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 TeleportHQ, the source comes from the code export dialog, where you select a target and download a ZIP, or connect the project to a Git repository and pull it from there. 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 TeleportHQ 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.** Routes mirror the pages defined in the editor, and framework exports also carry a router file the converter reads directly. 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 are written into a static folder inside the export, with remote references only when you deliberately linked an external image. **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.** The export target you choose changes everything downstream — an HTML export converts as a static site while a Next.js export must be built and pre-rendered first, and picking the wrong one is the most common cause of a confusing result. This is cheap to handle at the source and awkward to repair inside a generated theme, so deal with it before you convert. **Two.** The builder emits utility class names that are generated per project, so a partially copied stylesheet leaves pages that look almost right, which is harder to spot than a page that is obviously broken. 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:** the visual editor itself and any dynamic content bound to an external CMS through the builder's data bindings. 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 digital agency that used TeleportHQ for rapid client mock-ups and standardised on delivering every approved design as a WordPress theme instead of hosting on yet another platform. **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 TeleportHQ 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 TeleportHQ 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.