Archive a site

A site you are done with — a migration rehearsal, an abandoned copy, a customer who has left — can be archived. Archiving is reversible and deletes nothing.

What archiving does

• The site leaves your dashboard. It stays reachable from its own URL, and the dashboard offers a Show archived sites link.
• Every change is refused: editing, publishing, form submissions written through the API, and writes from API keys, MCP agents and installed apps alike. The refusal is the same wherever the request comes from, so an agent that still has the site’s URL cannot quietly keep working on it.
• Reading still works, including the content export. An archived site remains fully inspectable.
• The last published site keeps serving. Archiving stops new publications; it does not take down what is already live.

Archive a site

1. Open Settings for the site.
2. Find Archive this site.
3. Optionally write down why. The note is shown on the same page later, which is usually the answer to “what was this and why did we stop?”
4. Select Archive this site.

You need admin permission in the organization that owns the site. A site shared with you from another organization cannot be archived by you, however much access you were granted.

Restore a site

Open the site’s Settings and select Restore this site. It returns to the dashboard and accepts changes again immediately.

Through the API or an AI agent

The same actions are available to an API key and to MCP agents, with the same rules: an admin of the organization that owns the site, never through a share.

• MCP: archive_site (optional reason), restore_site, and get_site, whose lifecycle.status reads active or archived.
• REST: POST /api/v1/sites/{siteId}/lifecycle with { "action": "archive", "reason": "…" } or { "action": "restore" }; GET /api/v1/sites/{siteId}/lifecycle returns the current state.

While a site is archived, every other write through the API or MCP is answered with HTTP 409. Restoring is the exception, which is what makes it possible.

Removing an archived site’s media

Once a site is archived, its media can be deleted from your organization’s storage — the step before retiring the site for good. This is irreversible and requires the same owner-organization admin permission, and permanent deletion waits for it. Use the MCP tool purge_site_media or POST /api/v1/sites/{siteId}/media/purge. Objects that cannot be removed are reported and kept on record; run it again to retry them. Your Git repository and hosting project are not touched. See Media tools.

If the site still has a domain

Archiving is refused while a custom domain is live or verified on the site. That combination would leave the domain serving the last published version with no supported way to update it. Move or remove the domain first — see Custom domains — then archive.

The address Typeroll generates for a site before it has a domain (site-….<your sites domain>) does not block archiving. It belongs to your organization’s hosting, and like any address it keeps serving the last published version.

Deleting a site permanently

Archiving deletes nothing. When the site should be gone for good, an owner of the organization can delete it permanently once it is archived, through the API or an AI agent: review an inventory of exactly what is removed and what stays in your own accounts, then confirm it. Your Git repository, hosting project and DNS are not touched, and the last publication keeps serving from your hosting project until you remove it there. See Delete a site.

While a deletion is under way the site cannot be restored.

Check it

get_site reports lifecycle.status as archived, and the site no longer appears on the dashboard unless you select Show archived sites. The last published website still answers at its address.