AI app builders — often called vibe-code platforms — like Lovable, Bolt, and v0 let you describe a website and get a working one in minutes. They're remarkable for speed. But for Answer Engine Optimization, they carry a specific risk that catches many people off guard: the default output can be effectively invisible to AI search engines. Here's what's going on and how to fix it.
For the full platform-by-platform comparison, see the best website platform for AEO.
Why vibe-code sites struggle with AEO
The problem is rendering, not content quality. By default, many vibe-code tools generate single-page applications built with frameworks like React. In an SPA, the server sends a minimal HTML shell and the browser runs JavaScript to build the actual page. A human visitor never notices. An AI crawler does — because most AI crawlers fetch the raw HTML and do not run JavaScript.
The result: when ChatGPT, Perplexity, or Claude's crawler requests your page, it can see an almost empty document. Independent testing has repeatedly found vibe-coded sites invisible to AI engines for exactly this reason, and studies note that search engines take far longer to index JavaScript-heavy pages even when they can eventually render them. For AEO — where the whole game is being present in the answer — an unreadable page is a non-starter.
The good news: it's fixable, and improving
This is a solvable problem, and the platforms are moving. Lovable is a clear example: newer apps use a framework with server-side rendering built in, and for older apps it serves prerendered HTML to verified crawlers — including Google, Bing, and AI engines like ChatGPT, Perplexity, Claude, and Gemini. That means a Lovable site built or updated recently may already be far more AEO-ready than the blanket "SPAs are invisible" warning suggests.
But this varies significantly by tool and by when your project was created. Other builders may still default to client-side rendering with no crawler handling. So the rule is simple: don't assume, verify.
How to make a vibe-code site AEO-ready
The path depends on the tool, but the options are consistent:
- Check how your site renders to crawlers first. View the raw HTML a crawler would receive (for example, by fetching the page without JavaScript) and confirm your actual content — headings, body text — is present, not just an empty shell.
- Use server-side rendering if the tool supports it. SSR is the most robust fix because every visitor and crawler gets finished HTML. Some platforms now offer this natively.
- Add a prerendering service if you can't move to SSR. Prerendering detects crawlers and serves them a fully rendered HTML snapshot, while human users still get the app experience.
- Then layer on the usual AEO work: schema markup, clean heading hierarchy, sitemaps, robots.txt that allows AI bots, and llms.txt — none of which help if the content isn't in the HTML in the first place.
Who vibe-code tools fit for AEO
Vibe-code platforms are excellent for speed — prototypes, internal tools, and getting a product in front of users fast. If AI-search visibility matters for the site, treat AEO-readiness as an explicit step in the build, not a default you inherit. For a site whose main job is to be found and cited, you'll either want a tool that renders server-side out of the box or a plan to add SSR or prerendering before launch.
Run the crawler's-eye test on your own site
You do not need a developer, a tool, or a paid audit to find out whether AI engines can read your site. Two minutes, in a browser.
1. Pick the page you most want cited. Not the homepage — the service or product page a buyer would actually land on when researching your category.
2. View the source, not the inspector. Right-click, then View page source (Ctrl+U on Windows, Cmd+Option+U on Mac). This distinction is the whole test. "Inspect Element" shows the page after your browser has executed the JavaScript. View Source shows the raw HTML the server sent — which is all most AI crawlers ever see. Teams check the wrong one constantly and conclude they are fine.
3. Find a sentence from the middle of the page. Copy about ten words of body copy — not the headline — and search for it in the source with Ctrl+F.
4. Search the source for application/ld+json. Each match is one block of structured data telling engines what the page is. Count them.
5. Open yoursite.com/robots.txt. Look for GPTBot, ClaudeBot, PerplexityBot and Google-Extended, and check whether they are allowed or disallowed. Then try yoursite.com/llms.txt — most sites return a 404.
6. One extra step for AI-built sites, and it is the important one. Browser View Source is not always what a crawler receives. Platforms that prerender serve full HTML to verified crawlers while still sending the app shell to your browser — so your source view can look empty while the crawler is fine. To see what a crawler sees, run this in a terminal:
curl -s -A "GPTBot" https://yoursite.com | wc -c
curl -s https://yoursite.com | wc -c
If the first number is much larger than the second, prerendering is working. If both are small — under about 2,000 characters — you are shipping a shell to everyone.
How to read the result
Your content is in the source, or the GPTBot fetch is substantial. You are on a platform that renders server-side or prerenders for crawlers. Recent Lovable builds fall here. Verify rather than assume, which you have now done.
Both fetches return a near-empty shell. This is the failure this article exists for. Your site is invisible to ChatGPT, Perplexity and Claude — not ranking badly, not present at all. Nothing downstream matters until it is fixed: schema, content, keywords and llms.txt are all instructions attached to a document nobody receives.
A shell, on a site that used to work. Check when the project was created. Platform rendering behaviour has changed repeatedly, and an app scaffolded before those changes does not inherit them.
What this test cannot tell you
It will not tell you the fix, and the fix is not one-size. Server-side rendering is the robust answer where the platform supports it. Where it does not, prerendering for crawlers is the honest workaround, and it has to be maintained — bot user-agent lists change, and a prerender layer that silently stops matching them fails without any visible symptom.
We know because this happened to us. brandinglab.io is itself built on Lovable, and it lost AI-search visibility to exactly this problem before we put a Cloudflare Worker in front of it to prerender for crawlers. We found it by running the test above on our own site, which is why it is written the way it is.
If you got a shell, that is not a content problem and no article will solve it. Run our free AEO audit and we will tell you which of the three fixes your build actually needs.