I Love Lovable. But It Has a Real Problem.

I have been building with Lovable for a while now. Ask anyone who's watched me work — I'm an early adopter. Always have been. I jump on tools to find out what they actually do, not what the marketing says they do.

Lovable is genuinely impressive. I can go from a prompt to a working TypeScript app faster than I ever could by hand-scaffolding one. Clean UI. Usable output. For rapid prototyping and internal tooling, it's earned a permanent spot in my workflow.

But I recently hit a wall. And I think many newer builders, especially those with little to no dev experience, are hitting the same wall without understanding why.

---

What I Was Trying to Do

This personal brand site runs on Lovable. I think it looks good. It does what I built it to do. I deployed it to Lovable Cloud, pointed my domain, made tweaks, and moved on.

Then I started publishing content. Blog posts. Threat Intelligence reports. And I started noticing problems.

Blog posts were not generating previews in Slack. LinkedIn showed a blank card. I started wondering what an AI crawler — the kind powering Perplexity or Google’s AI Overviews — would actually see when it visited my site. The answer was almost nothing. Admittedly, this is what I get for vibe-coding my way through a framework I'd never worked with before.

Why This Happens

Lovable generates React applications powered by Vite. This is a solid architecture for building tools. It is the wrong architecture for content that needs to be found. By default, when a crawler, a link preview bot, or an AI scraper visits a Lovable site, this is what it receives:

<div id="root"></div>
<script src="/assets/index.js"></script>

That is the entire page. Your blog post, your bio, your project descriptions — all of it lives inside the JavaScript bundle. None of it exists until a browser executes that script and renders the page on the client side.

Human visitors with a modern browser see everything. Bots see an empty shell. This isn't a bug. It's exactly how client-side rendering works. The problem is that people like me are using it for a job it was never meant to do.

What I Tried

Open Graph tags. You can add og:title, og:description, and og:image directly to your Lovable project’s index.html. This fixes your homepage preview in Slack and iMessage. It adds some value, takes ten minutes. But it only covers your homepage. With a Lovable project, there is a single index.html file for the entire site. Every individual blog post, or page that you care about, still returns a blank card, because the content does not exist in the HTML — it only exists after JavaScript runs.

Cloudflare. I thought Cloudflare might intercept bot traffic and serve pre-rendered HTML. It can't. It's a CDN and security proxy — it doesn't render JavaScript. What it can do is route bot requests to a separate pre-rendering service. Which means you're now maintaining two additional services just to work around a framework limitation. Duct tape.

Prerender.io. It works. Bots get routed to a headless browser that executes your JavaScript and returns a static snapshot. But it adds latency, cost, and operational overhead — and still doesn't give each blog post its own metadata, structured data, or reliable AI-readable content.

Every one of these is a workaround. None of them solves the problem.

The Barrier

The problem is not Lovable. Lovable is doing exactly what it advertises. The problem is a framework mismatch and poor understanding of how the frameworks work on my part (I blame my blossoming but still amateur experience in front-end development). I used a client-side rendering tool for a use case that requires server-side or static rendering.

Client-Side Rendering (CSR): The browser receives JavaScript, runs it, and builds the HTML. Fast and capable for logged-in users interacting with a tool. Perfect for some of the other projects I am building. Invisible to anything that does not execute JavaScript — crawlers, bots, AI scrapers, and link previews.

Server-Side Rendering (SSR): The server generates the HTML before sending it to the browser. Every crawler and bot receives fully readable content immediately.

Static Site Generation (SSG): HTML is pre-built at deploy time and served as flat files. Fastest possible delivery. Ideal for content that does not change constantly.

Lovable gives you CSR. Content sites need SSR or SSG.

Use Case	Rendering Need	Right Tool
Dashboard, internal tool, SaaS app	CSR is fine	Lovable
Personal brand site, blog	SSR or SSG	Next.js, Astro
E-commerce storefront	SSR + dynamic content	Shopify, Next.js
Marketing landing page	Static HTML	Astro, Webflow

What the Right Stack Looks Like

For a personal brand site or blog: Next.js paired with Vercel is the most direct migration path. Next.js is a React framework, so your TypeScript and components transfer. It adds SSR and SSG on top. Each blog post generates its own metadata server-side. Every crawler reads it correctly. Vercel is built by the same team — deployment is connecting a GitHub repo.

Astro is worth considering if your site is primarily content. It ships zero JavaScript by default. Just clean, fast HTML. You drop in React components where you actually need interactivity. If discoverability is the primary goal, Astro is arguably the better fit.

For a storefront: Shopify. Yes, Lovable has a Shopify integration. However, I would caution you against building e-commerce from scratch. This is a solved problem. Shopify handles SSR, SEO, structured product data, and payment processing out of the box. I should know, I have my own Shopify store.

For internal tools, dashboards, and anything behind authentication: Lovable. Seriously. If your users log in to access the tool, discoverability doesn't matter. CSR is fast, the output is solid, and the development speed is real — assuming you have your prompting down and know how to engineer a platform before you hit build. This is what Lovable is built for.

One More Platform Worth Watching

Builder.io sits in an interesting position. It is a visual CMS and page builder that integrates directly with Next.js — meaning you get a drag-and-drop editing experience with SSR under the hood. It also integrates directly with Lovable, an unusual and potentially useful combination.

My honest assessment is that it is more complex to set up than Lovable, and it can introduce its own SEO complications if you are not deliberate about configuration. But for teams that want visual editing and need their content to be discoverable, it is worth evaluating seriously.

What I am Doing Now

I am not walking away from Lovable. Several projects I am building are the exact right use cases: authenticated tools, internal dashboards, and rapid prototypes I need to demo quickly. For those, it is as good as anything I have used.

But my personal brand site is moving. The content - blog posts, project write-ups, the work I want people and AI systems to actually find - needs to live in a framework that serves real HTML. That means Next.js or Astro, hosted on Vercel or Cloudflare Pages. I haven’t quite decided yet.

Now the question for you is, is your audience people logging in to use something, or the open internet trying to find you? Answer that honestly. The right tool gets obvious pretty fast.