Lovable Export Limitations: What You Don't Get

What the export actually contains

Both export routes produce the same thing. GitHub sync works on every plan and pushes a normal repository. "Download codebase" produces a ZIP and needs a paid plan. The steps for both are in our guide to exporting Lovable code.

Inside, it is an ordinary front-end project. Node 22, npm install, npm run build, output in dist/. Styling is Tailwind CSS with shadcn/ui components.

Where your pages live depends on when the app was created. Apps built before 13 May 2026 are React + Vite: pages in src/pages, routes wired up in src/App.tsx. Apps from that date on use TanStack Start with file-based routes in src/routes and a head() per route for title, description and JSON-LD.

Included: components, pages or routes, Tailwind and shadcn/ui setup, images and other files in public/, build config.
Included: per-route head() metadata on TanStack Start apps.
Not included: hosting, the prerendering layer, your database, your secret keys, the Lovable editor.

Limitation one: hosting and prerendering stay behind

The build output is static files, so any static host will serve it: Netlify, Vercel, Cloudflare Pages. That part is easy. What does not travel is Lovable's crawler prerendering.

This matters only for older React + Vite apps. On Lovable hosting, those apps are rendered in the browser, and Lovable prerenders them on request for verified search engines, link-preview bots and AI crawlers. Third-party SEO scanners still see an empty app shell. Move the same app to another host and nothing prerenders it at all: every bot gets the shell.

Apps created from 13 May 2026 use TanStack Start and are server-rendered. Every visitor and crawler gets full HTML, wherever you host them, as long as the host runs the server build. We cover the trade-offs in Lovable hosting and is Lovable good for SEO.

If you export an older app, you have three honest options: keep it on Lovable hosting, add your own prerendering or server rendering, or move the content to a platform that outputs HTML by default.

Limitation two: data, auth and secrets do not come along

The export is front-end code. Anything your app talked to stays where it was. A Supabase project keeps living in Supabase; the export only contains the client code that calls it. Same for authentication, dashboards and any third-party API.

Environment variables are a second trap. Variables prefixed VITE_ are baked into the bundle at build time, so your own build needs them set or the app ships with blanks. Keys that were never public are not in the repository, by design. You re-create them in your new host's settings.

Before you point a domain at a self-hosted copy, walk the app and list every screen that needs a login or loads data from a server. Those screens will not work from static files alone. Our notes on Lovable and Supabase describe what to do with each one.

Database: stays in Supabase or wherever it lives; reconnect from the new deployment.
Auth: needs the original provider configured again, including redirect URLs.
Secrets: re-enter in the new host; VITE_ ones must be present at build time.
Login-only screens: these are application screens, not marketing pages. Plan them separately.

Limitation three: you leave the editor

In Lovable you change the site by typing a prompt. After export, you change the site by editing TypeScript. That is the limitation people feel most, and it arrives on the day a non-developer needs to fix a price or swap a photo.

You can keep both. GitHub sync is two-way, so you can export, review and keep prompting in Lovable. But the moment you host the build yourself and edit files by hand, you own a code project. Someone has to run npm run build for every text change.

So the real question is not how to export. It is who edits the site next month. If the answer is a marketer, a code export alone is not the finish line.

Filling the editing gap with WordPress

One way to keep a visual editor after export is to convert the build into a WordPress block theme. Our converter runs in the browser and takes the Lovable ZIP or a GitHub repository. It outputs templates, header and footer template parts, one pattern per page, a theme.json with your palette and fonts, and your images copied into the theme.

That solves three of the gaps above at once. Pages become HTML that any crawler reads, so prerendering stops being your problem. Content becomes editable in the Site Editor without a build step. Forms map to Contact Form 7 and product pages to WooCommerce, so the dynamic parts have a standard home.

It does not solve everything, and we say so plainly. Supabase, authentication, dashboards, API calls, custom React state and event handlers do not convert. Carousels, tabs, modals and animations come across in their default or final state. The full list is on supported features.

Conversion, the side-by-side review in WordPress Playground and the theme download are free, so you can see the result before deciding. Two AI-fix attempts are included with every account.

A short checklist before you export

Run through this once. It takes ten minutes and saves a bad launch day.

Note the build date. Created before 13 May 2026 means React + Vite and client rendering. From that date, TanStack Start and server rendering.
Connect GitHub sync so you have the code on every plan, not only paid ones.
List your environment variables, including the VITE_ ones, and where their values live now.
List every backend dependency: Supabase tables, auth providers, API endpoints, third-party widgets.
List login-only screens separately from public marketing pages.
Build locally with Node 22: npm install, then npm run build. Open dist/ and confirm the pages look right.
Decide who edits next. A developer keeps the code. A marketing team needs a CMS, and converting to WordPress is one route.
Check redirects and the domain before you switch DNS, so old URLs keep resolving.

Where to check instead of guessing

Lovable changes. Plan details, export options and the prerendering behaviour are documented by Lovable itself, and that is the source to trust for anything not stated here. See docs.lovable.dev.

On the WordPress side, block themes, templates and theme.json are documented at developer.wordpress.org. If you want to try a theme before touching a live server, playground.wordpress.net runs WordPress in the browser.

If you are weighing a code export against a rebuild or a headless setup, we compared the three in converter vs manual rebuild vs headless.

FAQ

Does the Lovable export include my database?

No. The export contains front-end source code only. A Supabase project, its tables and its data stay in Supabase, and the exported code simply calls them. You reconnect the new deployment to the same backend, or you replace that part.

Why does my exported site look empty to SEO tools?

Apps created before 13 May 2026 are React + Vite and render in the browser. Lovable prerenders them on request for verified search engines and link-preview bots, but that only happens on Lovable hosting, and third-party scanners see the empty app shell either way. Hosting the same build elsewhere removes prerendering entirely unless you add your own.

Can I export the code without a paid Lovable plan?

Yes. GitHub sync works on every plan and gives you the full repository. The "Download codebase" ZIP is the option that requires a paid plan. Both produce the same project files.

Do environment variables come with the export?

Only the values that were baked into the build. Variables prefixed VITE_ are inserted at build time, so your own build needs them set again. Private keys are not stored in the repository and must be re-entered in your new host's settings.

Can I keep a visual editor after exporting from Lovable?

Not with the raw code export; after export you edit TypeScript and rebuild. Converting the build into a WordPress block theme is one way to get a visual editor back, because pages become patterns you edit in the Site Editor. The IQDesk converter does that in the browser, and conversion, review and the theme download are free.

Convert a Lovable site to WordPress All guides