Field Groups

Reusable sets of custom fields, applied to one or more content types, taxonomies, or the blog via Location Rules — the one place custom fields are defined.

What it is

A field group is a named set of custom fields (Text, Number, Image, Select, and more) plus a set of Location Rules deciding which entries it applies to — a content type, a taxonomy's terms, or the blog, any combination at once. Instead of defining a field list separately for every content type, define it once and target everywhere it belongs.

This is the single place custom fields are defined for content types, taxonomies, and the blog. The Content Types, Taxonomies, and Article panels still show each one's current fields, but read-only — with a pointer back here to change them.

Creating a field group

  1. 1

    Open Field Groups

    In the site editor, go to Workspace → Field Groups, then New field group.

  2. 2

    Add fields

    On the Fields tab, add each field: a label, an auto-derived key (editable), a type, and whether it's required. Every field here is added to every owner this group's Location Rules match.

  3. 3

    Set Location Rules

    On the Location Rules tab, choose what this group applies to: a Content Type, a Taxonomy, or the Blog. Conditions in the same rule row are combined with and; click Add rule group for an or — e.g. "Content Type is Recipes, OR Content Type is Articles."

  4. 4

    Save

    The fields immediately show up wherever the rules match — in the matching entries' editors, and in the target owner's (now read-only) Fields view.

Location Rules

A group can apply to several owners at once — a "SEO Fields" group targeting every content type, or a set of fields shared between a taxonomy's terms and the blog. Rules are OR-groups of AND-conditions, same shape as most rule builders: rows in one group all have to match (AND); any one group matching is enough (OR) — so "Content Type is Recipes AND Content Type is Articles" would never match anything (an entry is only ever one content type), while putting those as two separate or'd rule groups matches either.

Saving fails if a field's key would collide with a field from a different group that also applies to one of the same owners — rename one of the colliding fields to resolve it. Values are stored flat by key, so two groups can't silently overwrite each other's data on a shared owner.

Presentation & Settings

Beyond fields and rules, a group has a name, an optional description, an Active toggle (an inactive group's fields stop applying anywhere, without deleting them — handy for temporarily pulling a group out), and a Position (lower numbers show first when more than one group applies to the same owner).

A brand-new content type or taxonomy starts with zero fields

Creating a content type or taxonomy no longer collects fields inline — add them afterward from Field Groups, targeting the new content type or taxonomy by name. This mirrors how the group can be reused or reassigned later without editing the content type itself.

AI agents can manage field groups too

Anything you can do here is also available to an MCP-connected AI agent — see manage_field_groups in Zitegen MCP tools. It's now the only way to define custom fields for a content type, a taxonomy, or the blog; the older "fields" arguments on manage_content_types/manage_taxonomies/manage_articles have been retired in favor of it.