How to ship one h1, title, meta description and JSON-LD on Lovable

Quick summary

Check first, then read the rest of this guide. Run npx aiscan-cli yoursite.com, or paste the URL at AIScan. It grades C3, structured HTML made of one h1, a title tag, a meta description and JSON-LD, plus the rest of the content, discoverability, bot-access and capabilities checks in one pass, free and with no account.

Lovable doesn't give you a metadata file. It gives you an auditor.

Every other platform in this series has a place where title, meta description and schema live: a PHP template, a metadata export, a settings panel. Lovable has none of those for a project you didn't build the head tags into yourself. According to Lovable's own publishing documentation, fetched 23 September 2026, "Lovable generates your site's metadata while it builds your app: the site title, meta description, and site icon." There is no file to open and no field to type into for that part.

What Lovable gives you instead is a checklist that reads your actual code and your deployed pages, called the SEO & AI search review. Open it from More → SEO & AI search in the project toolbar, then click Scan project. Four of its findings map straight onto C3, listed here as verified on docs.lovable.dev:

Each failing row gets a Try to fix button that hands the specific fix to the agent, or you can click Try to fix all and send every open finding in one message. The review runs on unpublished projects too, so nothing here waits for a live domain.

In our own corpus of 501 scanned sites, re-measured 9 September 2026, 248 currently pass all four C3 signals at once, worth knowing before you assume a partial score is unusual.

Set the title and description by asking, not by editing

There is a genuine trap here for anyone used to a settings page: the title and description are not global. Lovable's documentation states plainly that "metadata is set per page… Lovable generates a unique title and description for every page of your app based on its content," and that changing it means asking in the project chat, for example: "Change my site title to 'Acme Task Tracker' and write a meta description about team to-do lists." That request is treated as a normal build message and spends credits like any other edit, according to the same page.

A metadata change only reaches the live site on your next publish, exactly like a code edit. If the project is already published, Lovable's reply ends with a Publish to update the live site button, so you don't have to hunt for the Publish dialog separately.

Let the review add the missing h1, then check what it actually wrote

The Content structure check fails on a missing h1, a heading that skips from h1 to h3, or an h1 so generic it says nothing about the page, in Lovable's own words: "H1 is missing or too generic" and "Heading levels skip from H1 to H3." Clicking Try to fix sends that finding to the agent, which edits the component that renders the page rather than a template file, because on a Lovable project there usually isn't a separate template to edit.

Read the diff before you accept it. An agent asked to add an h1 on a page that already has a large, unstyled heading sometimes wraps a second element instead of promoting the first one, which trades a missing-h1 finding for a two-heading finding on the next scan. Confirming the tag count after every fix, not just after the whole pass, catches that in one page load instead of a full review cycle.

JSON-LD is a finding, not a code snippet you paste in

The Structured data check is stricter than "does a script tag carrying JSON-LD exist." Lovable's own documentation for the check names three separate failure modes, verified on docs.lovable.dev: JSON-LD that "cannot be parsed," JSON-LD that "does not match the visible page," and a page that "clearly qualifies for a supported Google Search feature and already shows the facts that feature needs, but carries no markup for it." It's also explicit about what does not count as a problem: a missing generic WebSite or Organization block, and a missing FAQPage markup, are both called out as non-issues on their own.

Try to fix here either adds a new JSON-LD block matched to the page's actual content, a product page gets Product, an article gets Article, or repairs an existing block so its fields match what's on the page. If you'd rather brief the agent yourself, describe the entity and the fields you want rather than pasting a generic schema.org example. A copied Organization snippet with placeholder values is exactly the "does not match the visible page" failure the check is built to catch.

Read the review panel and the rendered HTML. They can disagree.

A Scanning your project… header means results are stale; wait for it to finish before trusting a green check. After a Try to fix pass completes, the review marks that finding Fixed provisionally and only confirms it on the next scan, so run Scan again rather than taking the badge at face value.

Then check the deployed page itself, because Lovable's review and a crawler don't always see the same HTML:

URL=https://yoursite.com/some-page
curl -s "$URL" | grep -c '<h1' # expect 1
curl -s "$URL" | grep -o 'application/ld+json' | wc -l # expect 1 or more
curl -sI "$URL" | grep -i x-robots-tag  # a "noindex" here means you tested a preview host

If the curl output looks right but AIScan still reports a failure, the gap is almost always the template split covered in our full Lovable setup guide: an older React + Vite project only serves its pre-rendered HTML to crawlers Lovable has verified, and AIScan isn't on that list.

Where AIScan fits, and where it doesn't

AIScan reads the HTML your server actually hands back, the same bytes an unverified crawler gets. On a React + Vite Lovable project that can be the single-page shell, by design, so a failing C3 there means an unverified client sees nothing yet, not that your h1 doesn't exist. On TanStack Start, AIScan sees exactly what everyone else does.

Lovable's own review goes further than our check in one specific way: it looks at whether your JSON-LD's @type genuinely matches the page, and whether a passing structured-data result even applies to that page's purpose. AIScan's C3 currently only asserts that a JSON-LD block is present and parses; it doesn't check the type against the content. Treat a Lovable "Structured data" pass as the stronger signal when the two disagree, and treat an AIScan pass as the one that also confirms an outside crawler can read it at all.

If your Lovable app pulls its articles from a connected WordPress or Shopify source rather than rendering them itself, this guide doesn't reach that content. A headless WordPress blog still needs its own robots.txt, schema and llms.txt handled on that domain, which is what ThinkRank is built for, and a connected Shopify catalog needs the same from StoreSEO.

Ship it, then scan the domain that matters

Run the SEO & AI search review, click through Try to fix all, publish, then scan your published custom domain, not the .lovable.app preview, at AIScan and read C3 alongside E3, D1, D2, B2 and C2. The full Lovable setup guide covers the rendering split and the discoverability files this post doesn't. If your stack owns metadata a different way, the Next.js and Webflow versions of this guide show two more mechanisms for the same four signals. Every platform guide lives at aiscan.site/guides, and the check definitions for this dimension are at /docs/checks/content.