--- title: Manage site-wide content description: Put the address, the social links and the footer text in one editable place, and read them from any template. updated: 2026-08-19 --- Some content belongs to the site rather than to a page: the postal address, the phone number, the social links, a copyright line, an analytics tag. Hardcoding it in the layout means an editor cannot change it, and duplicating it on every page means it drifts. Global fields are the third option.

Live example: Lisière. Its global fields carry the site-wide values its footer renders.

## 1. Declare the fields Global fields are declared once, in their own settings block, grouped in tabsets like any other type: This is Lisière's, in full. Two tabsets, because the editorial values and the technical ones do not belong on the same screen: ```yaml tabsets: infos: name: Infos fields: brandName: type: text label: Nom de la revue translatable: false baseline: type: text label: Baseline translatable: true email: type: text label: Email de la rédaction translatable: false social: type: textarea label: Réseaux sociaux info: Un lien par ligne (Instagram, Mastodon, etc.) translatable: false copyright: type: text label: Mention de copyright translatable: false site: name: Paramètres du site fields: GA: type: text label: Tag Google Analytics translatable: false ``` Two things to read off it. **`translatable` is per field, not per tabset**: the baseline is prose and gets translated, the email address and the analytics tag are the same string in every locale and are marked `false` on purpose. And **tabsets are only a back-office grouping** — in a template every global is flat, `globals.baseline`, never `globals.infos.baseline`. ## 2. Read them anywhere ```liquid

``` `globals` is available in every template, including partials, without being passed down. That is the point: the footer partial reads it directly. Guard optional values the same way as any field, since a global an editor has not filled yet is empty, not missing: ```liquid {% if globals.email != blank %}{{ globals.email }}{% endif %} ``` ## 3. Fill them Values are written with `update-global-fields-data`, where `data` and `translations` are JSON-stringified. Translatable globals follow the same rule as everything else: one locale per write. ## 4. Know what does not belong here | Content | Where it belongs | |---|---| | The address, social links, the copyright line | global fields | | Interface labels such as "Read more" | the dictionary, through `{{ 'Read more' | _ }}` | | A block an editor drops on several pages | a content-type, reused | | A list that grows | a collection | The line to hold is that global fields are for **single values reused everywhere**, not for content with a structure. A footer's three columns of links are a navigation, not three global text fields. ## Related