Plan your data needs
Before building templates, decide what your content looks like. What types of content will you have? What properties matter? How do they connect? CTXR uses Schema.org types, so you’re not inventing a schema from scratch — you’re picking from an existing vocabulary.
Start with your content types
Think about the distinct kinds of content your site will have. A walking route guide might need:
| Content | Schema.org type | Role |
|---|---|---|
| Locations | Place | Pages with name, description, geo, images |
| Routes | TouristTrip | Pages with a list of stops |
| Route stops | ListItem | Embedded in routes, pointing to places |
| Reviews | Review | Embedded, linked to a place |
| Overview pages | WebPage | Collection pages that curate content |
| Navigation | SiteNavigationElement | Menu with links |
You don’t need all of these on day one. Start with the types that represent your core content. You can always add more types later — there’s no schema migration to run.
Decide what’s a page and what’s a block
The key question for each type: does it need its own URL?
- Pages get a URL path, a full HTML template, and show up as standalone entries. A Place at
/fikkieis a page. - Blocks have no URL. They exist only inside other content, rendered as cards, fragments, or embedded elements. A review snippet inside a place page is a block.
The same type can be both. A Place could be a page (with a path) in one context and a block (a card on the home page) in another. The template system handles this naturally — pages/place.php for the full page, blocks/place-card.php for the card.
Map your properties
For each type, list the properties you’ll use. Schema.org gives you the vocabulary:
Place: name, description, geo (latitude/longitude), image, containedInPlace (region), identifier (external IDs)
TouristTrip: name, description, touristType (hiking, cycling), mainEntity.itemListElement (the stops)
Review: name, reviewBody, reviewRating, itemReviewed (points to the Place)
You don’t need to declare these anywhere — just use them in your templates. The platform stores whatever properties you save. But knowing them upfront helps your developer build the right templates.
Plan your references
References are how content connects. Think about:
- Which content curates other content? A WebPage curating a list of Places. A TouristTrip curating its stops.
- Which content relates to other content? A Review relating to a Place. An ImageObject relating to a Place.
Curatorial references (page includes block) trigger compilation cascades — when the block changes, the page updates. Relational references (review points to place) are resolved on demand.
The depth system keeps this orderly: pages are depth 0, components (reviews, list items) are depth 1, atoms (images, persons) are depth 2. References flow naturally within this hierarchy.
Consider external integrations
If your content relates to external systems, plan your identifiers early. A Place that corresponds to an OUP location gets an identifier:
"identifier": [{ "propertyID": "oup", "value": "1234" }]
This makes the content queryable by external ID from day one. Partners can ask “what do you have about our item 1234?” and get back the full node with all its connected content.
A practical checklist
Before your developer starts building:
- List your content types and map them to Schema.org types
- Decide which types are pages (own URL) and which are blocks (embedded)
- List the key properties per type
- Sketch the references between types (what includes what, what points to what)
- Identify any external systems that need to connect via identifiers
- Decide how many editors you need and what permissions they should have
With this plan in hand, a developer can start building templates immediately. The data structures don’t need to be configured anywhere — they emerge naturally from how you create content and write templates.