Can ChatGPT and Claude Read Websites Built With Lovable, Base44, Bolt, and v0? A Controlled Retrieval Test

AI site builders can produce polished pages very quickly. The harder question is whether AI agents can actually retrieve the content behind those pages.

I tested that by building the same page across Lovable, Base44, Bolt, v0, and a static HTML control. I then asked ChatGPT and Claude the same three questions about each page.

The result was clear.

• Every implementation exposed enough in the title and meta description for topic recognition
• Reliable body retrieval depended on whether the deployed page returned meaningful HTML in the initial response
• Some builders could produce retrieval-friendly output, some could not
• One improved retrieval with a hack that worked for the test page but does not scale cleanly
• This is a controlled retrieval test on deployed output, not a ranking study or a reverse-engineering claim about ChatGPT or Claude internals

I spent years working on rendering and discoverability problems at Wix, one of the largest JavaScript website platforms on the web. That background is why I wanted to test this in a controlled way. This is not a generic review of AI site builders. It is a narrower test of what an AI agent can actually retrieve from the deployed page.

Executive Summary

• I built the same page across Lovable, Base44, Bolt, v0, and a static HTML control.
• The page contained invented facts not found anywhere else online.
• I tested whether ChatGPT and Claude could retrieve:
  • the page topic (from the title and meta description)
  • a number from a table in the page body
  • a specific statistic buried in paragraph text
• Every implementation exposed enough in the title and meta description for topic recognition.
• Reliable body retrieval aligned with meaningful HTML in the initial response.
• The most useful product difference was not just who passed first. It was who could produce retrievable output when asked to make the page visible without relying on JavaScript.

The Questions This Experiment Answers

This test answers a few practical questions that site owners actually care about:

• Can AI agents still understand what my page is about, even if the page relies heavily on client side rendering?
• Does a correct summary mean the agent can actually read the body content?
• Which builders can produce output that is retrieval friendly when asked?
• Which builders leave you dependent on workarounds?
• If I am stuck on a builder with weaker body retrieval, can the title and meta description still help?

Test Design

I created the same page on five implementations: a static HTML control, plus versions built with Lovable, Base44, Bolt, and v0.

The page was a fictional field guide about the Veloran Crested Ibex. It included invented facts, a population table with specific numbers, and a paragraph level statistic. None of this information existed elsewhere online. That matters because a correct answer strongly suggests the agent retrieved the page itself rather than relying on prior knowledge.

I then asked ChatGPT and Claude the same three questions in fresh chats.

Questions used

1. What is this page about?
   Expected answer: a fictional field guide about the Veloran Crested Ibex

2. According to the population survey table on this page, what was the confirmed count in 2023?
   Expected answer: 288

3. On this page, what correlation did Torvik find between stone tower height and mating success? Please include the exact numbers.
   Expected answer: r=0.72, n=84

This layered design matters. A page can pass the first question and still fail the second and third.

Scope

This is a retrieval test, not a ranking study.

It does not prove how every AI retrieval system works internally. It does not prove that every client rendered page will always fail. It shows something narrower and more practical: in this test, the agents could read the title and meta description from every implementation, but body retrieval only worked when meaningful HTML was present in the initial response.

What Each Builder Produced

Title and meta description were readable everywhere. Body content was not.

Why That Difference Matters

This is where many people get fooled. A page can look complete in the browser, expose a good title and meta description, and still fail when an agent is asked for something that lives only in the page body. That means a correct page summary is not proof that the agent can actually access the content you care about. In this test, metadata success was a weak proxy for real retrieval success.

What the Agents Could Retrieve

1. Title and meta description (topic recognition)

Every implementation exposed a title tag and meta description that the agents could read. This is the easy part — even CSR apps inject these into the static HTML shell before JavaScript runs.

This matters because it shows that even when body content is not available, page level signals can still carry topic information.

2. Table retrieval from the page body

The second question targeted structured content in the page body. The correct answer was 288.

This is where the gap became obvious. The table was visible to a human visitor, but not reliably retrievable across all implementations.

These screenshots are from before Lovable applied its workaround. ChatGPT on the Lovable page. It thought for over a minute, then refused to guess:

The same question on the Bolt Astro version. Five seconds:

3. Paragraph level fact retrieval

The third question targeted a specific statistic buried in paragraph text. The correct answer was r=0.72, n=84.

Same pattern. Same content. Same questions. Different retrieval outcome based on what the deployed page returned.

Again, before Lovable’s workaround. ChatGPT searched the Lovable page for “Torvik,” “tower,” “mating,” and “stone.” Zero matches:

On the Bolt Astro page, it quoted the exact line:

What Changed When I Asked the Builders to Fix It

There is an entire ecosystem of prerendering and static generation solutions. That is not what this test is about. The point here is narrower: what could the builders themselves produce when asked to make the content visible without requiring JavaScript? That is where the biggest product differences showed up.

Bolt — passed (rebuilt to Astro)

• Test URL: csr-test.bolt.host
• Stack: React + Vite (initial), then Astro after prompt
• Default output: CSR shell. Failed body retrieval.
• When asked to make it SSR: Rebuilt the entire project in Astro. The output changed from a JS-rendered SPA to a static site with content baked into the HTML. Both agents passed all three questions after that. This is a real architectural fix. Full disclosure: Astro SSG on Cloudflare Pages is the same stack I use for this site.

Lovable — passed (hacky workaround)

• Test URL: csr-test.lovable.app
• Stack: React + Vite
• Default output: CSR shell. Failed body retrieval.
• When asked to make it SSR: Injected static HTML into the <div id=”root”> shell using noscript-header class names. ChatGPT found the data after this change, but still identified the page as “loading as a client-rendered app” and took over 60 seconds to extract the answer (compared to 5 seconds on Bolt’s Astro version). This is a hardcoded workaround, not a rendering architecture change. It does not scale to dynamic routes, API-driven content, or sites with more than a handful of pages.

Base44 — failed (no SSR support)

• Test URL: csr-test.base44.app
• Stack: React 18 + Vite
• Default output: CSR shell. Failed body retrieval.
• When asked to make it SSR: Told me directly that SSR is not possible on the platform. “Base44 apps are React SPAs. There’s no way to add server-side rendering without switching to a different framework, which isn’t supported here.”

v0 — passed (SSR by default)

• Test URL: v0-csr-test.vercel.app
• Stack: Next.js 16 + React 19
• Default output: SSR. Content present in initial HTML response.
• No fix needed. Both agents passed all three questions on the first try.

What the HTML Difference Looked Like

The core variable in this experiment was not the brand name of the builder. It was what the deployed page returned before any browser style rendering step.

In the weaker cases, the initial response mostly exposed the shell.

<body>
  <div id="root"></div>
</body>

In the stronger cases, the initial response already contained the heading, paragraph text, and table content.

<body>
  <h1>The Veloran Crested Ibex</h1>
  <p>...</p>
  <table>
    <tr><td>2023</td><td>288</td></tr>
  </table>
</body>

That difference is the mechanical center of the whole article.

What This Test Shows

This test supports four practical conclusions.

• Topic visibility is easier than body visibility.
  A page can expose enough signals for an agent to identify the topic while still failing body retrieval.

• Metadata success is not proof of content access.
  A correct summary can hide a deeper retrieval failure.

• The real product difference is fixability.
  The important question is not only what the builder produced first, but whether it could produce retrieval friendly output when asked.

• Not all fixes are equal.
  A hardcoded shell injection can make a page fetchable for a narrow case. That is still very different from a clean output model that scales.

I understand why these builders haven’t addressed this yet. They are growth-stage companies focused on shipping features and acquiring users. SSR is a maturity investment, not a growth lever. That tradeoff makes sense at their stage. But at some point they will have to address it, or their users will keep hitting this wall. I dealt with this firsthand at Wix, where we spent thousands of engineering hours building and maintaining SSR infrastructure for millions of sites. It’s expensive. It adds latency. It breaks in ways you don’t expect. But there’s no shortcut: if the content isn’t in the HTML, crawlers can’t see it.

That said, the responsibility here is shared. AI builders need to produce retrievable output, but AI companies also need to invest in reading the web as it actually exists. Google understood this. They didn’t build their Web Rendering Service out of kindness. They built it because they understood that to be the internet’s library, you need to be able to read JavaScript-rendered sites. It took them years and enormous infrastructure investment, but they did it because the alternative was an incomplete index. If OpenAI and Anthropic want their agents to give users the best available knowledge, they face the same choice. Right now, their retrieval bots behave as raw HTML fetchers. That’s a legitimate engineering tradeoff at this stage, but it means a meaningful share of the web is harder for them to access. Both sides have work to do.

What This Test Does Not Show

This article does not claim that every client rendered page always fails, or that ChatGPT and Claude never execute JavaScript under any circumstances. It does not evaluate external prerendering tools or static generation services, and it does not measure ranking, citation frequency, or referral traffic. The point is narrower: in this controlled setup, body retrieval aligned with meaningful initial HTML, and the builders differed in whether they could produce that output themselves.

Practical Takeaways

If your page only needs a basic topic signal, you still have some useful levers even on weaker implementations.

• Use a clear title.
• Write a strong meta description.
• Use a descriptive URL.

That last point is my recommendation, not part of the formal test. But it follows the same logic. If an agent cannot fully access the body, every clear signal about page topic becomes more important.

If the page needs real retrievability, not just topic recognition, the safer rule is stricter: make sure the important content is present in the initial response. That does not mean every site needs the same architecture. It does mean you should know whether your builder can produce retrieval friendly output when it matters, or whether you are depending on a workaround.

The simplest test you can run right now:

curl -s https://your-site.com | grep -c '<div id="root">'

If the result is 1 and the rest of the body is empty, your important content may not be reachable by AI retrieval systems.

Who Should Care Most

This matters most for pages where discoverability actually matters:

• landing pages
• product pages
• help content
• articles
• branded pages you want agents to understand beyond the title

For internal tools, dashboards, and private workflows, none of this matters.

Final Take

The main lesson is not “AI builders are bad.” It is that fast generation and good retrieval are not the same thing. All implementations could signal what the page was about. Only some could reliably expose what was actually inside the page. The more interesting difference was not just the initial result. It was which builders could produce retrieval friendly output when asked, and which ones left you with a workaround instead of a real solution.