ACF Pro field architecture: a default starting point

Here's the architecture we use as a starting point on every custom WP build.

The homepage and any landing-style page uses one flexible content field, typically called Sections, and nothing else. Each layout inside that flexible content field is a self-contained block: Hero, Two Column Text and Image, Feature Grid, Testimonial, CTA. Editors compose pages by stacking layouts, not by filling out a dozen separate fields. The mental model matches what they see on the front end.

Global site fields (header navigation, footer columns, default SEO, social links, contact info) go on a dedicated Options page rather than a single mythical "settings" post. Options pages are structured like the rest of the dashboard, not like a junk drawer.

“ACF is invisible when it’s done well. The editor just sees a logically organized page composer.

Posts and custom post types get a tight schema. Article gets Headline, Standfirst, Hero Image, Author (a relationship to a People CPT), Body (flexible content again), and Footer Links. That's it. If a field is needed on only one post, it's not a field. It's content inside the body.

Field labels are written for editors, not for developers. Not "post_meta_image_url_alt", but "Alt text for the cover image (used by screen readers and SEO)". The instruction text is part of the label.

The whole architecture is exported to a single ACF JSON file in the theme repository, version-controlled, and synced. Field changes happen in the codebase, not in the dashboard.

The goal isn't to be clever. It's to make a dashboard that an editor can return to in six months and still find their way around. ACF is invisible when it's done well. The editor just sees a logically organized page composer.