Platform · Bolt

Bolt builds in one place and publishes to another — and its SEO depends entirely on what you prompted.

Bolt runs your app inside an in-browser WebContainer while you build, then deploys the real site to Bolt Cloud, Netlify, or your own domain. Those are two different runtimes, and only the second one gets crawled. Bolt is also framework-agnostic with no SEO layer of its own — so whether search engines see real HTML or an empty shell comes down to the framework Bolt generated for you.

Bolt is built for speed of iteration, and it’s excellent at it. But “it works in the preview” and “a crawler can read the published site” are two separate facts on Bolt — and the gap between them is where visibility is lost.

Scan your Bolt site

Bolt’s strengths

Full-stack apps generated and run entirely in the browser — no local setup.
Framework-agnostic: React, Astro, Next.js, SvelteKit and more.
One-click publish to Bolt Cloud, or deploy to Netlify and GitHub.

Fast to ship — which is exactly why the SEO layer is so easy to leave on the default.

What decides whether Bolt sites get found

Bolt ships the app — the SEO comes from the code and the host

Because Bolt adds no SEO layer of its own, these are the factors that actually determine whether your published site is visible.

The framework Bolt generated

For a typical website prompt Bolt commonly scaffolds a Vite project, which defaults to a client-rendered SPA (BOLT-003). A crawlable site needs an SSR/SSG framework — Next.js, Astro, SvelteKit — chosen at generation time (BOLT-011).

Needs attention

Whether content is in the initial HTML

A default Vite/React SPA ships a near-empty shell — a root div plus a JS bundle — with title, meta, and body rendered only after JavaScript runs (BOLT-008). Bots that don't execute JS can see nothing (BOLT-009).

Needs attention

Meta, sitemap, robots, structured data

None of these are provided by the platform — they come entirely from the generated code (BOLT-012). On a fresh Bolt project they typically don't exist until you prompt for them.

Not detected

Where it's hosted

Publishing deploys to a bolt.host subdomain by default; Netlify is an alternate host if selected before first publish, and export to GitHub or .zip is supported (BOLT-004 · BOLT-005 · BOLT-007). Domains and redirects come from the chosen host.

Passed

The trap unique to Bolt

The URL you build against in Bolt is a WebContainer — a development environment running inside your browser tab, not your published site. The site search engines actually crawl is the deployed output on bolt.host, Netlify, or your custom domain. It is entirely possible for the preview to look perfect while the published build serves an empty shell, or for you to test SEO against the wrong URL and draw the wrong conclusion. On Bolt, the first rule is to always verify the production deployment, never the preview.

The Bolt-specific checklist

What to verify on a Bolt build

Run these against the published production URL — not the WebContainer preview.

Test the production URL, not the preview BOLT-013: Confirm crawlers are hitting your bolt.host, Netlify, or custom domain — the deployed site — and not the in-browser WebContainer preview URL, which isn't your real site.
curl the raw HTML for real content BOLT-008: Fetch the production page and check the response contains a real title, meta description, and body copy. If it's an empty root div, the project was scaffolded as a default Vite SPA.
If it's a shell, change the rendering model BOLT-011: An empty-shell result means you need an SSR/SSG framework or a prerender step before the site is SEO-viable — not just more meta tags on a client-rendered app.
Add a SPA fallback if you stay client-rendered BOLT-010: A single-page app on static hosting needs a fallback rule (e.g. Netlify _redirects /* /index.html 200) or deep links 404 — which crawlers treat as missing pages.
Add meta, sitemap, and robots explicitly BOLT-012: Because Bolt provides none of these, prompt for and verify per-page metadata, a sitemap, and a robots file in the generated code — they won't appear on their own.

Sources logged in RESEARCH_LOG.md (BOLT-*). Whether a Next.js app on Bolt Cloud runs true server rendering versus a static export is undocumented, so we verify it per project rather than assume it.

How a Bolt site's visibility is decided

Four choices, made mostly before you notice them

Bolt's speed hides these decisions inside a single prompt-and-publish flow. We make them explicit and fix the ones that block search.

Prompt
What you asked for implicitly picks a framework.
Framework
Vite SPA (default) vs an SSR/SSG framework decides rendering.
Render
Real HTML for crawlers, or a shell that needs JavaScript.
Deploy
bolt.host, Netlify, or custom domain — where headers and redirects live.
Verify
Fetch the production URL as a crawler and confirm what it receives.

We don't move you off Bolt — we make sure the framework, rendering, and deploy choices it made for you actually add up to a site search engines can read.

Where to go next

Start here

Check your published Bolt site, not the preview

Run the free scan on your production bolt.host, Netlify, or custom domain — no score, no email. It reads the deployed page the way a crawler does, so you find an empty-shell problem before Google does.

Run a free visibility scan

This is a narrow technical scan of the public page response. It does not measure rankings, content quality, backlinks, Google index coverage, or business opportunity.

Platform information last reviewed 17 July 2026. Platform capabilities change; every claim on this page is recorded, with its source and review date, in our internal research log and re-verified on a review cycle. Where behavior varies by configuration, we’ve worded it as a condition rather than a fixed fact.