Most agency websites start simple and grow messy. A blog turns into a tangle of one-off pages, case studies live as hand-built HTML, and the team forgets which fields a service page is supposed to have. The fix is a clear content model. In Acrosite, that model is built on three primitives: Posts, Pages, and Custom Content Types. Understanding when to use each one — and how Custom Fields keep them structured — is the difference between a site that stays maintainable for years and one that quietly rots.

This guide walks through the practical decision of Posts vs Pages vs Custom Content Types, shows how Custom Fields turn repeatable content like case studies and FAQs into consistent, predictable entries, and gives you a concrete example you can model your own setup on. It's written for agencies and content operators who manage many client sites, but the principles apply to any team running a Git-backed website.

The three building blocks

Acrosite is a Git-backed publishing platform: your content lives as Markdown or MDX files with YAML frontmatter in your own GitHub repository, and your team publishes through the dashboard instead of editing files directly. Every piece of content is a Content Item that belongs to one of three structural types.

  • Posts are time-based, chronological content. Blog articles, news updates, release notes, and announcements are all Posts. They have a publish date, they accumulate over time, and they're usually listed newest-first.
  • Pages are standalone, structural content. Your homepage, about page, contact page, and pricing page are Pages. They aren't chronological — they exist as fixed destinations in your site's navigation and don't pile up over time.
  • Custom Content Types are your own repeatable structures for everything that doesn't fit neatly into a Post or a Page. Case studies, team member bios, FAQs, locations, testimonials, and product entries are all good candidates for Custom Content Types.

The mental model is straightforward. If the content is dated and grows over time, it's a Post. If it's a unique, fixed destination, it's a Page. If you'll create many entries that all share the same shape, define a Custom Content Type.

When to use Posts vs Pages

The Post-versus-Page question trips up a lot of teams because both feel like "a page on the website." The clearest test is whether order and recency matter.

Use Posts when:

  • The content has a meaningful publish date.
  • Newer entries should generally appear before older ones.
  • You expect the list to keep growing indefinitely.
  • Examples: blog articles, company news, changelog-style updates.

Use Pages when:

  • The content is a permanent fixture in your site structure.
  • There's typically one of each, not an ever-growing list.
  • It lives in main navigation or the footer.
  • Examples: homepage, about, services overview, contact, privacy policy.

A useful rule: if you'd put it in a chronological feed, it's a Post. If you'd put it in the navigation bar, it's a Page. The few genuinely ambiguous cases (a "resources" hub, for instance) usually resolve once you ask whether visitors will browse it by date.

When a Custom Content Type earns its place

The moment you find yourself copying the structure of one Page to make another that looks almost identical, you've found a Custom Content Type. Repetition with a shared shape is the signal.

Consider an agency that publishes client case studies. Each one needs a client name, an industry, a hero image, a summary, the services delivered, a measurable result, and a body. If those are built as freeform Pages, every case study depends on whoever built it remembering all seven elements and formatting them the same way. Six months and three teammates later, half the case studies are missing the result and the images are inconsistent sizes.

A Custom Content Type solves this by defining the structure once. Every entry then prompts the author for exactly the right fields, in the right format, every time. The benefits compound across an agency:

  • Consistency — every case study, FAQ, or team bio follows the same structure, so the front end can render them reliably.
  • Speed — authors fill in fields instead of rebuilding layouts, which lowers the skill bar for non-technical contributors.
  • Maintainability — when you need to add a field (say, a "video URL"), you change the type once and every entry can adopt it.
  • Clean data — because the frontmatter shape is predictable, your Next.js or other Git-backed framework can query and template it without surprises.

You can read more about how this works on the Custom Content Types feature page.

How Custom Fields give structure shape

A Custom Content Type is only as good as the Custom Fields that define it. Custom Fields are the typed inputs that make each entry structured rather than a blob of free text. Acrosite supports field types such as text, rich text, image, and dedicated SEO fields, among others. Choosing the right type for each field is what keeps content clean.

  • Text fields are for short, single-line values: a client name, a location, a job title.
  • Rich text fields are for formatted body content where headings, lists, and links matter.
  • Image fields capture a specific asset — a headshot, a logo, a hero image — with a consistent slot rather than an inline upload.
  • SEO fields hold the metadata (title, description) that your framework reads to populate meta tags.

Because each field is typed, authors can't accidentally paste a paragraph where a date should go, and your templates always know what to expect. That predictability is what makes a Git-backed site genuinely maintainable as the team and the content both grow.

A worked example: a Case Study type

Here's how a Case Study Custom Content Type might be defined, and what a single Content Item's published frontmatter could look like once committed to the repository:

---
title: "Rebuilding the storefront for Northwind Retail"
client: "Northwind Retail"
industry: "E-commerce"
hero_image: "/images/case-studies/northwind-hero.jpg"
services:
  - "Web design"
  - "Performance engineering"
result: "38% faster page loads"
seo_title: "Northwind Retail Case Study | Acme Agency"
seo_description: "How we cut load times and lifted conversions for a national retailer."
date: "2026-06-01"
status: "published"
---

Northwind came to us with a slow, dated storefront...

The corresponding fields in the type would be: a text field for client, a text field for industry, an image field for hero_image, a repeatable text list for services, a text field for result, SEO fields for the metadata, and a rich text field for the body. Define it once, and every future case study follows the same blueprint.

Keeping a multi-site agency maintainable

Acrosite's structure is built for agencies running many sites. A Workspace contains Projects; each Project maps to a single Client website and its connected repository, and Clients group related work. That means a Custom Content Type defined for one Client's site is scoped to that Project — you can tailor a "Locations" type for a multi-branch business and a "Authors" type for a publication without the two interfering.

A few practices keep the model healthy over time:

  1. Decide the content types before you start producing content, not after the mess appears.
  2. Name fields clearly and consistently so any Team Member can pick up an entry.
  3. Use the right field type for each value rather than defaulting everything to text.
  4. Keep Pages for true one-offs and resist the urge to rebuild repeatable structures as Pages.
  5. Plan your content path (for example, content/case-studies/) so the committed files stay organized in the repo.

Once the model is in place, the rest of the workflow follows naturally. Drafts stay private in the app until they're ready; Client Reviewers can approve content through the Review Queue without touching GitHub; GitHub publishing commits the file with its frontmatter to the configured branch and path; and the Content Calendar plus Scheduled publishing let you line everything up in advance. Publish Logs and Deployment visibility record what happened on each release.

Tip

When you onboard a new Client, copy your standard set of Custom Content Types as a starting point, then trim or extend fields to fit that site. It turns setup from a half-day of guesswork into a short checklist.

A clean content model isn't glamorous, but it's the foundation everything else rests on. Get Posts, Pages, and Custom Content Types right at the start, lean on Custom Fields to keep entries structured, and your sites stay easy to manage no matter how much content — or how many clients — you add. To see how the pieces connect, browse the full features overview or explore ready-made templates to start from.

Frequently asked questions

Posts are dated, chronological content like blog articles; Pages are standalone, fixed destinations like a homepage or contact page; and Custom Content Types are your own repeatable structures, such as case studies or FAQs, that share a defined set of fields across many entries.
Create a Custom Content Type whenever you'll produce multiple entries that share the same shape. If you find yourself copying one Page's structure to build another nearly identical one, that repetition is the signal to define a type with Custom Fields so every entry stays consistent.
Custom Fields are typed inputs and include options such as text, rich text, image, and dedicated SEO fields, among others. Choosing the right type for each value keeps your content structured and ensures your templates always know what to expect in the frontmatter.
Your content lives in your own GitHub repository as Markdown or MDX files with YAML frontmatter. Publishing through Acrosite commits the file to the connected repository on the configured branch and content path, and Publish Logs record each step without exposing tokens or raw provider details.
Yes. A Workspace contains Projects, and each Project maps to one Client's website and repository, so a Custom Content Type you define is scoped to that Project. You can tailor types per site without one client's structure affecting another's.