--- title: "Lovable, Bolt & Claude: Are AI-Built Sites Invisible to AI Search?" description: "AI builders like Lovable, Bolt, v0 and Replit ship a site in an afternoon — but most generate client-side React SPAs that send crawlers a near-empty page. Why 'shipped' isn't 'findable', and how the Claude + VPS path bakes AIO into the prompt instead." canonical: https://aiovsseo.com/articles/ai-built-sites-seo.html date: 2026-06-07 --- # Lovable, Bolt & Claude: are AI-built sites invisible to AI search? TL;DR AI builders (Lovable, Bolt, v0, Replit) ship a polished site in an afternoon — but most generate **client-side React SPAs that hand crawlers a near-empty page**, the single biggest AI-optimization sin. "Shipped" isn't "findable." The fix is either prerendering/SSR on the builder road, or the **Claude + VPS road**: generate server-rendered static HTML and *encode the SEO/AIO rules into your prompt or skill*. This site was built exactly that way. Building a website used to take a team and weeks. Now you describe it to Lovable, Bolt, v0 or Replit and watch a polished product appear in an afternoon — or you hand Claude a brief and it writes the whole thing. The barrier to *shipping* a site has collapsed. But shipping was never the goal. Being *found* was. And here a quiet problem hides inside the magic: the default output of the easiest tools is often invisible to the exact systems — Google and the AI answer engines — you built the site to reach. ## The two roads of AI site-building There are broadly two ways people build with AI today, and they have opposite default behaviors for visibility. ### Road A — the visual builders Lovable, Bolt, Replit and v0 are extraordinary at turning a prompt into a working app. But most generate **client-side-rendered React single-page apps**. That means the server sends an almost empty HTML file, and JavaScript injects the text, headings and content *after* the page loads. A human with a browser sees a beautiful site. A crawler or an AI retriever that reads the raw HTML sees… almost nothing. ### Road B — Claude (or an agent) + your own stack Drive Claude or Claude Code against your own hosting and you control the output format. You can generate **server-rendered static HTML** — plain HTML, or a static framework like Astro — where every word is in the response the server returns. It's less push-button, but the result is natively crawlable. *This site runs that way: built with Claude on a small VPS, deliberately static and server-rendered, no client framework.* ## Why the default road hurts you We've said it across this site and it's the through-line here: **to be ranked or cited, your content must exist in the server-rendered HTML.** It's the first requirement in [GEO](/articles/what-is-geo.html), the structural advantage of [WordPress](/articles/wordpress-ai-optimization.html), and the thing a client-side SPA gets wrong by default. The result is the modern tragedy of the vibe-coded site: a gorgeous, fast-feeling product that Google indexes as a blank page and ChatGPT can't quote because, to them, there's nothing on it. You optimized the experience for the one audience — humans with JavaScript — and accidentally hid it from the two that decide your reach. > An AI can build you a beautiful site in an hour and make it invisible to AI search in the same hour. The tool's default is not your strategy. ## Fixing the builder road If you love the visual builders, you can keep them and close the gap: - **Prerender.** Generate static HTML snapshots of each page and serve those to crawlers — the most common retrofit for Lovable/Bolt SPAs. - **Use an SSR framework.** v0 outputs Next.js, which supports server-side rendering out of the box; migrating a Lovable project to Next.js is a known path. - **Prompt for plain output.** Bolt and Replit will generate vanilla HTML/CSS/JS if you ask explicitly — e.g. *"build this using pure HTML, CSS and vanilla JavaScript, no frameworks."* - **Verify with view-source.** Open the page, view source (not the DOM inspector), and confirm your headings and body text are actually there. If you see an empty shell and a script bundle, you have the problem. ## The Claude + VPS road: the prompt is the optimization layer The deeper shift is this: when an AI writes your site, **SEO becomes partly a prompting discipline.** The fundamentals don't change — you're just instructing a machine to honor them by default. The leverage is in encoding them once into your prompt or a reusable skill, so every page ships correct: 1. **Server-render everything.** Static HTML or SSR — content in the initial response, always. 2. **Lead with the answer; question-shaped H2s.** Bake the content shape into the instructions, not just the styling. 3. **Inline JSON-LD, server-side.** Article/FAQ/Breadcrumb in the HTML — for rich results, knowing it won't drive citations (see [metadata LLMs read](/articles/metadata-llms-read.html)). 4. **Ship the plumbing automatically.** `sitemap.xml`, `robots.txt` with a [Content-Signal](/glossary/content-signal.html) line, visible publish/update dates, internal links. 5. **Ping on publish.** Fire an [IndexNow](/articles/indexnow-for-ai-engines.html) submission so Bing sees new pages instantly. 6. **Scale with agent routines.** Claude's agent-teams and routines can generate programmatic SEO pages (glossaries, comparisons) on one template at volume — the same approach behind this site's glossary. Done once, that prompt or skill turns "the AI built a site" into "the AI built a site that's crawlable, citable, and indexed on day one." The generation was never the hard part; the discipline encoded into it is. ## The takeaway AI site-building is genuinely transformative — it's how this very site exists. But it relocates the SEO problem rather than removing it. The risk isn't that AI writes bad code; it's that the convenient defaults (client-side SPAs, no schema, no sitemap, no instant indexing) quietly decide your visibility for you — the same "who holds the dial" trap we flagged in [governing crawler access](/articles/governing-crawler-access.html). Keep your hand on the dial: tell the AI to build for the machines that decide your reach, and verify that it did. ## Frequently asked questions **Are Lovable and Bolt websites good for SEO?** By default, often not. They typically generate client-side-rendered React SPAs that send crawlers and AI retrievers a near-empty HTML page. Since being in the server-rendered HTML is the biggest requirement for being indexed and cited, the default output is a trap — fixable with prerendering, SSR, or prompting for plain HTML. **Can I build an SEO-friendly site with Claude?** Yes. With Claude (or Claude Code) plus your own hosting you can generate server-rendered static HTML that's natively crawlable — the approach this site uses. The leverage is encoding SEO/AIO requirements into the prompt or a reusable skill: server-render, inline JSON-LD, visible dates, sitemap, robots with Content-Signal, internal links, and an instant-index ping on publish. **How do I check if my AI-built site is visible to crawlers?** Use 'view source' (not the live DOM inspector). If your headings and body text are in the raw HTML, crawlers and AI retrievers can read them. If you see a near-empty shell with a script bundle and no content, your site is client-side rendered and likely invisible until you add prerendering or SSR.