Today Lovable's co-founder announced they're shipping SEO as a first-class feature: new apps are now server-side rendered, and existing apps get pre-rendering automatically.
The timing is notable. I published a post about a prerender pipeline I built manually for a Lovable site — one that ran on every deploy, silently failed for six months because of missing environment variables, and left four directory pages with zero GSC impressions the entire time. Lovable just made that class of problem their problem, not yours.
So: does this change the argument from Part 1?
The short answer is: partially. It fixes the crawlability problem. It doesn't close the performance gap, and the two paths they've shipped are actually quite different.
What they shipped
New apps: server-side rendering. Every request hits a server, which renders HTML dynamically and sends it to the browser. Googlebot gets real content on the first request — same as SSR frameworks like Next.js in default mode. The CSR crawlability problem is gone for new projects.
Existing apps: automatic pre-rendering. Build-time pre-rendering injects static HTML into the page before the React bundle runs. This is exactly the approach I was doing manually — a script that fetches data at deploy time and writes it into the HTML. Lovable is now doing this automatically.
These are two different things. Worth naming them separately.
What pre-rendering for existing apps actually means
The pre-rendering path for existing apps is a patch on CSR, not a structural fix. The React bundle still ships. The browser still downloads it, parses it, executes it, and hydrates. The pre-rendered HTML is injected at build time — so it's only as fresh as the last deploy.
What it fixes: Googlebot's first-wave crawl now gets real content instead of an empty shell. That's the thing that was causing pages to drop out of the index.
What it doesn't fix: the client-side hydration overhead. The performance characteristics are still those of a React CSR app — full JS bundle, hydration on every page load, PageSpeed scores that require active optimization to keep above 80.
The silent failure mode I documented — where the pre-render ran but the data fetch failed quietly and injected a placeholder — that risk goes away when Lovable controls the pipeline. They can test it. They can fail loudly. They can handle env vars correctly by default. The failure mode I hit was an implementation problem with a DIY script, not an inherent limit of pre-rendering. Lovable's version will be more reliable.
What SSR for new apps actually means
Server-side rendering is a real architectural change, not a patch. Every request hits a server, which generates HTML with current data and sends it. Googlebot sees real content. Users see real content on the first byte.
This puts Lovable new apps in the same rendering category as Next.js with getStaticProps or a hybrid SSR setup — crawlable, indexable, real HTML on first request.
The tradeoff SSR carries that SSG doesn't: every request has server latency. A static site serves from a CDN edge node — the file is already built, it just needs to travel from the nearest edge to the user. An SSR app has to compute the response first. For content that doesn't change per-user, that compute step is unnecessary overhead.
Static site (SSG/Astro) SSR (Lovable new apps)
────────────────────── ──────────────────────
Request → CDN edge Request → server
↓ ↓
file served render HTML (with live data)
immediately ↓
send to browser
TTFB: ~30–80ms (edge) TTFB: ~200–500ms+ (server)
For an app — a tool, a dashboard, something with real interactivity or user-specific data — SSR is the right call. The server compute is justified because the content is actually dynamic.
For a content blog where every page is the same for every visitor, SSG is still faster. The HTML is already there. No server needed.
When the Astro argument still holds
For pure content sites — blogs, documentation, resource hubs — the case for SSG hasn't changed. Astro ships zero JavaScript by default. Every page is a file on disk served from the CDN edge. There's no server to maintain, no per-request compute cost, and no JS bundle penalty on performance metrics.
My Astro blog consistently scores 95+ on mobile PageSpeed. A Lovable SSR app will score lower without active optimization — not because SSR is bad, but because it ships a full React bundle on every page and adds server latency to every request.
For content sites that need real interactivity — some dynamic widgets, user-facing forms, live data sections alongside static content — Lovable SSR is now a legitimate option where it wasn't before. The crawlability problem is solved. You're trading some performance headroom for faster development.
For existing Lovable sites with the CSR problem: the automatic pre-rendering means the indexability issue gets handled without a DIY script. The performance characteristics don't change, but the SEO floor is now reliable.
The actual update to Part 1
Part 1 said: "Lovable is built for apps, not blogs. But plenty of people use it for content sites anyway — that's the mistake this post is about."
The update is: Lovable is now credible for content sites that need interactivity. New apps are SSR — crawlable, indexable, real HTML on first request. The mistake that post was about (using a CSR framework for a content site and watching pages disappear from the index) is no longer baked into the platform by default.
The performance gap between SSR and SSG still exists. For a content site where every millisecond of LCP matters and every page is the same for every visitor, SSG is still the faster path. But the hard wall that made Lovable the wrong choice for organic search is gone for new projects.
That's a significant shift. The choice is now between a fast-to-ship SSR app with React's full ecosystem versus a leaner SSG site with lower performance overhead. That's a real tradeoff, not a clear wrong answer.
Part 1: Astro vs Lovable for SEO — Why Static Sites Win
Part 2: Building an Astro Blog with Claude Code
Top comments (0)