Lovable Just Shipped SSR. Here's What It Solves, and What It Doesn't.

For a while now, I'd been looking at migrating off Lovable.

Not because anything was broken. The app works. The design holds up. Clients like it. But dot2.solutions had an SEO problem baked into the architecture. Lovable shipped as a client-side SPA, which meant every crawler that matters — Google's, LinkedIn's preview bot, and now the ChatGPT and Claude browsing agents sourcing answers from the live web — saw a blank div until JavaScript executed. No rank. No GEO (generative engine optimization). Invisible to the models people are starting to ask instead of search.

So I started evaluating alternatives. Vercel with a Next.js rebuild was the obvious path. Rocket.new looked interesting. Bolt.new was on the list. I had a few weeks of research behind me — been struggling with this one for a while.

Then I opened a new Lovable project to ask the AI if it could rebuild something in Next.js. Here's what it said back:

I can't rebuild this in Next.js — this Lovable project runs on TanStack Start (React 19 + Vite), not Next.js. Next.js isn't supported here. The good news: TanStack Start gives you everything you listed — SSR, file-based routing, per-page meta, server functions, edge deployment — so we can rebuild your app with full SSR, just using TanStack Start instead of Next.js.

That's how I found out Lovable had quietly shipped SSR.

What actually changed

As of April 20, 2026, new Lovable projects ship on TanStack Start with full server-side rendering. Real HTML. Crawlable pages. Meta tags that arrive at the browser on the first pass, not after JavaScript decides to execute.

TanStack Start is a full-stack React framework built on Vite — the same tooling Lovable was already using. It hit Release Candidate status earlier this year and has been picking up real traction as the credible alternative to Next.js. Unlike Next.js, it takes a client-first approach: you write a SPA, and SSR is layered on top as an enhancement. That's a much cleaner fit for Lovable's generated code than the server-first, React Server Components mental model Next.js pushes. Which is probably why Lovable chose it.

The practical wins for new projects are real — Google's crawler gets actual HTML on first load, LLM browsing agents get a page they can actually read and cite, social cards work without build-time injection hacks, first paint is faster because content isn't waiting on JavaScript, and server functions give you type-safe backend calls without setting up a separate API layer.

Under the hood

For anyone wondering what's actually in the box, here's the exact stack a fresh Lovable project ships with today: React 19 with TanStack Start on Vite 7, TypeScript in strict mode, Tailwind v4 with a real design system (oklch tokens, custom typography), shadcn/ui on Radix primitives, file-based routing via TanStack Router, TanStack Query for data, and Cloudflare Workers edge deployment by default.

A few of those choices matter beyond just SSR. Cloudflare Workers edge means crawlers and LLM agents get the response in milliseconds anywhere in the world — and response latency is a ranking factor. The modern toolchain (Vite 7, TanStack ecosystem) keeps builds fast and output clean, which matters as the project grows.

I tested this on a fresh project I spun up — full content in the response body, meta tags in the head, no JavaScript execution required to read the page. The new defaults deliver.

TanStack Start vs Next.js for SEO

Fair question I kept asking during my research: is TanStack Start actually as good as Next.js for SEO, or was Lovable just picking the lighter option? Here's how they compare on what matters.

On the fundamentals that move rankings — SSR, crawlable HTML, meta tags, sitemaps — they're on par. Next.js has more out-of-the-box conveniences: the <Image> component handles format conversion and sizing for you, ISR is native, and the Metadata API is well-documented. That's fair — Next.js has been around longer and Vercel has invested heavily in the SEO surface.

TanStack Start matches on the fundamentals and beats Next.js on deployment flexibility. Nitro lets you ship to Cloudflare, Netlify, Deno, Bun, Node, or anywhere else without lock-in. The framework also ships with an LLM Optimization guide in its official docs, which is a small but telling signal that the team is thinking about where search is heading, not just where it's been. And for a Lovable-generated project, the Vite-based toolchain is a cleaner fit than Next.js's opinionated build system.

For a site that needs to rank on Google and get cited by LLMs, both do the job. Neither is a compromise.

What didn't change

Here's the catch the AI didn't volunteer: if your Lovable project existed before April 20, you're still on the old client-side Vite template. No migration button. No automated upgrade path. Lovable did not auto-migrate existing projects — and that's consistent with how framework-to-framework migrations typically go, because they never are fully automated. Different routing semantics, different data loading patterns, different component boundaries, different build outputs.

Which means: the SEO and GEO problem I was about to leave the platform over is still sitting there on the old stack.

What I'd actually do

I'm in exactly this situation, so this is the plan I'm running.

Move the blog to Ghost. This week.

This is where SEO and GEO velocity actually matter. Marketing sites rank for branded searches — your name, your company, your services. That traffic lands once people already know you exist. The blog is where you compete for long-tail search, for citations from LLM assistants, and for the kind of content that compounds. Ghost is SSR-native, purpose-built for content, and you get structured data, RSS, proper meta, and clean URLs without building anything. Solve the content layer first.

For your existing marketing site — workarounds exist.

I've built mine and they hold up. Whether a full rebuild onto the new stack is worth it depends on how much the old architecture is actually costing you. For dot2.solutions, my workarounds handle enough that a rebuild isn't urgent. For more content-heavy projects — especially client sites where organic search is the primary acquisition channel — rebuilding is worth the effort, and I'm planning exactly that for several of mine.

For new projects, just build on Lovable.

The biggest reason I was looking at other platforms is gone. SEO and GEO are solved at the platform level now. That changes the calculus for anyone who dismissed Lovable six months ago because their site wasn't going to rank.

Where this leaves me

The thing that was about to push me off Lovable is solved. I'm staying.

New client projects get built on the new stack. Some of my existing work stays on the old stack with workarounds in place. The blog migrates to Ghost this week because that's where content velocity actually matters.

And the piece I'm genuinely excited about: Ghost exposes a full Admin API — programmatic create, edit, and manage access to everything on the platform. Which means I can rebuild my entire blog workflow directly in Lovable, with Ghost as the SSR-native content backend. Both platforms playing to their strengths. Going to be a blast.

The content and knowledge layer is still mine to own — no platform solves that part for you. But the infrastructure layer just got materially better, and that changes who should be on this platform. If you dismissed Lovable because your site wasn't going to rank or show up in an AI answer, it's worth another look.

What's next

I'll share how the migration actually goes — the Ghost setup, the Lovable-driven publishing workflow, and whatever breaks along the way. If you're weighing the same decisions, follow along on LinkedIn, or drop me a line.