Content modeling decomposes content into its logical components and elements, and it's what makes dynamic, structured pages possible. A static page is manually built and self-contained; a dynamic page is generated from a consistent set of components governed by a template. Structuring content this way enables real capabilities: contextual navigation through metadata-driven links between related pages, content chunked into well-labeled sections that improve scanability, and content reuse, the same underlying content displayed differently depending on where and how it appears.
A content model has three key elements: content types, the distinct kinds of content objects a space comprises, each sharing common attributes and a common purpose; content components, the logical parts each content type breaks down into, balanced against the cost and complexity of actually building and maintaining that many discrete pieces; and access structures, the metadata that defines how components and pages relate to and link with each other.
Every reusable "related articles" list, every author bio that shows up consistently across dozens of pages, and every filterable product listing all trace back to the same underlying decision: someone modeled the content into components before building the page around it.
1: Content components broken out with structured, filterable metadata for each attribute. Filtering by ingredient and dietary requirement requires that "ingredient" and "dietary requirement" exist as distinct, structured pieces of data on every recipe, not buried inside a single block of prose. A static, unstructured page has no way to support this at all, there's nothing for a filter to query against.
2: Access structures. Contextual navigation between related recipes depends on metadata that defines how pages relate to each other, the access structures element of a content model. Without that relationship metadata, there's no mechanism for the site to know which recipes are actually related to which.
A reasonable decomposition of a single recipe into components: an ingredients list component, a cook-time and difficulty component, a step-by-step instructions component, a dietary-tags component, and a ratings or reviews component, each with its own well-defined purpose, matching how the source material describes decomposing a content type into its constituent parts.Having these as separate components, each with its own metadata, is exactly what makes personalized recommendations possible: a recommendation system needs structured signals to work with, this user has favorited several recipes tagged "vegetarian" with a short cook time, so surface similar recipes, and none of that reasoning is possible if a recipe exists only as one undifferentiated paragraph of text. This is the same underlying mechanism the source material describes for reusable content generally: separating content into components is what lets the same underlying data power multiple different features, not just the single page it originally appeared on.
Fill in your own details below; the prompt updates as you type. When it's ready, copy it into Claude or whatever AI tool you use.
Casts the AI as: You're a content strategist analyzing documentation to create a content model.
Names 7 specific outputs to produce, so the response comes back structured rather than a general summary.
Content domain, Total pages and Target audience tell the AI what your specific situation is, not a generic one.
For each content type: a name, what job it does for the user, how it differs from nearby types, and one example URL or title.
Fill in your own details below; the prompt updates as you type. When it's ready, copy it into Claude or whatever AI tool you use.
Casts the AI as: You are a content strategist and information architect who specializes in classifying documentation using the Diátaxis framework.
Names 5 specific outputs to produce, so the response comes back structured rather than a general summary.
Background tell the AI what your specific situation is, not a generic one.
Output as structured table: columns for page/title, proposed type, confidence, and a one-line reason grounded in the page content.
Fill in your own details below; the prompt updates as you type. When it's ready, copy it into Claude or whatever AI tool you use.
Casts the AI as: You're a content architect designing metadata schemas for documentation.
Spells out exactly what to analyze and return.
Content type definition tell the AI what your specific situation is, not a generic one.
Group attributes by category: required identifying fields, descriptive fields, relationship fields, and administrative/workflow fields.
Fill in your own details below; the prompt updates as you type. When it's ready, copy it into Claude or whatever AI tool you use.
Use this prompt when: Starting content modeling from scratch.