Skip to main content
A page is an address inside your site, with an agent answering on it. The agent owns the knowledge, the images and the identity, and several pages can share one agent: a home page, a product line and a campaign on one knowledge base. The look (logo, navbar, footer, theme) belongs to the site, so every page wears it. Two unrelated products stay isolated by giving each its own agent.

​
Two kinds of page

A page can be one of two kinds, and you pick which when you create it:
  • Conversational is the default: an agent answers visitors, and you write the editorial (badge, headline, the line under it) shown above the chat. This is everything below unless a section says otherwise.
  • Document is a markdown file you upload (a privacy policy, terms of service, an about page). It has no agent, no editorial and no chat: it renders your markdown inside the site’s navbar and footer, and everything a visitor reads comes from the file, including the page title, which is taken from the first heading. Use it for the static, legal or informational pages a site needs alongside its conversational ones.
Both kinds live at an address inside your site, both are published the same way, and both wear the site’s brand (logo, navbar, footer, theme).

​
Document pages

A document page is the simplest thing to publish: a name, an address, and the markdown.
  • Upload a .md file or paste the markdown in the console when you create the page, and again whenever you want to edit it.
  • Headings, lists, tables, links and emphasis are respected (GitHub-Flavored Markdown). The first heading becomes the browser tab’s title.
  • It is fully indexable. A document page is server-rendered with no JavaScript, so search engines read the whole document.
  • Raw HTML in the markdown is ignored, not rendered. The content is shown safely (a <script> or an onerror attribute never becomes part of the page), so a document is safe to publish on your own domain.
  • It is written in the page’s source language, which is fixed when the page is created. A translated version is a separate upload; document pages are never machine-translated, because a legal document is yours to word.
A document page counts toward your plan’s pages allowance like any other page. It never spends message credits: there is no agent and no conversation on it.

​
Linking to your own pages

The navbar and footer of your site (the site brand) can link to any of your pages by their path, with no domain to type:
A path that starts with / links a page of this site, so the same link works on your *.wondeya.app subdomain and on your own custom domain. You never hard-code the host. Serving on a custom domain is not live yet; until it is, your site answers on its wondeya.app subdomain. When you edit a navbar or footer link, the console suggests your site’s page paths; you can also type a full https://… URL for a destination outside your site.

​
Anatomy

​
The address

A page lives at a path under its site’s host:
The site’s part of the address is the globally unique half, which is why two different sites, even inside one workspace, can each have a /pricing. Path rules:
  • Up to 4 segments of 2 to 48 characters each (/pymes, /enterprise/latam), 200 characters in total. Each segment is lowercase letters and digits with single hyphens between them.
  • Case-insensitive: /Pricing and /pricing are the same address, stored lowercase.
  • Unique inside its site.
  • Your first page gets / automatically if you do not type a path. After that, a path you leave blank is derived from the name and deduplicated automatically (/pricing, then /pricing-2); a path you type is honored as typed.
  • Reserved by the platform, each together with its whole subtree (/api/anything is refused too): admin, api, app, cdn, console, docs, embed, mail, status, storage, well-known, widget, www, plus the language prefixes es and en, which address the translated variants.
Changing a path moves the public address immediately and there is no redirect from the old one. Links already shared, and anything a search engine has indexed, will stop resolving.

​
Draft and published

A page is born a draft, and publishing is a separate, deliberate act (its own control in the console, its own endpoint in the API), never a field on a settings form. Publishing puts an agent in front of strangers speaking in your name, and that should not be reachable by a stray key in a rename request. While a page is a draft:
  • every public address answers 404, the same 404 you would get for a page that does not exist;
  • it answers nobody in a conversation at its address (the widget is separate: a site key embeds the agent, not the page, and does not depend on this status);
  • you can still work on it, and talk to it in the console’s Preview.
Publishing requires a verified email address; everything else (creating, editing, previewing) works before the verification click. Publishing also registers your site’s host, and the host serves the home page: the page whose path is /. Your first page gets that path automatically, and a page at any other path cannot be published until something is published at / (the request is refused with a 409, code wondeya.page.root_required). For the same reason, while other pages of the site are published, the home page cannot be unpublished, moved off / or deleted: unpublish the siblings first, or move / to one of them. Unpublishing takes effect on the next request, and unpublishing the last published page takes the site offline. A page keeps the date it was first published even after you unpublish it: that is a record of history. What decides whether anything is served is the status, never that date.

​
What a stranger reads first

A conversational page that is only a text box has nothing to show someone who has not typed yet, and nothing for a search engine to read. So every agent carries display copy: a subtitle, a short description and a handful of suggested questions, all written from that agent’s own approved knowledge. This copy belongs to the agent, not to the page. It is composed once and reused by every page the agent answers on and everywhere its widget is embedded: the same brain says the same thing everywhere, and it is never composed twice into two different versions. It is part of what a visitor receives before any JavaScript runs, and it is what search engines index. It is written for you, not by you. wondeya composes it:
  • when your knowledge really changes: a document added, re-crawled or removed. Re-uploading the same file changes nothing, so nothing is rewritten;
  • when you change who the agent speaks for;
  • when you publish a page that uses the agent.
Composing takes a few seconds and never happens while a visitor is loading the page: the copy is written in the background and stored, so pages are always served instantly.
A page’s headline is its own. The subtitle, description and suggested questions come from the agent; the headline above the chat is the page’s editorial, which the owner writes. There is no per-page “cover” and nothing to rewrite by hand.
If there is not enough knowledge yet, the copy degrades honestly: no invented subtitle and no invented questions. Nothing is made up to fill the page. Add knowledge, and it fills in.

​
Search and social

What a search result or a social card shows is the page’s SEO metadata: a per-language <title> and meta description, distinct from the headline on the page, plus an optional social image. A field you leave empty falls back to the page’s own content and then to your home page’s values, resolved live. SEO covers the texts, the limits, the inheritance and the social image.

​
Who the agent speaks for

An agent identity is what turns a generic assistant into this business’s assistant. It has five parts, and every one of them may be empty: Empty is a meaning, not a gap. An agent with no description never describes the business at all; with no actions it offers no CTA; with no links it points nowhere. There is no platform default and there must never be one: a default identity is how one company’s page ends up describing someone else’s product. The actions and links lists are also the reason a CTA is safe. The agent emits an id, never a destination; the server swaps the id for the URL you registered, after the component has been validated.

​
Agent material or workspace material

Knowledge and images belong to an agent or to the whole workspace, and each agent has two switches, both on by default: whether it also answers from workspace knowledge, and whether it may also use workspace images. Because several pages can share one agent, flipping a switch changes every page the agent answers on and every embed, never a single page. This is what a workspace holding two unrelated products needs. Give each product its own agent and turn workspace knowledge off on both, and neither one can answer in the other’s name, not because the model was asked nicely, but because the material never reaches the turn.

​
Theme

The theme belongs to the site, and every page of the site wears it; there is no per-page override. Edit it on the site’s Brand tab and every page changes together. Theme describes the tokens themselves.

​
Deleting

Deleting a page is real (there is no tombstone that still answers), and it removes only what belongs to the page: the page itself, its public address and its own uploaded social image. The address is withdrawn first, so the page stops resolving before anything else changes. Knowledge and images belong to the agent and survive, still answering on the agent’s other pages and in every embed. Its widget site keys survive for the same reason: they belong to the agent, not to the page, so an embed keeps answering after the page is gone. Removing a corpus means deleting the agent, which refuses while any page still points at it. Deleting the published home page while other pages of the site are published is refused: they are served under the same host and would stop resolving with it.

​
Who can do what

A page is the public face of a business, so publishing is not a member-level action. Every call is authorized on the server regardless of what a screen chooses to show.

​
What the console covers today

The console’s Pages screen covers most of a page’s life: creating both kinds (with markdown upload or paste), the settings (name, address, agent), the editorial, the SEO texts and social image, a document’s markdown, publishing, unpublishing and deleting. The agent’s identity (business name, description, tone, actions, links) is edited on the agent’s own screen.
Two levers are API-only today: the agent’s content policy switches and the per-page sitemap hints (priority, change frequency, exclusion). The API reference documents the exact payloads.