We audited 330 live Lovable apps. 98.5% have a high-severity defect.

SummaryWhat 330 live Lovable apps reveal

Bottom line: Of 330 live Lovable-hosted apps audited on May 27, 2026, 325 (98.5%) shipped with at least one high-severity SEO defect. The dominant defect is the missing H1 tag (98.2% of apps). 93.9% have no analytics installed. 89.4% have no schema markup. The Lovable platform's React-SPA scaffolding generates apps that look correct visually but are structurally empty to every crawler that does not render JavaScript.

This is the first time we have measured the median Lovable app at scale. The numbers above are not extrapolations. They come from running the same free landing-page audit our paying customers use on 330 live *.lovable.app subdomains we pulled from the Internet Archive.

The headline result: 325 of 330 apps shipped with at least one high-severity defect we would file a case on if the site belonged to a Harvv customer. The dominant defect by far is the missing H1 tag, which we found on 324 of 330 apps. Combined with missing schema (295/330) and missing canonical URLs (273/330), the structural picture is consistent: Lovable apps render essentially nothing in their server-side HTML, and Google sees an empty shell.

This piece is the spoke article for our hub research piece The Lovable Friction Tax, which compares Lovable to v0, Cursor, Bolt, and Replit across 85 sites. The hub answers "is this a Lovable problem or a vibecoding problem." This piece answers "if it is a Lovable problem, how bad is it on the median app." The dataset behind every number is downloadable. Every number ties back to one of three files in data/research/.

01How we built the sample

The challenge with Lovable is that there is no public directory. Lovable does not publish a sitemap of customer apps, the platform does not require listing on a gallery, and Google indexing of *.lovable.app is incomplete (the same SEO problem that motivates the article: Google often cannot crawl the apps to know they exist).

We sidestepped that with the Internet Archive's CDX API. Every time the Wayback Machine spots a URL anywhere on the public internet, it records it. A query for url=*.lovable.app returned 5,000 URLs, which we collapsed by hostname to 361 unique candidate subdomains. We then HEAD-probed every candidate to filter out the dead ones, leaving 330 live *.lovable.app hosts.

Each live host then ran through our free landing-page audit (the same engine live at harvv.com/ads-audit). The audit reads the server-side HTML response and identifies tracking pixels, SEO structure, mobile UX, and structural defects. It does NOT render the page with JavaScript. That choice is deliberate: it matches what Google's initial crawl sees, what social-media link unfurlers see, and what every non-render-capable crawler (Perplexity, ChatGPT search, most AI agents) sees. JS-rendered content is a separate question we address at the end.

Total runtime: 29 seconds at concurrency 6. Median per-site audit: 626 ms. The full dataset and methodology code live at:

Reproducibility note: the Wayback Machine's index updates daily, so re-running the corpus fetch in the future will produce a slightly different (and larger) candidate set. The 330-site sample is a snapshot of what Wayback had indexed as of May 27, 2026.

Defect taxonomy (terms used throughout this article)

Each defect kind referenced below is a deterministic property of the rendered HTML response. Definitions are precise so an audit run by anyone else against the same URL would produce the same finding.

02The H1 catastrophe: 324 of 330

Bottom line:98.2% (324 of 330) of audited Lovable apps shipped with no H1 tag in their server-rendered HTML. Only one app in the entire 330-site corpus had a single, well-formed H1.

The single most common defect in the corpus is the missing <h1> tag. 324 of 330 apps (98.2%) ship without one. Five other apps had multiple H1s, also a defect but milder. Only one app in the entire corpus had a single, well-formed H1.

Why this matters: the H1 is Google's strongest single signal for what a page is about. A page without an H1 is a page Google cannot reliably topic-classify. Combined with the empty-shell problem in §4, an H1-less Lovable app gives Google essentially nothing to work with. The page might still rank for the exact-match brand string, but it will not surface for any topical query.

The reason this is universal is structural. When Lovable's AI scaffolds a React app, it generates components that visually look like a page hero (large bold text at the top, centered, primary brand color), but it renders that text inside a <div> or a <p>, not an <h1>. The visual output looks correct. The semantic output is empty. Lovable's AI is optimizing for what the user sees in the preview, not what Google sees in the source.

This is fixable in one prompt: "Wrap the main hero headline of this page in an <h1> tag. Make sure there is exactly one." Lovable's AI will do it on request. It just does not do it by default.

03The measurement vacuum: 6.1% have analytics

Bottom line:6.1% (20 of 330) of audited Lovable apps had Google Analytics 4 installed. 2.7% had any ad pixel. Every Meta Pixel we detected (7 of 7) was misconfigured to never fire a conversion event.

If you shipped a Lovable app and you want to know whether anyone is using it, the median answer is: you do not know. 6.1% of the apps in our corpus have Google Analytics 4 installed. 2.1% have a Meta Pixel. 0.6% have Google Ads conversion tracking. 0.3% have Microsoft Clarity. Everything else: nothing.

One additional defect worth surfacing: of the 7 apps that installed a Meta Pixel, our audit flagged 7 as tracker_misconfigured. The Meta Pixel was loaded and fbq('init', ...) fired, but no downstream track event for Lead, Purchase, AddToCart, CompleteRegistration, or InitiateCheckout was wired up. These apps believe they are tracking conversions. They are not. Meta's optimization algorithm has nothing to optimize against, so any paid traffic spend is functionally random.

The pattern is the same as the H1 one. The AI generates the snippet that visually appears correct (the Meta Pixel base script is there), but it stops at the part that requires understanding the app's conversion model. There is no AI in the world that can guess what "Lead" means for your specific app from the React component tree alone. That is a prompting gap, not an AI capability gap.

04The empty-shell problem

Bottom line:The median Lovable app serves 11 KB of server-rendered HTML because the entire page content renders client-side after JavaScript executes. Googlebot pays a 9x crawl-delay penalty for JS content (Onely, 2022). Perplexity, ChatGPT search, Claude, and social-media link unfurlers do not render JavaScript at all.

The median Lovable app in the corpus serves 11 KB of HTML. The 90th percentile is 12 KB. Even the heaviest app in our sample serves only 115 KB. By comparison, a typical Shopify product page is 350 to 800 KB. A WordPress post is often 100 to 250 KB.

Lean HTML is normally a good thing. Smaller bytes mean faster page loads. The problem here is what is NOT in those 11 KB: the page content. Lovable apps are React single-page applications, which means the server-rendered HTML is essentially just <div id="root"></div> plus a script tag that loads the React bundle. The actual page content is rendered in the browser AFTER the React bundle loads and runs.

What that does to crawlers:

• Googlebot can render JS, but it queues JS-rendering for later (the famous "second wave" of indexing). Onely measured a 9x slowdown vs HTML for the same content to land in the index. For new pages, that can mean weeks of indexing delay.
• Perplexity, ChatGPT search, and Claude typically do not render JS at all. To these crawlers, a Lovable app is a blank page.
• Social-media link unfurlers (Twitter, LinkedIn, Slack, Discord) make a HEAD or limited GET request that does not run JS. The link preview pulls from the static HTML's <title> and og: tags. If those are not in the static HTML, the link preview is empty.

This is why we found so many other structural defects in the audit. The audit reads the static HTML, the same thing every non-render-capable crawler reads. What we are reporting is what these crawlers see.

One technical solution to this exists. The platform can implement pre-rendering, where a headless browser runs the app and saves the rendered HTML, so crawlers see the post-JS content. Lovable does not do this by default. Customers who care about SEO have been migrating off the .lovable.app subdomain to Vercel or similar hosts that pre-render. We documented this rescue economy in the hub piece.

05Other defects we found

Beyond the headline H1 and tracker findings, the audit flagged these structural gaps. Each row is a count of distinct apps that exhibited the defect at least once on the audited URL.

The canonical URL finding (82.7% missing) is worth a separate note. A canonical tag is the line of HTML that tells Google "this URL is the authoritative version of this page." Without it, any URL that hits the same page (UTM-tagged share links, paginated views, query-string variants) becomes a duplicate-content competitor of the page it should be reinforcing. For an app that already has structural SEO problems, missing the canonical compounds the damage.

The 8 apps with viewport zoom blocked are using the explicit maximum-scale=1.0, user-scalable=no meta directive. That is a WCAG 1.4.4 violation. Users with low vision who need to pinch-zoom on a phone cannot. We found this on 8 of 330 (2.4%), all of which appear to be intentional design choices ("we want the app to look the same on every device") rather than AI defaults. Easy to revert.

061 in 12 are already dead

Bottom line:8.6% (31 of 361) of Lovable subdomains archived by the Internet Archive return HTTP 404. The Lovable subdomain was provisioned, the project was published at least once, the page was archived by Wayback, and then the project was deleted or the subdomain was reclaimed.

The original Wayback CDX query returned 361 unique *.lovable.app hostnames. 31 of those (8.6%) returned HTTP 404 on our HEAD probe. The Lovable subdomain was provisioned at some point, the project was published at least once, the page was archived by the Internet Archive, and then the project was deleted or the subdomain was reclaimed.

Two things this number does and does not say. It does say: among the Lovable apps Wayback bothered to archive (which is itself a popularity filter), nearly one in twelve are no longer reachable. It does not say: 8.6% of all Lovable projects ever created. The true mortality rate for the long tail of "I built a demo with Lovable on a Tuesday and never deployed it again" is presumably much higher, because Wayback never archived those at all.

The takeaway for builders: if you are evaluating Lovable as a serious platform for a customer-facing product, account for the fact that the median Lovable app does not appear to have a long support lifecycle. That is consistent with the reactivity-drift pattern documented in the hub piece. Most apps are abandoned after the first feature regression burns through the prompt credits.

07One prompt fixes most of this on your own app

Bottom line:A single prompt pasted into Lovable's chat addresses 7 of the 10 most common defects we found (H1 tag, canonical URL, JSON-LD schema, viewport zoom, meta description). The remaining 3 defects involve tracker installation and conversion-event wiring, which require knowing your app's business model.

None of the structural defects above require migrating off Lovable. They are AI prompting gaps. Once you know what to ask for, Lovable's AI will add the missing tags on request.

Here is the prompt we recommend. Paste this into your Lovable chat as-is:

That single prompt addresses 7 of the 10 defects in §5 of this article. The remaining three (tracker installs, tracker misconfigurations) require knowing your app's conversion model, which Lovable's AI cannot guess.

For the tracker part, we built a Lovable MCP server that installs Harvv's behavioral pixel (free for the first 50,000 events per month). The MCP installs the correct snippet in the correct file for whatever framework Lovable scaffolded (Vite SPA, TanStack Start, Next.js App Router, etc.), then verifies the install on your published URL. Install instructions and the one-prompt connector.

08Limitations & data access

A few honest caveats:

• Static HTML only. The audit reads the server-rendered HTML, the same view a non-JS crawler gets. Sites that hydrate content client-side will have additional H1, schema, and meta data injected by JavaScript after page load. Googlebot CAN see that data, but with the 9x crawl-delay penalty Onely measured. AI search crawlers (Perplexity, ChatGPT) and social-media link unfurlers cannot.
• One URL per host. We audited the root https://<host>/ URL for each of the 330 alive hosts. We did not crawl interior pages. Apps with multi-page structure may have different signal coverage on inner pages.
• Wayback-indexed bias. The Internet Archive does not crawl every public URL. Apps that have been shared publicly, linked from somewhere indexed, or visited by an Archive ingest agent are over-represented. The freshest deployments (last 30 days) are under-represented.
• No customer overlap. None of the 330 apps are Harvv customers. The dataset was collected externally from publicly accessible HTML. We have no commercial relationship to any audited host.
• Tracker detection is signature-based. We detect each tracker by matching known JavaScript signatures (e.g. fbq('init', ...) for Meta Pixel). A custom-rolled analytics implementation that does not match our signatures would not be detected. We do not believe this affects the 6.1% headline materially because Lovable's templates do not generate custom analytics by default.

The full dataset (raw findings JSONL + summary JSON + the URL corpus) is available on request: jordan@harvv.com. If you want to audit your own builder platform with the same methodology, we will hand you the three scripts.

Questions, corrections, or want to collaborate on a follow-up cut (sliced by app vertical, by deployment date, by custom-domain status)? Same email.

09Frequently asked questions

Short, citation-ready answers to the most common questions about this study and Lovable's structural defects in general. Each answer maps to a deeper section above.

What percent of Lovable apps have SEO defects?

98.5% of 330 live Lovable apps audited in May 2026 had at least one high-severity SEO defect. 98.2% (324 of 330) had no H1 tag. 89.4% had no JSON-LD schema. 82.7% had no canonical URL. Detail in Summary and §02.

Why don't Lovable apps rank on Google?

Lovable apps are client-side React single-page applications. The server-side HTML is essentially empty (median 11 KB across 330 audited apps) and the actual page content renders only after JavaScript executes. Googlebot pays a 9x crawl-delay penalty for JavaScript content (Onely, 2022). Perplexity, ChatGPT search, and most non-Google crawlers do not render JavaScript at all. Detail in §04.

How many Lovable apps have Google Analytics installed?

6.1% (20 of 330) of audited Lovable apps had Google Analytics 4 installed. 93.9% had no web analytics. 2.7% had any kind of ad pixel. All 7 sites with a Meta Pixel installed were misconfigured: the base script loaded but no Lead, Purchase, or downstream conversion event was wired up. Detail in §03.

How long do Lovable apps stay alive?

8.6% (31 of 361) of Lovable subdomains indexed by the Internet Archive are dead (HTTP 404). The Lovable subdomain was provisioned, the project was published at least once, the page was archived, and then the project was deleted or the subdomain reclaimed. The true mortality rate across all Lovable projects (including those Wayback never archived) is likely higher. Detail in §06.

Can I fix Lovable's SEO problems without leaving the platform?

Yes. Most defects are AI prompting gaps, not platform limitations. A single prompt pasted into Lovable's chat fixes 7 of the 10 most common defects: H1 tag, canonical URL, JSON-LD schema, viewport zoom, meta description. The remaining tracker-installation gaps require understanding the app's conversion model, which Lovable's AI cannot infer. Harvv publishes a Lovable MCP server that installs a behavioral pixel via one prompt and verifies the install on the published URL. Detail in §07.

What is the median page weight of a Lovable app?

11 KB of server-rendered HTML. The 90th percentile is 12 KB. Even the heaviest app in the 330-site sample served only 115 KB. Lean HTML is normally good, but Lovable's leanness reflects an empty React shell rather than compressed content. Detail in §04.

How was the Lovable-330 sample collected?

The corpus was sourced from the Internet Archive's CDX API (web.archive.org/cdx/search/cdx), which indexes every public URL Wayback has crawled. A query for url=*.lovable.app returned 5,000 archived URLs, deduped to 361 unique hostnames. Each hostname received an HTTP probe; 330 returned a status under HTTP 400 (alive) and 31 returned 404 (dead). The 330 alive hosts were then audited with harvv.com/ads-audit. Detail in §01.

Does this audit apply to Lovable apps on custom domains?

The 330-site sample is *.lovable.app subdomains only, so custom-domain Lovable deployments are not in the sample. However, the structural defects (missing H1, missing canonical, missing schema, empty server-rendered HTML) are properties of Lovable's React scaffolding output, not the hosting layer. A custom-domain Lovable deployment using the same scaffolded React app exhibits the same defects unless a pre-rendering layer like Vercel or Playwright SSG was added.