<p>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.</p><p>The <a href="https://docs.strapi.io/cms/features/content-type-builder">Strapi Content-type Builder documentation</a> 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.</p>

<h2>Start with editorial decisions</h2>

<p>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.</p><p>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.</p>

<h2>Use components for repeated shapes</h2>

<p>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.</p><p>I avoid one giant page component with dozens of optional fields. Editors have trouble understanding it, APIs return noisy shapes, and validation becomes weak.</p>

<h2>Use relations for independent records</h2>

<p>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.</p><p>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.</p>

<h2>Protect against thin generated pages</h2>

<p>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.</p><p>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.</p>

<h2>Plan API queries with the model</h2>

<p>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.</p><p>I test the rendered Next.js page, not only the JSON response. A technically correct relation can still produce duplicate headings or broken canonicals.</p>

<h2>Review change cost</h2>

<p>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.</p><ul><li>Each fact has one owner.</li><li>Components represent repeated shapes.</li><li>Relations connect independent records.</li><li>Location pages require unique evidence.</li><li>API population stays bounded.</li></ul>

<h2>Need help with Strapi?</h2>

<p>Terry Hunt Dev designs content models through <a href="/services/strapi-development">Strapi development services</a>. If your CMS has duplicate service or location fields, send the current content types through the <a href="/contact">contact page</a> after removing private records.</p>

See how I approach Strapi content modeling for services, locations, blog posts, reusable components, relations, and safeguards against thin pages.

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

Model services, locations, and articles in Strapi without duplicating facts or generating thin location pages.

<p>A Strapi multi-site setup uses one content platform to support more than one website, brand, region, or audience. The hard part is not adding a <code>site</code> field. The hard part is deciding which content is shared, which content must stay separate, and which editors can publish to each destination.</p>

<h2>Choose the ownership model first</h2>
<p>Before building content types, list the sites and the people responsible for them. Decide whether each site shares legal ownership, infrastructure, release schedules, security requirements, and editorial governance. Separate Strapi instances are often safer when organizations have different administrators, compliance boundaries, or failure tolerance.</p>
<p>A shared instance is a better fit when one team governs the sites, content reuse has clear value, and the organization accepts a shared operational dependency.</p>

<h2>Three practical Strapi multi-site patterns</h2>
<h3>1. Site relation on each entry</h3>
<p>Create a <code>Site</code> collection with fields such as name, key, domain, locale defaults, theme reference, and publishing status. Content entries relate to one or more sites. The frontend requests entries for its site key.</p>
<p>This pattern is explicit and easy to query. It also requires validation so editors cannot publish an entry with missing or conflicting site relationships.</p>

<h3>2. Shared entries with site-specific overrides</h3>
<p>Keep reusable information, such as an organization description or service definition, in a shared entry. Store site-specific title, introduction, call to action, or metadata in related override records. This reduces copied content while preserving local or brand-specific language.</p>
<p>Use overrides only for fields that need them. A content model with an override for every field becomes harder to understand than separate entries.</p>

<h3>3. Separate instances with a shared frontend package</h3>
<p>Some organizations should keep content and permissions in separate Strapi instances while sharing frontend components, schemas, and deployment tooling. This costs more to operate but reduces the effect of one site's publishing or infrastructure problem on the others.</p>

<h2>Example content model</h2>
<pre><code>Site
- name
- key
- primaryDomain
- defaultLocale
- active

Page
- title
- slug
- site (relation)
- pageType
- sections (dynamic zone)
- seo (component)
- publishStart
- publishEnd

GlobalSetting
- site (relation)
- navigation
- footer
- contactDetails
- defaultSeo</code></pre>
<p>Use a composite rule in application logic for <code>site + slug</code>. A slug that is unique in one site may be valid in another, so a global slug rule can block legitimate pages.</p>

<h2>Query by site, not by hostname alone</h2>
<p>The frontend should resolve the current site from controlled configuration, then request content with that site key. Do not trust an arbitrary request hostname to select private content. Preview and webhook endpoints need the same site validation.</p>
<p>Cache keys and revalidation tags should include the site identifier. Otherwise, publishing one site's page can invalidate or overwrite another site's cached response.</p>

<h2>Roles, permissions, and editorial boundaries</h2>
<p>Strapi roles can limit administrative actions, but the exact site-level permission model needs testing against your Strapi edition and workflow. If editors must be isolated from other brands or legal entities, confirm that the required restrictions apply in the admin interface and API. Use separate instances when the boundary cannot be enforced and audited.</p>

<h2>SEO requirements for every site</h2>
<ul>
  <li>Generate canonicals from the correct domain and route.</li>
  <li>Keep XML sitemaps separate by hostname.</li>
  <li>Store site-specific titles, descriptions, social images, and robots directives.</li>
  <li>Use structured data that names the correct organization and visible service area.</li>
  <li>Prevent preview, duplicate-domain, and inactive-site URLs from being indexed.</li>
</ul>
<p>Shared content does not mean every site should publish the same page. Each site needs a reason for the page and enough distinct information to serve its audience.</p>

<h2>Deployment and recovery planning</h2>
<p>A shared Strapi instance creates a shared dependency. Review database backups, uploaded media, environment separation, migrations, restore testing, rate limits, monitoring, and the effect of a failed deployment on every site. Record how each frontend behaves if the CMS is unavailable.</p>

<h2>Questions to answer before building</h2>
<ul>
  <li>Which content is shared, localized, or owned by one site?</li>
  <li>Can an editor see or change another site's content?</li>
  <li>Who approves global changes?</li>
  <li>How are domains, redirects, previews, and sitemaps generated?</li>
  <li>Can one site deploy or recover without the others?</li>
</ul>
<p>A short architecture review can answer these questions before the content model hardens around the wrong ownership assumptions. See <a href="/services/strapi-development">Strapi development services</a> for implementation help and the <a href="/portfolio/railway-and-strapi-projects">Strapi and Railway portfolio</a> for related project context.</p>

Plan a Strapi multi-site CMS with site relations, shared content, permissions, routing, SEO controls, cache isolation, deployment, and recovery.

Content Modeling Resources & Benchmarks

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

How to Structure Strapi for Multiple Websites

Need hands-on help with Content Modeling?