Site Architecture Questions
Four questions to answer and record before building a site: who owns each landing route, how each listing is populated, where shared fields live, and where a repeated block comes from.
Four questions decide most of a site's architecture, and they are easy to answer by accident while writing templates. Answer each one on purpose before you build, and write down the choice and the reason. The record lets the next developer or agent see why the site is shaped the way it is, so a later change is a recorded amendment instead of a surprise.
These are prompts to think through, not a gate. There is almost always more than one valid way to build a site, and an answer that differs from the trade-offs described in the linked topics is fine when you can say why. If a question does not apply to the design (no catalog, nothing repeated), say so and move on.
1. Who owns each catalog landing route?
For each family of cards that has a listing page (equipment, services, industries), name the record that owns the route at the family's root: the Datastore itself (its own URL and listing template) or an Article that picks or fetches the items. Record the route, the owner, and why. If a datastore and an Article both describe the same family, say which one is the landing.
The trade-offs, including the datastore properties involved and what EnforceRootPath does, are in Choosing Content Ownership, under "Who owns a family's landing page".
2. How is each listing populated?
For each listing (a landing page, a section on Home, a sidebar), say whether it shows editor picks, a fetch, or both. Name the picker field and its type for picks; name the list method call, its limit, and its order for a fetch; for both, say how many picks come first and what fills the rest. Say how a link is guarded when a picked entity may have no page.
The trade-offs and a worked snippet are in Choosing Content Ownership, under "Picks, a fetch, or both". Obtain a Collection and Narrow and Order cover the fetching side.
3. Which fields are shared across datastores, and where do fields live?
List any FieldIDs that more than one datastore must carry because the datastores render through the same partial, and say where that set is declared once. For the other fields, say whether each lives on the Datastore or on a partial. A field on a partial assumes each item has a page that includes the partial, so a datastore whose items never have pages needs its fields on the Datastore itself.
The trade-offs are in Choosing Content Ownership, under "Where the fields live", and in Where Custom Fields Belong.
4. Where does a block that appears more than once come from?
For each block that shows up in more than one place (testimonials on Home and on a testimonials page, one call to action on many pages), name its source: the datastore and the picker field that selects from it. If you decide to keep separate copies instead, say so and accept that they will drift apart.
The trade-offs, with testimonials as the worked example, are in Choosing Content Ownership, under "Pages without page items".
Keeping the answers
Put the answers in the site's architecture notes before development, one short line each: the question, the choice, the reason. Change an answer later with a dated amendment that says what changed and why, rather than editing the original. The question of static versus dynamic section data is a separate decision, covered in Choosing a Content Architecture; which CMS objects a finished site needs is covered in Site Objects Checklist.