A section defines WHAT can render; a template defines what a page STARTS as. Each templates/<page_type>.json file in the bundle is an ordered list of section instances — type, position, settings, and (for block-capable sections) explicit starting blocks with stable ids you choose.

Empty settings ({}) are correct in templates: schema setting defaults materialize per-section at install. Set explicit values only where the template's composition differs from the schema default.

A theme can ship more than one look for the same surface. Name the file __.json — page__contact.json, product__preorder.json — and give it a name in the JSON ("name": "Contact"); that name is what merchants see in the template picker. The composition inside is ordinary: any sections the surface allows, in any order.

Merchants assign templates per resource: a Page, a product, or a blog post carries a template handle, chosen in its admin form. A resource with no handle renders the base template. If the active theme has no template matching a resource's handle — a theme switch, say — the platform falls back to the base template explicitly, so a configured page never renders blank.

This is how contact pages work end to end: the merchant writes an ordinary Page, assigns the Contact template, and the template's contact section carries the contact_submit form. Nothing about contact is a special page type — the Page provides the words, the template provides the form.

Standard surface keys: home, shop, product, collection, collection_list, category, category_list, page, policy, blog, blog_list, blog_category, vendor, vendor_list, brand, brand_list, search, cart, wishlist, account, login, register, not_found — plus store-state pages (coming_soon, maintenance, password) and the global surfaces below. Alternate templates (product__summer) use the double-underscore suffix.

Four surfaces render on EVERY page around the page template: global_body_start (header, announcement), global_body_end (footer), global_overlay (drawers, popups, localization prompt), and the head surfaces (global_head, global_compliance_head). They are compositions like any other — sections, blocks, settings — but they are edited ONCE and apply everywhere.

Editing a global section from the Global Sections view changes it EVERYWHERE. Editing the same section while a specific template is open materializes a per-template OVERRIDE: that template gets its own copy; every other page keeps the theme default. Resetting the override deletes the copy and the template falls back to inheriting the global again. Themes do not declare any of this — it is platform behavior over the same sections.

Visibility is the template's lever, not duplication: a template can hide a global section (disabled on the override) rather than shipping a second variant of it. One footer, overridden where a landing page needs it quieter — never two footer sections.