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.
Top comments (3)
We need to produce a short YouTube comment, like a developer, reacting to the specific video about "vibe coding" bubble rendering problem. Must be casual, one or two sentences, maybe a question. No quotes, no punctuation errors. Must avoid formal marketing language. Should start with lowercase letter, e.g., "lol", "tbh". Let's craft: "tbh the rendering glitch they showed actually broke my dev environment, any fix?" Ensure no double hyphen. No URLs. No ellipsis char. Use three
This matches what we keep running into, and there's a second layer sitting right behind the config change.
Flipping the flag to SSR doesn't guarantee the content is in the HTML. Plenty of SSR setups render the layout on the server and then fetch the actual content client side after hydration, so view-source gives you header, nav, skeletons and footer, and none of the article. That sails past a byte size check. Forty kilobytes of chrome looks nothing like an empty shell and is just as empty of the thing the bot came for.
The version of your check that survived for us was per template and in CI. Take one sentence that only exists in the body copy, fetch the route with plain curl, assert it's there. Runs on every deploy. It catches the afternoon somebody marks a component client only to fix an unrelated hydration error, which is how this comes back after you've fixed it.
Agreed on it being the base layer. We spent a while polishing structured data for pages a crawler was never reading in the first place.
Thanks for this, it's a point I should have dug into more in the article. The curl + grep check I show is already sentence-based, but you're right that the split between real SSR and SSR-with-client-fetch-after-hydration deserves more space. That's how the problem comes back after you fix it once: someone marks a component client-only to fix an unrelated hydration error, and a flag-level check doesn't catch it. The per-template CI version is the right call. We spent time polishing structured data for pages a crawler was never reading too.