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, the structural advantage of WordPress, 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:
- Server-render everything. Static HTML or SSR — content in the initial response, always.
- Lead with the answer; question-shaped H2s. Bake the content shape into the instructions, not just the styling.
- Inline JSON-LD, server-side. Article/FAQ/Breadcrumb in the HTML — for rich results, knowing it won't drive citations (see metadata LLMs read).
- Ship the plumbing automatically.
sitemap.xml,robots.txtwith a Content-Signal line, visible publish/update dates, internal links. - Ping on publish. Fire an IndexNow submission so Bing sees new pages instantly.
- 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. 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.