AIScan.site
Platform playbook

AI-agent readiness for Lovable apps

Lovable projects go from idea to public URL faster than anything else we scan, and the failure pattern follows from that speed: the app is real, the marketing surface around it is not. Routes exist but carry the starter title, there is no llms.txt, the sitemap lists three URLs, and content that the app fetches after mount is invisible to anything that does not run JavaScript. All of it is fixable in the same session that built the app.

C3 · Structured HTML (title, meta, JSON-LD, single H1)E3 · Heading hierarchy & server-rendered textC2 · /llms.txtD2 · XML sitemapM4 · Machine-readable pricingB2 · Explicit AI bot rules

What our own scans say about Lovable

Not an estimate. These numbers come from public AIScan reports and change as we scan more.

Lovable sites scanned
23

Distinct public domains, counted once each at their most recent scan.

Average score
73/100

Mean of the latest public scan for every Lovable domain we have graded.

What Lovable sites fail most often

Computed from public AIScan reports, refreshed as we scan. Private reports are never included.

How Lovable sites fail, and what fixes it

Starter metadata still in place

A generic title and description on every route is the single loudest signal that nobody has thought about how this page appears in an answer. Each content route needs its own title, description and OG pair.

C3 · Structured HTML (title, meta, JSON-LD, single H1)

Data fetched on mount instead of in a loader

A page that renders a spinner server-side and the answer client-side scores as an empty page, because for a crawler it is one. Route loaders that prefetch the query are the fix, and they are also faster for humans.

E3 · Heading hierarchy & server-rendered textC3 · Structured HTML (title, meta, JSON-LD, single H1)

A sitemap with the routes but not the content

Static routes are easy to list; the generated ones — posts, profiles, listings — are the ones an agent needs. A sitemap route that reads from the database keeps up on its own.

D2 · XML sitemap

Pricing that only a browser can read

If the product sells, the plans need real prices in the served HTML with Offer structured data. Check M4 is the difference between being compared and being skipped.

M4 · Machine-readable pricing

Step-by-step fixes: /docs/platforms/lovable · /docs/checks/content · /docs/checks/commerce · /llms-txt-generator

Businesses running on Lovable

No business stories mapped to Lovable yet — browse all use cases.

Questions Lovable owners ask

Why does my app score badly when the pages clearly work?
They work in a browser. The grader reads what the server sends, and on a client-fetched page that is a shell. Check E3 is measuring the gap between those two things.
What is the fastest single fix?
Per-route metadata, then server-rendering the main content route through a loader. Those two usually move more points than everything else combined.
Do I need llms.txt for an app rather than a site?
If anyone should discover it — yes. It is the file that says what the product does in words an assistant can repeat, and it takes ten lines.
Is a generated sitemap worth it for a small project?
It is worth it the moment content is created by users rather than by you, because that is the point where a hand-written list starts lying.
Does this apply to Bolt, Replit or v0 projects too?
Yes. The stacks differ slightly, the failure shape is identical: fast app, thin public surface.

Scan your Lovable site and see where you actually stand

Free, no account, about twenty seconds. The report names every failing check by ID, shows the evidence we found, and gives the fix for your platform — plus a hand-off prompt you can paste straight into Claude Code or Cursor.

Run a free scan npx aiscan-cli yoursite.com

Prefer to read first? Browse every check we run or the guide library.