Home and landing pages
The home page is not a template but a data file: the sections list in
data/home/<language>.yaml decides which sections the page has from top to
bottom, and each section’s content is looked up by name in the same file. An
ordinary page with layout: landing uses the same sections.
Every section is rendered on the server. Prices, star counts, screenshots, avatars and download states all have to exist in the repository before Hugo starts; no section fetches data in the browser.
A site migrating from Docsy’s blocks/* home page has to rewrite it: the theme
has no blocks/cover, blocks/section or blocks/feature shortcodes, and
keeping them fails the build with
template for shortcode "blocks/cover" not found. The two ways forward are the
data/home/<language>.yaml described here, or layout: landing on an ordinary
page.
Where the home page’s data lives
The home page’s content file keeps only a title and a description:
Section data is a file per language:
home page data
data/
home/
- en.yamlEnglish home page
- zh.yamlChinese home page
The lookup order is data/home/<current language>.yaml → data/home/en.yaml →
data/home.yaml for a single-language site.
The file has only two levels: a sections list, and the same-named keys that
list references.
That is how this site’s home page is written; the complete file is
data/home/en.yaml in the repository.
A minimal working home page
Paste the following, replace the text and links, and it publishes. Write
internal links as site paths without a leading slash, and the theme adds the
current language prefix (docs/start/ → /docs/start/).
Hero
The hero is the first screen, and the only section with a large title and an illustration.
Without title_lines it uses title, and without either the site title. The
image is a CSS background: with an alt the container carries role="img", and
without one it is hidden from assistive technology.
align: center gives a text-only centred first screen: the text block widens
and centres, the title balances its line breaks, and note moves below the
buttons. It does not accept image, and having both fails the build.
The section registry
There are 22 section types, named with hyphens (underscores in older data are
normalized). Apart from the hero, each shares the three heading fields
eyebrow / title / desc (or text) plus a class.
| Type | What it holds |
|---|---|
hero |
The first screen: large title, buttons, a theme-following image |
metrics |
Numeric facts, with optional count animation and source links |
capabilities |
Alternating left-right capability narratives with a dedicated visual panel |
principles |
Numbered product principles |
cards |
A general card set: features, scenarios, entry points |
logo-wall |
Tools and partners, as a grid or a pure-CSS marquee |
gallery |
A wall of screenshots |
testimonials |
Quotations with attribution |
contributors |
People, roles, avatars and links |
faq |
Questions and answers, collapsible or flat |
markdown |
A stretch of free Markdown |
cta |
The closing call to action |
pricing |
Pricing tier cards |
pricing-compare |
A tier-by-feature comparison matrix |
command-box |
One copyable command |
steps |
An ordered procedure, optionally with commands |
timeline |
Dated milestones |
code-plate |
Code inside a presentation panel |
preview |
A stretch of Markdown source beside what it renders as |
case-study |
A case: metrics plus a quotation plus a source |
download |
One or more data/download/ records |
bar-chart |
Numeric comparison without any chart JS |
A misspelled type does not silently disappear: the build emits an
unknown section type warning and skips the section. Adding
--panicOnWarning in CI turns that into a build failure.
The commonest sections, minimally
Cards and capability panels are the two used most. cards controls its column
count with columns:
capabilities is one capability per screen with a structured visual panel on
the right, and visual.type must be one of shell, components, code,
image or card:
Minimal YAML for the other ten scenario sections
These fragments come from the theme repository’s executable regression
fixture tests/site/data/landing/demo/en.yaml,
and the field names can be copied.
The download section consumes exactly the data/download/<key>.yaml from
Releases and downloads, introducing no second version
model.
Turning any page into a landing page
Two lines of front matter make an ordinary content page a landing page: a full-width canvas that keeps the navbar, the command palette and the footer, and drops the sidebar and the outline.
The data lives in a directory parallel to the home page’s, likewise split by language:
landing page data
data/
landing/
pricing/
- en.yaml
- zh.yaml
A non-home landing page looks for its data in this order, and fails the build rather than rendering an empty page when nothing is found:
sectionsin the page’s front matter;data/landing/<key>/<exact language>.yaml;- The exact-language entry inside a single
data/landing/<key>.yaml; - The English or language-less record.
Small amounts of data can go in front matter, but landing: and sections: are
mutually exclusive:
Writing a section entry
Each item in sections is either a type-name string or a map:
| Key | What it does |
|---|---|
type |
The section type; omitted, key is used as the type |
key |
Which key to read data from, defaulting to the same name as type; use it to distinguish two uses of one section |
data |
Inline data, so no top-level key is looked up |
id |
The section’s anchor ID, generated from key / type by default |
enabled: false |
Disables the section while keeping its data |
partial |
Swaps in the site’s own partial. A local template convention, not portable landing data |
Languages and local facts
Narrative text belongs in per-language files (zh.yaml / en.yaml). A shared
record of facts can also fall back field by field: <field>_<exact language> →
<field>_<base language> → <field>, with - in a language tag normalized to
_. A Chinese site resolves title_zh_cn, then title_zh, then title.
camelCase suffixes are not accepted.
Display text inside a section is site data, not the theme’s i18n strings. Only the theme’s own controls — marquee pause, pricing states — use translation keys. Configuring a multilingual site as a whole is in Languages.
A few optional facts on the landing shell are local too, written in hugo.yml
and never fetched at runtime:
The footer is not home page data: it reads data/footer/<language>.yaml (or
data/footer.yaml on a single-language site), and this site has one per
language. A leftover footer key in data/home/<language>.yaml fails the build
with a message naming the new location. How to write it is in
Navigation and menus.
Output
| Output | What appears |
|---|---|
| HTML | The full static section content, plus landing.js loaded on demand for reveal, counting, copying and theme image switching |
| Content kept; dynamic surfaces such as the marquee become a static grid, and controls are removed | |
| Markdown | Titles, prose, lists, tables and code, with no component classes |
| RSS | Landing sections are not emitted |
With JavaScript disabled the server-rendered document is still complete. The marquee’s duplicate track stays out of the accessibility tree, and pausing uses a checkbox that needs no JavaScript; with the reader’s reduced-motion preference on, movement and reveal are switched off.
Verify
- The build is warning-free:
hugo --printPathWarnings --panicOnWarning. A misspelled type, a missing data key, andlandingalongsidesectionsall surface here. - Open the home page and any landing page, compare each section against the data file, and look at every language.
- Reload with JavaScript disabled: the content is still there, only without motion.
- Look at both light and dark, confirming
image.lightandimage.darkare each correct. - When deploying to a subpath, confirm internal links and images all carry the prefix.
Related
- Brand and appearance — site name, logo, colours and fonts
- Navigation and menus — navbar, footer and the language menu
- Releases and downloads — the data behind the
downloadsection - Languages — enabling languages and splitting data by language
- Configuration — full definitions of
params.ui.landing_searchand the rest