A website CMS that fits
the content, not the other way around.

Begin with the information you need to manage.

Articles, projects, people, and topic pages each have a recognizable purpose. Build an inventory of real examples before choosing fields. Note where information repeats, what is missing, and who knows how it should be maintained.

The content model guide turns that inventory into useful types, fields, and relationships. Its examples focus on meaning rather than tying every field to a decorative component in the current design.

Keep structure helpful, not burdensome.

Give each field a reason to exist. Record where it appears, whether it is required, and what a good value looks like. A category field should help organize content; an unused collection of optional metadata should not become a new weekly chore.

Use help text to explain decisions. A summary field can describe the reader’s takeaway rather than simply repeat the instruction to enter a summary. Distinguish an incomplete draft from content that is ready to publish.

Plan for relationships and change.

An article can refer to an author or topic without repeating its entire description. Decide what happens when that related item is renamed, unpublished, or removed. Keep those behaviors understandable to editors, not just to the developer who configured them.

Treat URLs and dates deliberately. Record existing addresses before a migration, preserve known publication information, and avoid giving old content a new update date merely because the design changed. Document schema changes so that future maintainers can follow their meaning.

Evaluate the workflow with real people.

Ask an editor to create a varied set of content using only the labels and instructions you provide. Watch where they hesitate. Then ask a reviewer to approve a change and a maintainer to recover one. This connects the model to the actual work rather than judging the CMS by a feature checklist alone.