The root cause: client-side rendering
Every major vibe-coding platform defaults to building React single-page applications (SPAs) with client-side rendering. This is what that means in practice.
When a search engine crawler visits your site, it receives the HTML that the server sends. With client-side rendering, the server sends a minimal HTML file. The content lives in JavaScript files that run in the browser after the page loads. The crawler receives the HTML and moves on. It never waits for the JavaScript to execute.
What the crawler sees:
<!DOCTYPE html>
<html>
<head>
<title>My App</title>
</head>
<body>
<div id="root"></div>
<script type="module" src="/assets/index.js"></script>
</body>
</html>
Your content, your product descriptions, your headings, your links. None of it is in that HTML. The crawler sees an empty page.
What the platforms say about it themselves
This is not a characterisation. The platforms document it directly.
"the browser loads a small initial HTML shell and then handles routing and rendering with JavaScript"
"Indexing can take a bit longer (days instead of hours)"
"Many AI systems don't reliably see dynamically rendered content, so they may miss your pages or only see partial content"
"The Agent may add elements like titles, descriptions, or tags based on your prompts, but this isn't systematic and doesn't guarantee full or correct implementation."
Source: Lovable documentation, "Implement SEO and GEO best practices", docs.lovable.dev/tips-tricks/seo-geo
"Base44 apps are client-side rendered (CSR) by default, so most AI crawlers do not execute your app's JavaScript or see the full content directly."
"Base44 does not set a custom meta description tag for each page."
"Base44 does not inject schema types such as FAQPage, Article, Product, LocalBusiness, or Organization by default."
Source: Base44 documentation, "SEO and search visibility", docs.base44.com
The 199-upvote feature request on Base44's feedback board, titled "Essential SEO Improvements for Base44 Web Apps", is one of the most requested features in the platform's history. It has remained unresolved since June 2025.
What experts who have examined these platforms say
"No SSR. No SSG. No ISR. Pure CSR."
Elimelech's analysis confirmed that GPTBot (OpenAI), ClaudeBot (Anthropic), Common Crawl, and PerplexityBot all receive only the initial HTML shell when visiting Lovable sites. Social media platforms including Facebook, LinkedIn, Twitter, Slack, Discord, and WhatsApp also see nothing — which means link previews do not work either.
"Vibe coders: Lovable has a big SEO problem by default it renders on the client side, which means google cannot see that content and you will struggle to get indexed or rank for any keywords worth considering if you care about search engines (or LLMs) being able to view content!"
Google's own Search Advocate, John Mueller, reviewed a vibe-coded site posted publicly to a developer community in October 2025 and documented the following issues: key homepage content stored in a JavaScript file making it unavailable to crawlers, hidden H1 and H2 headings, JSON-LD structured data using unsupported types, and redundant directives throughout the code. Mueller's assessment: "your homepage should have everything that people and bots need to understand what your site is about." (Source: Search Engine Journal, October 15, 2025.)
How each platform compares for SEO architecture
Research by Onely, cited by Jan-Willem Bobbink in a February 2026 technical analysis on DEV Community, found that Google takes approximately 9 times longer to index JavaScript-heavy pages compared to static HTML, and that sites exceeding rendering budgets experience up to 40% lower indexation rates.
The structural problem beyond SEO
The SEO problem is the most visible symptom of a deeper structural issue. Vibe-coded apps are produced one session at a time, with no shared architecture between them. Each session produces what the AI decided. There is no schema you can build on, no predictable data model, no guaranteed upgrade path.
- Architecture decided by the AI in each session
- No shared data model between apps
- No predictable URL structure for additional pages
- Data stored in AI-generated tables with no documented schema
- Adding a second app means starting a new session with no context from the first
- No documented upgrade path for changes
- Hosted on the platform's infrastructure, not yours
- Consistent schema across every install (published, documented)
- Every app shares the same contacts, records, and organisation tables
- URLs managed by Core's slug registry, changeable without reinstalling
- Database schema versioned, idempotent, auditable
- Second app connects to the same data the first app uses
- Changes handled as scoped tasks against the live codebase
- Installed on hosting you own and control
If you build a CRM with Lovable and later need an invoicing app, those two apps do not share data. The contacts in the CRM are not visible in the invoicing app. You have two separate CSR applications with two separate databases, neither of which is indexed by Google, neither of which can share a link preview on social media.
A Merebase CRM and a Merebase invoicing app share the same database. The contacts you track in one are the contacts you invoice in the other. They are different views of the same data, on a server you own, indexed by a server-rendered architecture that search engines can read.
What vibe-coding platforms are actually good for
The critique above applies to using these platforms for anything that needs to be found or built on. That is not their strongest use case.
Nati Elimelech's assessment included appropriate uses: "Internal tools, dashboards, admin panels, prototypes." For tools used behind a login that will never need to rank in search or be shared in an AI answer, CSR is not a problem. A prototype that only your team sees does not need to be crawled.
The problem is that these platforms are marketed as if you can build anything with them. You can build something that works in a browser. You cannot build something that is findable, shareable, or built on a foundation you can extend. Those are different things.
A vibe-coded app works in a browser. It does not necessarily work for search engines, AI crawlers, social previews, or the developer you hire next year to extend it.