Bolt.new, StackBlitz’s in-browser AI app builder, can take you from idea to deployed app in minutes. What it cannot do automatically is make that app rank. The default Bolt output is a Vite + React single-page application: the initial HTML is nearly empty, content loads after JavaScript runs, and most crawlers never see any of it. Bolt SEO starts with understanding that gap, then closing it before you launch.
This guide covers how to confirm what Bolt generated, which rendering fix to choose, how to add real per-page metadata, and how to build the supporting signals (sitemap, robots.txt, canonical, schema) that separate a prototype from an indexable production site.
Why Bolt apps don’t rank by default
Bolt generates client-side rendered (CSR) React applications unless you explicitly ask for something different. On a CSR site, the server sends a near-empty HTML shell and the browser does all the rendering work after JavaScript executes. Googlebot does queue JavaScript rendering, but it does so in a second wave that can lag by days or weeks. Many other crawlers, especially the AI crawlers used by Perplexity, ChatGPT, and similar tools, skip JavaScript execution entirely and only read the raw HTML they receive. If that HTML is empty, they have nothing to index and nothing to cite.
This is not a Bolt-specific bug. It’s the default behaviour of React SPAs, and it applies equally to apps built with Vite’s vanilla scaffolding, Create React App, or any other CSR setup. The single-page application SEO guide covers the mechanics in full. The short version: if your <body> contains only a <div id="root"></div> when JavaScript is disabled, you have a rendering problem.
Step 1: Confirm what Bolt actually generated
Before fixing anything, check what you’re working with. Export your Bolt project and inspect the generated files.
Open index.html. If the body looks like this, you have a pure CSR app:
<body>
<div id="root"></div>
<script type="module" src="/src/main.tsx"></script>
</body>Also check package.json for the framework. Most Bolt outputs use Vite with React. Some prompts produce Next.js (which has SSR built in) or Astro (which defaults to static output). If you see "next" or "astro" in your dependencies, your rendering situation is already much better, and you can skip to the metadata section. If you see "vite" alongside "react" but no "next" or "@remix-run", you have a CSR app that needs attention.
Step 2: Choose your rendering fix
There are three paths. Which one suits you depends on how much you want to stay inside Bolt versus exporting and working locally.
Option A: Re-prompt Bolt to scaffold a different framework
The simplest fix is to start with a better foundation. Before Bolt generates your app, include in your prompt: “Use Next.js with the App Router and server components” or “Use Astro with static output.” Both produce HTML that is fully rendered before it reaches the browser.
This only works at the start of a project. You can’t easily convert an existing Bolt Vite + React project to Next.js inside Bolt without essentially rebuilding it.
Option B: Add prerendering with vite-plugin-ssr or a static pre-renderer
If you want to keep your existing Bolt project, add a prerendering step. Export the code, then install a tool like vite-plugin-ssg or react-snap that crawls your app locally and writes out static HTML files for each route.
npm install vite-plugin-ssg --save-devIn vite.config.ts, replace the standard React plugin entry point with the SSG variant. After your build runs, each route gets its own index.html with real content baked in. This is the same technique described in the React SEO guide.
Option C: Export and migrate to Next.js or Astro
For anything you intend to maintain and grow, export the Bolt project and migrate it to Next.js or Astro locally. This is the honest answer for production use. Bolt is excellent for prototyping and for getting a UI structure in place quickly. The deployment target for a site you want indexed is a proper framework with SSR or SSG, deployed to a host that supports it (Vercel, Netlify, Cloudflare Pages).
The platform SEO overview covers the trade-offs across frameworks in more detail.
Step 3: Add real per-page metadata
Once rendering is solved, every page needs a unique <title> and <meta name="description">. In a CSR React app these are often missing entirely, or every page shares the same placeholder title from index.html.
If you chose Next.js, use the Metadata API in your layout and page files:
// app/page.tsx (Next.js App Router)
import type { Metadata } from 'next'
export const metadata: Metadata = {
title: 'Your Page Title',
description: 'A clear, unique description under 160 characters.',
}If you are staying with Vite + React and adding client-side rendering, install react-helmet-async and wrap each page component:
import { Helmet } from 'react-helmet-async'
export function HomePage() {
return (
<>
<Helmet>
<title>Your Page Title</title>
<meta name="description" content="A clear, unique description." />
<link rel="canonical" href="https://yoursite.com/" />
</Helmet>
{/* page content */}
</>
)
}Note that react-helmet-async only sets tags client-side. For crawler visibility you still need prerendering or SSR to serve those tags in the initial HTML response.
Every page needs a distinct title (not “My App” on every route), a description under 160 characters, and a canonical tag pointing to the preferred URL for that page.
Step 4: Add a sitemap and robots.txt
Sitemaps tell crawlers which URLs exist and when they were last updated. Without one, crawlers have to discover pages by following links, which means deep pages often go unindexed.
For a static site or Next.js project, generate a sitemap.xml at build time. A minimal example:
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://yoursite.com/</loc>
<lastmod>2026-05-23</lastmod>
</url>
<url>
<loc>https://yoursite.com/about/</loc>
<lastmod>2026-05-23</lastmod>
</url>
</urlset>Place it at /sitemap.xml and declare it in robots.txt:
User-agent: *
Allow: /
Sitemap: https://yoursite.com/sitemap.xmlYour robots.txt should explicitly allow all crawlers unless you have specific sections you want excluded. Blocking JS or CSS files here is a common mistake that breaks rendering for crawlers.
Step 5: Add schema markup
Schema tells search engines (and AI tools) what kind of entity your page represents. At minimum, a business or SaaS site should have WebSite schema on the homepage and WebPage or Article schema on content pages. More specific types (like Product, FAQPage, or SoftwareApplication) are worth adding where they match your content.
{
"@context": "https://schema.org",
"@type": "WebSite",
"name": "Your App Name",
"url": "https://yoursite.com"
}Place this in a <script type="application/ld+json"> tag in your <head>. In Next.js you can add it to the root layout. In Astro it goes in your base layout’s head slot.
Schema that matches your content increases the chance your site is surfaced accurately in AI answers. The schema markup for AI SEO guide goes deeper on which types matter most.
Bolt for prototyping vs. Bolt for production
This distinction is worth being direct about. Bolt is a remarkable prototyping tool. It excels at rapidly generating a working, visually coherent app you can show stakeholders, test ideas with, or use as a development starting point.
It is not designed as a production SEO stack. The in-browser environment means some framework choices aren’t practical to configure fully inside Bolt’s interface. Configuration files, server-side routing, dynamic sitemap generation, and fine-grained build tooling are all easier to manage once you’ve exported the project and are working in a local environment with a proper deployment pipeline.
The honest workflow for most Bolt projects is: prototype in Bolt, export and refine locally, deploy via a framework that supports SSR or SSG. That is not a knock on Bolt. It is the right tool for the right job. Trying to run a complex SEO-optimised production site entirely within the Bolt interface adds friction in the wrong places.
Compare this with Lovable, which handles some publishing concerns more directly, though the rendering defaults are similar.
How Bolt SEO affects AI citations
AI tools like ChatGPT, Perplexity, and Google AI Overviews pull from indexed web pages. If your Bolt app is client-rendered and never properly indexed, it will not be cited in AI answers, no matter how good the content is.
The AI crawlers used to build these systems are generally less capable of rendering JavaScript than Googlebot. Many operate on a simple HTTP fetch with no JavaScript execution. If your page serves an empty shell to a plain HTTP request, AI systems see nothing and cite nothing.
Getting indexed correctly is the baseline. From there, well-structured content with appropriate schema, clear entity definitions, and authoritative internal linking are what drive citation rates. Tools like Fokal track citation rates across AI engines on a schedule, so you can see whether changes to your rendering, content, or schema are actually moving the needle rather than guessing. The AI visibility guide covers what the indexing-to-citation path actually looks like.
What to do next
If you have an existing Bolt project you want to rank, the priority order is: (1) confirm the rendering situation, (2) choose your fix and implement it, (3) add per-page titles and descriptions, (4) generate a sitemap and robots.txt, (5) add schema on key pages. Steps 3 through 5 are quick wins even before the rendering fix is in place, because they’re ready to go the moment you do fix rendering.
Checklist:
- Export the Bolt project and check
index.htmlandpackage.json - Identify whether you have a CSR SPA (Vite + React), Next.js, or Astro
- Choose a rendering fix: re-prompt for SSR/SSG, add a prerender plugin, or migrate
- Add unique
<title>,<meta name="description">, and<link rel="canonical">to every page - Generate a
sitemap.xmlcovering all public routes - Add a
robots.txtthat declares the sitemap and allows all crawlers - Add
WebSiteschema to the homepage; add page-appropriate schema elsewhere - Deploy to a host that supports your chosen rendering approach (Vercel, Netlify, Cloudflare Pages)
- Submit the sitemap in Google Search Console and verify indexing