Lovable Pre-Launch Checklist: 8 Checks Before You Ship
To check a Lovable site before launch, test the parts Lovable does not generate for you: request the page with JavaScript off to confirm the served HTML is not empty, get your Supabase keys and table access sorted, then add the sitemap, structured data, llms.txt and real 404 that Lovable ships without. Run the eight checks below worst first, before you point a domain at it. The screen looking finished in the browser is not the same as the site being readable to Google and ChatGPT.
More than 100,000 new projects are created on Lovable every day, per reported platform figures. Almost all of them are built by someone who is not a web engineer, which is the point of the tool and also the reason the same eight holes ship over and over. Lovable writes the React screen you described. It does not write the parts no one describes: the server-rendered HTML a crawler reads, the sitemap Google wants, the 404 that returns an actual 404. Those are invisible in the preview and decisive after launch.
This is a checklist for the Lovable stack specifically, not another generic go-live list. Lovable builds a Vite single-page app wired to Supabase, and that exact combination fails in exact ways. Knowing the stack tells you where to look, so each check below names the Lovable-specific failure, the evidence to look for, and the fix written as a prompt you paste back into Lovable's chat.
What Lovable ships, and the gap it leaves
A Lovable site is a web app whose pages and logic were generated from natural-language prompts instead of written by hand, deployed as a client-rendered React app with a Supabase backend. The generator optimizes for the thing you can see: a screen that looks right, clicks through, demos well. It does not optimize for the readers you never mention in a prompt. The Googlebot fetching your HTML. The GPTBot deciding whether to quote you. The buyer reading your refund terms before they pay.
That blind spot is structural, not a bug you got unlucky with. Across the first 37 AI-built sites run through Tabkeel's exam, 92% went live with at least one of these holes and the typical site carried more than five, a pattern written up in the seven-front pre-launch checklist for AI-built sites. A Lovable build is the cleanest example of the pattern, because the whole stack is predictable: the same framework, the same backend, the same omissions every time.
The Lovable Ship List: 8 checks before you point a domain at it
Run these in order. The first two close channels that everything else depends on, so a failure up top makes the checks below moot. Stop treating the site as done until all eight pass.
- Serve real HTML, not an empty app shell.
- Get your Supabase keys and table access right.
- Add a sitemap and kill any leftover noindex.
- Add JSON-LD structured data.
- Publish an llms.txt.
- Make missing pages return a real 404, not a 200.
- Match the pricing page to the terms.
- Read what ChatGPT says about you.
The rest of this page works through each one on the Lovable stack. Checks 1 and 2 are the ones that end in real damage. The other six decide whether you are found, understood and quoted.
Check 1: Serve real HTML, not an empty shell
A Vite single-page app paints the whole page in the browser after JavaScript runs. So the HTML your server actually sends is close to empty, often a single mount point with your headline, copy and prices existing nowhere in it:
<body><div id="root"></div></body>A person visiting sees a full page, because their browser runs the script. Most AI crawlers do not. GPTBot, ClaudeBot and PerplexityBot do not execute JavaScript, so they read that empty body and leave. Google renders on a delayed second pass and usually gets there, slower and with weaker signals in the meantime. The reader whose opinion decides whether you get cited receives your title tag and nothing else. To see what they see, open the page and use View Source, not Inspect. Inspect shows the rendered tree; View Source shows the raw HTML a crawler actually receives. If your product description is not in it, you have found your first hole. The correction Tabkeel returns reads like a prompt, because it is one you hand to your own builder rather than code dropped in your repo:
My marketing pages render entirely on the client, so a crawler with JavaScript disabled sees an empty body. Move the homepage, pricing and about pages to server rendering or static prerendering so the served HTML already contains the headline, the feature copy and the prices. Keep the logged-in app routes client-side. Verify by loading each page with JavaScript off and confirming the product description is present in the source.
This is the single most common finding on AI-built sites and the one that quietly voids every other SEO effort, since a page a crawler cannot read has no rankings and no citations to improve. It is covered in full in the guide on making your website readable to AI.
Check 2: Get your Supabase keys and table access right
Lovable wires most projects to Supabase, and this is where a fast build turns into a data leak. Two different things get confused, so be precise. The Supabase anon key living in your client code is public by design and safe on its own. The protection that actually matters is Row Level Security (RLS), the per-table rule that says who can read which rows. Lovable can scaffold a table with RLS off or with a policy that allows any request, and then every row in it is readable by anyone who opens the browser console, no login required.
The real breach comes from a service-role key. That key bypasses RLS entirely, and it belongs only on a server. If a prompt talked Lovable into calling a privileged operation from the client, the service-role key can end up in the browser bundle, where it hands a stranger full read and write over your database. Two manual checks before launch: open your Supabase dashboard and confirm RLS is enabled on every table holding user data, and grep your deployed bundle for any key that is not the anon key. Rotate anything that already shipped.
Be clear on scope: Tabkeel's exam reads your public surface, so it does not scan your bundle for secrets. This one is on you, and it is the check that ends in a headline instead of a bounce, so it earns the two minutes.
Checks 3 to 6: The findability parts Lovable never fills
None of these four ship with a Lovable build, and each has a silent failure mode that looks fine in the preview. Fix them together in one pass.
| Check | What Lovable leaves out | The silent failure |
|---|---|---|
| Sitemap and noindex | No sitemap.xml; a staging noindex can survive to production | A single leftover noindex hides the entire site from Google |
| Structured data | No JSON-LD on the page | Answer engines have no machine-readable summary to quote, so you are harder to cite |
| llms.txt | No llms.txt at the root | Low severity, but a cheap signal that points AI readers at your key pages |
| Soft 404 | The SPA serves index.html for every path, so unknown URLs return HTTP 200 | Google reads the 200 as a promise of real content and indexes empty pages, diluting the site |
The soft 404 is the sneakiest, and it is baked into how a single-page app routes. Ask for a URL that does not exist, say /pricing-old, and the app returns your shell with a 200 status instead of a 404. To a browser it looks like a blank page. To a search engine it looks like content worth indexing. Add a catch-all route that returns a genuine 404 status for unmatched paths. Structured data and the sitemap are a few minutes each; add a JSON-LD block describing your product and a generated sitemap, then submit it in Search Console. The llms.txt is last because it carries the least weight of the four.
Check 7: Match the pricing page to the terms
Lovable generates a pricing page from your prompt and, if you asked for legal pages, a terms document from a template. These two are written at different moments and never checked against each other, so they drift. The pricing page says a plan is 19 dollars a month; the terms, copied from a boilerplate, still reference a 29-dollar tier or a 14-day trial you removed. The pricing page promises cancel anytime; the terms describe an annual commitment the template shipped with.
A buyer who reads both before paying notices, and the contradiction reads as either sloppiness or a trap. This is billing integrity, one of the seven fronts, and it is easy to miss because both pages look correct on their own. Read them side by side and reconcile every number, every trial length, and every cancellation promise. Tabkeel's exam flags the mismatch with both quotes side by side, so you see exactly which line contradicts which.
Check 8: Read what ChatGPT says about you
Your Lovable app is days old, so a language model has almost nothing to recall about it. Ask ChatGPT what your product is and you will likely get a shrug, because name recall is a lagging signal built from press, reviews and mentions your site does not have yet. That is normal and not worth panicking over, a point covered in the piece on why ChatGPT does not know your startup. What is worth checking is the failure you can actually fix: whether the model, when it does describe you, says something wrong. A price you dropped, a feature you cut, a category you left. That happens when the model reads an old cache or an unreadable page and fills the gap with a guess.
The check is direct: ask a model what your product is and what it costs, then compare its answer to your live site, word for word. Tabkeel automates this as the AI mirror. It puts the question to a model on every exam, stores the answer verbatim, checks it against your site, and keeps the history, so you fix the page, run it again, and watch the model's answer change. On the Founder plan that mirror runs weekly and lands in your inbox, which is how you catch a drifting description before a buyer does.
Run all eight in about two minutes, or keep it on a schedule
You can work this list by hand. View Source for check 1, the Supabase dashboard for check 2, a JSON-LD validator and Search Console for the middle, a careful read for the pricing, and a chat window for the mirror. Or paste your URL into the Tabkeel exam and it returns checks 1 and 3 through 8 as findings with the evidence attached and each fix written as a prompt, with the most severe one shown in full at no cost. To test the render trap on its own first, the AI readability tool runs without a login. The full method behind the fronts is in the methodology, and the wider version of this discipline, the app layer plus the public surface, is the guide on how to QA a SaaS you built with AI before launch.
If you ship on Lovable more than once, running the manual pass every time gets old. The Founder plan at 49 dollars a month is built for that: it runs the exam across three sites and up to 150 pages, hands back every finding as a paste-ready prompt rather than a single sample, and emails you the AI mirror weekly for each site. For one launch you are staring down today, the free exam returns all eight findings with their evidence, and you fix them by hand before the domain goes live. Either way, the goal is the same. Ship a Lovable site the machines can read, index and quote, not just one that looks done in a preview.
Frequently asked questions
How do I check a Lovable site before launch?
Run eight checks in order, worst first. Confirm the served HTML is not empty by loading the page with JavaScript off, get your Supabase keys and Row Level Security right, then add the sitemap, JSON-LD structured data, llms.txt and a real 404 that Lovable ships without, reconcile your pricing page against your terms, and ask a model what your product is to catch a wrong description. The full exam runs the readable-surface checks in about two minutes.
Why does my Lovable site show up empty to Google and ChatGPT?
Because a Lovable build is a single-page app that renders in the browser, so the HTML your server sends is nearly empty. Most AI crawlers do not run JavaScript and read that empty body. Google renders it on a delayed pass but with weaker signals. Server-render or prerender your marketing pages so the headline, copy and prices are in the served HTML.
Are exposed Supabase keys in a Lovable app a security problem?
The anon key in your client code is public by design and safe on its own. The real risks are Row Level Security being off, which exposes whole tables to anyone with the browser console, and a service-role key ending up in the client bundle, which bypasses RLS entirely. Confirm RLS is on for every user-data table and that no service-role key shipped to the browser.
Does Lovable add SEO and structured data automatically?
No. Lovable builds the screen you prompt for. It does not generate a sitemap, JSON-LD structured data, an llms.txt or a real 404 status for missing pages, and a staging noindex can survive to production. These are the findability gaps you add by hand or catch with an exam before launch.
Why doesn't ChatGPT know my Lovable app yet?
Name recall in a model is built from press, reviews and third-party mentions accumulated over time, and a days-old app has none of them, so a blank answer is expected. What matters is whether the model describes you wrong when it does answer, which you catch by asking it and comparing the reply to your live site. Tabkeel's AI mirror runs that check and tracks how the answer changes as you fix the page.
See what AI and Google read on your site
The exam crawls your public site and returns every finding with the evidence and a paste-ready fix. Free, no signup.
Run the free examMore articles