Pages vs fragments — what to build
Purpose: Decide between a page, a content fragment and an experience fragment for any new content requirement.
Who this page is for
| Audience | Why it matters to you |
|---|---|
| All engineers | The most common modelling fork in the road |
The decision table
| Criterion | Page | Content Fragment | Experience Fragment |
|---|---|---|---|
| Has a URL of its own | Yes | No (data only) | Not primarily |
| Authors compose layout | Yes | No | Yes (once, reused) |
| Channel-neutral | No (web-first) | Yes | Partially |
| Structured/typed fields | Via dialogs | Yes — schema (CF model) | No |
| Reused across pages | Via XF/embed | Via reference | Yes — that's the point |
| Typical PHI example | The gold plan page | Plan data (premium, benefits) | "Why PHI" promo band |
Litmus tests
- "Would a mobile app want this as data?" → Content Fragment.
- "Will marketing reuse this designed block on many pages?" → Experience Fragment.
- "Does it need its own URL and SEO presence?" → Page.
- "Is it really configuration, not content?" (feature flags, API endpoints) → OSGi config, not content at all.
Combining them (the usual answer)
Plan PAGE (/content/phi/plans/gold-hospital)
├── hero component ← page-local authored content
├── plan-facts component ────▶ references CF /content/dam/phi/fragments/gold-hospital-data
├── "Why PHI" XF ───────────▶ references XF /content/experience-fragments/phi/why-phi
└── disclaimer component ───▶ references CF /content/dam/phi/fragments/hospital-disclaimerThe page is thin composition; facts and reusable blocks live once. This is the shape most mature AEM sites converge on.