Your AI-built page works in the chat but breaks once you host it

This is the most common disappointment in the whole AI-to-published pipeline. The thing worked in front of you, you exported it, you hosted it, and now a button does nothing or the screen is white.

Almost always the page did not break — it lost something the chat environment was quietly providing. Here is what, roughly in order of how often it is the answer.

1. It was calling the AI, and now it cannot

If your artifact did anything intelligent at runtime — summarising, answering, generating text as the visitor used it — it was calling a model through the host environment. Exported and hosted elsewhere, that channel is gone, and the feature that made the thing impressive is the first to die.

This is also why Anthropic requires viewers to sign in for AI-powered artifacts specifically, while ordinary published ones open for anyone. Covered in more detail in sharing a Claude artifact.

There is no client-side fix. Either keep it in the chat, or give the page a backend of its own — which is a different project from hosting a file.

2. An API key that cannot travel

If the AI wrote code holding a key, hosting it publishes that key to anyone who views source. Some models refuse and leave a placeholder, which means the hosted page calls an endpoint with the string YOUR_API_KEY_HERE and fails.

Treat a key in client-side code as broken by design rather than as a bug to patch. Anything needing a secret needs a server holding it.

3. CORS

A page fetching a third-party API from a browser only works if that API allows your origin. Chat previews often run under permissions a plain website does not get, so a request that succeeded there is refused once the page is on a normal domain.

The signal is a console error mentioning Access-Control-Allow-Origin, and the fix is on the API side, not yours — which usually means choosing an API that permits browser calls, or putting a server in between.

4. Assets that were never inside the file

Images, stylesheets or scripts referenced as separate files will not survive on their own. For a single shared file this is absolute: each upload gets its own link, so a relative src is resolved as a different share rather than a neighbouring file.

The fix is to make the file self-contained — CSS and JavaScript inlined, images as data URIs — or to publish the set as a mini-site, where authored paths are preserved.

5. Module scripts and bare imports

Code using import statements needs those modules to resolve. Bare specifiers like import x from "react" do not resolve in a browser without a bundler or an import map, and a relative import points at a file that is no longer beside you.

If the page is blank with a console error about module specifiers, this is it. Ask the model to rewrite it without imports, or to include the libraries from a CDN.

6. The page is fine and the server is lying

Worth ruling out before rewriting anything: if the browser shows your source code instead of the page, or downloads it, nothing is wrong with the file at all — the host is sending the wrong content type. One curl command tells you.

Diagnosing it quickly

• ✓Open the browser console first. Blank page plus a module error is cause 5; a CORS message is cause 3; a 404 for an image is cause 4.
• ✓Nothing in the console but a dead feature usually means cause 1 or 2 — the page loaded, the call did not.
• ✓Source code on screen instead of the page is cause 6, and no amount of editing the file will fix it.
• ✓Best prevention: ask for "a single self-contained HTML file with no backend and no API keys" before generating, rather than repairing afterwards.