Why Your Bolt.new Site Is Invisible to Google

The confusing part is that the site clearly works. You open it, the pages load, the links click. So it feels like Google should just find it. But “a person with a browser can use it” and “a crawler can read it” are two different tests, and a default Bolt build passes the first while quietly failing the second. To fix it you need to know which of two Bolt-specific things is wrong: you are checking the wrong URL, or your content only exists after JavaScript runs.

First: are you even looking at the real site?

Bolt runs your app inside StackBlitz WebContainers — a Node runtime running in the browser itself (BOLT-001). The preview you edit against is that in-browser development environment, not your published site. The indexable site is the deployed output — on a bolt.host subdomain, on Netlify, or on a connected custom domain (BOLT-013). New projects default to built-in Bolt Cloud hosting, which publishes to bolt.host with no third-party account (BOLT-004); Netlify is an alternative, but only if you choose it before the first publish (BOLT-005).

So the first thing to confirm is boring but decisive: the URL you are testing is the deployed one, not the WebContainer preview. Everything below assumes you are checking the published address.

The empty shell, specifically on Bolt

Bolt is framework-agnostic — if it runs on StackBlitz, it runs on Bolt, including React, Vue, Svelte, Astro, Next.js, Nuxt, and Remix (BOLT-002). That freedom is also the trap: for a plain “build me a website” prompt it commonly reaches for Vite + React (BOLT-003), and a default Vite/React app is client-rendered. The server sends a root element and a script bundle; the title, meta tags, and body content only appear after the browser executes JavaScript (BOLT-008).

A visitor never notices the half-second of assembly. A crawler that does not execute JavaScript — or executes it late and incompletely — can receive the empty shell and move on, which is why a default Bolt site risks being invisible unless server rendering, static generation, or prerendering is added (BOLT-009). Even for crawlers that do render, you are betting your indexation on a step that a server-rendered page never has to take.

There is a second, quieter failure that looks identical from the outside. A single-page app deployed to static hosting needs a fallback rule so that deep links serve the app instead of a 404 — on Netlify that is a _redirects line (BOLT-010):

# _redirects — without this, every URL except "/" can 404
/*    /index.html   200

# A 404 at the URL a crawler tries is indistinguishable, to that
# crawler, from a page that does not exist. It won't be indexed.

How to make a Bolt site crawlable

Because Bolt hosts whatever you build, the fix lives in the app, and there are two honest paths.

1. Generate on a framework that ships crawlable HTML. Whether a Bolt site returns crawlable HTML is determined by the framework chosen at generation time — an SSR/SSG framework such as Next.js, Astro, or SvelteKit rather than the default Vite SPA (BOLT-011). Bolt supports all of them (BOLT-002), so this is a prompt-and-scaffold decision, ideally made before you build rather than retrofitted after.
2. Or add rendering to the SPA you already have. If you are committed to the Vite app, the content has to reach the crawler some other way — server-side rendering, static pre-generation of your key routes, or a prerendering step — plus the SPA fallback rule so deep links resolve (BOLT-010). This is more work than starting on an SSR framework, which is exactly why the framework choice matters up front.

Either way, the meta tags, sitemap.xml, and robots.txt are still yours to write — Bolt will not add them for you (BOLT-012). And if you want the project out of Bolt entirely, you can export it as a .zip or two-way sync it to a GitHub repo and take the code with you (BOLT-007).

That is exactly the check our free visibility scan runs — it reads your public page the way a search engine does and reports what is and isn’t in the HTML, with no score and no email gate. For the full breakdown of Bolt’s preview-versus-production split and the framework decision, see SEO for Bolt sites. When the fix belongs in the code — server rendering, a sitemap, real metadata — that is what Search Foundation is for.