Guide
Lovable Supabase and WordPress: What to Do
Supabase does not move to WordPress. It is a backend your React code talks to, not markup a theme can hold, so a converter leaves it out. The practical answer is a split: the marketing pages become a WordPress site, and the logged-in app keeps running on Lovable hosting or your own host against the same Supabase project. This guide shows how to draw that line, what to do with forms and data, and what needs a developer.
Why Supabase cannot convert
A Lovable app with Supabase has two halves. One half is layout: sections, headings, cards, images, Tailwind colors and fonts. The other half is behaviour: a Supabase client, queries, auth sessions, inserts on submit, state in React.
A WordPress block theme stores the first half. Templates and patterns are HTML with block markup. theme.json holds the design tokens. None of that can run a supabase.from('leads').select() call.
So our converter reports Supabase instead of converting it. The same is true of authentication, dashboards, API calls and custom React state and event handlers. The full list is on supported features.
This is not a WordPress limitation you can argue with. WordPress can do databases, users and forms. It just does them with its own stack, not with your Supabase schema and your React components.
Draw the line: marketing site vs app
Before you convert anything, split your pages into two lists. The split decides everything else.
Marketing pages are public, static and read by Google: home, features, pricing, about, contact, blog, legal. These convert well and benefit most from WordPress, because a non-developer can edit them.
App pages are behind a login and driven by Supabase: dashboard, account, billing, any screen that shows a user's own rows. These stay where they are. Our converter reports application screens behind a login rather than converting them.
- Convert: pages that look the same for every visitor and need no session.
- Keep on Lovable or your own host: anything that reads or writes Supabase per user.
- Decide case by case: pages that are public but read Supabase, such as a listing that renders rows from a table.
- Rewrite in WordPress: simple forms that only insert a row, such as contact or waitlist.
Run WordPress and the Supabase app side by side
The common setup is one domain for the marketing site and a subdomain for the app. For example example.com on WordPress and app.example.com on Lovable hosting or a static host.
Your Supabase project does not move or change. The app keeps the same project URL and anon key. Nothing in Supabase knows or cares that the marketing pages now come from WordPress.
Mind two details. First, DNS: the root domain points at your WordPress host, the subdomain at the app host. We cover the moving part in Lovable custom domain. Second, links: every "Log in" and "Sign up" button in the converted theme must point at the app subdomain, as a full URL.
If you keep the app on Lovable hosting, see Lovable hosting for what that covers. For anything about Supabase integration settings inside Lovable, check Lovable's documentation.
- List the Supabase-backed routes in your project. Older apps: look in
src/pagesandsrc/App.tsx. Newer apps:src/routes. - Pick the app host. Keep it on Lovable, or build it yourself with
npm installandnpm run buildon Node 22 and deploydist/to a static host. - Point a subdomain at the app and the root domain at WordPress.
- Convert the marketing pages to a WordPress theme and install it.
- Fix the cross-links in the WordPress header and buttons so they use the full app URL.
- Test a login round trip: click Log in on WordPress, sign in, and land back in the app.
Forms, waitlists and lead capture
Many Lovable sites use Supabase for one small thing only: a contact form or a waitlist that inserts a row. If that is your case, you do not need Supabase on the marketing site at all.
Our converter turns Lovable form markup into a Contact Form 7 form. The fields and the layout come across; the submit handler does not. WordPress emails the submission instead of writing to a table. Details are in Lovable contact form in WordPress.
If the rows matter, you have three options. Use a WordPress form plugin that stores entries in the WordPress database. Keep the form as a small embedded page on the app subdomain. Or have a developer post the form to a Supabase edge function from WordPress.
Export any existing rows from Supabase before you retire the old form, so you do not lose past leads.
Public data that comes from Supabase
The hard case is a public page that renders Supabase rows: a blog, a directory, a changelog, a product catalogue. There is no session, but the content is dynamic.
If the data is content, move it into WordPress and stop reading Supabase for it. WordPress posts, pages and products are built for this, and your editors get a real editing screen. Blog-like data arrays in the code become real posts and categories with a query loop; see Lovable blog to WordPress. For a catalogue, WooCommerce is the target; see Lovable to WooCommerce.
If the data must stay in Supabase because the app writes to it, keep that page on the app subdomain. A second option is a developer-built sync: a scheduled job that creates or updates WordPress posts from Supabase rows through the WordPress REST API. That is custom work, not something the converter does.
Whatever you choose, pick one source of truth per dataset. Two systems writing the same records will drift.
Converting the marketing half
Once the split is clear, the conversion itself is ordinary. Export the project as a ZIP on a paid plan, or connect the GitHub repository, which works on every plan. Exporting Lovable code walks through both.
Drop the ZIP or the repo into the converter. It produces a WordPress block theme: templates, header and footer template parts, one pattern per page, theme.json with your palette and fonts, and your images copied into the theme. The review screen shows the converted site next to the original inside WordPress Playground, in the browser.
Supabase-driven sections will appear empty or missing in the review. That is expected. Delete those sections in the Site Editor, or replace them with a static version and a button that links to the app.
Install the theme with Appearance → Themes → Add New → Upload Theme → Activate. Pages are created on activation and the front page is set. Conversion, review and the theme download are free, and every account includes two free AI-fix attempts; see pricing for credits beyond that.
Before you launch
Keep the staging site out of Google while you work. Settings → Reading has a checkbox "Discourage search engines from indexing this site". Check it now, uncheck it before launch.
Then run the split-specific checks below. The general launch list lives in migrate Lovable to WordPress.
- Auth links work from WordPress to the app, on desktop and mobile.
- Supabase keys are not in the theme. Search the theme files for your project URL and anon key and remove anything that leaked in through copied markup.
- Old app URLs redirect. If
example.com/dashboardused to work, redirect it to the app subdomain. See Lovable redirects in WordPress. - One canonical marketing page per topic. Do not leave the old pricing page live on the app subdomain next to the WordPress one.
- Form submissions arrive. Send a real test and confirm the email lands.
- Indexing is back on: uncheck the Settings → Reading box on launch day.
FAQ
Can a Lovable Supabase backend be converted to WordPress?
No. Supabase is a backend your React code calls at runtime, and a WordPress block theme only holds markup and design tokens. Our converter reports Supabase, authentication, dashboards and API calls instead of converting them. The usual answer is to keep the app on its own host and convert only the public marketing pages.
Can WordPress read data from Supabase?
Not out of the box. A developer can build it, usually with a scheduled job or a plugin that calls Supabase and writes WordPress posts through the REST API. For content like blog posts or products, it is simpler to move the data into WordPress and let WordPress own it.
What happens to my Lovable contact form that writes to Supabase?
The converter rebuilds the form markup as a Contact Form 7 form, with the same fields and layout. The Supabase insert is not carried over, so WordPress emails the submission instead of writing a row. If you need stored entries, use a WordPress form plugin that saves them in the WordPress database.
Do I have to shut down my Supabase project after moving to WordPress?
No. Your Supabase project keeps running unchanged for the app half of your product. Only retire it if nothing reads or writes it any more, and export the rows you want to keep first.
Where should the logged-in app live after the marketing site moves?
A subdomain such as app.example.com is the common choice, with the root domain pointing at WordPress. You can keep the app on Lovable hosting or build it yourself and deploy the static output to any host. For Lovable-specific hosting and Supabase settings, check Lovable's documentation at docs.lovable.dev.