Authors¶

Everything in this page is done from AdminCentral. You never edit a file.

The [H1] SEO tab¶

Page properties have a tab called [H1] SEO, and the content apps that have been enabled for it (products, case studies) have the same tab in the item form. The fields are identical in both places: a catalog product is optimised where you edit the product, not somewhere else.

Inside the tab you will find one or two panels — Metadata and Sitemap — depending on what the template needs. A detail template that lists a collection may show only Sitemap, because its own address is never published. If you expect a panel and it is not there, that is a one-time setup job for a developer, described in Developers · Installation.

📸 [Screenshot: page properties dialog open on the [H1] SEO tab, with the Metadata panel expanded showing the Content, Indexing (robots), Social, Structured data / GEO and Advanced groups]

Content¶

Empty fields fall back, they never break anything. An empty Title uses the item's own title (for catalog items, its name). An empty Description uses the Summary / TL;DR. An empty Summary / TL;DR simply means the link in llms.txt falls back to the description, and then to the title. Filling these in is an improvement, never a prerequisite.

Indexing (robots)¶

Note — No index does not remove the page from the sitemap; the field for that is Exclude from sitemap, in the Sitemap panel. The two are separate on purpose: a page can be excluded from the sitemap and still be indexable through a normal link.

Social (Open Graph / Twitter)¶

Leave Social image empty and the site's default social image is used, when one is configured. If neither exists, the share simply has no image.

Structured data / GEO¶

Leave them empty and the structured data is still generated, just with less detail.

Advanced¶

Warning — Raw JSON-LD (override) must be valid JSON. When you fill it in, Schema.org type and Topics / entities stop having any effect on the structured data — your text is published instead of the generated one. The FAQ block is published separately and is not affected.

What happens on its own¶

You fill in what adds meaning; the plumbing is generated:

• The canonical address of the page.
• The complete social card: og:title, og:description, og:url, og:type, the site name, the image and its alternative text (which reuses the title), and the matching Twitter/X tags.
• The crawler instruction built from No index and No follow.
• The publication and update dates, taken from the page itself.
• The structured data, from Schema.org type, Topics / entities and the title and description — plus a separate FAQ block whenever you have entered questions.
• The publisher block (organisation name, type, logo and social profiles), taken from the site configuration.

Sitemap¶

The sitemap is generated from the published pages. There is nothing to maintain and nothing to regenerate.

A developer creates one page named sitemap per site or brand — see Developers · Installation — and from then on:

• Its location decides its scope. A sitemap page at the root covers the whole site; a sitemap page under /brand-a covers /brand-a only.
• It is served at /sitemap.xml, and at /brand-a/sitemap.xml for a brand.
• Its own dialog holds a single read-only field, Automatic sitemap, that restates these rules. There is nothing to fill in there.

What you do control is per page, in the Sitemap panel of the [H1] SEO tab:

Left empty, Priority is calculated from how deep the page sits: 1.0 at the root, 0.1 less per level, never below 0.1. Left empty, Change frequency is weekly. A value outside 0.0–1.0 is refused when you save.

Warning — Exclude from sitemap takes the whole branch with it. Ticking it on a section landing page removes every page underneath, which is usually what you want — but it does mean one checkbox can remove many addresses at once.

There is a fourth field in that panel, Source workspace (dynamic page). It is an advanced, one-time setting a developer fills in; leave it alone. What it does is described below.

Dynamic collections¶

Some templates render one address per item — a case study detail, a product detail. Those pages are expanded automatically: instead of the template's own address, the sitemap gets one entry per item of the collection, built from the item's slug. Publishing a new case study adds it to the sitemap with no further action, and removing it takes it out.

The dates come from each item; the priority and the change frequency come from the template, because all the items share it.

Languages¶

On a multilingual site each page appears once per language, and every entry carries the full set of language alternates so Google never reads the translations as duplicates. The home page of the default language is the one exception: it is published as /, without a language prefix, because that is the address visitors actually land on.

On a single-language site the addresses are published plain, with no language information — which is correct: alternates for one language say nothing.

📸 [Screenshot: the sitemap page in the Pages app, and the resulting sitemap.xml opened in a browser]

robots.txt¶

robots.txt is the set of traffic rules crawlers read when they arrive. It lives in a page named robots, created once by a developer, and has one editable field.

Open the page properties and edit robots.txt content. What ships as the starting point is:

User-agent: *
User-agent: AdsBot-Google
Disallow: /admin/
Disallow: /.magnolia/
Disallow: /modules/

One directive per line. An empty field is valid and means "everything is allowed".

Note — the Sitemap: line is appended for you, with the right domain for whichever address the file is served from. Do not write it by hand or it will appear twice.

Same scoping rule as the sitemap: a robots page at the root serves /robots.txt, and one under /brand-a serves /brand-a/robots.txt.

📸 [Screenshot: the robots.txt content field in the page properties dialog]

llms.txt¶

llms.txt is the equivalent of the sitemap, written for AI assistants — ChatGPT, Claude, Perplexity, Gemini. It is a readable index of the site: what it is about, and which content matters.

It is fully automatic. There are no fields to fill in, because it reuses what you have already entered:

• The title and description at the top come from the site configuration.
• Each first-level page becomes a section, with its own pages nested underneath.
• Each link's description is the page's Summary / TL;DR, or its Description, or its title — whichever is filled in first. For a collection item it is the Summary / TL;DR, then the item's own description, summary or subtitle.
• Pages marked No index are left out. Your decision about search engines applies to AI too — though, unlike Exclude from sitemap, the pages underneath a hidden page still appear.
• Dynamic collections are expanded, exactly as in the sitemap.
• The sitemap, robots and llms pages themselves never appear.

It is served at /llms.txt, and at /brand-a/llms.txt for a brand. Its dialog holds a single read-only field, Automatic llms.txt.

To improve what it says, fill in Summary / TL;DR on the pages that matter. That is the only lever, and it is the same field that feeds the search snippet.

📸 [Screenshot: generated llms.txt showing the site title, the description blockquote and two sections with nested links]

The Redirects app¶

Open [H1] SEO › Redirects. Each rule sends visitors from an old address to a new one, which is what protects your ranking when a site is redesigned, a section is renamed or a platform is migrated.

📸 [Screenshot: Redirects app, list view with several rules and the rule form open]

Creating a rule¶

The three match types¶

Pick prefix to rename a section, exact for a single address, regex only when the address has to be transformed.

When several rules match the same address the most specific one wins: exact beats prefix, which beats regex; between two rules of the same type, the longer pattern wins. There is no priority to set by hand.

Languages¶

On a multilingual site you normally leave the language out of both fields. A rule written as /products/old catches /es/products/old and /en/products/old, and the visitor keeps the language they were reading in. Write a language only when you mean it: in Source URL pattern to restrict the rule to that language, or in Target URL to move the visitor to another one.

Bulk import and export¶

In a migration you will not type hundreds of rules one by one.

1. Select the root — or a brand folder — and click Import from CSV.
2. Click CSV template to download a spreadsheet with the right columns, or Full CSV export to start from the rules you already have.
3. Fill it in, upload it under CSV file, and click Import.
4. Export to CSV in the list view downloads the current rules for auditing, or to edit in bulk and re-import. Standing in a brand folder exports that folder only.

A row with an error does not abort the import: the valid rules are created and you get a message telling you how many were created, how many updated and how many failed.

Note — the round trip is safe: re-importing an export updates the rules instead of duplicating them, as long as you keep the name column untouched. That column is the identity of the row, and the marca column decides which brand folder a rule belongs to — the folder written in the file wins over the folder you happen to have open.

Where rules apply¶

A rule works on the public site and inside the platform, and takes effect within a minute of saving — no deployment, no restart.

Warning — brand folders organise the list, they do not scope it. A rule filed under /brand-a is applied to any address that matches it, whichever brand the visitor is on. Write the brand into the Source URL pattern if you need the rule to apply to one brand only.