Most industrial CMS buildouts start the same. You add a Title field, then a Body field. Then someone needs a short summary for cards, so you add Summary. The new article template calls for an Intro. Then Description appears somewhere, followed by Short Description, and before long you have overlapping text fields everywhere with no clear rules and no shared understanding of what each one is for.
At Astuteo, we've seen this happen on enough manufacturing sites to know it's not because of careless teams. Content fields are added as needs emerge, and by the time the site is two years old with 1,500 entries, the content model is a mess that is difficult to scale.
A better approach is to define a canonical starting set of text fields before content entry begins. Not every field the site will need, just a clear and defensible baseline for headings, summaries, and other supporting text. Here is the starting set we recommend.
Plain Text
Plain text carries no formatting. These are short, portable fields that hold up when pulled into cards, navigation menus, search results, or other page listings. Start with these:
Plain Text Fields
Field
Max Chars
Use Case
Typical Surface
Title
250
Main title of the page, product, or service
Page headers, browser tabs
Eyebrow
40
Short contextual label above headings
Section headers, cards
Navigation Title
60
Compact title for constrained spaces
Page headers, articles, CTAs
Subheading
120
Secondary line below heading for added context
Page headers, articles, CTAs
Teaser
250
1–2 sentence hook for list pages
Cards, search results, overviews, feeds
Alt Text
200
Accessible description of visual content
alt attribute, accessibility layers
Caption
300
Descriptive text for media assets
Image and video captions, galleries
Title is the H1 on the page, the primary identifier everywhere the content appears. Every entry needs one. Keep it factual and specific.
Eyebrow is a short label above the heading, 40 characters max. It offers category context at a glance, like "Case Study" or "Used Equipment".
Navigation Title is a compact version of the Title for menus, breadcrumbs, and tabs. 60 characters. When the full title won't fit in a mobile nav, this field is ready to serve.
Subheading sits below the title and adds a line of context, up to 120 characters. Useful on landing pages and product headers where the title alone doesn't say enough.
Teaser is a standalone 1–2 sentence hook, 250 characters, that works without the headline next to it. This is a workhorse field on manufacturing sites – used for products, services, markets, articles, and more – so an important one to get right. Every entry with a body field needs a strong teaser.
Alt Text lives on the media asset, not the page. Each image gets one alt text everywhere it appears. For a manufacturer with hundreds of product photos, this is where accessibility happens.
Caption varies by project. For some companies, having one caption attached to each image works fine. But for manufacturers whose products span multiple applications, a single caption rarely fits every context. In those cases, caption should be applied at the page level, not the asset one.
Rich Text
Also known as a WYSIWYG field, rich text fields output formatted HTML. This includes everything from bold and italics on the simple end, through more complicated components like tables and custom code. Start with these:
Rich Text Fields
Field
Max Chars
Use Case
Typical Surface
Intro
600
Short text that opens content
Article excerpts, landing page lead-ins
Text (or Body)
–
Long-form rich text
Page body, articles, detailed content
Product Description
–
Product-specific text content
Product detail pages
Intro is a short formatted opening, around 600 characters. Use it when you need a linked term or emphasized phrase above the body but not full layout control.
Text or Body is your main content field. Pick one default name and stick with it. Articles, landing pages, features, anything with long-form prose lives here. In some content models, this field gets renamed and reused if a page needs separate prose sections.
Product Description is a separate rich text field scoped to product entries. Keeping this distinct from the general Text field lets you enforce different rules, templates, and guidance for product content.
WYSIWYG Toolbars
Most CMS platforms allow the rich text editor to be customized, but giving users too many features can create headaches. Consider these two to start:
A minimal option: A toolbar that includes bold, italic, links, and list formatting only.
A complete option: This toolbar should include formatting for paragraphs and headings (commonly H2-H4, since H1 comes from Title), bold, italic, lists, links, and more. More scientific industries typically need superscript and subscript. It should include everything needed to write detailed content on your website.
SEO Text Fields
Most modern CMS systems offer robust SEO solutions that include the meta title, meta description, and much more. While SEO fields are also essential text, they aren't included here for that reason.
This isn't the last set of text fields your CMS will need. But it's an intentional starting point that prevents the slow accumulation of overlapping, poorly-defined text fields that makes content modeling difficult at scale. Define these before the first entry goes in, and every decision that follows becomes a lot easier.
# Content Fields — Text
Canonical text field library. CMS-agnostic definitions for every text field by semantic purpose, portable type, constraints, and editorial guidance. CMS-specific implementations (handles, field types, editor configs) live in separate adapter files per platform.
---
## Portable Type Taxonomy
| Portable Type | Description | Input Style |
|---|---|---|
| `short-text` | Single-line plain text, 120 characters or fewer | Single-line input |
| `long-text` | Multi-line plain text, more than 120 characters | Multi-line textarea |
| `rich-text-minimal` | Rich text with bold, italic, and links only | Restricted rich text editor |
| `rich-text-full` | Rich text with full toolbar (headings, lists, links, tables) | Full rich text editor |
---
## Plain Text Fields
| Field | Portable Type | Max | Use Case | Typical Surfaces |
|---|---|---|---|---|
| Eyebrow | `short-text` | 40 | Short label above headings | Section headers, cards |
| Navigation Title | `short-text` | 60 | Compact headline for constrained spaces | Nav, breadcrumbs, tabs, mobile headers, browser tabs |
| Subheading | `short-text` | 120 | Secondary line below a heading; adds context or framing | Article headers, landing pages, hero sections, CTAs |
| Teaser | `long-text` | 250 | Self-contained 1–2 sentence hook; works without the headline | Cards, feeds, search results, notifications, API, RSS |
| Alt Text | `long-text` | 200 | Accessible description of visual content; stored on asset | `alt` attribute, accessibility layers |
| Caption | `long-text` | 300 | Descriptive text for media; may be stored on asset or per-usage | Image/video captions, galleries, lightboxes |
---
## Rich Text Fields
| Field | Portable Type | Max | Use Case | Typical Surfaces |
|---|---|---|---|---|
| Intro | `rich-text-minimal` | 600 | Short rich text that opens content or supports a heading | Article intros, landing page lead-ins, above-the-fold |
| Text | `rich-text-full` | — | Full rich text body content | Body content, articles, detailed sections |
| Product Description | `rich-text-full` | — | Product-specific rich text | Product detail pages |
---
## Field Instructions
Editor-facing help strings. CMS implementations should use these as the instruction/description text shown to content editors.
- **Eyebrow:** Short label displayed above the heading.
- **Navigation Title:** Optional compact version of the heading for menus and breadcrumbs.
- **Subheading:** Supporting line displayed below the heading.
- **Teaser:** One or two sentences that work as a standalone hook. Appears on cards and other descriptive listings.
- **Alt Text:** Describes this image for users who can't see it.
- **Caption:** Visible text displayed with this media.
- **Intro:** Short formatted introduction for this content.
---
## System Guidance
### Content Rules
- Plain text fields contain no HTML, no markdown.
- Fields at 120 characters or under are single-line inputs. Fields over 120 characters render as multi-line text areas.
- Max character counts are ceilings, not targets.
- No field should duplicate another field's content on the same content type.
- Empty is better than faked. A missing field falls back gracefully; a bad one doesn't.
### Plain Text vs. Rich Text
- Teaser (250 chars) is the upper boundary for general-purpose plain text prose. Anything longer warrants rich text.
- If a Teaser needs inline formatting (bold, italic, links), use Intro instead.
### Rich Text Toolbar Profiles
Two profiles only. If a field doesn't fit either, reconsider whether it should be rich text.
**Minimal** — Used for Intro.
- Bold
- Italic
- Links
**Full** — Used for Text and Product Description.
- Headings (H2, H3 only — H1 comes from the entry title)
- Bold
- Italic
- Bulleted lists
- Numbered lists
- Links
- Source editing
### Fallback Chain
Teaser → truncated body (last resort). Document this in the CMS so editors understand the cost of leaving Teaser empty.
### Asset-Level Fields
Alt Text is stored on the media asset, not per-usage. One image gets one Alt Text everywhere it appears.
Caption storage depends on the project. When a single caption fits every context the image appears in, store it on the asset alongside Alt Text. When the same image serves different purposes across pages — common with manufacturers whose products span multiple applications — store Caption at the page level instead. Pick one approach per project and document it in the CMS.
### Body Fields
Every content type with a Text or Product Description field should also carry a Teaser. No body field should exist without a portable plain-text companion.
