Short answer: Headless CMS content modeling means describing your content as typed, reusable records (an article, an author, a product, a location) with fields and references between them, and leaving page layout to the front end. Model the things your business talks about, decide early which fields are translated into Hebrew and which are shared, and the same content can feed the website, an app and AI answer engines.
Key takeaways
- Content types hold records: in Strapi, collection types manage many entries and single types manage exactly one, such as a site settings record.
- Components are reusable field groups: they cannot exist on their own, and Strapi's dynamic zones let editors stack them in any order.
- Localization is a modeling decision: Payload and Contentful translate per field, while Sanity documents both field-level and document-level approaches.
- Structure carries into search: clean fields simplify hreflang pairs, structured data and plain text that AI systems can quote.
Content types, components and references
Start with nouns, not pages. List what the business publishes: services, case studies, people, locations, articles. Each becomes a content type with typed fields and validation rules. A group of fields that repeats across types, such as an SEO block with title, description and share image, becomes a component. Strapi's Content-type Builder defines all three, and Sanity, Contentful and Payload have direct equivalents under different names.
References connect the records. An article references its author and its related services; it does not copy the author's name and photo into its own fields. Change the author once and every page updates.
Localization for English and Hebrew
Decide per field what is translated. Titles, body text and slugs are language-specific; prices, dates and product codes usually are not. Payload marks a field with localized: true and falls back to the default locale when a value is missing, and Contentful uses field-level localization by default. Sanity's guide notes the trade-off: field-level keeps languages in one document but publishes them together, while document-level lets each language publish on its own schedule. In Strapi, localization is enabled per content type and per field.