How to Convert a Bolt.new Site to WordPress (2026 Guide)

You built a site in Bolt.new. It works. Maybe you deployed to *.bolt.host, maybe you pushed it to Netlify or Vercel. You’ve watched your Search Console stay flat at zero impressions for weeks, realized the underlying problem — Bolt’s default output is a client-rendered single-page app that Google struggles to index — and concluded the fix is a migration to WordPress.

This guide walks through that migration end-to-end. It’s the DIY version of what we do in 7 days as a service, documented so you can execute it yourself if you’d rather.

Realistic time investment: a weekend for a single-page site, 3–7 focused days for a multi-page marketing site. Add time for Supabase backend migration or custom WebContainers setup.

Who this guide is for:

• Bolt.new users comfortable with React, Vite, and WordPress basics
• Anyone evaluating DIY vs. hiring it out
• Freelancers handling Bolt migrations for their own clients

Who it isn’t for:

• Complete WordPress beginners — do a WordPress 101 course first
• Anyone under deadline pressure — this is a multi-day project, not an afternoon

If the scope feels bigger than you want to take on, Bolt.new to WordPress migrations start at $299. No shame in handing this off.

Why Bolt.new migrations are different

Before jumping into steps, three things make Bolt migrations distinct from Lovable or v0:

1. Framework variance. Bolt.new doesn’t have a single default stack. Depending on how you prompted it, your project could be Vite + React, Next.js, Astro, SvelteKit, or something else. This guide assumes the most common output (Vite + React + Tailwind), but check your package.json first — if it’s Next.js, some steps are closer to the v0 migration.

2. WebContainers. Bolt runs your Node.js environment directly in the browser via StackBlitz’s WebContainers. That’s a development-time detail — your production build is standard. But it means your Bolt “project” isn’t a traditional git repo until you export it.

3. The hosting problem is worse. The default yoursite.bolt.host deployment is more SEO-limited than Lovable’s hosting or v0’s Vercel setup. Custom domains work, but the underlying infrastructure still ships a pure SPA. Community workarounds like <noscript> fallbacks patch the symptom but not the root cause. Migration is the clean path.

With that context, here’s the step-by-step.

Step 1 — Audit your Bolt.new site before touching anything

Don’t start building in WordPress yet. Inventory first.

Open your Bolt project and document:

• Every page, with URL, title, meta description
• Every section on each page — hero, features, testimonials, pricing, FAQ, etc.
• Every asset — images, logos, icons, videos
• Every integration — Supabase (very common on Bolt), Stripe, form handlers, analytics
• Every interactive element — forms, modals, filters, animations

Screenshot every page at desktop (1440px) and mobile (375px) widths. These are your reference.

Document your color palette (hex values from tailwind.config.js), font families (usually Google Fonts imports), and any custom spacing.

Check your package.json and note: what framework is the Bolt project actually using? This affects a few decisions later.

Step 2 — Export your Bolt.new code

Bolt.new has built-in GitHub export. Use it.

From Bolt’s UI: Export → Connect GitHub → Push to new repo.

Clone the repo locally:

git clone https://github.com/yourusername/your-bolt-project.git
cd your-bolt-project
npm install
npm run dev

You won’t ship this code in production — it’s reference for the WordPress rebuild. What you’ll actually use:

• Component structure — tells you what sections exist and how they’re composed
• tailwind.config.js — exact color palette and typography
• Copy strings — faster than copying from the rendered site
• /public and /src/assets — all your images and icons
• Supabase client code, if present — for rewiring backend in Step 7

What you won’t use:

• The React/Vue/Svelte source — you’re rebuilding in WordPress blocks
• The Vite build config
• Any WebContainers-specific configuration

Step 3 — Set up WordPress

Two hosting options:

Managed WordPress hosting (recommended for most people): SiteGround, Kinsta, WP Engine, or Cloudways. One-click install, SSL included, caching built-in. $8–$40/month.

Your own server (DigitalOcean, Hetzner, AWS): more control, more work. Only if you have DevOps comfort.

For Bolt migrations I typically default to Cloudways or SiteGround — both handle the annoying stuff (SSL, backups, WordPress updates) automatically.

Once WordPress is installed:

1. Log into /wp-admin
2. Settings → General — set site title, tagline, timezone
3. Settings → Permalinks — select Post name (gives you clean URLs like /about/)
4. Settings → Reading — confirm “Discourage search engines from indexing” is unchecked. This is the single most common launch-blocker on migrations.
5. Delete the default “Hello World” post, “Sample Page,” and “Uncategorized” category

Step 4 — Install a lightweight theme

Bolt.new outputs tend to be modern, Tailwind-driven, often with gradient backgrounds and card-heavy layouts. The WordPress themes that match this aesthetic and stay fast:

• Kadence — my default. Flexible, fast, works well with any block editor workflow.
• Blocksy — similar strengths, slightly more visual customization.
• GeneratePress — the minimalist option. Very fast, fewer built-in features.

Avoid: Divi, Avada, any multipurpose theme with a bundled page builder. They’re slow and they fight your rebuild.

Install via Appearance → Themes → Add New. Activate. Then set site identity (logo, favicon, primary color) in Appearance → Customize.

Step 5 — Pick your block system

Two real choices for building pages:

Gutenberg + Kadence Blocks (recommended for Bolt migrations). Gutenberg is native WordPress, stays fast, and Kadence Blocks (free) adds the layout flexibility Bolt designs usually need. Kadence Blocks Pro ($129/year) adds about a dozen more advanced blocks.

Elementor Pro ($59/year). Familiar visual drag-and-drop interface. Adds roughly 10–20 Lighthouse performance points of overhead — meaningful on a site you’re migrating specifically to improve ranking.

For Bolt migrations, Gutenberg + Kadence Blocks is the right call. Bolt designs tend to be clean and geometric, which maps naturally to block composition. Elementor is only worth it if you’ve used it for years and don’t want to learn Gutenberg.

Step 6 — Rebuild page by page

This is where the work lives. For each page:

1. Create the page: Pages → Add New
2. Set the title and permalink slug — match your Bolt.new URL exactly if you can
3. Build the layout section by section, using screenshots as reference
4. Copy text content from your Bolt site’s rendered output (use browser copy, not source — the rendered output has the final copy)
5. Upload images to Media Library (Media → Add New). Optimize first with Squoosh or TinyPNG. Target: under 200 KB each.
6. Match colors exactly from your tailwind.config.js hex values
7. Match fonts — install the same Google Font family (Kadence has a typography panel in Customize that handles this in one click)

Bolt-specific rebuild notes:

• Framer Motion animations — Bolt often generates these. For the WordPress rebuild, either drop them or translate the essentials to CSS transitions. Most are decorative; nothing ranks worse without them.
• Gradient hero sections — these need custom CSS in WordPress’s Additional CSS panel. Pull gradient definitions from your exported code and adapt.
• Lucide icons — Bolt uses these heavily. Lucide icons are available as SVG — upload directly to Media Library or use a WordPress icon plugin.

Test every page at desktop and mobile widths as you build. Chrome DevTools’ device toolbar is sufficient.

Time estimate: 45–90 minutes per page of layout work for a moderately complex marketing site. Homepages with multiple sections take longer; contact and about pages faster.

Step 7 — Rewire Supabase and integrations

Bolt.new’s default integration with Supabase is common enough that it deserves its own step. If your Bolt project doesn’t use Supabase, skim to the forms section.

If your Bolt site uses Supabase

Three paths, depending on what you were using Supabase for:

Path A — Supabase was just a contact form backend. Delete that integration entirely. Use WordPress’s Fluent Forms plugin instead. Much simpler, no external dependency.

Path B — Supabase was storing content (blog posts, products, listings). Decision point: migrate the data into WordPress (as posts, pages, or custom post types), or keep Supabase as the backend and have WordPress call its API.

• Migrating into WordPress is better long-term. Content becomes editable in the WordPress admin, shows in search, benefits from WordPress SEO plugins.
• Keeping Supabase is faster short-term but adds complexity you’ll maintain indefinitely.

Path C — Supabase handled user auth. If your site had user accounts, either (a) rebuild as WordPress user accounts (native, well-supported), or (b) bridge via a custom plugin. Path (a) is nearly always the right answer for migrated sites.

Other standard integrations

• Contact forms: Fluent Forms (free) — lightweight, reliable. Connect email delivery via WP Mail SMTP.
• Payments: WooCommerce for products, Stripe Payments plugin for simple one-offs.
• Analytics: Site Kit by Google — GA4 and Search Console in one plugin.
• Email capture: MailPoet for native lists, or embed forms from ConvertKit / Mailchimp / Beehiiv.

Step 8 — Migrate images and assets

Upload every image from your exported Bolt project’s /public and /src/assets folders to WordPress Media Library. Keep filenames consistent — makes content replacement easier.

Critical step: set descriptive alt text on every image. WordPress doesn’t enforce this, but Google uses it heavily for image search and page-level SEO. “hero-image.jpg” isn’t alt text — “Homepage hero showing Bolt.new dashboard converted to WordPress” is.

For many-image migrations, Phoenix Media Rename and Media Library Assistant plugins help with bulk operations.

Step 9 — Set up SEO properly

This step is the reason migration is worth doing. Skip it and you’ll have a prettier site that still doesn’t rank.

Install Rank Math (free tier is enough)

1. Plugins → Add New → search “Rank Math SEO” → Install → Activate
2. Run the setup wizard. The WordPress SEO setup guide has exact settings for every screen.
3. For every page you built, set focus keyword, SEO title, and meta description in the Rank Math sidebar.
4. Verify XML sitemap at /sitemap_index.xml — it should list every published page.
5. Submit sitemap to Google Search Console.
6. Test your homepage in Google’s Rich Results Test — confirm schema validates.

Set up 301 redirects for any URL changes

This is the step that preserves your existing SEO equity. If any URL from your Bolt site changes in WordPress — even trailing slashes — you need a 301 redirect.

1. In Rank Math, enable the Redirections module
2. For each changed URL, add a 301 from old path to new path
3. Test with curl -I https://yoursite.com/old-url/ — should return HTTP/1.1 301 with Location: header pointing to the new URL

Skipping redirects throws away whatever domain authority your Bolt site had accumulated. With redirects, Google transfers authority to new URLs typically within 2–4 weeks.

For the broader “why SEO matters here” context, why your AI-built website isn’t ranking on Google explains the three root causes this migration addresses.

Step 10 — Launch checklist

Before switching your domain’s DNS to the new WordPress site:

• All pages built and render correctly on desktop + mobile
• All images uploaded with real alt text
• All forms tested (submit a real entry, confirm email arrives)
• All internal links updated — zero links pointing back to the old Bolt URL
• Rank Math configured for every page with unique title and description
• XML sitemap accessible and accurate
• robots.txt allows crawling
• 301 redirects configured for any URL changes
• SSL certificate active
• Cloudflare in front as CDN (free tier is fine)
• Google Analytics receiving data
• Search Console verified for the new site

Once all boxes check, switch DNS to the new WordPress host. Global propagation takes 24–48 hours — some visitors see the old Bolt site during that window. This is normal.

After the switch:

1. Submit the sitemap URL in Search Console
2. URL Inspection → Request Indexing on homepage + top 5 pages
3. Keep the Bolt.new deployment live for 2 weeks as a fallback
4. Monitor Search Console daily for the first week — watch for crawl errors

Common pitfalls (Bolt-specific)

Forgetting about WebContainers state. If your Bolt project did real-time development in-browser, some of what worked locally may not work the same way outside that environment. Test every interactive feature in the exported repo before assuming parity.

Framework mismatch assumptions. Your Bolt project might not be what you expected. If package.json shows Next.js instead of Vite + React, the server-side rendering story on WordPress is different — more of this guide applies as-is, but the backend API route migration from the v0 tutorial is more relevant.

Leaving the <noscript> fallback in place. Some community guides suggest adding <noscript> blocks to Bolt sites as a SEO workaround. If your Bolt project has these, they’re not needed on WordPress — remove them during the rebuild.

Not optimizing images. 4 MB hero images destroy Core Web Vitals. Squoosh or TinyPNG before upload, every time.

Over-installing plugins. Every plugin adds weight. For a Bolt migration, you typically need: your theme, page builder/blocks, Rank Math, Fluent Forms, Site Kit, WP Mail SMTP, WP Rocket (or LiteSpeed Cache), and whatever’s business-specific. Eight to twelve plugins total. More than that starts degrading performance.

Losing your Bolt project too early. Keep it running for 2 weeks post-launch. If anything breaks in the WordPress site, you want the fallback option.

When to hand this off

Conditions where DIY typically doesn’t pencil out:

• You don’t have 3–7 days of focused time available in the next 2 weeks
• You’ve never set up WordPress before
• Your Bolt project has complex Supabase logic you don’t fully understand
• The site has 8+ pages or custom backend features
• You need the migration done fast (under a week)

Bolt.new to WordPress migrations through us start at $299 for single-page sites, $599–$1,299 for multi-page. Every project includes full SEO setup, training video, and 14 days of support. Fixed scope, 7-day delivery. For a preview of what that service looks like day-by-day, see the Bolt.new migration case study walkthrough.

If you DIY and hit a specific problem, the related guides:

• Bolt.new vs WordPress for SEO — context on why the migration matters
• Complete SEO guide for AI-built websites — strategic SEO overview
• WordPress SEO setup guide — tactical Rank Math walkthrough

FAQ

Can I migrate a Bolt.new site without using GitHub export? You can, but it’s harder. Without the exported code, you lose direct access to your Tailwind config and component structure, and you’re working from rendered HTML only. Export is free and takes 30 seconds — there’s no good reason to skip it.

What if my Bolt project uses Supabase heavily? You have three options covered in Step 7. Fastest path: keep Supabase as a backend, have WordPress call its API. Cleanest long-term path: migrate Supabase data into WordPress as custom post types. The right choice depends on what the data is and who edits it.

Will my yoursite.bolt.host URL work after migration? The bolt.host subdomain belongs to Bolt. You can’t take it with you. If traffic was pointing there, set up a redirect from the Bolt deployment (while it’s still live) to your new domain before killing the Bolt project. If you’d been using a custom domain pointed at Bolt, just repoint the DNS — users experience no URL change.

Do Bolt.new sites pass Core Web Vitals? Occasionally, for simple single-page sites. More often, no — the heavy JavaScript bundle fails LCP on mobile. After migration to WordPress with proper caching and CDN, Core Web Vitals typically go from failing to passing, which is itself a direct ranking signal.

How much faster does WordPress rank than Bolt.new for a new site? On a new domain, the rankings timeline is similar — 3–6 months either way, because domain age is the dominant factor. The difference is what you’re waiting for: on WordPress, you’re waiting for ranking accumulation on a site Google can actually crawl. On Bolt, you’re waiting for ranking on a site Google may never fully index. The WordPress wait has a payoff; the Bolt wait often doesn’t.

Can I keep my Bolt.new project as a staging environment after migration? Sure, though it’s usually overkill. WordPress hosts (Kinsta, WP Engine, SiteGround) offer native staging environments that integrate with the production site for push-button deploys. That’s a cleaner workflow than maintaining two different stacks.

The honest bottom line

Migrating from Bolt.new to WordPress isn’t hard — it’s tedious and it takes real time. Nothing in this guide requires deep technical expertise; it requires patience and attention to detail across a multi-day project.

The Bolt-specific wrinkles are: framework variance (check your package.json), common Supabase integration (decide early how to handle it), and the bolt.host deployment limitations (plan your DNS cutover). Everything else is standard WordPress migration work.

If you have the time, DIY works. Follow the steps, don’t skip the SEO setup, test before launching. If you don’t have the time, we do this in 7 days with a fixed quote and the full SEO stack included.

Either way, the goal is the same: a WordPress site that preserves your Bolt.new design and finally gets discovered by Google.