Definition Box: Format, Rules and Examples
Use a definition box to give readers a precise, extractable explanation of a page’s main term, with strict rules for length, placement, syntax, and QA.
A definition box gives the page’s main term one exact, bounded explanation before the article expands it. It is an opening element: a reusable content component that appears near the start because a reader should not have to infer the central term from examples, benefits, or background.
That live example is the complete element, not a teaser for a definition farther down the page. Its title is optional; its body is not. The production contract below determines when the element belongs, what each field means, and how the same content maps across publishing systems.
Why this element matters
Readers rarely begin an informational page by reading every word in order. They scan the title, opening lines, headings, and visually distinct blocks to decide whether the page answers their question. A definition buried in an introductory paragraph makes that reader separate the answer from context, claims, and scene-setting. The box removes that work: its boundary says, “this is the definition.”
That boundary also gives the definition a stable, addressable position. Editors know where to review it, templates know where to render it, and future revisions do not force a reader or a quality check to search several opening paragraphs. Consistent placement matters across a library because the same information job should not move unpredictably from page to page.
Machine extractability is the ability of software to isolate a content unit without losing its meaning. A typed definition with a title and body can be indexed, compared, quoted, or transformed independently. A sentence that merely happens to define a term inside free text dissolves into its surrounding prose: software must guess where the definition begins, where it ends, and whether the preceding claim is part of it. Follow the element writing rules so the semantic identity survives even when the visual design changes.
The wording still has to work without the box. Styling creates contrast for people; a self-contained subject, verb, and distinguishing meaning create extractability for machines. “It is a method for improving them” fails when removed from its paragraph. “Content pruning is the process of removing, consolidating, or updating pages that no longer serve a useful search or business purpose” survives.
When to use it
Use a definition box when the page is organized around one term and that term can be defined precisely in a short statement. It is mandatory for glossary-term and what-is-X formats. It is also mandatory for diagnosis- or condition-style content: a reader must know what the named condition is before considering causes, tests, or remedies.
Symptom-led pages and how-to pages use the element rarely. Add it only when one short definition resolves genuine ambiguity needed for the task. For example, a guide titled “How to fix keyword cannibalization” may define keyword cannibalization before the steps because the diagnosis controls which fix applies. A guide titled “How to change a title tag” does not need a box defining a title tag if the audience and opening instruction already make the object unambiguous.
Do not use a definition box for:
- A broad introduction, history, benefit claim, or explanation of why the subject matters. Those passages develop the article; they do not define the term.
- A summary of the page. A summary collects several conclusions, while a definition states the meaning of one term.
- A product promise such as “AmICited is the easiest way to improve visibility.” That is positioning, not a testable definition.
- A warning, caveat, prerequisite, or tip. Its communicative job differs even when a theme could make it look like the same colored panel.
- A secondary term introduced midway through the article. Define that term in the sentence where it first appears, or give it its own page when it deserves sustained treatment.
- A quotation whose authority substitutes for clarity. Attribute a formal definition in the surrounding prose when attribution is necessary; keep the box readable as a direct statement.
The common near-miss is an “introduction to the definition”: “Customer churn is one of the most important concepts for subscription businesses, and understanding it can transform growth.” This says that the concept matters but never says what it is. The box cannot make empty scene-setting precise.
Where to place it
Placement encodes priority. Put the definition box immediately after the introductory paragraph or short introduction, as the first content block. The introduction establishes why the reader is on the page; the box then fixes the meaning before any causes, examples, benefits, steps, or comparisons depend on it.
Do not place navigation, a table of contents, key takeaways, an image gallery, or a promotional call to action between the introduction and the definition. Those blocks force the reader to cross unrelated material before receiving the term’s meaning. Breadcrumbs and the page hero are template chrome rather than authored content, so they may precede the introduction.
Use one definition box per page. The rule exists because the component identifies the page’s primary definitional object. Two boxes create two competing main terms and make extraction ambiguous. If both terms are genuinely primary, split the subject into two pages and connect them in prose. If the second term is subordinate, define it inline rather than styling it as a second canonical answer.
A direct answer block can coexist with a definition only when it answers a different main question. On a diagnosis page, the definition may state what the condition is while the direct answer states the recommended first action. When the page’s main question is “What is X?”, the direct answer and definition are the same answer. Collapse them into one definition box; adjacent versions merely repeat wording and compete for extraction.
Anatomy
The element has two authored regions and one structural relationship. The screenshot must show the rendered element without baking explanatory text into the image; the legend below remains selectable, accessible, and maintainable when the design changes.
Rendered legend
- Optional title: Usually “What is X?” It identifies the exact term and must not add a second claim.
- Required body: One self-contained definition that names the term, places it in a useful category, and states what distinguishes it.
- Opening position: The box follows the introduction and precedes the first explanatory section. This relationship is part of the contract even though it is not a field.
Border, background, padding, icon treatment, and typography belong to the renderer. Authors supply meaning, not visual tokens. The element must remain understandable if every decorative style is removed.
Design examples
The gallery covers the supported content variants rather than inventing different semantic types. Each capture should reuse the same definition where possible so reviewers can judge title handling, body wrapping, and viewport behavior instead of comparing unrelated copy.
With title: The preferred variant when the term is unfamiliar, ambiguous, abbreviated, or different from the exact page title.
Without title: Allowed when the page heading and immediately preceding introduction make the subject unmistakable. The body must still name the term; omission of the title never permits pronouns such as “it” to replace the subject.
Maximum length: The renderer wraps the full body. It must not truncate, collapse, scroll, or reduce the font to accommodate copy at the editorial maximum.
Narrow viewport: Title and body retain their order, readable line length, and visible boundary. No meaning may depend on an icon moving beside the text.
Parameters
The parameters separate content from presentation. Their limits keep definitions comparable across pages and prevent the component from turning into a general-purpose callout.
Definition box parameters
| Name | Type | Required | Min/max | Default | Source |
|---|---|---|---|---|---|
| title | Plain string | No | 2–8 words; 70 characters maximum | None | First heading in the directive body; shortcode or block attribute in platform adapters |
| body | Plain text with limited inline Markdown | Yes | One sentence preferred; 1–300 characters | None | Directive body after the first heading, or the entire body when no heading is present |
| term | Plain string | Derived | 1 term; 100 characters maximum | Page's main term | Title when present; otherwise the explicit subject of the body |
| inline link | URL and anchor | No | 0–1 link | None | Body; use only for necessary attribution |
| position | Document relationship | Yes | Exactly once, first block after the introduction | None | Post-type anatomy and document order |
The renderer may derive the term for indexing, but authors must never write a body that depends on that derived field being displayed. A copied definition has to name its subject explicitly.
Syntax and code examples
All three forms carry the same title and body. The portable Markdown directive is the canonical authored form; Hugo and WordPress are adapters. The examples deliberately use identical wording so a migration test can compare values, not merely appearance.
Portable Markdown directive
:::definition
## What is content pruning?
Content pruning is the process of removing, consolidating, or updating pages that no longer serve a useful search or business purpose.
:::
The first heading maps to title; everything after it maps to body. Omit the heading for the titleless variant, but keep the term in the body.
Hugo shortcode
{{< callout type="note" title="What is content pruning?" >}}Content pruning is the process of removing, consolidating, or updating pages that no longer serve a useful search or business purpose.{{< /callout >}}
The site reuses the existing callout renderer for the visible Hugo treatment. The definition contract still comes from the typed portable source: note is a rendering adapter here, not permission to put ordinary notes in definition boxes.
WordPress block or shortcode
[definition title="What is content pruning?"]Content pruning is the process of removing, consolidating, or updating pages that no longer serve a useful search or business purpose.[/definition]
A WordPress implementation may expose the same fields as a custom block. The stored values remain title and body; editor controls, colors, and spacing are presentation settings and must not alter the definition’s meaning.
Examples
This is good because it names the term, identifies the condition, and states the distinguishing consequence. It does not claim that every pair of pages sharing a word competes; the phrase “same search intent” supplies the necessary boundary. The body is useful without the title and short enough to quote intact.
This is bad because it never defines keyword cannibalization. It offers importance, audience, urgency, and a vague effect, but no category or distinguishing condition. Replacing “one of the most important” with “a situation where multiple pages compete for the same search intent” turns promotion into meaning.
A second bad pattern is overloading the box: a definition followed by causes, five examples, a warning, and a recommended tool. Even if the first sentence is accurate, the extra material destroys the stable boundary. Keep the definition; move causes and examples into the next section, the warning into its correct element, and the recommendation to the point where the reader can act on it.
Schema markup and accessibility
A definition box does not create a standalone Schema.org entity automatically. On an ordinary article, its text remains part of the enclosing Article or TechArticle. On a glossary page, a publishing implementation may map the term and definition to a suitable vocabulary only when the site has adopted that schema policy. Do not invent a DefinitionBox type: it does not exist in Schema.org.
Likewise, do not duplicate the body in JSON-LD merely because the box looks important. Schema markup must describe the page truthfully, and duplicating visible prose into an unrelated property creates noise rather than stronger meaning. If a schema property is populated, its value must match the visible definition in substance and update with it.
The element needs no interactive ARIA role. Render it in normal document order as a labelled region or semantic container, with the title before the body. Do not use role="alert", because a static definition is not urgent or newly arrived information. Do not use color or an icon as the only signal that the block is a definition. If the title is implemented as a heading, its level must follow the page hierarchy; the source’s ## is a field-mapping convention, not an instruction to create an invalid heading jump.
Keyboard behavior is ordinary reading behavior: the box itself is not focusable. Any link inside follows normal link semantics and needs a descriptive anchor. Screen-reader output must preserve the same title-then-body order visible on screen.
Writing rules
Write the definition before writing its benefits. Begin with the term itself, then use a linking verb such as “is,” “means,” or “occurs when.” State the nearest useful category and the characteristic that separates the term from neighboring concepts. This sequence exists because category without distinction is broad, while distinction without category leaves the reader unsure what kind of thing the term is.
Keep the body to about 300 characters maximum, including spaces. Prefer one sentence. A second short sentence is acceptable only when a necessary boundary cannot be expressed clearly in the first. The limit is editorial rather than an invitation to compress punctuation, remove articles, or pile clauses together. If accuracy requires more space, put the exact core in the box and qualify it immediately afterward.
Use a neutral, declarative tone. Avoid “important,” “powerful,” “game-changing,” “you need to know,” and similar judgments. Avoid circular definitions such as “content optimization is the act of optimizing content.” Expand abbreviations on first use unless the abbreviation itself is the page’s term. Use the same canonical name that appears in the page title.
Never place these inside the body:
- More than one primary term or a list of related terms.
- Benefits, history, causes, symptoms, examples, steps, product pitches, or calls to action.
- Tables, images, videos, forms, buttons, footnotes, or nested callouts.
- Unsupported superlatives, invented statistics, or claims that require a paragraph of evidence.
- A second heading, bullet list, or block quotation.
- Pronouns whose meaning depends on the preceding introduction.
One attribution link is the exception, not the target. Use it only when a legal, scientific, or standards-based definition depends on a named source. Put extended citations and disagreement between sources in ordinary prose, where the reader can see the qualification rather than mistaking one contested wording for a universal definition.
Post types that use it
The postTypes frontmatter records the registered joins. The table translates those joins into editorial rules. Diagnosis/condition-style and symptom-led formats are described here as usage patterns, but they are not linked as separate playbook post types because they are not in the current canonical registry.
Post-type requirements
| Post type | Requirement | Position | Reason |
|---|---|---|---|
| [Glossary term](/seo-playbook/post-types/glossary-term/) | Always | First content block after the introduction | The page exists to establish one canonical meaning before adding context, examples, or related terms. |
| [What-is-X page](/seo-playbook/post-types/what-is-x/) | Always | First content block after the introduction | The page's main question is definitional, so this box also serves as the direct answer. |
| [How-to guide](/seo-playbook/post-types/how-to-guide/) | Rarely | After the introduction and before prerequisites or steps | Use it only when misunderstanding one short term would cause the reader to choose or perform the wrong procedure. |
For diagnosis- or condition-style pages, use the box always and place it before symptoms, causes, severity, or remedies. For symptom-led pages, use it only when the symptom name has a genuinely short, stable definition. If the box would merely restate the title—“A slow website is a website that is slow”—omit it and begin with the diagnostic threshold or observable problem in prose.
QA checklist
A reviewer checks meaning before appearance. A polished box containing a vague introduction is still a failed definition.
- One main term: The page and box define exactly one primary concept.
- Correct position: The box is the first authored content block after the introduction, with no table of contents, takeaways, gallery, or promotion inserted before it.
- One occurrence: No second definition box competes with the canonical answer.
- Actual definition: The body states what the term is or when the condition exists; it does not merely say why the term matters.
- Self-contained wording: The body names its subject and makes sense when copied without nearby prose or styling.
- Precision: Category, distinguishing characteristic, and any essential boundary are accurate. The wording does not overgeneralize.
- Length: The body is no more than about 300 characters and remains readable rather than compressed.
- Clean contents: No benefits, history, examples, steps, product claims, media, tables, or nested elements appear inside.
- Direct-answer decision: If the page asks “What is X?”, the definition box is the only direct-answer element. If both elements appear, they answer clearly different questions.
- Accessible semantics: Title precedes body, heading order is valid, color is not the only identifier, and no alert role or unnecessary focus target is present.
- Portable parity: Markdown, Hugo, and WordPress mappings retain the same title and definition.
- Structured-data restraint: Any schema value matches the visible copy, and no invented Schema.org type is used.
- Screenshot status: Comments remain non-rendering capture instructions until the named files exist; no nonexistent image path is referenced as an image.
FAQ
The academy template renders the five reviewed questions stored in this page’s [[faq]] frontmatter. Together they cover necessity, coexistence with direct answers, links and citations, the length limit, and the one-per-page rule.
More tutorials in this section
Ready to put it into practice?
Free check · 7-day trial · no credit card