When AI Can't Read Your Page, It May Read Your Metadata Instead

A colleague recently asked me to review a product ahead of its public launch and assess how the company was positioning it. Before reading the company's marketing copy, I did what I often do when investigating an unfamiliar product. I gave Claude the website URL and asked it to explain the product.

What Claude Was Actually Reading

Claude answered, and its answer confused me. It described the company as serving small and medium-sized businesses in Europe — which wasn’t what I understood the company was trying to communicate. The company was working to expand into the US market, and I knew that going in. So I challenged Claude to explain where that description came from.

Claude then told me what it was actually looking at. The site, it explained, runs as a single-page JavaScript application. The initial HTML response didn’t contain the web page copy a visitor sees after the browser runs the JavaScript.

Some sites work this way by design. The server sends an HTML shell and a bundle of JavaScript; the browser runs that code and constructs the visible page. A retrieval tool that reads only the initial response may never receive the resulting copy. On this site, Claude found the title, the description, and a few other tags — but not the body content. Claude pointed to two of those tags specifically: the meta description and the Open Graph description, nearly identical, one line each — both describing that same European customer base, written for search engines and social-media link previews rather than for a reader trying to evaluate whether to hire this company.

So I copied the entire page — the actual marketing copy, not the URL — and gave that to Claude instead.

From the metadata, Claude described a company that helps European SMEs make their content AI-ready. That wasn’t what the company was trying to communicate. It wanted to reach businesses in the United States and beyond. After reading the page copy I provided, Claude described a broader argument: AI is already consuming a company’s content whether the company prepared it or not, and the quality of that output depends on how well the content is structured. The company delivered this through a staged program — assess, define, transform — that didn’t require adopting a new authoring standard first.

None of those distinctions appeared in the initial HTML. To a tool that never ran the site’s JavaScript, this company was two sentences long — and, on the question of who it served, those two sentences said something the company itself didn’t say.

What This Means

I don’t think the company made an unusual mistake. Many sites render their content in the browser rather than sending it fully formed from the server. Whether an AI retrieval tool can read that content afterward depends on a separate decision: whether the server also produces a readable version for tools that don’t execute JavaScript. That decision is usually made once, by engineering, when the site is built — and rarely revisited by whoever writes or approves the marketing copy. I noticed the gap only because I asked an AI to summarize the company before reading the site myself. Other people evaluating the company could do the same, and get the same incomplete answer.

The stakes here weren’t abstract. The company was working to expand into the US market. I was reviewing it from the US. Claude, working only from the metadata, positioned the company as Europe-focused when it was trying to reach businesses in the United States and beyond. A prospective US customer running the same search, or an AI assistant evaluating the company on that customer’s behalf, could have reached the same conclusion.

The site was built with Lovable, an AI-powered platform that generates websites and apps from written prompts, which makes the cause harder to identify. Lovable now uses server-side rendering by default for projects created after May 13, 2026, built on a framework called TanStack Start. Older projects, built on React and Vite, are pre-rendered on request instead — but only for verified crawlers; human visitors still receive the client-side application.

In this situation, Claude, apparently received that client-side application. I can’t say why. Perhaps the project predated Lovable’s current architecture or maybe the request wasn’t recognized as a verified crawler. Or perhaps the pre-rendering may failed for that request.

Server-side rendering could have made the page’s actual copy available in that initial response. A meta description that matched the page’s actual intended audience — instead of naming the wrong region — would have given Claude a more accurate account even with the body copy inaccessible.

Structured data could have added machine-readable facts about the company (product, for example), but it wouldn’t have exposed the full argument or explained the staged program the company plans to offer. Those details lived in the website copy itself.

The experiment made me wonder who was responsible for the machine-readable version of this company’s pitch — and whether anyone had reviewed it as content.

Tech writers already verify procedures, terminology, and examples before publication. They should also review the page’s title, description, structured data, and the content available before its JavaScript runs.

My experiment began as a positioning review. It ended with two descriptions of the same company: the one prospective customers could see and the one Claude could retrieve. The visible page addressed a broad market. The metadata positioned the company as serving small and medium-s