The Rendering Blind Spot of Vibe Coding: AI Search Can't See Your App

Vibe coding has become the mainstream way to build for the web in 2026. Type in a prompt, get a working app in 30 seconds, deploy it straight to production. Tools like Lovable, Bolt, and v0 make it possible to complete prototypes and ship them without writing a single line of code.

These apps look fine in the browser, and they work. But to AI search engines, they're invisible.

The Root of the Problem: Client-Side Rendering by Default

Every link in the vibe coding toolchain produces client-rendered SPAs by default. The server returns an HTML shell containing nothing but a <div id="root"></div> and a <script> tag. The browser downloads the script, executes it, and renders the content. In a browser, that's fine. For bots, it's not.

GPTBot, ClaudeBot, PerplexityBot, and Googlebot don't execute JavaScript the way browsers do. They fetch the HTML, parse it, and stop. If the content isn't in the HTML, then for the retrieval pipeline, it doesn't exist.

This isn't a new problem. Ever since React popularized client-side rendering, SPAs have been plagued by this rendering issue. What's new is the scale: in 2026, tens of thousands of sites are generated by vibe coding tools, each one carrying the same default configuration—an empty HTML shell, JavaScript-rendered content, and invisibility to crawlers.

SPA (Single-Page Application) is a web app architecture where the server returns only a minimal HTML shell on first load, and all subsequent page transitions and content rendering are handled by JavaScript in the browser. It makes the interaction feel close to a native app, but for crawlers that don't execute JS, all they ever get is the same empty shell.

CSR / SSR / SSG are three rendering timings. CSR (client-side rendering) generates content by running JS in the browser; SSR (server-side rendering) generates full HTML on the server on each request; SSG (static site generation) produces HTML files at build time. The three may look nearly identical to users, but only the latter two let crawlers read the content directly on the first request.

GPTBot, ClaudeBot, PerplexityBot are the crawlers for OpenAI, Anthropic, and Perplexity, respectively, used to supply web content for AI search and question answering. They behave like early Googlebot: request the HTML, parse the text, don't run page scripts. So whether content appears in the initial HTML directly determines whether it can enter AI's retrieval pipeline.

How to Check: Two Lines of Commands

You don't have to wait until your analytics dashboard shows zero organic traffic to realize there's a problem. A quick curl check tells you:

curl -s https://your-vibe-coded-site.com | wc -c

If the response is only a few hundred bytes, you've got the shell. If it reaches several thousand bytes or more, the content is in the HTML.

To verify further, check the page source (not the rendered DOM):

curl -s https://your-vibe-coded-site.com | grep -i "your main content text"

If grep returns nothing, your content is JavaScript-rendered, and no AI search engine can read it.

llms.txt Won't Save You

For the past few months, discussion in the GEO community has been almost entirely dominated by llms.txt. Google advises ignoring it, Chrome Lighthouse^Ad audits it, and four independent studies show it has no effect on AI citations.

But even if llms.txt worked perfectly, it wouldn't solve the rendering problem. The llms.txt file links to your pages, and when AI bots follow those links and fetch the HTML, if the HTML is empty, the bot has read the file and visited the page but found nothing. The file is just a map to an empty room.

Research from Ahrefs confirms this pattern: AI bots crawl HTML pages, not auxiliary files. Limy's research tracked 515 million bot events and found that the vast majority of bot requests are directly for HTML. The retrieval step that decides what to cite reads your HTML. If there's no content in the HTML, you're invisible.

llms.txt is a proposed plain-text file placed at the root of a website, listing the site's important pages and brief descriptions in Markdown format so that large language models can quickly understand the site structure. It's positioned similarly to robots.txt or sitemap, but aimed at AI understanding and citation rather than crawl permissions. The controversy: major AI companies haven't committed to reading it, Google explicitly says not to rely on it, and multiple independent tests have observed no measurable impact on citation rates.

GEO (Generative Engine Optimization) refers to optimization practices for AI search and generative answers, with the goal of making content easier for large models to retrieve, cite, and summarize. It shares an underlying premise with traditional SEO—content must be crawlable and parseable—but adds requirements around content structure, citable passages, and entity clarity. The rendering problem is a precondition for GEO, not a GEO strategy itself.

Three Fix Paths

The fix isn't specifically about AI; it's the same set of old solutions that have existed since SPAs became popular:

Option one: Static generation. Generate full HTML at build time. Astro, Next.js configured with output: export, and Gatsby do this by default. Every page is a complete HTML file, and bots get all the content on the first request.

Option two: Server-side rendering. Render HTML on the server on each request. Next.js App Router, Nuxt, and SvelteKit all support this. The server sends full HTML, and bots can read it.

Option three: Prerendering. Generate static snapshots of pages and serve them to bots. This is a workaround that adds complexity, and if the prerendered content differs from what users see, it may be judged as cloaking. Avoid it unless there's no other choice.

The boundary between prerendering and cloaking: Prerendering is generating a static HTML snapshot at build or request time, served specifically to crawlers, while real users still use the SPA. Search engines define "showing different content to crawlers and users" as cloaking, which violates webmaster guidelines and can lead to ranking penalties. The risk lies in the snapshot not matching what users actually see—for example, the snapshot contains full product information while the user side only shows it after login or interaction. If the prerendered content is completely identical to the user's above-the-fold content, it's usually not considered cloaking, but the judgment is up to search engines, which is why this article recommends prioritizing SSG or SSR.

Next.js's output: export: This is Next.js's static export mode, which pre-generates an HTML file for each route at build time and can be deployed to any static host. It contrasts with App Router's SSR mode: the former generates HTML at build time, the latter at request time. Both let crawlers get full content; the choice depends on whether the page needs dynamic data.

Tool Defaults Are the Key

Tools that generate SPAs should default to static generation or SSR. Currently they default to CSR because that's the shortest path to a working prototype: the user types a prompt, the tool generates a React app, and the app runs in the browser. As for it being invisible to crawlers, the user won't notice until they look at analytics and wonder why organic traffic is zero.

Some tools have started to address this. Lovable added an SSR option, and Bolt supports deploying to platforms that handle prerendering. But the defaults still lean toward CSR, and most users won't change the defaults.

Rendering Is the Foundation of AI Visibility

The rendering problem is the lowest layer of AI search visibility. If your content isn't in the HTML, nothing else matters—llms.txt, Schema, content structure, citable passages, all of it is moot. Bots have to be able to read your page first before higher-level signals mean anything.

In the audit tool geo-optimizer-skill, which I maintain, the rendering check is the first test signal: fetch the page both with and without a headless browser and compare the results. If the content differs significantly, it's flagged as JS-dependent. This is the most common failure mode, and the one with the clearest fix path.

If you're using vibe coding, check the HTML output first. If it's empty, switch to SSG or SSR. The interface users see stays the same, but every search engine and AI crawler that matters can see you. This isn't a GEO strategy; it's just a configuration change.

One-line Summary

Vibe coding tools output client-rendered SPAs by default, so AI crawlers can't read the content—switch to SSG or SSR.

Paragraph Summary

The article points out that the mainstream vibe coding tools of 2026 (Lovable, Bolt, v0, etc.) generate client-rendered SPAs by default: the server returns only an empty HTML shell, and content is rendered by JavaScript in the browser. GPTBot, ClaudeBot, PerplexityBot, and Googlebot don't execute JavaScript, so these sites are completely invisible to AI search. The author provides two lines of self-check commands using curl with wc -c or grep, and clarifies that llms.txt can't fix this—bots following links still hit empty HTML, as confirmed by research from Ahrefs and Limy showing that bots request HTML directly. There are three fix paths: static generation, server-side rendering, and prerendering (which carries cloaking risk and should be avoided). The root cause is that tool defaults lean toward CSR; rendering is the foundation of AI visibility.