How I Model Services, Locations, and Blog Content in Strapi

I begin content modeling with editor questions. Which facts change together? Which copy must remain unique? Which page needs a relation instead of another text field? Those answers determine whether I use a collection type, single type, component, or relation.

The Strapi Content-type Builder documentation describes Strapi collection types, single types, components, and six relation shapes. I use those tools to express editorial ownership, not to mirror every frontend component.

Start with editorial decisions

I list the choices an editor makes for a service, location, and article. A service owns its offer, audience, process, and limitations. A location owns verified geographic facts and local contact context. An article owns its argument, sources, and publication metadata.

If editors cannot explain who owns a value, a shared component may hide duplication rather than solve it. I assign one source of truth before adding a relation.

Use components for repeated shapes

Components work well for structures that repeat inside several content types, such as an SEO field group or a visible question-and-answer item. The fields travel together, but the component does not exist as an independent record.

I avoid one giant page component with dozens of optional fields. Editors have trouble understanding it, APIs return noisy shapes, and validation becomes weak.

Use relations for independent records

A service and a location can exist independently, so I connect them with a relation. The relationship says that a service is available in a location; it does not create useful local copy by itself. The location page still needs a distinct purpose and evidence.

Blog posts can relate to services for internal links, but I keep the article's link text and context editable. An automatic card grid is different from a contextual recommendation inside the article.

Protect against thin generated pages

I do not publish every service-location combination. A record needs a defined audience, unique main copy, verified local facts, and a reason to exist beside the parent service page. Templates can enforce structure, but they cannot supply evidence.

I add a publication validation rule or editorial checklist that catches empty differentiators, duplicate metadata, and missing internal links before the frontend indexes a route.

Plan API queries with the model

Relations require deliberate population in Strapi 5. I decide which related fields each page needs and avoid recursive population that returns an oversized graph. Public queries select published fields; preview queries use protected credentials and draft status.

I test the rendered Next.js page, not only the JSON response. A technically correct relation can still produce duplicate headings or broken canonicals.

Review change cost

Renaming a field can make prior data inaccessible through the admin interface until it is migrated. I treat schema edits as data migrations with backups, a mapping, and a rollback plan.

• Each fact has one owner.
• Components represent repeated shapes.
• Relations connect independent records.
• Location pages require unique evidence.
• API population stays bounded.

Need help with Strapi?

Terry Hunt Dev designs content models through Strapi development services. If your CMS has duplicate service or location fields, send the current content types through the contact page after removing private records.