The short answer
Google Sites is free, and the part most people expect to pay for is free too. If you already own a domain, you connect it from the site's own settings at no cost, and Google's documentation puts the ceiling at five domains per site. Birta charges $12 a month before it will connect one at all. That row goes to Google.
What the $12 buys is a different surface. On Birta the connection to the agent you already talk to is how the product is used, not a second door onto a dashboard, so one connection reaches the draft, the published version at its own address, the way back to an earlier version, the declared lead form, and the remarks a reviewer pinned to the page.
On Google Sites all of that sits inside the editor. Google's Sites API carries the notice "Sites API is deprecated and might stop working at any time. Sites API can only access classic Sites," and classic Sites is the version Google replaced in 2016. Google's own Workspace MCP server, in public developer preview since May 2026, exposes Gmail, Drive, Calendar, Chat and a contacts directory. Sites isn't on the list. So the history, the sharing and the publish button are all things a person opens in a browser after signing in.
That makes the fork short. If a person is doing the editing, Google Sites is a good free tool. If an agent is doing it, the whole life of the site after the files exist is on Birta's side of the line.
What each side actually costs
Google Sites is free on an ordinary Google account, with no plan and no trial. It's also included on every Google Workspace tier, which Google's pricing page listed in September 2026 as Starter at $7 per user per month, Standard at $14, and Plus at $22. Nothing on that page is a Sites-specific charge, and there is no add-on to buy for the custom domain. Paying for Workspace buys you Gmail on your domain and the rest of the suite. Sites comes along with it.
The only thing a subscription is required for is buying a new domain through the Publish dialog, which routes you into a Workspace plan. A domain you already own needs nothing.
Birta's numbers are simpler and higher. The free tier publishes at a Birta address, with 50 projects at 25 MB each, 10 readable form submissions per project per month, and a "made in Birta" badge on every published page that can't be switched off. Solo is $12 a month: one custom domain, 100 MB per project, 100 leads a month, badge gone. Pro is $39 a month: five domains, 200 MB per project, no lead cap.
What the free tier does not gate on our side is any of the agent-facing work: drafts, versions, rollback and the whole review round run on it. Solo buys the domain, the headroom and the badge coming off.
Check both against the current pages before deciding anything. Prices move, Google's faster than ours.
How far an agent reaches on each side
Google Sites is edited through its own interface, and everything that interface owns stays there. Restoring a version, sharing the site with someone, publishing a change: each one is a person signing in and clicking. There is no documented, supported way for a program to do any of it. The Sites API exists, but it's deprecated, and by Google's own description it "can only access classic Sites," a product retired years ago. Nothing replaced it for the current version.
Google has been moving toward agents everywhere else, which makes this specific rather than general. Its Workspace MCP server started rolling out on 1 May 2026 in public developer preview, giving agents real tools for Gmail, Drive, Calendar, Chat and a contacts directory. Five products. Sites is not one of them. That could change, and if it does this page changes with it.
Birta is built the other way round. There is no editor to open, because the connection is the product. The same conversation creates the project, writes the files, publishes a version, rolls back to an earlier one, connects a domain, reads the leads that came in, and reads the remarks a reviewer left on the page. Nothing on that list stops at the edge of the connection and waits for somebody to sign in. If you haven't met the idea before, here's what an agent connection actually is.
What Birta leaves to the agent
Birta imports nothing. It doesn't read a Drive folder, doesn't open a Google Doc, doesn't unpack a Takeout archive, doesn't fetch a page by link, and none of that is on the roadmap. Written flat like that it reads like a gap, so it's worth noticing which side of the connector it sits on.
That same Workspace MCP server, the one with no Sites tools in it, does cover Drive. Your agent can open the export, read the document the copy lives in, take the images out of the folder they're already in, and write the whole thing out as HTML. That half of the job has tools today, from Google, and Birta building a worse second version of them would help nobody.
The half with no tools is publishing. That's the one Birta supplies: a public address, a version saved for every publish, a way back to an earlier one, a page a reviewer can mark up, a lead form, a domain, a daily visitor count.
Compare the work after the first publish
| Decision | Google Sites | Birta |
|---|---|---|
| Best fit | A page a person edits by hand, inside Google's own tools | A static commercial site an agent builds and keeps updating |
| Building the site | Google's themes and layouts, with an embed block for your own HTML, CSS or JavaScript | An agent produces the files; Birta never edits the design |
| What an agent can reach | Nothing documented. The Sites API is deprecated and reaches only classic Sites, and Google's Workspace MCP server doesn't cover Sites | The whole surface from one connection: the draft, the published version at its own address, rollback, a domain, the leads, the review remarks |
| Publishing a change | Open the editor, change it, publish | Re-publish through the same agent conversation |
| Versions and rollback | Restore an earlier version of the whole site, or restore one page without restoring the rest | Every successful publish is a saved version; the last 10 stay visible, and any of them can go live again |
| Getting a review | Share the draft with someone's Google account as an editor, or switch on the Site info contact form, which is Workspace-only, needs the visitor signed in, and emails you their message with the page it came from | Each published version has its own address that opens with no account by default; remarks are pinned to elements on the page, and the agent reads them and edits the same draft |
| Lead form | Embed a Google Form, with no cap on responses and answers written to Sheets | The agent declares the form's fields directly; submissions show up in the project's Forms tab |
| Lead delivery | Google Forms' own notifications and its Sheets responses | Leads land in the project panel, and everyone with access gets one email digest roughly 15 minutes after the first lead; no Telegram, no webhook |
| Custom domain | Free. Connect a domain you already own, up to five per site | One included with Solo, five with Pro |
| Branding | No vendor badge | No badge on Solo or Pro; the free tier carries one that can't be turned off |
| Storage | Google publishes no per-site limit for Sites | 100 MB per project on Solo, 200 MB on Pro |
| E-commerce and payments | Not part of Sites | None. No payment acceptance of any kind for a site's visitors |
Two rows in that table go to Google outright. The domain is free where ours is paid, and the version history restores an individual page, which Birta can't do at all. Our history is also capped at the last 10 publishes; Google's documentation states no such limit.
They read differently once you ask who operates them. Google's restore is a person in the editor picking a page. Ours is one call your agent makes mid-conversation, next to the draft it is already editing and the remarks it just read back, which is where every other move on the site happens too.
Getting someone to sign off on the page
Google Sites is built for collaborators, not for reviewers. You can share the site with people, and they get editing rights or, on a restricted site, the Published Viewer role. Either way they need a Google account, and neither role lets them leave a comment on the page. Sites has no commenting the way Docs does.
There is one feedback path, and it's narrower than it sounds. Google's announcement of site feedback describes a contact option in the site info panel: "The feedback will be sent to the site owner by email," including the page it came from. Two conditions come with it. "Site viewers must be logged in to a Google account to share feedback," and "This feature is only available for G Suite domain-owned sites; it is not available for consumers and non G Suite organizations." So on a free personal account the answer is an email or a chat message, same as anywhere else.
Birta puts that round on the page. Every version has its own permanent address, handed back when the agent opens a draft and again when it publishes. It is the version's address, not the live site's, and it keeps working after publication, so it stays the link you send when you want an opinion rather than a launch.
By default anyone holding that address opens it without an account. The browser passes a signed handoff in the background and the visitor gets a nickname, which is what signs their remarks. They mark the remarks straight onto the page, pinned to the element they're talking about.
Your agent reads them back. Birta's own instruction to it is that the owner "may mark remarks on the page", and that it should then read them, "make the changes in this same draft, and tell them to refresh the same page." Each thread returns its number, the page and element it points at, whether it is still open, and every message with its author and time. Thread numbers don't change, so a remark can be named again a week later.
One limit, said plainly: the agent only reads. It cannot post a reply into a thread or mark one resolved, and an attempt to write is refused. Resolving is done in the browser by someone with project access. Everyone on the project also gets an email digest of new remarks roughly 15 minutes after the first one arrives, with their own remarks left out. Nothing here is gated by plan, and the versions and remarks guide is the walkthrough.
Stay on Google Sites when...
Stay when a person is doing the editing. That's the honest boundary. Google's editor is built for someone making visual decisions directly, and handing that person a conversation with an agent instead is not an upgrade.
Stay when the site lives inside Google's tools anyway. Embedded Docs, Sheets, Calendars and Forms are already there, already free, already signed in. Rebuilding that arrangement somewhere else costs you something and gains you nothing.
Stay when a Google Form is doing the job. It has no response cap, it writes every answer to a spreadsheet, and it costs nothing. Birta's form is a different shape rather than a bigger one: the agent declares the fields and then reads the submissions back, so the form and its leads stay with the site instead of living in a second product.
And stay when price decides it. Google Sites is free, and free is a real number.
Birta fits better when...
Birta fits once an agent is producing the site and the work left is publishing it, keeping it current, and handling what happens when someone fills in a form.
Choose it when the changes arrive as instructions rather than clicks. You describe the change, the agent edits the files and publishes again, and nobody opens an editor in between.
Choose it when a bad update has to be reversible without rebuilding from memory. Every successful publish becomes a version, the last 10 stay available, and any of them can go live again with the original files intact. Each one also downloads as a single archive.
Choose it when somebody has to approve the page before it counts. They open the version's address, mark the two things they'd change where those things actually are, and never sign in to anything.
Choose it when the page has to look like whatever the agent wrote. On Google Sites your custom code goes into an embed block inside Google's own layout. On Birta the site is the files, so there's no theme underneath it to work around.
And choose it when a real lead form belongs on the site and the submissions should sit with the project rather than in a separate spreadsheet.
The tradeoff is stated above and it's real: you'll pay $12 a month for something Google gives away, and Birta has no visual editor, no store, and no way to take a payment from your site's visitors. What the $12 covers is the surface one connection reaches, which is the draft, the version and its address, the rollback, the form and the sign-off round, none of it behind a sign-in.
Moving from Google Sites
Google will give you your content back. What it won't give you is a website you can host somewhere else.
Google's export runs through Drive and covers draft and published sites, themes, fonts, colors, logos, favicon, the text and images, embedded HTML, navigation, buttons, custom page paths and attachments. Google describes the result as an archive to keep or to use the data in another service, which is a fair description. It's source material, not a site.
So plan this as a rebuild.
- Step 1Export the contentPull the site's text, images, navigation and page structure out through Drive. Copy anything the export misses straight from the live pages.
- Step 2Rebuild through the agentHand the exported content and a description of the site to your agent, and have it produce the new static site from that material.
- Step 3Publish and verifyPublish through Birta, check every page and the form submission, then move the domain's DNS once the new site passes review.
The domain move is the least painful part. You already own it, and pointing it somewhere else is the same job you did to connect it to Google in the first place.
The decision
Google Sites is the right call whenever a person edits the site by hand. It's free, the custom domain is free, and it sits inside tools you already use. Most people reading a "Google Sites alternative" query should stay exactly where they are, or move to a builder with better templates.
Birta is the better fit for the narrow case Google can't serve at all: an agent builds the site, an agent maintains it, and the site needs somewhere it can actually be published, versioned, and given a working form.
Check your current agent path
Pick the tool you already use and verify the documented connection before moving any content or changing a domain.