# Pages & Sales Pages


Your site needs two kinds of pages, and they are built differently. There are the pages a
visitor expects to find — a front page, something about you, the terms and privacy pages,
maybe a blog — which you write the way you write anything. And there is the sales page: one
per offer, built on a designed template, where the words matter more than anywhere else on
the site and where your assistant does the first draft.

This chapter is both. It shows the pages a new site starts with and how to make more, the
sales page from the starter letter to live, and the rule the platform enforces so a page with
"[rewrite me]" prompts on it never reaches a buyer. A path such as *Sales and marketing → My Pages*
names a group in the admin's navigation and the page under it.

## Concepts

**A page has a kind, a format and an address.** The kind says what the page is for: a general
page, a blog post, the front page, terms, privacy policy, cookie policy, or a thank-you
page. The format says how its content is stored: *Rich Text* for anything you write in the
editor, *HTML* for a page you or your assistant author as markup (a plan feature), and the
*designed* format of sales pages, where content lives in named slots on a template. Every
page is served at `/page/<slug>`; *Serve at site root* makes it answer at `/<slug>` as well,
unless the slug is a name the platform reserves. A page is public the moment it exists — there
is no draft step for ordinary pages — and it appears in the site's sitemap and in its
`/llms.txt`, the page agents read to learn what a site offers.

**A new site starts with four pages.** A front page at `/` titled with the site's name,
carrying a welcome line and a *site contents* block that lists what the site shows the public
— its pages, its live offers, its podcast — plus terms, privacy and cookie-policy pages at `/terms`, `/privacy` and `/cookies`, all
written as starting points for you to edit. These four kinds are *standard* pages: a site has
one active page of each, and if you write a second front page or a new terms page you make it
the active one from the list. The site header and footer wrap every page: the logo on the left
(the logged-out menu is only *Login* and *Forgot your password?*; there is no site menu to
edit), and the Terms, Privacy and Cookies links underneath.

**A sales page belongs to an offer.** It is the page a buyer reads before the checkout, and it
points at the offer it sells — the price on the page and the buy button are wired to the offer
and change with it. An offer gets its sales page when it is created (the Selling chapter), and
several pages may sell one offer, with one of them the offer's own. Sales pages are not listed
under *My Pages*; you reach one from its offer.

**A sales page is slots on a template.** The template — today there is one for selling,
*Sales Page*, a full-length letter for an audience that has never heard of you — fixes which
sections exist and in what order: the hero with its headline, subheadline and badges; the
problem; a two-column comparison; how it works, in steps; your approach; proof; what you get;
why the price; the call to action; and the FAQ. The hero and the call to action are always
there; every other section can be shown or hidden, and sections with lists (badges, rows,
steps, deliverables, questions) take as many items as you like. What you cannot do is reorder
sections or invent new ones; the freedom is in the words. Rich slots take bold, italic and
lists, and body copy takes no links, so the only click on the page is the buy button. The look
is a theme that draws its colours and fonts from your brand (Getting Started), not from the page.

**Placeholders never go public.** A new sales page is a *starter letter*: every section filled
from what the offer knows, with bracketed prompts where only you know the substance —
*"[What staying stuck costs them]"*. Publishing the offer is refused while any of those remain,
from the offer's edit page, from the wizard and from your assistant alike, and the refusal
lists each one with a link to the spot in the editor. Until the offer is published its sales
page answers visitors with a 404; you, signed in as the Headmaster, see it with a banner saying
so, exactly as buyers will once it is live. A scheduled offer's page is public before the
launch, so you can send traffic to it.

**HTML pages are for the assistant to write and you to touch up.** On plans with custom HTML
pages, a page can be stored as markup — the natural output of an assistant that designs a
page for you. You can edit the source, but the everyday path is *touch-up*: open the live page
as the Headmaster, click the pencil, and the text that is safe to change is highlighted; you fix
a word, bold a phrase, save, and the page is live. Structure and styling stay with the source.

## Hands-on

### The pages you start with

Mira's site came with a front page, terms, privacy and cookie pages. *Sales and marketing → My Pages*
lists them with their kind, address and format, filtered by chips (*Front Pages*, *Blog Posts*,
*Terms*, …) or searched by title. *Edit* opens the editor, *Preview* the public page in a new
tab, *Copy* duplicates one, and the lightning button on an inactive standard page makes it the
active one. The *Set up your site* checklist on the admin home keeps *Edit your front page*
unticked until the front page has been saved once.

Mira says: *"Rewrite my front page: who I am, what the course does, and keep the list of what
is on the site."* The assistant reads it with `omumu_page_get` (by slug or id) and writes it
back with `omumu_page_update` — title, tagline, search description, contents, image or slug —
keeping the site contents block, which is an embed in the content rather than text. In the
admin, the editor is the page's content with a *Page Settings & SEO* panel: title, slug,
*Serve at site root*, search description and kind; *Save* publishes at once.

### Add a page

*"Make an About page at /about-mira: I was a developer for fifteen years, now I teach people who
don't code to automate the boring parts of their week."*

`omumu_page_create` takes the slug, title, kind and contents — Markdown is fine for a page
written in conversation; it is stored as rich text — and returns the public address.
`omumu_page_list` shows every page, filtered by kind. In the admin: *New Page* asks for title,
slug, kind and format (*Rich Text Editor* or *HTML Editor*, the latter only on plans that
include it) and opens the editor. To put an opt-in form on a page, write
`[optin-form id="…"]` on a line of its own; the Audience & Email chapter has the forms.

### Write a blog

A blog post is a page of the *Blog Post* kind. The public blog lives at `/blog`, each post at
`/blog/<slug>`, with RSS and Atom feeds at `/blog/feed.rss` and `/blog/feed.atom`. Create posts
as any other page (`omumu_page_create` with type `blog`, or *New Page* with the kind set to
Blog Post); the *Blog Posts* chip under *My Pages* lists them. There is a separate *Blog
Management* page at `/admin/blog` with the same list, but nothing in the navigation links to it.

### Write the sales page

Mira's offer *Automate Your Week* has a sales page full of prompts. She says: *"Rewrite my sales
page from these notes: the problem is Sunday evenings lost to spreadsheets, the first win is a
report that builds itself, refunds within 14 days, no questions."*

The assistant calls `omumu_template_list` once to see the template's sections and the fields
each slot takes, reads the page with `omumu_page_get`, and writes the whole slot document back
with `omumu_page_update` — the full page every time, not one section; the template, the offer
and the price are fixed facts the document cannot change. A field the template does not have
is dropped without a word, so it checks the result. When the page is clean, publishing the
offer with `omumu_offer_update` goes through; while prompts remain, it fails with the list
(section, field, excerpt, editor path), and `omumu_offer_get` shows the same list under
`salesPagePlaceholders` for a check before trying.

In the admin, *Sales and marketing → Offers*, the offer, *Edit sales page* opens the page on its real look:
click any text and type; *Show or hide this section* on the optional sections; *Add badge*,
*Add row*, *Add step*, *Add testimonial*, *Add item*, *Add question* for the lists; the buy
button's label is editable, its destination is not. *Save page* makes it live for anyone who
can see the page; *View live page* shows it. From the public page, the pencil in the corner
brings the Headmaster back to the editor.

### Publish, and what buyers see

Publishing is the offer's *Valid From* (the Selling chapter). With placeholders left, the edit
page refuses and lists them, each a link to its section; fix them, save, and publish again. Once
live, the page shows the site header and footer, the price from the offer, and a buy button
that goes straight to the checkout. Pausing or ending the offer keeps the page up; unpublishing
hides it again.

### Author a page in HTML

*"Design me a one-page launch announcement in HTML with a countdown-style headline, our
colours, and a link to the sales page."*

`omumu_page_create` with `encoding: MANAGED_HTML` stores the markup as given and serves it
inside the site header and footer. Editing it in the admin — the source editor and the
touch-up alike — needs a plan with custom HTML pages; without one the page is shown read-only
there. Afterwards Mira
opens the live page, clicks the pencil, and lands in *Touch up copy*: highlighted text can be
edited and formatted (bold, italic, underline, highlight), dimmed text is protected, and *Save*
says *Your changes are live*. If the page changed under her meanwhile, nothing is saved and she
reloads. Changing the structure means *Edit source*, which is the markup itself.

### What you cannot do yet

Stated plainly: ordinary pages have no draft state — a page is public the moment it exists, and
only sales pages follow their offer's status. There is no site menu to edit; the logged-out
header links only to sign-in, so pages reach each other through the front page's contents block
and your own links. Sales pages are not listed under *My Pages*, and nothing links the blog's
own admin page. One selling template, one theme per template, no reordering of sections, no
images inside a sales page beyond the brand. And the sales page's only buy button is at the
end of the letter; the hero shows the price and the access badge, not a button.

## Reference

### `omumu_page_create`

Creates a new page. The page is live on the public site immediately — there is no draft step — and the result's publicUrl is the address it is served at. Two modes:

**Slot page (recommended for sales pages):** Pass 'template' (discriminator from omumu_template_list) and 'slotJson' (whole-document slot JSON validated against that template). For SALES templates, also pass 'offerId'. Wiring fields (offerId, purpose) must be tool parameters — never inside slot contents.

**Classic page:** Pass 'contents' with optional 'encoding' (QUILL_JSON or MANAGED_HTML). MANAGED_HTML is available but de-emphasised for selling pages — prefer slot pages instead.

- **Write category:** standard write
- **Access:** requires the `PAGE_WRITE` permission

| Parameter | Type | Required | Description |
|-----------|------|----------|-------------|
| `contents` | string | no | Classic page content. Raw HTML when encoding is MANAGED_HTML, Quill JSON or markdown otherwise. Not used when creating slot pages. |
| `encoding` | string | no | Content encoding for classic pages: QUILL_JSON (default) or MANAGED_HTML. Not used when creating slot pages. |
| `offerId` | string | no | Offer ID this sales page sells. Required for SALES templates; must be a valid offer belonging to this site. Never pass inside slot contents. |
| `slotJson` | string | no | Whole-document slot JSON validated against the named template. Required when 'template' is provided. |
| `slug` | string | yes | The page URL slug (e.g., 'my-course-launch') |
| `template` | string | no | Template discriminator from omumu_template_list (e.g. 'sales-cold-traffic'). Required for slot page creation; causes slotJson validation against the named template. |
| `title` | string | no | The page title |
| `type` | string | no | Page type: blog, frontpage, userpage, terms, privacy, cookies, template, block, offer, thank_you |

### `omumu_page_delete`

Deletes a page by ID

- **Write category:** standard write
- **Access:** requires the `PAGE_DELETE` permission

| Parameter | Type | Required | Description |
|-----------|------|----------|-------------|
| `pageId` | string | yes | The page ID to delete |

### `omumu_page_get`

Gets a page by ID or slug. At least one of pageId or slug must be provided. The result's 'public' field is false for a sales page whose offer is not published (visitors get a 404 there until it is), true otherwise.

- **Write category:** read-only
- **Access:** requires the `PAGE_READ` permission

| Parameter | Type | Required | Description |
|-----------|------|----------|-------------|
| `pageId` | string | no | The page ID (provide this or slug) |
| `slug` | string | no | The page slug (provide this or pageId) |

### `omumu_page_list`

Lists all pages for the current site, optionally filtered by type

- **Write category:** read-only
- **Access:** requires the `PAGE_READ` permission

| Parameter | Type | Required | Description |
|-----------|------|----------|-------------|
| `excludeOfferPages` | boolean | no | Exclude auto-generated offer pages |
| `type` | string | no | Filter by page type: blog, frontpage, userpage, terms, privacy, cookies, template, block, offer, thank_you |

### `omumu_page_update`

Updates a page. The change is live on the public site immediately — there is no draft step — and the result's publicUrl is the address the page is served at. For slot pages (encoding SLOT_JSON), pass 'slotJson' with the full updated slot document — wiring (offerId, purpose) is immutable on update and is not re-validated here. For classic pages, pass any combination of 'title', 'tagline', 'metaDescription', 'contents', 'image', or 'slug'.

- **Write category:** standard write
- **Access:** requires the `PAGE_WRITE` permission

| Parameter | Type | Required | Description |
|-----------|------|----------|-------------|
| `contents` | string | no | New content for classic pages. Format depends on page encoding: raw HTML for MANAGED_HTML pages, Quill JSON for QUILL_JSON pages. |
| `image` | string | no | New header image URL |
| `metaDescription` | string | no | New meta description for SEO |
| `pageId` | string | yes | The page ID |
| `rootPublished` | boolean | no | Serve the page at the site root (/\<slug>) in addition to /page/\<slug>. Reserved platform names (admin, terms, courses, ...) are refused. Both addresses keep working; rendered links, canonical metadata, and the sitemap use the root URL. Omit to leave unchanged. |
| `slotJson` | string | no | Full updated slot JSON document for slot pages (encoding SLOT_JSON). The template discriminator is read from the existing slot document. Wiring is immutable. |
| `slug` | string | no | New URL slug (changes the page URL) |
| `tagline` | string | no | New tagline |
| `title` | string | no | New title |

### `omumu_template_list`

Returns all registered page templates with their section layouts and per-section JSON schema. Call this tool first when building a slot page so you know which template discriminator to pass to omumu_page_create and what slot fields each section expects. Each entry includes: 'name' (the discriminator), 'purpose' (e.g. SALES), 'sections', and 'schema'.

- **Write category:** read-only
- **Access:** requires the `PAGE_READ` permission

No parameters.