AEM Content Fragments vs Blocks: Choosing the Right Content Model
Compare AEM Content Fragments and Edge Delivery blocks, understand their different roles, and choose an architecture that fits authoring and delivery.
On this page
AEM Content Fragments and Edge Delivery blocks both support reuse, but they solve different problems. A Content Fragment is structured domain content intended for reuse across channels. A block is a page-level presentation and behavior pattern.
#Content Fragments
A Content Fragment is based on a model with fields such as title, description, date, image, and links. Its structure should express what the content means, not every visual arrangement a page may need.
#Blocks
A block reads authored rows or structured input and decorates them into semantic HTML, CSS, and browser behavior. A hero, card grid, accordion, or comparison table is a presentation pattern with an authored contract.
#Compare the roles
Question | Content Fragment | Block |
|---|---|---|
Primary role | Model reusable domain content | Render a page pattern |
Reuse | Across channels and experiences | Across pages with consistent presentation |
Change | Domain model and lifecycle | Layout, styling, and interaction |
#When to use each
Use a fragment when content has a stable domain identity, structured fields, reuse needs, or a governed editorial lifecycle. Use a block when the main problem is a page pattern or interaction. A page-specific section does not need to become reusable domain content.
#Combine them carefully
A block can render a list of fragments. The fragment defines the content contract; the block defines the page presentation. Keep permissions, source identifiers, and caching metadata available at the boundary.
#Authoring and migration
Ask what authors change, who approves it, where the content appears, and how it is previewed. For document-based authoring, define block tables, section conventions, metadata, and examples. Migrate one representative slice and measure author effort, performance, and exceptions before scaling.
#Common mistakes
Putting layout-specific fields into every content model.
Making one block responsible for unrelated content types.
Assuming structured content automatically creates good authoring.
Ignoring permissions when reusing content across channels.
Translating component names instead of modeling user needs.
#Frequently asked questions
#Can a block render a Content Fragment?
Yes, when the delivery integration supports it. Keep content and presentation contracts separate.
#Should every page section be a fragment?
No. Page-specific content can remain in the page authoring flow.
#Conclusion
Content Fragments model reusable information; blocks model page presentation and behavior. Choose by asking whether the thing is domain content or a web pattern. A clear boundary improves authoring, reuse, performance, and migration flexibility.