Notion CMS Guide

Build and maintain a website in Notion. Write the content with native blocks, organize the website in one CMS database, and use Themes to give each component its intended presentation. Local Notion downloads that source and generates the website's pages, media and routes.

This guide starts with everyday editing and a small complete website. It then explains page structure, reusable design, navigation and publication. The appendices retain the full CMS schema, Tags and stock Theme lookup. Installation and the complete command reference belong in the Local Notion Manual .

1. Start in Notion

One CMS database can supply the whole website. Each row is a Notion page: its properties describe its role and website location, while its body contains the words, pictures, columns and links visitors will see.

Open a row to edit its content. Use the table to manage properties such as Type, Status, Themes and Sequence. A filtered database view makes this easier without creating another CMS or moving the underlying rows.

Understand the Four Responsibilities

A Theme cannot publish a Draft Page, create a missing image or provide a form submission service. A Notion database view does not determine which rows the website publishes.

Keep the website's content and shared components in one CMS database. Use their Types and locations to compose pages instead of creating a separate database for every visible component.

The body remains native Notion content. The database properties connect that content to the website's structure and presentation.

Choose the Right Owner

Use Page for a complete article or compact page; Section for one band of a longer page; Gallery for a growing collection of cards with detail pages. Use Header, NavBar and Footer for shared framing. Internal is an advanced customization owner.

Begin with the row that owns the content you want to change. Editing a Footer's text is different from hiding that Footer on one Page. Styling an image is different from changing the background of its Section.

Check Your Executable and Theme Package

Check the selected executable's help before following a command recipe:

localnotion --help
localnotion create-cms --help
localnotion git --help

If a command is unavailable, use the documented alternative for that build. Keep older compatibility notes tied to their named renderer rather than applying them to every website. The stock Theme lookup also does not install custom theme packages.

2. Build a Small Complete Website

Create a homepage, an About Page, navigation, a Footer and a small card collection. Use these neutral names as examples and substitute your own public content.

Create the Homepage

Open the row and add an introduction, a Heading 2 and supporting text. Insert a real Image block with a useful caption. The standard Page template can display Item as the title; avoid adding a duplicate Heading 1 unless the selected page design deliberately owns that title.

Leave the Themes selection empty for the first preview. Selecting the Theme named empty is different: that Theme intentionally suppresses visible content.

Add About, Navigation and a Footer

Create About Us, Type Page, Status Published. Leave its address fields blank for the calculated /about-us route. Write the Page and its Summary.

Create Shared Navigation, Type NavBar, and Shared Footer, Type Footer, with blank address fields. Add labelled links to Home, About Us and Cards. Use public contact information in the Footer. Root framing can be inherited by descendant routes, so author it once.

For a website still using the legacy 1.5.0.12 renderer, follow the framing compatibility note in Appendix A.3. Its Hidden framing workaround prevents an older composition defect; Hidden does not disable framing selected for a route.

Add a Card Collection

Add a Summary, first Image and detail content to each row. Select @UseFirstImageAsFeature when that image should be preferred for the card. The collection is /cards; Website Service opens /cards/website-service. Gallery categories provide badges and filter values rather than extra URL levels.

Products, photographs, articles and team members can all be Gallery subjects. The subject does not change the component's behavior.

Compare the Collection and Its Detail Pages

Each Gallery row supplies both a card and the Page it opens. Keep category spelling consistent, use comparable image proportions and write Summaries that help visitors choose a card.

Test a category filter, open a card and follow the route back to the collection. A card's appearance alone does not prove its destination works.

A collection's category filters come from its Gallery rows. Keep labels consistent and choose categories that help visitors find the right subject.

Selecting a filter changes the visible cards; it does not change the underlying CMS Type or move the card Pages.

3. Structure Pages, Sections and Child Pages

Let the CMS Calculate Normal Routes

For an ordinary Page, Local Notion combines consecutive nonblank Root and category fields with Item. Fill the hierarchy without gaps.

A blank Root stops ordinary category traversal; Category2 cannot skip a blank Category1. Database relations and view order do not define this hierarchy.

Leave Custom Slug blank for normal calculated routes. Use an override only for a deliberate routing requirement, such as / for a simple Page homepage. Enter a page path, not a complete domain or an anchored visitor link. A literal # in Custom Slug does not create a Section anchor.

Compose a Longer Page from Sections

Create Published Sections with the same base location and distinct Sequence values. For a /studio page:

The Sections become one continuous route. Their titles supply Section anchors; they do not become three independent detail Pages. Leave space between Sequence values so another Section can be inserted at 15. Equal values do not establish a dependable editorial order.

Keep one composition strategy at each route. Before replacing an ordinary Page with a Section group, move or retire the competing Page and regenerate the affected route.

Give Each Section a Clear Job

Use an introduction to explain the page, a content band to develop the subject and a closing band for the next action. Separate Sections make those pieces independently editable and allow compatible presentation choices.

A first Section is still body content. It does not become the website's Header merely because it comes first.

Create Detail Content as Native Child Pages

Insert a native Page block inside the owning Page or Section where its link should appear. Open that child Page and write only the detail belonging to that subject. For example, a Services Section can contain child Pages named Architecture, Implementation and Support.

A child of a Section uses the Section's base route, without its fragment, then appends the child's title. For example, a Details child of /company#services becomes /company/details. Verify the calculated result rather than inventing an HTML filename or manually repeating the title in a separate external link.

Native child Pages inherit their owner's publication, scheduling, Tags, authentication and category context. Their Summary is not simply copied. A child Page is not another CMS database row with its own independently editable Type and publication properties. Choose a separate CMS row when those controls must be independent.

Keep Links and Containment Consistent

A real child Page establishes containment. A Link to Page alias points to an existing Page and does not move or reparent it. Neither a database view nor a URL override changes native containment.

Keep the child link in the intended position in the parent body, use one native Breadcrumb near the beginning of the child, and test the generated Page and its return navigation.

4. Manage Editing Views and Publication

Create focused views of the same CMS database. Views are editing tools; they do not publish, hide, reparent or reorder website content by themselves.

For a Services editing view, show its overview Section rows rather than every row whose name contains “Services.” Use exact Type and address conditions. Give independently authored detail-page Sections their own view when they belong to another route. Native child Pages remain within their owning content rather than becoming duplicate CMS rows.

Keep an unfiltered administrative view. Hide irrelevant columns in routine views instead of renaming or removing required properties. Show Item, Type, Status, Themes and Sequence when arranging a Section group.

Ordinary Page, Section and Gallery content requires Published and no future Publish On date. The date is evaluated against UTC during generation. Draft, QA and Hidden do not publish ordinary content. A scheduled or Hidden change takes effect only after the next completed download, render and publication cycle.

Framing is selected independently of that ordinary-content gate. A Draft Footer can still frame a Page. Use deliberate placement or the supported hide Tags on the content owner to change framing behavior. Appendix A gives the complete rules.

5. Write and Arrange the Content

Use Real Structure

Use native headings for the reading hierarchy, paragraphs for explanation and lists for parallel points. Choose heading levels for their meaning, then use the theme to adjust their visual size. A small-looking heading is still a heading; a bold paragraph is not a substitute.

Write clear titles in consistent Title Case, preserving names such as .NET, iOS and scikit-learn. Keep the main title stable and descriptive. Short labels may use a different treatment when the design calls for it; do not apply an uppercase transformation to every heading or link.

Build Columns in Notion

Drag a block beside another to create native columns. Put the main heading and introduction before supporting columns when that provides the clearest reading order. On a narrow screen, columns stack in their authored order.

columns_md changes the breakpoint behavior of an existing column list. columns_middle aligns shorter content within available height. Neither creates columns from ordinary paragraphs.

Distinguish Badges, Links and Lists

Format a short span as inline code and select badge to make a static label. Use a compatible auxiliary color for its accent. A separate Code block is a different element. A badge is not automatically a link, and a list of tool names should not become a row of unrelated destinations.

Create a labelled link only where navigation is intended. Embedded Page links open their actual Pages; ordinary rich-text links need real destinations. bullet_check decorates native bullet points with check-circle markers; it does not create interactive checkbox state.

Preserve native link indicators when changing a theme. Check icon-to-text spacing, first-line alignment and wrapped labels. Hover and keyboard focus should remain visible against the owning Section's background; an underline on interaction can clarify the destination without making every resting label bold.

Use Notes as Notes

An ordinary Callout is useful for an information or warning note. Use a concise message, appropriate icon and readable block background.

callout_card has a different contract: the Callout's own text is a destination URL, while its child blocks supply the visible content. Do not apply that modifier to a prose note unless it is intentionally being authored as a link card.

Render Mermaid Diagrams

Local Notion renders native Notion Code blocks whose language is Mermaid as diagrams in HTML output. Create a Code block, select Mermaid from its language menu and enter the diagram definition directly, without Markdown fences. Add a caption in Notion when the diagram needs a description. No additional CMS theme, HTML injection or page-specific script is required.

flowchart LR
    Notion["Notion CMS"] --> Local["Local Notion"]
    Local --> Website["Published website"]

A successfully rendered diagram appears above a collapsed Diagram source control. Readers can open that control to inspect its definition. A diagram with invalid syntax shows an explanation and keeps its source visible; other diagrams on the page continue to render. Ordinary Code blocks retain their normal code presentation.

Pull, Render and Publish

Use the normal pull command to fetch Notion edits and render them, or use render to rebuild content already stored locally. Mermaid introduces no separate command. Replace PAGE_UUID with the containing Page's ID and use your repository path.

localnotion pull --path "./my-website" --objects PAGE_UUID --render true --fault-tolerant false
localnotion render --path "./my-website" --objects PAGE_UUID --fault-tolerant false

Both operations write repository output and can invoke its configured Git commit/push behavior. Check the repository's Git settings before running them; use a separate repository with Git disabled for a local-only preview.

Publish the generated render-assets directory with the HTML. The diagram stylesheet, Mermaid bundle and initializer use public generated paths beneath render-assets/assets; the accompanying license files are part of the output. The same runtime is supplied for online and offline rendering, with no Mermaid CDN fallback. An offline export therefore needs its asset files as well as its HTML. Keep .localnotion and .git inaccessible to website visitors.

Compatibility and Diagram Labels

The bundled Mermaid 11.12.0 runtime uses strict security with HTML labels and click callbacks disabled. Use plain-text labels rather than HTML markup. Diagram directives cannot relax these security settings. Custom renderer templates must retain the Mermaid template's runtime token and its source, display and error hooks.

6. Compose a Reusable Theme

Separate Base Design, Modifiers and Companions

A base theme establishes the site's visual language. Native modifiers adjust supported concerns such as image width, spacing, color, shapes and motion. A reusable companion can define a semantic component such as an introduction, feature grid or closing action band.

Use the selected package's documented owner, block structure and order. Later overlays can replace earlier templates or tokens, so an intentional companion may need to come after a native modifier. A Page-link companion, for example, can replace the ordinary link slot while retaining the native destination and icon contract.

Do not assume every modifier remains a harmless cosmetic layer under every companion. Use one deliberate choice for a concern rather than stacking contradictory alignments or colors. Custom package names are separate from the stock preset lookup and must be installed before selection.

Put Styling in the Styling System

Make reusable visual changes in theme templates, tokens and styles, then select them through the owning CMS row. Preserve native content, semantic roles and existing modifiers that remain compatible. Avoid putting a complete stylesheet into each Page or editing generated HTML as a permanent fix.

Internal rows can provide named tokens consumed by compatible themes. Use them for supported configuration rather than duplicating large page-specific scripts. A native child Page does not acquire its own CMS Themes property: its presentation follows the renderer's inheritance and package contract.

Choose Color Roles Deliberately

Inline Notion colors and component templates can override inherited colors. Inspect actual text, links, badges and hover/focus states against each light or dark surface. A named color does not establish adequate contrast by itself.

Join Sections with Space and Shape

Select top and bottom padding on the owning Section. Container padding and internal paragraph margins are different sources of space. A separator also needs enough clearance to avoid crossing headings, pictures or links.

Version Theme Assets Together

Templates and their CSS or JavaScript are one design package. When an asset changes, update its versioned URL consistently wherever the package loads it. Use the package's supported token and asset-path conventions; cross-package references must point to the package that actually owns the asset.

Check the generated URLs and served bytes after publication. A changed filename query is useful only when it identifies the new asset. Do not change unrelated runtime files merely to force a refresh.

Local overrides, including empty files, can mask newer embedded defaults. Preserve intended overrides during upgrades and review their lifecycle before removing them. A later repository opening can restore missing built-in files.

7. Add Images, Headers, Cards and Galleries

Preserve an Image's Natural Proportions

Insert a real Image block, use sufficient source detail and give it a descriptive caption. In compatible CMS templates, the caption also supplies alternative text. A cover, body image and listing feature image have different jobs.

Use image_framed or image_shadow when that treatment suits the picture. Choose the shadow target before its shared strength. image_zoomable controls click-to-enlarge behavior; animate_image_zoom controls an entrance effect. Test opening and closing the viewer separately from the image's resting appearance.

Create a Header with More Than One Slide

A Header is separate framing. In the compatible carousel template, each native Toggle supplies a slide containing its heading, copy, action and images. Add several genuinely different slides when a rotating banner is intended.

An Image captioned exactly {BACKGROUND} is treated as the slide background. Use it when cropping is appropriate. Foreground artwork is a separate image and can retain its natural dimensions. Keep any intended overlay or contrast layer as part of the theme's design rather than removing it while replacing artwork.

Header size, fade, controls and particle treatments depend on their actual templates and scripts. Check the active slide, Next/Previous controls, readable overlay and narrow layout. A still picture does not prove a carousel cycles. The Toggle's expanded state in Notion is not a reliable way to choose a different renderer template.

Author a Small Fixed Card Grid

Create native columns with one Callout per card. Put the destination URL in the Callout's own text and the visible heading, image and description in its child blocks. Select a compatible callout_card treatment and appropriate card colors on the owner.

Keep cards comparable in length and check both the outer card and any deliberate child links. With legacy near-full-column-height card templates, arrange additional cards as another column row rather than stacking them within the same column.

Use Gallery rows instead when the collection should grow, carry categories and provide individual card Pages. Authored Callout cards and generated Gallery cards are different mechanisms even when they look similar.

8. Add Navigation, Forms and Motion

Use Native Destinations and Breadcrumbs

Use descriptive navigation labels, verify the calculated route and preserve the native Page-link target where possible. Add one native Breadcrumb near the beginning of a detail Page. Check its ancestry and return link after moving or renaming content.

A root NavBar or Footer can be inherited unless a nearer component replaces it. Headers are local by default; @UseParentHeader requests the parent's Header and @HideHeader takes precedence. Apply hide Tags to ordinary content, not to the Footer or Header itself.

Test fixed or sticky menus on a long Page. They must leave titles, breadcrumbs, anchor destinations and the Footer visible. Link styling for ordinary content does not necessarily apply to NavBar templates.

Embed Forms Deliberately

An Embed block or supported integration can display a form, but a button theme and @ContactForm do not create a submission backend. Configure the actual form provider, destination and success behavior.

Match the containing Section to the form's surface. A theme outside a third-party iframe cannot freely restyle its internal fields; use the provider's own supported settings. Check labels, required fields, focus, narrow layout and the real submission flow using appropriate test data.

Keep Typed Text Secondary to the Title

Use a short typed Heading 2 or Heading 3 for a capability line when the selected theme supports it. Separate phrases with a vertical bar, for example Design the System|Build the Product|Operate the Service. Keep the main title and navigation stable.

The typing library and compatible template must both be present. Preserve readable text when motion is reduced or the script is unavailable. Check the actual theme definition before combining typing with shadows or other heading replacements.

Apply other motion only after the static layout is sound. Column effects need columns and image effects need images. Test an entrance during scrolling, not just after it has settled. Keep essential content readable when an effect does not initialize.

The native loading circle should be part of the theme's documented lifecycle. Do not permanently hide it with a blanket CSS rule to conceal a stalled dependency. Confirm that fresh navigation reaches usable content; external resources can affect load timing, and a single interrupted navigation does not establish its cause.

9. Pull, Preview and Publish

Create or Connect the CMS

Use an existing CMS with the required schema, or use create-cms when the selected executable provides it. Share the intended Notion parent Page with the integration first and grant the capabilities required by the command.

localnotion create-cms --parent "YOUR_PARENT_PAGE_UUID" --title "Website CMS"

The command creates a blank CMS rather than website content. If it is unavailable, prepare the schema from Appendix A. Initialize with the database ID; Notion's data-source ID is a separate identifier.

For a new empty local folder, a PowerShell example is:

mkdir website-repository
$notionKey = (Get-Content -LiteralPath "C:\Private\notion-key.txt" -Raw).Trim()
localnotion init --cms "YOUR_DATABASE_UUID" --profile website --path "./website-repository" --key $notionKey
Remove-Variable notionKey

Use your own protected key file and exclude it from source control. Reading the value from a file avoids putting the literal token in shell history. Credential lookup is command- and build-specific; use the installed help rather than assuming every command supports the same environment-variable convention.

Fetch New Content or Rebuild Downloaded Content

localnotion pull --all --path "./website-repository"
localnotion render --all --path "./website-repository"

Pull downloads Notion source and normally renders it. Render rebuilds downloaded content without fetching new Notion edits. Use render for an installed theme change; fetch the actual owner when its native child list is stale. Rendering an old graph cannot discover a newly added child Page.

A renamed parent can affect descendant breadcrumbs and a shared component can affect many routes. Rebuild the affected dependencies, then inspect the generated result. Do not delete source content or add a duplicate link merely because one browser still shows an older result.

Keep Preview and Publication Separate

Use an isolated repository or copy for local experiments. Disable automatic commit/push through the supported configuration command when available:

localnotion git --path "./website-repository"
localnotion git --path "./website-repository" --enabled false --push false

If the executable lacks that command, follow its documented configuration workflow. Preserve unrelated settings. Do not replace the complete registry with a small example or hand-edit generated resource registrations as routine authoring.

The website profile generates hosted paths. Opening one HTML file directly does not fully test routes or assets; preview through an appropriate local web host or staging site. Run one writer at a time against a repository.

Transfer and Activate the Complete Result

Git is one possible transfer mechanism; another deployment process can copy the generated files. Inspect the destination and publication effects before enabling automatic push. Transfer HTML, themes, media and the route mappings together.

For a new Nginx setup, initialization can enable hosting generation and the intended base URL. This does not provision DNS, TLS, a server or a reload service. See the existing Hosting companion Page for the full setup procedure.

Validate the generated configuration and activate it through the host's intended process. A successful local render, transfer, active server configuration and served website are separate checkpoints. A zero command exit alone does not prove all of them succeeded; read its warnings and errors.

Follow the complete path from Notion source to downloaded content, generated output and the hosted website. Check each boundary separately when the public result is stale.

Rendering changes local output. Transfer and host activation make that output available to visitors; neither is implied by a saved Notion edit.

Check Publication and Access Separately

Published and Publish On control ordinary content inclusion. @Private excludes sitemap entries; it does not prevent direct access. Authentication is a host-enforced access setting, not a visual hiding choice.

Native child Pages inherit their CMS owner's authentication context. Independently authored Pages need their intended setting; a protected parent URL is not enough by itself.

Keep credential-bearing repository data and history private.

10. Verify and Maintain the Website

Follow the Complete Editing Cycle

Check the saved Notion row and body, downloaded source, generated Page, transferred files and actual public route in that order. This identifies the first stale or failing stage without guessing that every discrepancy is a browser-cache issue.

Write a deliberate Summary on independently authored CMS rows. Where metadata is derived automatically, preview it: names such as .NET, ASP.NET and Node.js must remain intact. Newer source can correct extraction behavior before an installed binary is updated, so verify the artifact actually doing the pull.

Solve the Smallest Proven Problem

Preserve Useful Structure During Changes

Reuse native Page and block identities when correcting content. Keep intentional links, child order, breadcrumbs and shared components. A working visual change should not silently remove an icon, replace a child Page with an unrelated URL or reset independent configuration.

Use the appendices as a lookup after the first site works. Start with supported native blocks and a small compatible theme combination, then refine one concern at a time and verify the result that visitors actually receive.

Appendix A. CMS Schema, Types and Tags

This section lists the required CMS structure and supported behavior. Routine editing can use filtered views with only the relevant columns visible.

A.1 Choose the Right Kind of Content

Select Type according to the component the row must produce.

A Gallery contains cards. Their subject might be products, photographs, articles or team members. A card's subject does not change how the Gallery component works.

A.2 The Complete Table Structure

Status must be a Select, not Notion's separate Status property type. Themes and Tags are Multi-select. The created/edited fields are native system properties, not ordinary text fields with matching names. The canonical CMS does not require relations, formulas, rollups, or Parent/Menu/Header/Footer columns.

A.3 Publication and Shared Framing

For ordinary Page, Section and Gallery content, choose Published and leave Publish On empty or set it to a time that is already due. Draft, QA, Hidden, blank or unrecognized statuses do not publish ordinary content.

The website is generated, so a schedule takes effect on a pull and regeneration after its due time. Changing a row to Hidden also needs a completed publication cycle to remove the old hosted result.

Header, NavBar, Footer and Internal are selected as shared framing independently of ordinary publication gating. Changing a Footer to Draft is therefore not a reliable way to disable it. Remove or change its intended placement, or hide it from the relevant content with the supported Tags.

For the older 1.5.0.12 website renderer, set pure Header, NavBar and Footer rows to Hidden. Published framing at the exact address of an ordinary Published Page can be mistaken for an extra body part. Hidden avoids that unwanted contribution while the selected framing still works. Keep the actual Page Published, then check the complete generated route, particularly when upgrading.

A.4 Use Tags for Behavior

These are the twelve canonical Tags. Put them on ordinary content, and select exact names rather than inventing a similar one.

Choose one feature-source Tag; if several are present, the current preference is first-image, then cover, then thumbnail. Additional custom tags are metadata unless a theme or program explicitly consumes them. Some site-specific palettes contain other names; that does not make them canonical or universally implemented.

Appendix B. Stock Theme Reference

The lookup describes stock modifiers, not a requirement to select every option or a catalogue of separately installed design packages. A preset name in Notion does not implement a missing template. Follow the selected package's compatible modifier list and overlay order.

The following tables list the 228 stock Theme preset names, their intended effects, required content and known limits. Bold Type names identify the recommended owning row. Select exact names in that row’s Themes property. Compatible inherited templates can also affect a Gallery detail page; verify that output before using a modifier more broadly.

Descriptions are grounded in inspected templates and styles. They describe intended mechanisms, not a claim that every option or combination has passed a visual test. Some compatibility notes describe the legacy 1.5.0.12 website renderer and its theme definitions. An installed package can override those definitions, and source changes can precede a released binary. Check the actual executable and theme package rather than treating every historical limitation as universal. Compatibility notes identify known gaps rather than silently substituting a similarly named option.

Choose one deliberate value for a competing role. Keep the relevant Notion block in place, preview its complete route, and test interactions separately from still images. The editor colour of an option is just a Notion label.

B.1 Content Visibility

Choose whether a row contributes visible content. This is a composition decision, not a substitute for publication settings.

B.2 Body Text

These choices affect compatible paragraphs, quotes and callouts on a Page or Section. Heading and image alignment have their own controls. Choose one alignment and one main text-colour treatment rather than competing values.

B.3 Headings

Create real Heading 1, 2 or 3 blocks in a Page, Section or compatible Header, then choose their presentation. Visual size does not change a heading's structural level. The all-heading choices affect all three levels; level-specific choices affect only that level.

Heading Checks: typed effects replace the whole heading template and need live verification. In the inspected legacy definitions, the Heading 1 typed template had a missing shared-shadow reference, while typed Heading 2/3 omitted normal shadow hooks. The left-alignment choices also requested a rule absent from that stylesheet. These are compatibility observations: check the installed package before assuming the same limits. An ordinary default's left appearance does not prove that a modifier can reset another alignment.

B.4 Section Spacing

Apply these to Section rows, not ordinary Pages. Top and bottom can be chosen independently. The inspected stylesheet's default is 3rem per edge; the small choice is 0.5rem and the large choice is 6rem. Content-block margins can remain after section padding is removed.

B.5 Section Separators

A separator decorates the bottom edge of a Section or Header. Its SVG starts with a white or inherited fill; after page load, the CMS script matches it to the next visible Section’s effective background colour. Preview the complete boundary: image or gradient backgrounds, missing scripts and Section padding can affect the result. A Notion divider is instead a rule inside content.

B.6 Columns

Make a Notion column list before selecting these choices on its Page or Section. Breakpoints control when columns sit side by side and stack, rather than specifying a fixed column width. Choose one breakpoint. Test the real phone layout rather than inferring it from a theme name.

B.7 Images

Add a real Image block first. The inspected renderer contains the picture responsively. Alignment needs an image narrower than its container; captions stay centred. Size rules below describe the stock definition described here, including maximums hidden behind some shorter option names. The named scale is 5/10/15/25/35/45/60rem from smallest to largest; a rem follows the site's root text size.

Image checks: percentage height requires a defined containing height; minimums can overflow phones; a maximum larger than the source can look unchanged. The actual output also depends on the column/container and source aspect ratio. Compare both portrait and landscape content before generalizing.

B.8 Color Roles

Names such as primary, success and body refer to the installed theme's palette, not fixed universal colours. Main text, container background, auxiliary text, small accents and callout cards have separate controls. Inline Notion colours and component templates can override inherited colour. Inspect contrast on the final page.

B.9 Badges, Callouts, Lists and Quotes

These choices style particular Notion blocks inside a Page or Section. A clickable callout card needs URL text and visible child blocks. A badge needs inline-code text, not a Code block. The detailed recipes show how to author the underlying content.

B.10 Links and Buttons

Create a labelled rich-text link and a real destination first. A button is a presentation of that link. Arrow and muted-link treatments replace the ordinary link template and can bypass button or underline choices; navigation has its own markup.

Download-label checks: the inspected detector recognizes WINDOWS, WINDOWS STORE, MACOS, APPLE STORE, LINUX and GOOGLE STORE, plus bracketed labels such as [Download]. It needs its Section-end script, supporting libraries and external icons; test other page links because its scan is document-wide.

B.11 Shadows

First enable the shadow on the intended image, callout, button or heading; then choose one shared strength here. A strength alone does not add shadows everywhere. The inspected Gallery card and badge shadows are independent of this shared setting.

B.12 Headers and Slideshows

Select these on a Header row resolved by the content page. Native Notion Toggles supply slides; their children contain the heading, copy and image. The renderer selects its default slide template regardless of the Toggle's expanded/collapsed state in the editor. An image captioned exactly {BACKGROUND} becomes a cover-style slide background. The alternative toggle_open template has a missing include in the inspected legacy installation; changing the editor state does not select it. Percentage heights depend on the containing layout.

B.13 Navigation

Use a NavBar row at the intended route or branch. Add linked paragraphs and, when needed, a toggle containing dropdown links. Position changes need a long page and a scroll test; a fixed bar can cover a title or anchor. Use one positioning choice.

B.14 Entrance Animation

Motion choices need matching blocks and the website's animation scripts. Test their entrance from a fresh load/scroll position. A still screenshot cannot prove a transition, timing or reduced-motion behavior. Column hooks in the inspected templates cover only one-to-four-column layouts.

B.15 Advanced Content Rendering

Use these on a Page or Section only for reviewed advanced content, with a version-matched preview. Literal code examples should stay readable. These two presets have different jobs; neither should be selected merely because a page contains documentation.

🖥️ Hosting