SGEN content modeling overview

In short. SGEN gives every piece of your site content one of four shapes: Pages (stable references at fixed URLs), Posts (chronological streams with built-in archive + RSS), Custom objects (structured sets with defined fields — team members, products, case studies), and Collections (curated or rule-based groupings across the other shapes). The shape you pick determines how the content is templated, filtered, queried, and surfaced in SEO. Pick wrong early and you'll feel it when you try to filter or cross-link later — but all four shapes support migration between them. Decision rule: match the shape to the content's behavior, not its form.

On this page: The four shapes · Decision: when each fits · Patterns worth calling out · Diagnosing the wrong shape · Examples · How shapes age

How content modeling works in SGEN

SGEN offers four content shapes. Every entry on your site fits one of them. The shapes are not interchangeable — each carries different behaviors, different default templates, different SEO and analytics handling, and different fit for different content patterns.

Pages

The stable-reference shape. Home, About, Pricing, Contact, Services, individual landing pages — all pages.

Pages have:

• A unique slug at the site root or under a section (/about, /services/consulting, /pricing).
• A meta block with WebPage schema defaults (or a more specific type you set).
• A position in the site tree — pages can nest under parent pages to express hierarchy.
• No automatic chronological feed. Pages are linked deliberately, not streamed.

When to pick pages: content has a stable URL, is referenced from navigation (not a feed), and is a small fixed set (handful to a few dozen).

When pages fight you: you need chronological listings, filtering by author/category/tag, or hundreds of entries with structured fields. At that point, move to posts or a custom object.

Posts

The chronological-stream shape. Blog posts, news entries, changelog items, product announcements — all posts.

Posts have:

• A slug under a section (/blog/, /news/).
• Article schema defaults with author, publish date, and modified date.
• Required fields: author, publish date, category, and optional tags.
• Automatic archive with paginated listing, category filters, and tag filters at the section root.
• RSS feed generation for syndication.

When to pick posts: the content is timely, you want a built-in archive with filtering, you want RSS, and volume is expected to grow.

When posts fight you: content is not chronological (a glossary, a directory, a catalog doesn't fit); content has many structured fields beyond title/body/author/date; or the content is one-of-one.

Custom objects

The structured-set shape. Team members, products, case studies, events, recipes, properties, locations — each of these is typically a custom object.

Custom objects have:

• A defined schema — you specify the fields each entry has (text, number, date, image, reference to another object).
• A slug pattern under a dedicated section (/team/, /case-studies/).
• Schema defaults driven by the object type — Person for team members, Product for products, Event for events.
• A list view in the admin with filtering, sorting, and bulk actions.
• Optional reference fields linking to other objects (a case study references the team members who worked on it).

When to pick custom objects: content has more than two or three structured fields you want to filter; entries reference one another; you want the same schema enforced on every entry.

When custom objects fight you: the content is unique (one entry, no shared schema — use a page); or it's a chronological stream where date is the primary axis (use a post).

Collections

The curated-grouping shape. Collections are not a fourth content type — they are a way of grouping entries across the other shapes. "Featured products," "staff picks," "summer collection," "current campaign."

Collections have:

• A name and slug at the collection root (/featured, /staff-picks).
• A membership rule — manual (you add entries one at a time) or automatic (entries that match a query, e.g. all products tagged summer-2026).
• An ordering — manual, by date, by name, or by a custom field.
• A meta block for the collection page itself.

When to pick collections: you want to surface a curated subset without changing the underlying entries; you want the same entry in multiple groupings without duplication; you want a section that updates as the membership rule changes.

When collections fight you: you want to author content that lives only in the collection (use a page or post); or you want strict non-overlapping categorization (use the category field on posts, or a reference field on custom objects).

When each shape fits and fights

Quick lookup:

Patterns worth calling out

A landing-page library past ~25 entries probably wants to become a custom object. The inability to filter, sort, and bulk-manage starts to hurt. Migrating earlier is easier than migrating later.

A "news" section used for changelogs should usually be posts with a clear category split (news, changelog, announcement). Posts handle both well; the category split keeps the streams separable.

A glossary, directory, or catalog should almost always be a custom object even if it is small. Schema enforcement (every term has a definition; every directory entry has the same fields) pays for itself the first time you template a list view.

A case study or portfolio piece should be a custom object, not a post. Case studies are referenced by other content (services pages, team members, related work). Reference fields on a custom object enable that linkage cleanly; posts cannot.

Collections are not for archives. "All blog posts from 2023" is an archive view of the post stream — the post section already produces that automatically. A collection would duplicate the listing without adding value.

Avoid the "everything is a page" default. Pages work until you need to filter, template uniformly, or cross-link entries. That's when the wrong shape starts costing hours. The reverse trap — making everything a custom object — is also real: a single about-the-company entry doesn't need a schema.

Decision rule that holds: match the shape to the content's behavior, not its form. A page that lists team members is not a team page — the underlying content is team members, and team members are a custom object.

What to do if it does not work

Symptom: a content section is hard to filter or sort. The set probably wants to be a custom object. Pages and posts have a fixed set of filterable fields; custom objects let you filter on any field you defined.

Symptom: every entry has the same fields by convention but nothing enforces it. Custom objects enforce field presence at save time. Switching from pages catches missing-field cases before they reach the template.

Symptom: a single entry needs to appear under more than one section. That's collections territory — the entry stays in one canonical place; the collection lists it alongside others that match the curation rule.

Symptom: posts feel oversized — body is short and structured fields are doing the real work. The content has outgrown the post shape. Define a custom object with the relevant fields and migrate the posts in.

Symptom: a custom object section has only three or four entries that never grew. Consider whether the entries should be pages. The overhead of a custom object pays for itself at scale; with only a handful of entries, pages are simpler.

Examples

Solo consultant's site. Five pages (home, about, services, pricing, contact) and one blog post section. No custom objects. No collections. The shape map holds for years; the content fits the model.

Mid-size consulting firm. Same five pages and blog. Plus a "team" custom object (photo, role, bio, linked case studies). Plus a "case studies" custom object (client, industry, challenge, approach, outcome, linked team members). Plus a "services" custom object replacing the single services page. The references between objects produce automatic cross-linking on every template.

Ecommerce shop with editorial content. Pages for legal/policy (Terms, Privacy, Shipping). Posts for an editorial blog. A "products" custom object with full schema (price, inventory, category, images, variants). A "lookbook" custom object (each entry references the products in it). Collections layered on top: "featured products" (manual membership), "new arrivals" (automatic, based on publish date), "summer campaign" (manual, seasonal). The shop's surface adapts to seasonal pushes without duplicating the underlying product entries.

How shape choices age

A site's content model is a living thing. New sections get added; what started as a handful of pages becomes a structured set; what started as a single feed splits into multiple categories.

Migrations between shapes are supported:

• Pages → custom object. When a page section outgrows itself. Define the object, map page fields to object fields, migrate.
• Posts → custom object. When a post section's structured fields outweigh its body content. Same pattern.
• Custom object → evolved schema. Custom objects support schema migrations with content-side fallbacks — existing entries get the new field as null until backfilled.

The pattern: pick the shape that fits today, and trust the migration path if today's shape stops fitting tomorrow. Revisit the model annually — sections that are hard to filter, hard to template, or inconsistently fielded are flagging a shape mismatch.

Connected pages

• SEO Architecture overview — how each shape affects URL patterns, schema defaults, and sitemap inclusion.
• Analytics Data Pipeline overview — how content shape affects which dimensions are available in reports.
• Staging and Versioning overview — how each shape behaves across draft, scheduled, and published states.
• Workflow and Automation overview — how content events fire automations and which shapes emit which events.
• SGEN Glossary — definitions for post, page, custom object, and collection.