Moving a Tilda Site to an Agent-Maintained Birta Site

When people say "migrate a Tilda site," they usually mean one of two different jobs. One is mechanical: export the site as files and feed those files into whatever comes next. The other is what actually happens when the destination is an agent-maintained site: your agent looks at the live Tilda site, rebuilds the content and structure as a new site, and publishes that to Birta.

This is about the second job, because it's the one Birta does. The first job isn't the platform's work at all. Birta has no Tilda exporter, isn't planning one, and never opens a Tilda link itself. Your agent is the part that does that: a web-capable agent reads the published site and reduces it to static files, and that is the closest thing to an export you'll get on this route. What it hands back is the rendered site rather than the Tilda project, and the FAQ at the bottom is precise about where that falls short.

What follows: what to check before you start, what the move actually looks like, what happens to your URLs and search ranking, and what changes about the day-to-day work once the site is on Birta.

Before you start

A migration is worth doing when it has a concrete reason behind it, such as a cost, a missing capability, or a workflow that's genuinely broken. Before you commit a client to it, look at what the current site is actually doing, because a few things don't carry over automatically:

• Custom code blocks. Tilda's Zero Block and embedded HTML/JS let people drop in fairly arbitrary markup. Your agent needs to see that code directly, because screenshots of the rendered result aren't enough for it to reproduce the behavior, only the look.
• Third-party embeds. Booking widgets, chat widgets, maps, and similar third-party scripts need to be re-added by hand, the same way you'd add them to any new site.
• The exact contact form and its submission history. There's no import path for a Tilda form's configuration or the leads it already collected. Birta has its own lead-capture forms, so your agent can build a new, working form as part of the rebuild, but that's a fresh form, not a copy of the old one. Anything a client needs from past submissions has to be exported from Tilda first, separately.

None of this means don't do it. It means know what you're rebuilding before you start the clock on a client's site.

What the move actually looks like

The destination is one thing: Birta. Not a menu of CMS options, and not a mechanical conversion. In practice, it runs as one continuous conversation with your agent rather than a sequence of separate tools.

1. Step 1Review the live siteOpen the Tilda site and note its pages, sections, navigation, and anything custom, including code blocks, embeds, and forms.
2. Step 2Brief the agentPoint it at the live site (or your notes) and describe what needs to carry over, section by section, the way you'd brief a designer.
3. Step 3Let it rebuild the pagesThe agent produces the new site as ordinary files. It isn't importing a Tilda export, it's recreating the structure and copy you described.
4. Step 4Publish itThe same conversation publishes the finished files to a live Birta address, the way any new Birta site goes live.
5. Step 5Reconnect the domainIf the old site used a domain you control, point it at the new project instead.

The domain step uses the same DNS setup as any other Birta project. Apex vs. www, which record type, why verification sometimes stalls: all of it is covered in full in connecting a custom domain. Skip straight there once the site itself is live and you're ready to point the domain at it.

URLs, SEO, and what carries over

This is the part worth being precise about, because the honest answer is less convenient than a slogan.

Birta has no redirect or URL-mapping feature. There's no way to tell it "this old address now serves from here"; nothing maps a former Tilda URL to its new location automatically. That matters because Google's own guidance on site moves is specific about what actually preserves ranking signal: permanent redirects, kept in place for at least a year, while Google recrawls and reindexes both the old and new URLs. Without that, a page that moves address is closer to a new page than a moved one, as far as ranking history goes.

The one lever you do have: Birta publishes whatever path structure the published files use, so the agent can give the rebuilt pages the exact same paths the old Tilda site had, same /about, same /services, whatever the old structure was. That doesn't replace a redirect, but it means a search engine (or a bookmark, or a link from another site) that already points at /services keeps finding the right page instead of a broken one. Ask for this explicitly when you brief the agent; it isn't automatic just because it's possible.

What changes day to day

Tilda edits happen in its visual editor. You open Zero Block or the page canvas and change things directly. A Birta site doesn't have a canvas to open; edits go back through the same conversation you used to build it. You ask for the change, the agent publishes a new version, and that version goes live.

That's a different rhythm, not a worse one. The mechanics, how a prompted edit turns into a published version, why the old page sometimes still shows up right after publishing, and how to undo a change you don't like, are covered in updating a live website without redeploying the whole site. The short version: publishing keeps every version, so a bad edit gets undone by restoring the one before it, not by patching it back by hand.

Frequently asked questions