How do I turn a ZIP file into a website?

Unzip it, confirm index.html sits at the top level, and publish the files. With an agent that can read your disk, that is one prompt: it unzips, checks the structure and the paths, publishes through Birta, and hands back the address.

Why does my uploaded ZIP show a file list instead of my site?

Because the archive has a wrapping folder, so there is no index.html at the root of what got published. Re-zip from inside the folder, or have the agent move the files up a level.

Can I upload a ZIP directly to Birta?

Not as an archive. Files arrive through the connector, so the agent unzips on your machine and writes the files into a draft. That is also what makes the structure check possible before anything goes live.

What if my archive is a builder export?

Open it first. Exports frequently contain template files rather than finished HTML, absolute URLs pointing at the old domain, or a database dump that only the original platform can read. What is publishable is the built static output.

Can I update the site later without re-uploading everything?

Yes. The agent edits the files in a new draft and publishes it; the address stays the same and the previous version remains available to roll back to.

ZIP to Website: Publish a Site from an Archive with an AI Agent

The short answer

Give the archive to an agent that can read your files and ask it to unzip, check where index.html sits, and publish through Birta. If the archive is wrong you hear about it before the link exists, which is the whole difference: nearly every broken attempt is the same mistake, an archive that wraps the site in a folder.

What a publishable archive contains

index.html at the top level of the archive, not inside a folder.
The CSS, JavaScript, images and fonts the page references, beside it or in subfolders that match the paths in the HTML.
Nothing that needs a server: no PHP, no .env, no build config waiting to be run.

Check the archive without unzipping it

One command lists the contents, and the first lines tell you whether you have a problem:

unzip -l site.zip | head -20

If the first entry is index.html, you are fine. If every line starts with the same folder name, like my-site/index.html, the site is one level down and a plain upload publishes a directory listing or nothing at all.

The prompt

For an agent with access to your files (Claude Code, Claude Cowork, Cursor, Codex):

I have an archive at [path/to/site.zip]. Unzip it into a temporary folder and
look at the structure.

Tell me before publishing:
- whether index.html is at the top level or nested inside a folder;
- whether any file references an absolute path like /style.css that would break;
- whether anything in there needs a server rather than being static.

If it is publishable, create a Birta project, write the files into a draft with
the same relative structure, publish it, and give me the address. If it is not,
tell me exactly which of the three checks failed.

That last instruction is the point of the page. An agent asked to publish will publish; an agent asked to check first tells you the entry page is nested, and you fix a one-line problem instead of debugging a live link.

The other prompts around this one, including the one that collects a client's remarks, are in AI website prompts.

The three things that usually break

A wrapping folder. You zipped the folder instead of its contents. Everything is one level too deep. The agent moves the files up; by hand you re-zip from inside the folder.

Absolute paths. The HTML asks for /style.css with a leading slash, which means "the root of the domain". That works when the site sits at the root and breaks the moment it does not. Relative paths (style.css, ./assets/logo.svg) survive being moved.

Something that is not static. A theme from a marketplace often ships PHP templates, a build config, or a package.json expecting npm run build. None of that runs on a static host. The build output is publishable; the source archive usually is not.

If the archive came from a builder export

Exports are the most common source of surprises. Expect one or more of: a database dump nobody can use without the platform, absolute URLs pointing back at the old domain, template files instead of finished HTML, and assets referenced from a CDN that stops serving them once the account closes. Open the archive and look before you plan a migration around it.

After it is live

Publishing through the agent leaves you two things a drag-and-drop upload does not:

Versions and rollback. Every publish stays addressable, so replacing a bad archive is choosing the previous version rather than re-uploading and hoping.
A review link that needs no account. Send the version's address and whoever gets it marks remarks straight onto the page, pinned to the element. Your agent reads those numbered threads and fixes them in the same draft; it cannot reply or resolve.

Publishing again from a corrected archive is the same three steps, and the address does not change.

What this path does not cover

Uploading the archive yourself, without an agent. Birta takes files through the connector, so the unzipping happens on your machine, in the agent's hands. A chat-only assistant with no access to your disk cannot do this one.
Archives that are not a website. A zip of PDFs or images is a file-sharing job, not a publishing one.
Anything needing a server, a database or authentication.
Payments on your own site. Not something Birta does yet.

A custom domain needs a Solo or Pro plan; on the free tier the site gets a Birta subdomain and keeps the "made in Birta" badge.

Publish the archive and keep the versions

The agent checks the structure, publishes, and every version stays one call away.

Connect your agent to Birta