# From pages to structured content ### About this export | Field | Value | | --- | --- | | **content_type** | lesson | | **platform** | contentstack-academy | | **source_url** | https://www.contentstack.com/academy/courses/content-modeling-with-contentstack/from-pages-to-structured-content | | **course_slug** | content-modeling-with-contentstack | | **lesson_slug** | from-pages-to-structured-content | | **markdown_file_url** | /academy/md/courses/content-modeling-with-contentstack/from-pages-to-structured-content.md | | **generated_at** | 2026-08-03T11:49:37.685Z | > Part of **[Content Modeling](https://www.contentstack.com/academy/courses/content-modeling-with-contentstack)** on Contentstack Academy. **Academy MD v3** — structured for retrieval; no quiz or assessment keys. #### Lesson text # From pages to structured content > **TL;DR** > > * Structured content separates what the content is from where and how it appears -- model domain concepts (Product, Category), not page layouts. > * Use Reference fields to connect content types instead of duplicating data; change it once, and every referencing entry reflects the update. > * Each delivery channel (web, mobile, email, voice) fetches the same entries and renders only the fields it needs -- no per-channel content types required. > * Ask three questions before creating a content type: does the concept exist independently, will it appear in multiple contexts, and would editors update it separately? A traditional e-commerce product page bundles the title, description, price, category, product images, and SEO metadata into a single database row tied to a URL. That coupling works until someone asks you to show the same product on a mobile app, a marketplace feed, or a store locator - and suddenly the "page" abstraction falls apart. The shift from page-oriented to structured content is not a trend; it is the architectural response to delivering content across channels that a single page template was never designed to serve. ## Why this matters This lesson is where many developers either start modeling cleanly or accidentally recreate page-shaped CMS habits inside a headless platform. If you get this mental shift right, later lessons about references, APIs, and governance become much easier. ## You will be able to * explain why page-based thinking breaks down in omnichannel systems * identify domain concepts that deserve their own content types * connect structured modeling choices to cleaner API delivery across channels ## The page-oriented model and its limits Traditional CMS platforms like WordPress and Drupal organize content around pages. Each page maps to a URL, contains a layout template, and stores its content in a combination of a title field, a body blob, and a collection of custom fields or widgets. The editing interface reinforces this model: authors see a page preview, drag layout components around, and publish the result as a single unit. This works well under specific conditions: * Content appears on exactly one website. * The design team controls the layout. * Each piece of content lives at one URL and nowhere else. The problems surface when requirements expand. Consider an e-commerce site like Veda built on a page-oriented CMS. A single "Product" page template might contain: * The product title and description * A price and availability (stored in custom fields) * Product images uploaded to the media library * The product line and category (entered directly on the page) * Related products (hardcoded or manual links) * SEO metadata (a set of custom fields) Every piece of data lives inside that one page. If the marketing team wants to show all Digital Dawn products on the homepage, someone needs to write a custom query that parses product line data out of product pages. If a marketplace feed needs just the title, price, and images without any layout HTML, a developer has to strip tags and hope the structure is consistent. If the same product line has 20 products, the line description is duplicated 20 times with no single source of truth. This is not a shortcoming of WordPress specifically. It is a structural consequence of organizing content around pages rather than around the content itself. ## What structured content actually means Structured content separates _what the content is_ from _where and how it appears_. Instead of storing a product as a single page, you decompose it into distinct content types, each with a defined schema of fields: * Product - title, url, short\_description, description, price, media * Product Line - title, url, description, image, products (Digital Dawn, Urban Armor, etc.) * Category - title, url, description, media (Earrings, Necklaces, Bracelets, Rings) * Page - title, url, components (modular blocks for hero, list, rich text) Each content type is independent. A Product _references_ a Product Line rather than duplicating the line description. A Category entry exists once and can be referenced by every product in that category. A Product Line groups products without being embedded inside them. In Contentstack, these content types are created under Content Models in the left navigation of your stack. Each content type defines a schema - an ordered set of fields with specific types (single-line text, number, date, reference, file, and so on). Every entry you create against that content type conforms to the schema. The result is content that is predictable, queryable, and channel-independent. ## The Veda migration: a concrete example Let us walk through the Veda: The Revival Collection content model in Contentstack. In a page-oriented CMS, each product page would bundle everything into one row. In Contentstack, the same information becomes distinct content types with explicit relationships. ### Product content type Field Type Purpose title Single Line Text The product name (e.g., Matrix Link Bracelet) url Single Line Text URL path (/products/digital-dawn/matrix-link-bracelet) short\_description Multi Line Text Summary for cards and search results description Multi Line Text Full product description price Number Price in currency units media File, multiple Product images product\_line Reference (Product Line), multiple Collection (Digital Dawn, etc.) category Reference (Category), multiple Category (Earrings, Bracelets, etc.) ### Product Line content type Field Type Purpose title Single Line Text Collection name (Digital Dawn) url Single Line Text URL path description Multi Line Text Collection description image File Collection hero image products Reference (Product), multiple Products in this line ### Category content type Field Type Purpose title Single Line Text Category name (Earrings, Rings) url Single Line Text URL path description Multi Line Text Category description media File Category image ### Page content type Field Type Purpose title Single Line Text Page title url Single Line Text URL path components Modular Blocks Hero, list, rich text, etc. Now the product line description exists in exactly one place. Change it once, and every product that references that line reflects the update. The mobile app can fetch just the Product content type with include\[\]=product\_line to resolve the reference, getting clean JSON without any HTML layout artifacts. A marketplace feed can request only title, price, and media using field projection in the Contentstack Delivery API. A store locator gets the same content through the same API - no screen-scraping, no special endpoints. ## Content reuse across channels The real payoff of structured content is reuse. When content is decomposed into typed, referenced entries, each channel consumes exactly the fields it needs: Channel Content consumed Website Full product with description, product line, images Mobile app Product summary, price, media Marketplace feed Title, price, short description, first image Email campaign Title, short description, hero image, link Partner API feed Product data without branding or layout In-store display Product images, QR code to full page None of these channels need to parse a page template. Each one makes an API call to the Contentstack Content Delivery API, requesting the content types and fields it cares about. The content is created once and delivered everywhere, which is the core promise of the headless model introduced in lesson 1.1.1. ## The mental model shift Moving from pages to structured content requires a change in how teams think about their work. Here are the key shifts: **Authors stop thinking in pages and start thinking in entries.** A product is not a page; it is an entry in the Product content type. The product line is a separate entry. The author creates each piece independently and connects them through references. This feels unfamiliar at first - authors may ask "where is my page?" - but it gives them the ability to update a product line description once instead of editing 20 product pages. **Designers stop thinking in templates and start thinking in components.** The layout is no longer stored in the CMS. Instead, the frontend application fetches structured data and applies presentation logic. A product card component on the homepage and the full product detail page both consume the same Product entry - they just render different fields. **Developers stop building page controllers and start building API consumers.** There is no server-side template rendering in the CMS. The frontend (whether React, Vue, Next.js, or a native mobile app) fetches JSON from the Delivery API and handles all rendering. This separation is explored further in lesson 1.1.1 on what headless means. ## Content types as reusable schemas, not page layouts A common mistake during migration is to recreate the page structure inside Contentstack. Teams build a content type called "Product Page" with 30 fields that mirror every element on the old template. This defeats the purpose of structured content. The content type should model the _domain concept_ (a product), not the _page layout_ (a product page). Ask these questions when designing a content type: 1. Does this concept exist independently? A product line (e.g., Digital Dawn) exists whether or not it has any products yet. That suggests Product Line should be its own content type, not a group field inside Product. 2. Will this content appear in more than one context? If categories appear on product pages, category landing pages, and navigation, they should be their own content type with references rather than being embedded as text. 3. Would editors need to update this independently? If changing a product line description should not require opening every product, the product line must be a separate entry. These questions lead to smaller, more focused content types connected by references - exactly the pattern Contentstack is built to support. Module 2.2 on relationships and composition explores reference patterns in depth. ## Common mistakes > **Common Pitfall** > > The most common migration mistake is recreating the old page layout inside Contentstack -- a "Homepage" content type with fields for hero\_section, featured\_products\_carousel, and newsletter\_signup. This locks content into a single layout and throws away the reuse benefits of structured content. Use Modular Blocks or references to compose pages from independent content pieces instead. 1. **Recreating page layouts as content types.** Building a "Homepage" content type with fields for "hero section," "featured products carousel," and "newsletter signup" locks content into a single layout. Instead, use Modular Blocks or references to compose pages from independent content pieces. See lesson 2.2.1 on references vs. modular blocks. 2. **Storing structured data inside rich text fields.** Putting the product line description inside a JSON RTE field as formatted text makes it impossible to query by product line, filter products, or generate collection pages. If data needs to be queried or reused independently, it belongs in its own content type with discrete fields. 3. **Duplicating content instead of referencing it.** Copying the product line name and description into every product entry creates a maintenance burden and guarantees inconsistency over time. Use Reference fields to point to a single Product Line entry. Contentstack's include\[\] parameter on the Delivery API resolves references in a single request. ## Practice in Contentstack Open one real content type in your stack and inspect it as if you were preparing the Veda storefront for multiple channels. 1. Identify one field or section that is page-shaped rather than domain-shaped. 2. Rewrite it as a structured content idea: a content type, reference, or modular block. 3. Explain which second channel would benefit from that restructuring. ## Summary Structured content separates the domain from the page. In Contentstack, that means modeling products, categories, product lines, and reusable page composition patterns as structured entities instead of bundling everything into one template-shaped record. #### Key takeaways - Connect **From pages to structured content** back to your stack configuration before moving to the next module. - Capture one concrete artifact (screenshot, Postman call, or code snippet) that proves the step works in your environment. - Re-read the delivery versus management boundary for anything you changed in the entry model. ## Supplement for indexing ### Content summary From pages to structured content. From pages to structured content TL;DR Structured content separates what the content is from where and how it appears -- model domain concepts (Product, Category), not page layouts. Use Reference fields to connect content types instead of duplicating data; change it once, and every referencing entry reflects the update. Each delivery channel (web, mobile, email, voice) fetches the same entries and renders only the fields it needs -- no per-channel content types required. Ask three questions before creating a content type: does the concept exist independently, will it appear in multiple contexts, and would editors update it separately? A traditional e-commerce product page bundles the title, ### Retrieval tags - From - pages - structured - content - content-modeling-with-contentstack - lesson 02 - From pages to structured content - content-modeling-with-contentstack lesson ### Indexing notes Index this lesson as a primary chunk tagged with lesson_id "02" and topics: [From, pages, structured, content]. Parent course slug: content-modeling-with-contentstack. Use asset_references URLs as thumbnail hints in search results when present. Never surface LMS quiz content or assessment answers from this file. ### Asset references _No image or video thumbnail URLs were extracted._ ### External links | Label | URL | | --- | --- | | Contentstack Academy home | `https://www.contentstack.com/academy/` | | Training instance setup | `https://www.contentstack.com/academy/training-instance` | | Academy playground (GitHub) | `https://github.com/contentstack/contentstack-academy-playground` | | Contentstack documentation | `https://www.contentstack.com/docs/` |