Migrate Bolt.new to WordPress: A Practical Migration Guide

Bolt.new is StackBlitz's AI coding platform, and the crucial detail for migration planning is that it runs entirely inside a WebContainer — a Node runtime compiled to WebAssembly that lives in your browser tab. That means every build, every dependency install, and every dev server that happens in Bolt.new happens without touching a remote server. Once you understand this, the migration path is obvious: you're not exporting a hosted site, you're exporting a normal npm project that happens to have been assembled in a browser. Bolt.new most commonly produces Vite + React projects, occasionally Next.js or Astro, and always ships a fully valid `package.json`, `vite.config.ts` or `next.config.js`, and a `dist` or `out` directory once you run the build script. From the converter's perspective it looks identical to a project scaffolded with `npm create vite@latest` — which is exactly why the conversion is so reliable.

The reasons overlap with every other AI-builder-to-WordPress conversation, but Bolt.new has one specific driver worth calling out: hosting cost. StackBlitz's paid tiers are priced for developers who need faster WebContainers and more AI credits, not for teams who want to run a public marketing site. Deploying the exported Bolt.new project to Vercel Pro adds another subscription, and WordPress hosting simply undercuts that math at almost any scale. The second reason is the editorial gap. Bolt.new is fantastic at generating a landing page in fifteen minutes. It's not built to let a marketing team ship a blog post at 4pm on a Thursday without pinging the developer. WordPress collapses that round-trip, and every team we've worked with reports the same effect: publishing frequency roughly doubles within a quarter of the cutover. A third reason is longevity. A Bolt.new project is code, but the code lives inside a StackBlitz environment. Migrating to WordPress means the site now lives on infrastructure you own, portable to any host on the planet.

Do these three checks before you export. First, run `npm run build` inside the WebContainer and confirm it exits cleanly. A green build in StackBlitz means a green build in the converter's worker; a red one will fail there too. Second, walk the app in the WebContainer preview and note every route. If the routing library is React Router, expose the route list in a serialisable file so the pre-renderer can find every URL; Next.js and Astro do this automatically via file conventions. Third, prune any dependencies you don't need — Bolt.new occasionally imports packages the AI thought you might need but you never used, and every one of them slows the install step. Export via GitHub if the project is bigger than a handful of files: the StackBlitz GitHub integration commits everything cleanly, and the converter pulls a shallow clone. For smaller projects the direct ZIP download is fine.

Upload the project (ZIP or GitHub URL) via the AI to Wordpress home page. The pipeline runs framework detection, spins up a disposable worker, installs dependencies, and runs the build. A headless Chromium then walks every discovered route, captures the rendered HTML, and hands the payload to the theme generator. The generator emits standard WordPress template files: `front-page.php` for the home route, `page.php` for static routes, `single-<cpt>.php` for dynamic routes, plus `header.php` and `footer.php` extracted from the shared shell. Tailwind's compiled stylesheet is enqueued as the theme stylesheet, hashed JavaScript chunks are mirrored into the theme's assets folder, and a minimal `functions.php` registers menus, image sizes, and enqueue rules. Before you pay, the theme boots inside a WordPress Playground instance in your browser so you can click through every page. If something looks wrong, you fix it in the Bolt.new source and rerun. If everything looks right, you pay €17 and download the theme ZIP. Nothing is charged before the preview is green.

Provision WordPress on any host — the theme has no exotic requirements. Upload the ZIP via Appearance → Themes → Add New → Upload, activate it, and set the home page under Settings → Reading to the theme's `front-page` template. Recreate the navigation in Appearance → Menus using the labels from your Bolt.new design and assign it to the primary location the theme registered. If your Bolt.new project called a serverless API you owned, decide now where that API is going to live. The two clean options are: rewrite it as a WordPress REST endpoint (best for consolidation) or keep it on Vercel/Cloudflare Workers and add your WordPress domain to the CORS allowlist (best if the API is complex or shared with other frontends). Both are supported; there is no wrong answer. Install a caching plugin (WP Rocket, LiteSpeed Cache, or W3 Total Cache) and enable page cache plus lazy-load. The theme is essentially static HTML with hydration on top, so cached pages hit sub-500ms even on modest hosts.

Bolt.new projects commonly use `VITE_*` (Vite) or `NEXT_PUBLIC_*` (Next.js) variables, both of which are inlined at build time and therefore travel with the compiled bundle. That means any public API key you baked into the frontend continues to work in WordPress unchanged. Server-only variables (unprefixed) are a different story: they never reached the compiled bundle, and they don't exist in WordPress either. If your app relied on server-only variables for API routes (`pages/api` in Next.js, or a custom Node backend in Vite), you have two migration paths. The first is to rewrite each endpoint as a WordPress REST route inside a small custom plugin, using WordPress's transient cache and its native database for state. The second is to keep the endpoints on their existing host — Vercel Functions, Cloudflare Workers, or a small VPS — and call them via CORS from the migrated frontend. Neither is more correct; the choice depends on how much backend logic there is and how much of your organisation already knows WordPress vs Node. One detail worth checking: any endpoint that assumed same-origin requests will need CORS headers configured now that the frontend is on a WordPress domain. This is the single most common gotcha in the first 48 hours after cutover.

The migration preserves URLs exactly: every route the pre-renderer discovered ends up at the same path in WordPress. Google treats the WordPress site as the same content on the same URLs, so unless you're also changing domains there is nothing to redirect. When you are changing domains (from a `bolt.new` preview URL to your custom domain, for example), install the Redirection plugin, generate a CSV of `old_url,new_url` pairs, and import in a single shot. Submit the new sitemap in Search Console within 24 hours, then request indexing for the ten highest-traffic pages. In our data, small sites re-index inside a week; larger ones inside two to three weeks. Rankings usually improve for two reasons: pre-rendered HTML is easier for search engines to consume than SPA shells, and the migrated theme emits richer structured data (breadcrumbs, article, organization) than a bare Bolt.new build. If content velocity picks up post-migration (which is the norm), the organic curve typically bends up within a quarter.

The three most common post-launch fixes are worth naming so you spot them fast. First, purged Tailwind classes: any class name you constructed dynamically at runtime will not survive the build. Safelist it in `tailwind.config` and rerun the migration. Second, oversized icon libraries: if you imported `lucide-react` with a wildcard, tree-shaking failed and the bundle is 400KB bigger than it needs to be. Switch to named imports and rerun. Third, missing meta tags on dynamic routes: if you generate `<title>` and `<meta>` server-side via a helper that wasn't in scope during pre-render, those tags won't appear in the HTML. Move the helper to a module-level call so it fires during build. None of these are catastrophic, all of them are five-minute fixes, and all of them are surfaced by the audit step of the converter as soft warnings before you download. Read the warnings, fix them at source, rerun the migration. The reward is a WordPress site that renders your Bolt.new design one-for-one and gives your team a real editorial surface for everything that comes after.