Template Designers: Template Layout
Specify the shared visual system and navigation behavior once, then apply it consistently to every page using the layout.
Theme and branding
The website's brand settings live on the Web record. Web.appearances stores the tokens a deployment applies: primaryColor, secondaryColor, accentColor, backgroundColor, fontSans, fontHeading, and fontMono. The deploy step maps them into the template's site config: fontSans becomes the base font, fontHeading the heading font, primaryColor the base color, and backgroundColor the page background.
Define your palette as semantic roles (primary action, background, body text, accent, focus indicator) and map each role to one of those fields. If your design needs a token the list does not cover (say, a separate surface color or a fourth font), flag it: that requires a template-level change, not a CMS edit. Web.logo and Web.favicon hold the brand assets; supply production-ready files.
Header
The header is built from the main menu: MenuItem records with kind main. Each item carries a label, url, icon, order, optional parentId for dropdown nesting, openInNewTab, target, and a linkType (URL, PAGE, POST, CATEGORY, TAG) that determines what the item links to.
Design the logo/site name, the primary navigation, the mobile menu, and any account or language controls the template supports. Define selected, hover, focus, and expanded states. Show the behavior for a long site name, long menu labels, and a menu deeper than the template supports; agree on the maximum nesting depth with the developer.
Keep the primary action clear and the mobile reading order understandable. Specify whether the header scrolls away or stays fixed, and how anchored content remains visible beneath it.
Footer
The footer uses the footer menu (kind footer) plus Web.copyright for the legal line. Social links come from Web.externalLinks, a name/URL map; specify which networks, their icons, and their order.
Include the supported secondary navigation, contact information, and policy links. Every link needs an intended destination. If a field is optional, show the layout with that field absent. copyright, social links, and secondary menus can all be empty.
Avoid assuming login, checkout, or language-switching features are available just because their buttons appear in the design. Confirm the implemented route and behavior first; analytics and messenger integrations exist (Web.integrations holds Google Analytics, Facebook Pixel, Google Tag Manager, and a messenger brand code), but visible features such as search or cart depend on the template.
Handoff checklist
| Element | Stored in | Confirm with the developer |
|---|---|---|
| Color roles | Web.appearances.primaryColor, secondaryColor, accentColor, backgroundColor | Which role maps to which field; any missing token |
| Fonts | appearances.fontSans, fontHeading, fontMono | Loading method and fallbacks |
| Logo, favicon | Web.logo, Web.favicon | Sizes, formats, dark-mode variant |
| Header navigation | MenuItem kind main | Max depth, icons, mobile collapse |
| Footer navigation | MenuItem kind footer | Grouping and column layout |
| Copyright line | Web.copyright | Text and whether year is dynamic |
| Social links | Web.externalLinks | Supported networks and icons |
| Tracking/messenger | Web.integrations | Which IDs the deployment needs |
Handoff and review
Provide shared components and variants, token mappings, mobile behavior, and examples of long or missing content. Review the layout on a content page and an application page if both use it.
