Why AI can't find your Lovable site

You built the site in Lovable. It deployed, it looks good, the copy reads well. Then you opened ChatGPT, asked the question your best customer would ask, and your brand was not in the answer. The first explanation you find will be that your site is an empty <div> and AI crawlers cannot run JavaScript. That explanation is half right, and the half that is wrong will cost you an afternoon rebuilding something Lovable already does for you.

The diagnosis everyone gives you is dated

The standard write-up goes like this: Lovable ships a React single-page app, the server sends a near-empty HTML shell, the browser builds the page with JavaScript, and every AI crawler sees nothing. Two claims are stacked there. The first — that AI crawlers do not execute JavaScript — is still true and still decisive. The second — that a deployed Lovable site therefore serves an empty shell to those crawlers — is the part that changed.

Lovable's own documentation is explicit on both branches. Apps created from 13 May 2026 are built on TanStack Start with server-side rendering: "Every request returns fully rendered HTML, for humans and crawlers." Older React + Vite projects are not left behind either — they get on-request pre-rendering on deployed public URLs: "When a verified crawler arrives, Lovable renders the page on the fly and returns the resulting HTML." Google, Bing, social-preview bots and the AI engines are on the verified list.

What has not changed: only Google's crawler runs your JavaScript

The rendering constraint underneath all of this is real, measured, and worth stating precisely. Vercel and MERJ instrumented over 500 million GPTBot fetches across their network and found no evidence of JavaScript execution at all. GPTBot pulls .js files in roughly one request in nine — and never runs them. The same pattern holds for the other retrieval crawlers. Google's stack is the exception, because AI Overviews and Gemini ride on the Googlebot renderer that has executed JavaScript for years.

This is why rendering sits above everything else in the order of operations. It is not a ranking factor you tune — it is binary. Content that only exists after hydration is not weakly ranked for a non-rendering crawler; it is absent from the candidate pool, and no amount of schema, headings or keyword work operates on text the engine never received.

The check that works, and the one that lies to you

Almost every guide tells you to right-click, choose View Page Source, and look for your text. On a Lovable React + Vite project, that test is misleading — and it fails in the direction that makes you do unnecessary work.

Pre-rendering is gated on crawler verification, not on a user-agent string. Your browser is not a verified crawler. Neither is curl with a spoofed User-Agent from your laptop, because verification is done on the requester, not on what it claims to be. Lovable says this outright: "Third-party SEO scanners, link checkers, and other agents will see the regular SPA shell, not the pre-rendered HTML." So a view-source that shows <div id="root"></div> tells you nothing about what ChatGPT received.

robots.txt: most guides tell you to allow the wrong bots

This is the most common real defect we see, and it survives every rendering fix. Vendors deliberately split their crawlers along two independent axes: one token governs whether your content may train future models, a different token governs whether the retrieval crawler may fetch your pages so you can be cited right now. They are separate strings with separate IP ranges, and blocking one says nothing about the other.

The prompts circulating for Lovable almost all tell you to allow GPTBot. GPTBot is the training token. Allowing it does not make ChatGPT able to cite you, and blocking it does not stop ChatGPT citing you. The token that gates ChatGPT search citations is OAI-SearchBot, and it usually goes unmentioned.

Two honest caveats on robots.txt as a mechanism. It is a compliance signal, not enforcement: Perplexity documents that its user-triggered fetcher generally ignores it, and Cloudflare has published evidence of undeclared crawlers reaching pages that blocked the declared ones. And a blocked training token is not a problem to fix — plenty of companies deliberately opt out of training while staying fully visible in AI search. Those are two different decisions and deserve two different conversations.

Sitemap and canonicals: cheap, boring, worth it

A sitemap.xml listing every real route with an honest lastmod, plus one canonical URL per page, costs you ten minutes and removes a whole class of ambiguity about which URL is the page. Lovable can generate and repair both, but its documentation is careful to note that "sitemaps, robots.txt, metadata, and other SEO elements are not always generated up front" — so this is a thing to check, not a thing to assume. After you connect a custom domain, submit the sitemap in Search Console; that also gives you the inspection tool from the previous section.

Schema, llms.txt, and the multipliers you keep being shown

Add Organization on the homepage and Article on anything article-shaped. Do it because it makes your entity unambiguous to parse, not because it is a citation lever — Google is first-party explicit that structured data is not a ranking factor; it buys parsing and rich-result eligibility. And for two popular types it no longer buys even that: the HowTo rich result was removed in September 2023, and the FAQ rich result stopped appearing in Google Search on 7 May 2026. The markup still parses. It just earns no SERP real estate.

Skip llms.txt. Every Lovable guide includes a prompt for it and the case against is unusually clean: Google has said it does not support the file and is not planning to, measured adoption across sites sits around ten percent, no major engine has published that it reads one, and Lovable's own SEO review explicitly does not treat a missing llms.txt as a problem. It is a file you maintain for an audience that does not read it.

Three prompts worth pasting into Lovable

Run them in this order, and only after the diagnosis above. There is no fourth prompt here because the rest of the list — pre-rendering, llms.txt — is either already handled or not worth handling.

1. Find out what you already ship

Before changing anything, audit and report back on this project's current
search and AI-crawler setup. Tell me: (1) whether this app uses TanStack
Start with SSR or React + Vite with on-request pre-rendering; (2) whether
robots.txt, sitemap.xml and per-page canonical tags exist today, and show
me their current contents; (3) which pages have a unique title and meta
description and which are inheriting a generic one; (4) whether any
JSON-LD is emitted, and on which routes. Do not fix anything yet — just
give me the current state as a list.

2. robots.txt and sitemap.xml, with the correct tokens

Create or update robots.txt so that it allows all crawlers by default
(User-agent: * / Allow: /) and does not disallow any of these tokens
anywhere in the file: Googlebot, Bingbot, OAI-SearchBot, Claude-SearchBot,
PerplexityBot, Applebot. Use those exact strings — do not invent variants
and do not add a token that is not on this list. Add a Sitemap: directive
pointing at the sitemap on my custom domain.

Then generate sitemap.xml listing every public route with its full URL on
the custom domain and a real lastmod date. Do not include private,
authenticated or preview routes. Add a canonical link tag to every page
using the same absolute URLs as the sitemap, so the two never disagree.

3. One H1, real headings, self-contained answers

Audit the heading structure of every public page. Each page should have
exactly one H1 naming what the page is about, then H2s and H3s in order
with no skipped levels. Where a heading poses a question a buyer would
actually ask, make the paragraph immediately under it a complete answer
that still makes sense if it is quoted on its own, with no "as mentioned
above" or "see below" references to surrounding text. Keep the wording
and the claims exactly as they are — restructure only. Show me a diff of
the heading changes before applying them.

After the plumbing, the plumbing stops mattering

This is the part the fix-it-in-30-minutes framing quietly skips. Everything above buys you candidacy — the engine can reach your pages, read them, and parse what they are about. None of it buys selection, which is the separate question of whether the engine picks you over everything else it retrieved for that question. Those are different failure modes with different fixes, and conflating them is the reason people ship all seven checkboxes and still see nothing change. We pull them apart in discoverability vs selectability.

The harder truth underneath it: most citations in AI answers point at pages you do not own. Roundups, review sites, community threads, documentation that is not yours. A perfectly rendered site with immaculate schema is still one candidate among many, and the ground you actually need is off your own domain — which is slower work with a longer lead time. Which sources AI engines cite has the shape of that landscape.

One adjacent question worth settling early if pre-rendering makes you nervous: serving a rendered version of a page to a crawler is not cloaking as long as the substance is identical — the line Google draws is format versus content, and the burden of staying on the right side of it is yours. We walk through that distinction in what an Agent Experience Platform actually does.

How to tell whether any of it worked

Not by asking ChatGPT once. In a study of 2,961 brand-recommendation prompts across ChatGPT, Claude and Google's AI surfaces, the engines returned the same ordered brand list less than one percent of the time for an identical prompt. A single query measures the noise, not your standing — and it will happily tell you the fix failed on Tuesday and worked on Thursday.

1. Write down a fixed prompt set — fifteen to thirty real buying questions, frozen, before you change anything.
2. Run each prompt several times per cycle, and keep every raw answer with its date and the model version that produced it.
3. Tag every result with the engine and the surface. A model API answer and a Google AI Overview are different products with different citation behaviour; folding them into one number hides half your exposure.
4. Report ranges, not points. With a handful of runs per prompt the interval around any single percentage is wide, and pretending otherwise is how people celebrate noise.
5. Wait a full refresh window before judging a change. Engines re-crawl and re-index on their own clock, typically days to weeks, not hours.

The short version: check what Lovable already renders before you rebuild it, fix the robots.txt tokens because that is the one silent killer, skip llms.txt, and then accept that the technical layer was never the interesting part — it was the entry fee. If you want the before-picture to measure everything else against, run the free audit and start from a baseline instead of a guess.