How do I turn a ZIP file into a website?

Unzip it, confirm index.html sits at the top level, and publish the files. Uploaded to Birta's chat, or handed to 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?

Yes. Upload it to Birta's chat: its agent unzips it, checks the structure and the paths, and writes the files into a draft. Your own agent does the same through the connector, unzipping on your machine. Either way the structure check happens 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

Upload the zip to Birta's chat, or give it to an agent that can read your files, and ask it to unzip, check where index.html sits, and publish. 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

In Birta's chat, attach the zip and send the prompt with the path line dropped. For an agent with access to your files (Claude Code, Claude Cowork, Cursor, Codex), send it as is:

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, then replies in each thread and resolves it.

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

What this path does not cover

Publishing the archive without any agent. The zip goes to Birta's chat or to your own agent; either one unzips and checks it. A third-party chat assistant that can neither read your disk nor take the file through Birta 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.

Your own domain works on the free plan, which keeps the Birta mark on the page; removing the mark is the Team plan.

Publish the site and keep the versions

Upload the zip to Birta's chat and its agent checks and publishes it. Or connect the agent you already use.

Start in Birta