Most apps built on Lovable are invisible to AI.

The leaderboard — best first

Scores ran from 22 all the way to a perfect 100. That spread is the good news: a great score is achievable on the exact same stack, so this is a knowledge gap, not a platform ceiling. The four A-grade apps below are named as positive examples of what good looks like. The rest are anonymized — we're not here to shame any individual builder.

What broke, and how often

The failures cluster around one root cause — the page is rendered by JavaScript in the browser, so the HTML a crawler fetches is nearly empty. Each percentage is the share of the 17 scanned apps where we observed that specific issue at scan time.

Spread 22→100, median 56; 41% scored below 50, while 24% earned an A. The top performers prove it's solvable: one app passed all 9checks, and the next three A's failed only a single signal each.

What this means — and the honest fix

The number-one failure here is the JS shell: a page with no server-rendered text. This is the part it's tempting to overclaim, so we won't. A browser embed cannot fix it.An embed is JavaScript too, and these crawlers don't run JavaScript — so a script that injects JSON-LD or meta tags into the DOM is invisible to the very bots that already saw a blank page. The honest fix for a JS-shell app is to server-render or static-render the content (ask Lovable to pre-render your page) and to add an llms.txt file — a real file you place, which non-JS crawlers read directly.

Methodology & honest caveats

We believe a study is only worth citing if its limits are stated as plainly as its findings. Here are ours.

• Hand-picked, not random.
  We scanned 18 public, live apps we could confirm were built with Lovable. This is the apps we scanned — never a claim about all Lovable apps, which we have no way to enumerate or sample representatively.
• A single-date snapshot.
  Each app was scanned once, in June 2026. A score is a point-in-time measurement of the HTML served that day; a redeploy can change it the moment it ships. We lock the date so the number is reproducible in context.
• Public homepages only.
  We fetched each app's public homepage — nothing beyond what an AI crawler already requests. No scraping of private pages, no authentication, no probing past the front door.
• Readability, not recommendation.
  The score measures AI-readability from server-side HTML: does the text, structured data, and llms.txt a crawler reads actually exist? It is not proof that ChatGPT or Claude do, or don't, recommend an app today.
• The live-perception probe is separate — and ChatGPT & Claude only.
  Whether a model actually knows and names an app is a different check. Where we run it, it covers ChatGPT and Claude only. Perplexity and Gemini are not probed live, so we make no claim about what they would say.
• “Crawlers don't run JS” is documentation, not a probe.
  That GPTBot and ClaudeBot fetch the page without executing JavaScript is how those crawlers are documented to work — a well-established fact about the bots, not something we measured live per app.
• Best-first, no shaming.
  We name the A-grade apps as positive examples and anonymize the rest. Low scores trace to platform defaults — most AI builders ship JavaScript-only by default — not to any builder's negligence.
• 18 found, 17 reachable.
  Of the 18 apps we found, 17 responded. The unreachable one (an NXDOMAIN on the scan date) is excluded from the 17-app average and every percentage above.

Scored on getAdvantage's 9-signal AI-readability engine — the same scan you can run on your own app. See the full methodology for how each signal is weighted.