Vibe-coded apps have an SEO problem. Here's how to fix it

Tools like Lovable, Bolt and v0 are amazing for shipping an idea in an afternoon. They are not amazing at SEO. The whole page is a client-side React bundle, which means Googlebot on its first crawl sees an empty . No content. No headings. No schema. No rankings. For an MVP that relies on organic traffic, that is a founding-year problem.

Here are the two fixes I use at Sirajov, ordered from smallest effort to largest payoff.

Fix 1: Cloudflare Worker SSR proxy

A Cloudflare Worker sits between your domain and Lovable. When a request comes in, the Worker checks the User-Agent: real visitors are proxied through to Lovable as usual; bots (Googlebot, Bingbot, GPTBot, PerplexityBot, ClaudeBot) get server-rendered HTML with real content and full schema markup, from the same URL.

This is not cloaking when it's done correctly. The content the bot receives has to match what the user eventually sees once the JS executes. The setup is two steps:

1. Add one CNAME to your DNS pointing your custom domain at the Cloudflare Worker.
2. Paste one prompt inside Lovable so the worker has a canonical page inventory to server-render from.

When to use the Worker approach

If you are not ready to migrate off Lovable, and you need pages indexed this week, the Cloudflare Worker is the right call. It's the only fix that keeps Lovable's visual editing flow intact.

Fix 2: Migrate off Lovable with Claude Code

The Worker buys you time. But if the app has to rank seriously, handle dynamic content, or be maintained by humans a year from now, you'll want to move to a "normal" web stack. The fastest way I've seen is to let Claude Code do the migration for you.

The 10-step migration recipe

1. Push your Lovable project to GitHub so Claude can work with it easily.
2. Install Claude Code locally so it can read and edit your repo directly.
3. Point Claude at your repo (GitHub remote or local path).
4. Create a Supabase project for database and auth (roughly five minutes).
5. Ask Claude to migrate the project away from Lovable with this prompt: "Migrate this Lovable project into a normal web stack and organize the repo cleanly."
6. Set up hosting on Vercel. The free tier covers most MVPs.
7. Ask Claude which environment variables and API keys are required; it's surprisingly good at identifying them.
8. Generate the keys and create a .env file (Supabase keys, API tokens, etc).
9. Ask Claude to configure deployment. It can wire the GitHub → Vercel flow and connect Supabase.
10. Fix anything that breaks by asking Claude to debug, one error at a time.

This setup ends up more flexible than Lovable itself. You stop paying per-prompt credits for app changes, and you can fall back to free models for small edits, since Lovable is already using Claude under the hood for most of its generation.

The Lovable + Claude hybrid

If you're mid-project and not ready to migrate, there's a middle path that multiple r/lovable users have validated: connect Lovable to GitHub, then give Claude Code access to the same repo. Claude sits on a layer above Lovable, guiding it through complex features, debugging, and enhancements, while you run SQL directly in Supabase for database changes (Lovable doesn't charge to run a query, so it's free).

Results: fewer burned credits on blocking components (users report 100+ credits saved on a single component), better handling of tangled logic, and, critically for this article, enough control over the output HTML that you can retrofit SSR and schema incrementally.

Which fix should you pick?

• Marketing site or landing page only → Cloudflare Worker SSR. Cheapest, fastest.
• Product with dynamic content that needs to rank → migrate to Claude Code + Supabase + Vercel.
• Mid-project and can't rebuild → Lovable + Claude hybrid, then retrofit SSR on the pages that matter.

Where I plug in

Sirajov has migrated a handful of Lovable MVPs off the platform using exactly this recipe. If you'd rather not burn a week on the plumbing, I can take it from prompt to indexed production, usually in under two weeks.

Frequently asked questions

Why can't Google index Lovable pages directly?

Lovable ships a client-rendered React bundle, so the initial HTML is an empty root div. Googlebot's first-pass crawl captures that empty HTML; it may (or may not) come back later to render JavaScript. For new domains with no authority, that second-pass render is often never triggered.

Is the Cloudflare Worker fix considered cloaking?

Not if the bot sees the same content a user eventually sees once JS executes. Serving pre-rendered HTML to bots is an established SEO pattern; it only becomes cloaking if you serve different content to bots than to users.

How much does the full migration cost?

DIY: a weekend and a Vercel + Supabase free-tier account. Delivered by Sirajov: typically around one sprint, bundled into my MVP Production package.

Can I keep editing visually after migrating?

You lose Lovable's in-browser editor, but gain a normal dev loop and can bring any visual tool (or another AI builder) on top of the repo. Most teams don't miss it once they see how much faster Claude Code iterates.

Sources

• r/lovable showcase: 'I solved Lovable's biggest SEO problem' (Cloudflare Worker pattern).
• r/lovable tutorial: 'Lovable <> Claude = 10X performance' by u/EIAMM.
• r/lovable: 10-step migration to Claude Code + Supabase + Vercel.