Free-text pages are easy to start and hard to maintain. The first case study looks great, the second one forgets a field, and by the tenth nobody remembers what a case study is supposed to contain. The cure is Custom Fields structured content: instead of letting every entry drift into its own slightly different shape, you define the fields once and every entry inherits them. In Acrosite, Custom Fields sit on top of your content model and quietly enforce consistency without forcing anyone to touch Markdown or YAML by hand.
This guide explains why free-text content drifts, how Custom Fields fix it, and what that looks like in practice. We'll walk through four concrete examples — a case study, an FAQ, an author profile, and a service or location page — with the exact fields each one needs and a real frontmatter block you can model your own setup on. We'll also cover the consistency and SEO benefits, and where to stop so you don't over-engineer a content type nobody asked for.
Why free-text pages drift
A blank page is the most flexible thing you can give a content creator, and that flexibility is exactly the problem. When a case study is just "a page with some text," the structure lives only in the head of whoever built the first one. Everyone after them is reverse-engineering a pattern from an example, and small differences accumulate fast.
You've probably seen the symptoms:
- One case study has a measurable result; the next three don't.
- Hero images are different aspect ratios because nobody specified one.
- Some entries have an industry tag and some don't, so filtering breaks.
- SEO descriptions are present on half the pages and missing on the rest.
- A new teammate copies the wrong example and propagates an old layout.
None of these are dramatic failures. They're slow erosion. The site still works, but it stops being predictable, and predictability is what lets you template, filter, sort, and redesign content later without auditing every entry by hand.
How Custom Fields enforce structure
In Acrosite, content is organized into Posts, Pages, and Custom Content Types. A Custom Content Type is your own repeatable structure — case studies, FAQs, team bios, locations — and Custom Fields are the typed fields you attach to it. Each field has a type: short text, rich text, an image, a date, a boolean toggle, an SEO field, and so on. Individual entries are Content Items, and every Content Item of a type gets the same fields in the same order.
The shift is subtle but important. Instead of a blank canvas, the person creating a case study sees a form with labeled inputs: Client name, Industry, Hero image, Summary, Result, Body. They can't forget the result field, because the field is always there. They can't paste a 4000-pixel-wide image into an <img> tag, because the image field handles upload and reference. The structure is no longer tribal knowledge — it's part of the content type itself.
Custom Fields don't replace your writing. The body is still rich text you control. They constrain the metadata and repeatable parts so the creative parts stay clean.
When a draft is published, Acrosite commits a Markdown or MDX file with YAML frontmatter to your connected GitHub repository on the configured branch and content path. The Custom Fields you defined become the frontmatter keys. That means your front-end framework — Next.js or any Git-backed static framework — reads the same predictable keys on every entry. See Custom Content Types for how the type and its fields are defined.
Four practical examples
The fastest way to understand Custom Fields is to see real field lists. Here are four content types most agency and business sites need, with the fields that earn their place.
Case study
Case studies are the classic candidate. Every one shares a shape, and missing a single element undermines the whole pitch.
- Client name — short text
- Industry — short text or select
- Hero image — image
- Summary — short text (used in listings and meta description)
- Services delivered — rich text or list
- Result — short text (the measurable outcome)
- Body — rich text
- SEO title and description — SEO field
FAQ entry
FAQs feel too simple for a content type until you have forty of them scattered across pages. A type keeps them queryable and reusable.
- Question — short text
- Answer — rich text
- Category — short text or select
- Display order — number
Author profile
If multiple people write Posts, an author content type keeps bylines consistent and lets you reference one author across many articles instead of retyping a bio.
- Name — short text
- Role — short text
- Avatar — image
- Bio — rich text
- Social link — short text (URL)
Service or location page
Service pages and location pages are the same problem in two costumes: many near-identical entries that must stay parallel for navigation and SEO.
- Title — short text
- Slug — short text
- Summary — short text
- Body — rich text
- Region or service area — short text
- SEO title and description — SEO field
A real frontmatter example
When a case study Content Item is published, Acrosite serializes its Custom Fields into YAML frontmatter at the top of the committed file. Here's what a case study might look like at content/case-studies/northwind-rebrand.md:
---
title: "Northwind Rebrand Doubles Demo Requests"
client: "Northwind Logistics"
industry: "Supply Chain"
hero_image: "/images/case-studies/northwind-hero.jpg"
summary: "A full rebrand and site rebuild that lifted qualified demo requests 112% in one quarter."
services:
- "Brand identity"
- "Website rebuild"
- "SEO migration"
result: "112% increase in qualified demo requests"
seo_title: "Northwind Logistics Rebrand Case Study"
seo_description: "How a supply chain brand doubled demo requests after a rebrand and site rebuild."
date: 2026-05-18
---
The full case study body lives here as Markdown or MDX.Notice that every key maps to a Custom Field you defined once. The next case study you publish will have the exact same keys, so your case-study listing component and detail template never have to handle a missing field. That predictability is what makes structured content cheap to render and safe to redesign.
Consistency and SEO benefits
Two payoffs come almost for free once content is structured.
The first is consistency at scale. Because every entry of a type carries the same fields, you can build one template that renders all of them, filter and sort by any field, and trust that bulk operations behave. A redesign becomes a template change, not a fifty-page manual audit. New Team Members onboard faster because the form tells them what's required instead of relying on a wiki page nobody updated. If you run client work, this also keeps quality even across Projects, since every Project's content follows the same contract.
The second is SEO. A dedicated SEO field on each type makes meta titles and descriptions a routine part of creating content rather than an afterthought someone remembers later. Structured frontmatter also feeds structured data and clean, consistent listing pages, which search engines reward. Because the fields are always present, you don't ship pages with empty meta tags — a common, quiet SEO leak on free-text sites.
Structured content also pairs cleanly with scheduling and review. Drafts stay private in the app until published, Scheduled publishing holds an approved draft and commits it at the chosen time, and Client Reviewers can comment and approve specific Content Items before anything reaches your repository.
How to avoid over-engineering
Structure is a tool, not a goal. The failure mode on the other side is a content type with twenty fields, half of them optional and rarely filled, which is just a blank page with extra friction.
A few guardrails keep you honest:
- Define a Custom Content Type only when you'll create several similar entries. One-off pages stay Pages.
- Add a Custom Field only when it appears on most entries. Genuinely optional details can live in the rich-text body.
- Prefer a handful of meaningful fields over an exhaustive schema. You can add a field later; removing one after fifty entries is the painful direction.
- Use the field type that matches the data — an image field for images, a date for dates — so the form does the validating for you.
- Reserve the rich-text body for the parts that are genuinely freeform. Don't try to model paragraphs as fields.
The right amount of structure is the amount that prevents drift without slowing creators down. When in doubt, start lean. A case study with seven well-chosen fields beats one with eighteen that nobody completes.