The short answer
Open the Code view in Canvas, take the HTML out, and hand it to an agent that can read your files. It publishes through Birta and you get an address that behaves like any other website.
Canvas will not hand you a site file with a download button. Google's own help lists exports to Docs, to Slides and to Colab, and none of those is the page you built. What it does give you is the code itself: "To open and edit the code, at the top right of the Canvas panel, click Code." So the file exists, it just has to be copied rather than downloaded.
Get the code out of Canvas
- Step 1Open CodeTop right of the Canvas panel. The HTML is there in full.
- Step 2Copy all of itEverything, including the styles and scripts in the same file.
- Step 3Save it as index.htmlOne file, in an empty folder on your machine.
- Step 4Look for what is missingAny image or font the page loads from somewhere else.
Canvas usually produces one self-contained file, which is the easiest case there is:
styles and scripts sit inside the HTML, so a single index.html is the whole site.
If the build was split into several files, the Code view shows them one at a time. Save each with the name it carries, keeping them beside each other in the same folder.
Why the share link is not the same thing
Canvas can produce a g.co/gemini/share link, and it is tempting to treat that as
publishing. It is not the same object.
That link points at a Gemini app, and Google is direct about what holding it means: "Anyone with the public link to a multi-user app can view and edit all data associated with the app." For a demo among people you know, fine. For something you put on a card, send to a client, or let a search engine find, you want a page nobody can edit and a domain that is yours.
A static file at a fixed address. Visitors read it, nobody can change it, the address does not depend on a chat session, and you can point your own domain at it.
Check the static boundary once
Three conditions, and a package that fails one is refused before anything is stored:
index.htmlat the root of what gets published, not inside a folder.- Every asset the HTML references, beside it or in subfolders matching those paths.
- Nothing that needs a server. No API keys expecting a backend, no database.
That last one is where a Canvas build most often stops. If Gemini wrote something that calls a model at runtime, the preview worked because the chat supplied the connection. Published on its own, it is a page with a broken button. Either take that feature out or accept that the published version is the static part.
What usually breaks
Images referenced but never copied. The preview showed them because it resolved
paths inside Google's own environment. Your folder has an img tag pointing at nothing.
Fix it by putting real files at those paths, or ask the agent to.
Base64 images making a small page enormous. Canvas likes embedding pictures directly into the HTML. It works, and it also turns a one-page site into a file several megabytes long. Ask the agent to pull them out into real image files.
Fonts loaded from somewhere that no longer answers. Check the page in a browser from your own folder before publishing. What you see locally is what visitors get.
A single quote or a truncated tag from copying. Rare, but it happens when the Code view is long. Opening the local file catches it in a second.
The prompt
For an agent with access to your files and to Birta, such as Claude Code, Claude Cowork, Cursor or Codex:
I have a page Gemini built in Canvas, saved at [path/to/index.html].
Before publishing, check and tell me:
- whether every image, font and script the HTML references actually exists in the folder
- whether anything in it needs a server or an API key at runtime
- whether images are embedded as base64, and how much of the file size that is
Fix what you can: pull base64 images out into real files, and drop or replace
anything that needs a backend, telling me what you changed.
Then publish it to Birta as a new project named [name] and give me the address.The order matters. You want the report before the address, because a page that publishes successfully with a broken button is worse than one that never published.
Update it later
Keep working in Canvas if that is where you are comfortable. When the page is better, copy the code out again and ask the agent to publish a new version. The address does not change, and everyone holding your link sees the update.
Old versions stay, so a change you regret is a rollback rather than a rebuild.
When Canvas is the wrong place to keep working
Once the page is live and you are making small edits, the round trip through Canvas starts costing more than it gives: copy out, save, publish. At that point let the agent edit the published files directly and leave Canvas for the next new thing.
If your build is not from Canvas at all, the AI-generated site route covers the other tools.
Bring the Canvas build, get a real address
Your agent checks the file, fixes what the preview was hiding, and publishes it.