Content Types

Before building, list the kinds of content the site holds, and decide for each whether a built-in content type already covers it or whether it needs a datastore of its own. "Content type" here means a kind of content, such as news posts, events, or testimonials. It does not mean a custom field's Type or a Liquid value such as a string or an integer. This is the first question in Planning and Strategy because the answer decides which datastores, templates, and menus exist at all. There is more than one valid way to model most sites, so treat what follows as considerations and write the reason for each choice down.

Built-in content types
The CMS already provides content types with their own fields, editing screens, and Liquid objects. Content lists them all and links each one's reference page; the ones below are the usual starting points.
• News, a journal, or "the blog": a Blog with Blog Posts, which also bring Tags and Authors.
• Events: a Calendar with Calendar Entries.
• People who write posts or articles: Authors.
• Categories or topics for posts and articles: Tags.
• One-off pages (legal, a campaign, an editorial page): an Article with its own template and fields. Record why it is an exception if most of the site is built another way.
• Downloadable files: Documents. Pictures: Images, which Galleries can group.
• Forms that visitors submit: Forms.
• A block of editor-owned markup shown in several places: a Snippet (see Using Includes and Snippets).
• Navigation: Menus and Menu Items.
• Moved or tracked URLs: Redirects (see Site Objects Checklist). A Redirect is a built-in type but not an entity.
• Visitors who sign in or are recognized: Profiles, which drive personalization and permissions (see Personalization). Like a Redirect, a Profile is not an entity.

Custom content types as datastores
A datastore fits content the built-in types do not cover, where several items share one set of fields: services, products, locations, job openings, testimonials, FAQs, calls to action, partners, and a single settings item that holds site-wide content such as the logo, contact details, social links, and footer groups. Datastore Design covers the choices that are specific to datastores. Reusing Content covers how pages show a datastore's items without copying them.

Reimplementing a built-in type
A blog should almost always be a Blog with Blog Posts rather than a datastore whose items have pages. This is a strong consideration, not a prohibition, and the reason is what each type already provides. A Blog Post has a post date, summary, body, featured image, tags, and authors built in, and the Blog is itself the page at its URL. A datastore item has only the fields you define, so a datastore blog redefines all of those and then needs a listing template that rebuilds what {% blog_posts %} already does: filter by blog, tag, author, and date range, and order by post_date. Blog, Blog Post, and {% blog_posts %} are designed together, and the blog scenarios show the whole set. The same reasoning applies to events, files, images, forms, and menus.
A datastore is the better home for records that are not posts (locations, job openings, products), even when a listing orders them by date. If you choose a datastore for something a built-in type covers, record why. The /blog menu item should link to the Blog itself, which is the landing page, not to a separate listing Article. To build the pages, see the blog_posts method, the topics Obtain a Collection and Blog Post, and the Blog Page and Blog Post Page complete examples.

One datastore or several
Two families with the same card and detail shape but different names ("Services" and "Solutions") can be one datastore plus a discriminator field, a select or radio such as offering_kind, that listings and pickers filter on. Split them into separate datastores only when they need different fields or have different owners or lifecycles. Do not split to cut the datastore count, and do not split only because the design shows them in two sections.

Field, fieldset, or entity
Fieldsets let editors manage a consistent group of related values as one structured unit. Use a fieldset when values belong together inside one owning entity. Use a scalar field for one independent value. Use CMS entities or datastore items when each item needs its own identity, URL, querying, governance, or reuse beyond the owner, and do not reach for a fieldset when content needs any of those. For what a fieldset is and how a template reads it, see Field Values. For how to build and inspect one, see Common Template Patterns.

Links and exceptions
A link to something already in the site should be the target's own URL (for example item.full_url), never a copied path.