Can I Add a Blog to an AI-Built Site? Yes, Two Ways
Yes, in one of two shapes. Either posts written straight into pages, where each new article is an edit at 3 credits, or a database-backed blog where Supabase stores the posts and the generated pages read them, so publishing afterwards costs nothing. Pick by how often you plan to publish.
That choice is the whole decision, and it is worth making before the build rather than after. Converting a handful of hardcoded posts into a database-driven feed later is possible, but it is a structural change, and structural changes are the expensive kind in any tool.
What are the two shapes, exactly?
The static shape means each post exists as a page in the project. The build generates the layout, and every new article is an edit that adds another page. Nothing is stored anywhere else, and nothing can break at read time because there is nothing being read.
The database shape means posts live in a Supabase table with fields like title, slug, body, and date. The generated site has an index page that lists them and a post page that renders one. Adding an article means adding a row, which happens outside the builder and therefore outside your credit balance.
Both produce real pages at a real URL, published to your-slug.zugo.run with a custom domain on top. The difference is not what a reader sees. It is who does the work when you publish for the twentieth time.
Which one should you pick?
Frequency decides it, with one secondary factor: who else touches the site.
| Situation | Better shape | Why |
|---|---|---|
| A few posts a year | Static pages | No database to set up, no rows to write |
| Weekly publishing | Database-backed | Publishing stops costing credits |
| Someone non-technical publishes | Database-backed | They add rows, they do not prompt |
| Posts need categories and filters | Database-backed | Filtering needs queryable data |
| Three case studies that never change | Static pages | A table would be ceremony |
| You want an archive that grows for years | Database-backed | The alternative accumulates pages forever |
The middle rows are the honest ones. Writing rows in a Supabase table is not as pleasant as typing into a familiar publishing interface, and if daily editorial work is the point of the whole site, weigh that seriously against a dedicated content platform. That comparison is in AI builder vs WordPress.
For most product sites, marketing sites, and portfolios, the static shape is enough for a year and the database shape is the upgrade you make once publishing becomes a habit rather than an intention.
What does adding a blog cost in credits?
Per action, so the arithmetic is available before you start.
| Action | Credits |
|---|---|
| Single build: site, app, or game | 6 |
| Multi-page platform, first three pages | 12 |
| Each additional page | 3 |
| Edit, including adding one static post | 3 |
| Hi-Fi build | 12 |
| Hi-Fi edit | 6 |
So a blog added to an existing site as an index plus two posts is three additional pages, or 9 credits. A site built from scratch with home, about, blog index, and post template is 12 plus one additional page, so 15 credits. A database-backed blog costs the same to build and then nothing per post, which is the entire argument for it.
The Free plan includes 5 credits once, which is less than one fresh build at 6, so a blog of any shape starts on a paid plan. Pro is $25 per month with 200 credits, roughly 16 full platforms or 33 quick builds. Business is $99 per month.
How do you prompt for a blog that works?
Say which shape you want, name the fields, and describe the index. Prompts that ask for "a blog" leave the builder to choose between the two shapes on your behalf, and it will pick one.
Weak: "add a blog to my site." Strong: "add a blog with an index page listing posts newest first with title, date, and a two-line excerpt, and a post page with title, date, and body. Store posts in Supabase with fields title, slug, body, published date."
The second version fixes the shape, the ordering, the fields, and both page layouts. If you want the static shape instead, say so explicitly: "three posts written directly into the pages, no database", and paste the actual text of the first post so the layout is designed around real content rather than placeholder length.
Add the practical extras in the same prompt while it is cheap: a link from the main navigation, a heading structure that starts at one H1, and a sensible URL pattern. Retrofitting navigation is an edit; asking for it once is free.
Will the blog actually get indexed by search engines?
The pages are real pages at real URLs, which is the necessary condition. What decides the rest is mostly outside the builder.
Connect a custom domain if the blog is meant to build authority, because a domain you own accumulates it and a shared subdomain does less for you. Connect Google Analytics if you want to know whether anyone arrives. Both are built-in connectors.
Then do the part no builder does: write things worth linking to, give each post a specific title that matches what someone would actually search, and link posts to each other. A blog of five posts that answer five real questions outperforms twenty that restate the homepage.
The database shape has one operational advantage here. When posts are rows, changing the layout of every post is one edit against one template, which means a design improvement applies to your whole archive instead of to one page. The domain setup is covered in our custom domain guide.
What are the limits worth knowing?
Four, and none of them are hidden.
There is no familiar editor screen. In the database shape you add rows in Supabase. That is fine for a technical founder and genuinely awkward for a marketing team that expects a publishing interface, so match the shape to the people.
Static posts accumulate cost. At 3 credits per edit, a weekly static blog is a recurring spend that a database-backed one avoids. Do that arithmetic before choosing convenience today.
Very specific features arrive through edits. Scheduled publishing, multi-author bylines, comment threads, and tag pages get built up in layers rather than delivered by one prompt. Zugo does not replace a development team on a genuinely complex product, and a full editorial system is closer to that end than most people expect.
Verification is narrow. Every build is booted in a sandbox before it reaches you, and a build that fails to load is reported as a failure rather than handed over. That lowers the risk of publishing a broken page. It does not remove it, and it does not check that your post reads well.
The sensible plan: start static, publish four posts, and see whether you keep going. If you do, move to the database shape and stop paying per article. The content-first version of this walkthrough is in how to build a blog with AI, and the structural cost model is in can AI build a multi-page site.
When you are ready, open Zugo, name the shape you want in the prompt, and paste your first real post into it rather than asking for placeholder text.