Can ChatGPT and Perplexity read a website built with Lovable?

ChatGPT and Perplexity can read a Lovable site when the HTML their crawlers receive already holds the page text, and on Lovable that depends on when the app was created. Apps created on or after 13 May 2026 (22 June 2026 on Enterprise plans) run on TanStack Start, which renders full HTML on the server for every request. Older React + Vite apps stay client-rendered for people and get on-request pre-rendering that Lovable serves only to crawlers it verifies, which it says include the ChatGPT, Perplexity, Claude and Gemini crawlers. I based this on Lovable's documentation as I read it on 1 November 2026, Vercel's crawler analysis, two independent write-ups of the Lovable change, and fixing the same problem on my own Lovable site in October 2026.

By Ronan Liedmeier, fractional head of growth. Last updated 1 November 2026.

Client-side rendering means the server sends a near-empty HTML page and JavaScript builds the content in the visitor's browser. A crawler that does not run JavaScript receives only that empty shell.

Do AI crawlers run JavaScript?

The crawlers behind ChatGPT, Claude and Perplexity do not run JavaScript; they read the HTML the server sends. Vercel's analysis of crawler traffic on its network, published 17 December 2024, states that "none of the major AI crawlers currently render JavaScript" and names OpenAI's OAI-SearchBot, ChatGPT-User and GPTBot, Anthropic's ClaudeBot and PerplexityBot (Vercel).

The same analysis found that ChatGPT's and Claude's crawlers download JavaScript files without executing them. The exceptions it names are Gemini, which runs on Googlebot's infrastructure, and AppleBot, which renders through a browser-based crawler. I have not found a crawler operator documenting a change since, so I treat raw HTML as what these crawlers read.

That is why the rendering question decides everything else. In my check of 1,586 software company websites on 22 October 2026, 170 (10.7%) had under 150 words of text in raw HTML on both the homepage and sampled pages (full results).

What does a Lovable site send to an AI crawler in 2026?

What a Lovable site sends depends on its stack. Lovable's documentation describes two stacks with different behaviour, and a third setup exists when someone adds build-time prerendering to an older app, which is what I did.

Lovable's documentation lists the crawlers that receive pre-rendered pages: search engines such as Google and Bing, AI search crawlers such as ChatGPT, Perplexity, Claude and Gemini, social-preview bots and verified SEO tools. Unverified bots get the regular single-page app (Lovable Documentation).

Pre-rendering applies only to deployed public URLs. Lovable's product page says older apps need "no opt-in or migration" to get it (Lovable). Lovable also serves a Markdown version of each page, on both stacks, to any client that asks for Markdown. Its documentation says, "That is how AI assistants read your site."

Why does a curl test give the wrong answer on an older Lovable site?

On a React + Vite app, a curl test shows what an unverified bot gets, which is the empty app shell. A verified crawler may get the pre-rendered page at the same URL, so curl can report a problem that GPTBot or PerplexityBot does not have.

Hado SEO reported in April and May 2026 that Lovable checks crawlers by IP address and reverse DNS, so changing curl's user agent to GPTBot does not get you the pre-rendered version. Lovable's own documentation does not say how it verifies crawlers. Hado sells prerendering and crawl analytics, so read its findings with that interest in mind.

The Markdown version gets around this. Lovable returns it to any client that asks with an Accept: text/markdown header, and on my own Lovable site on 1 November 2026 the homepage came back as Markdown with about 950 words. My free readiness check asks for that version whenever a page's HTML comes back nearly empty, and counts the page as readable when the Markdown holds the text.

The reverse is just as important. I could not confirm from outside what Lovable's pre-rendering serves to OAI-SearchBot or PerplexityBot, and neither could two independent write-ups. Encited, in an article last updated 20 October 2026, wrote of the pre-rendering and AI or social crawlers: "We could not verify that it reaches them." Hado prompted ChatGPT, Claude and Perplexity to fetch Lovable URLs directly and got no usable page content, though a live fetch by a chat assistant is a different agent from the search crawler.

How do you check what AI crawlers get from your Lovable site?

Start with the stack, because it decides which test means anything. On a TanStack Start app, curl is a valid test; on a React + Vite app, curl only shows the unverified path and you need an outcome test.

1. Find the stack. An app created before 13 May 2026 (22 June 2026 on Enterprise) is on React + Vite unless it was upgraded. To confirm, open package.json in the code view and look for @tanstack/react-start.
2. On TanStack Start, run curl -sL https://yourdomain.com/some-page | grep -c "a sentence from the page". A result of 0 means the sentence is missing from the HTML and something on that route renders in the browser only.
3. On React + Vite, run curl -sL -H "Accept: text/markdown" https://yourdomain.com/some-page. If the sentence is in the Markdown, AI assistants that ask for Markdown can read it. A plain curl that returns an empty shell only confirms you are on the bot-only path.
4. Run Lovable's SEO and AI search review. Lovable says it checks the sitemap, robots.txt, metadata, structured data, page structure, alt text, canonical tags, indexing and AI readiness.
5. Lovable recommends Google's URL Inspection tool for checking pre-rendered output. Googlebot renders JavaScript on its own, so a clean result there says little about crawlers that do not.
6. Run an outcome test. Publish a unique, specific sentence on a deep page, wait a week, then ask ChatGPT search and Perplexity what that page says about the topic and see whether they quote it. This is my recommendation, and it measures the thing you care about: whether the engine has your text.

Which fix fits a Lovable site?

If every visitor and every crawler must get the same HTML, upgrade to TanStack Start or add build-time prerendering. If you can live with bot-only pre-rendering you cannot inspect, staying on React + Vite costs nothing and needs no work.

Serving pre-rendered pages to crawlers and the client-rendered app to people is what Google calls dynamic rendering. Google's page, last updated 10 December 2025, says it "was a workaround and not a long-term solution," and that Googlebot generally does not treat it as cloaking as long as the content is similar for users and crawlers (Google Search Central). Lovable's React + Vite pre-rendering works that way.

Encited reported that the pre-rendering "runs at publish time" and covers only pages that exist as static routes in the project at that moment, and that a page whose content arrives from a database, CMS or API at request time is not covered. Lovable's documentation describes the same feature as on-request and says content that loads with the page is usually included while content that loads late may be missing. The two descriptions differ, so if your blog or product pages come from a database, test those routes first.

What did I do on my own Lovable site?

My site, growthmarketing.solutions, is built with Lovable on React + Vite. On 15 October 2026, the raw HTML of the homepage held only the head and an empty root div.

The same day, the Insights section moved to static HTML generated at build time from markdown files. The marketing pages followed with a build-time prerender step: after the normal client build, a second Vite build renders each listed route to HTML on the server side and writes it into the published files, and the browser then hydrates the page. Fifteen routes are on that list today, including the homepage, pricing, /ai-visibility and /geo-for-saas, and the build fails if a route's canonical tag does not match its URL.

The static build step fixed the biggest blocker in one working day. What it buys me is one version of each page for everyone, so a plain curl of any listed route shows exactly what GPTBot and PerplexityBot receive, and my own checker reads the same thing.

The cost is maintenance. A new page needs its route added to the list, or it falls back to the empty shell for crawlers that do not run JavaScript.

What I'd do

1. Check the creation date of the app, then confirm the stack in package.json.
2. On TanStack Start, curl five pages: the homepage, pricing, one product page, one article and one page that pulls data from a database. Fix any route where the text is missing.
3. On React + Vite, run the outcome test on two deep pages before deciding anything. If ChatGPT search and Perplexity quote your text after a week, the pre-rendering is doing its job.
4. If they do not, or if you need curl and your SEO tools to see what crawlers see, add build-time prerendering for the public routes. Plan a TanStack Start upgrade when you next have a quiet week for testing.
5. After any change, add a deploy check that fetches three key URLs without JavaScript and fails if the word count drops under 150.

I work as a fractional head of growth for B2B software companies, and rendering is the first thing I check in an AI Search Audit, from $2,000 for one week. Send me your URL and I'll check which stack it runs on and what a plain fetch returns before we talk.

Re-check by 1 February 2027: Lovable's rendering documentation and dates, whether Lovable documents how it verifies crawlers, any new crawler documentation on JavaScript rendering, and the 15-route list on my own site.