Vibe coding is the dominant trend in web development in 2026. You type a prompt, get a working app in 30 seconds, and ship it. Lovable, Bolt, v0, and similar tools have made it possible to prototype and deploy a web application without writing a line of code.

The apps look good. They work in a browser. They are invisible to AI search engines.

The problem

Every tool in the vibe coding stack produces a client-side rendered SPA by default. The server returns an HTML shell with a <div id="root"></div> and a <script> tag. The browser downloads the script, executes it, and renders the content. In a browser, this works. For a bot, it does not.

GPTBot, ClaudeBot, PerplexityBot, and Googlebot do not execute JavaScript the way a browser does. They fetch the HTML, parse it, and move on. If the content is not in the HTML, it does not exist for the retrieval pipeline.

This is not a new problem. It is the same rendering problem that has plagued SPAs since React popularized client-side rendering. What is new is the scale. In 2026, tens of thousands of sites are being generated by vibe coding tools, and every one of them ships with the same default: empty HTML shell, JavaScript-rendered content, invisible to crawlers.

How to check 

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

If the response is a few hundred bytes, you are getting the shell. If it is several kilobytes or more, the content is in the HTML.

You can also check what a bot sees by looking at the page source, not the rendered DOM:

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

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

Why llms.txt does not fix this

The llms.txt debate has consumed the GEO conversation for months. Google says to ignore it. Chrome Lighthouse audits for it. Four independent studies say it has no effect on AI citations (see the first article in this series for the full data).

But even if llms.txt worked perfectly, it would not fix the rendering problem. An llms.txt file links to your pages. When an AI bot follows those links, it fetches your HTML. If your HTML is empty, the bot reads the file, visits the pages, and finds nothing. The file is a map to empty rooms.

The Ahrefs study confirmed this pattern: AI bots fetch HTML pages, not auxiliary files. The Limy study tracked 515 million bot events and found that bots overwhelmingly request HTML directly. The retrieval step that decides what to cite reads your HTML. If your HTML has no content, you are invisible.

The fix

The fix is not AI-specific. It is the same fix that has existed since SPAs became popular:

Option 1: Static generation. Generate complete HTML at build time. Astro, Next.js with output: export, Gatsby, and Elevento do this by default. Every page is a full HTML file. Bots get everything on the first request.

Option 2: Server-side rendering. Render HTML on the server for each request. Next.js with App Router, Nuxt, and SvelteKit support this. The server sends complete HTML. Bots can read it.

Option 3: Prerendering. Generate static snapshots of your pages and serve them to bots. This is a workaround that adds complexity and can be flagged as cloaking if the prerendered content differs from what users see. Avoid it unless you have no other option.

What the vibe coding tools should do

The tools that generate SPAs should default to static generation or SSR. Right now, they default to CSR because it is the simplest path to a working prototype. The user types a prompt, the tool generates a React app, and the app works in the browser. The fact that it is invisible to crawlers is not visible to the user until they check their analytics and wonder why they have zero organic traffic.

Some tools are starting to address this. Lovable has added an SSR option. Bolt supports deployment to platforms that handle prerendering. But the defaults still favor CSR, and most users do not change defaults.

The broader implication

The rendering problem is the base layer of AI search visibility. If your content is not in your HTML, nothing else matters. Not llms.txt, not Schema, not content structure, not citation-worthy passages. The bot has to be able to read your page before any of the higher-level signals can work.

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

If you are vibe coding, check your HTML output. If it is empty, switch to SSG or SSR. Your app will look the same to users and become visible to every search engine and AI crawler that matters. The fix is one configuration change, not a GEO strategy.