> ## Documentation Index > Fetch the complete documentation index at: https://docs.attensira.com/llms.txt > Use this file to discover all available pages before exploring further. # Hosted answer pages > Pages we serve for you when there is nowhere else to ship: what a hosted page contains, how it is published and undone, and how to serve the pages from your own subdomain with one CNAME record. > [!WARNING] > > **Not served yet.** The destination endpoints are built but not switched on yet: `GET /v1/destination`, `PUT`, `DELETE` and `POST …/check` on `/v1/destination/domain`, and the app's `/v1/projects/{id}/destination/domain` routes answer `404` on `webapp.attensira.com` and on `api.attensira.com`. Choosing hosted answer pages in setup (`PUT /v1/onboarding/workspace/{id}/destination`) is served. Serving from your own subdomain, and reading `GET /v1/destination`, work as described below once those routes are. The five-minute check of a connected host is not scheduled yet either, so a host would not turn on by itself. Hosted answer pages are a place for Attensira's changes to go when your own site cannot take them: no repository we can open a pull request against, no CMS we can draft into. Each page answers one question your buyers ask AI engines, on a small site we serve for your workspace. You can serve that site from a subdomain you own, such as `answers.yourcompany.com`, by adding one DNS record. Nothing about a hosted page is hidden from you. It is a change like any other: drafted by an agent, approved by you or by the workspace's [autonomy level](https://docs.attensira.com/agent/approval.md#autonomy-levels), listed in your history, and undone with one action. ## Choosing hosted answer pages Hosted answer pages are chosen where you choose any destination: the **Connect** step of [setup](https://docs.attensira.com/start/setup.md), or `PUT /v1/onboarding/workspace/{id}/destination` with `hosted`. There is nothing to sign in to and no credentials change hands. Choosing it gives the workspace its site, at one subdomain of ours named after the workspace. We pick that address; it cannot be set to an arbitrary host. Names a reader would take for ours, such as `www`, `api`, `app` or `docs`, are never given out. ## What a page contains Every page is the answer, written for the question, and the parts an answer engine reads first: * **The answer itself**, from the change you approved, written in Markdown and turned into HTML when the page is served. Raw HTML in the text is never passed through, so nothing an agent quoted can run as a script on a page under your name. * **A title, a description and a canonical address.** The canonical address is your own subdomain once it is live, and our address before then. * **The date it was last updated**, on the page and in the `Last-Modified` header. * **Questions and answers**, when the change has them, shown under **Questions** on the page. * **Structured data** (JSON-LD): an `Article` with your organisation as publisher and the date it was modified, and a `FAQPage` when the page has questions and answers. Every claim on a page is held to the same rules as anything else an agent writes: it traces back to a [Brand Book](https://docs.attensira.com/brand-book/overview.md) fact or a cited source. See [Every claim traces to a fact or a source](https://docs.attensira.com/agent/approval.md#every-claim-traces-to-a-fact-or-a-source). ### What the site serves besides the pages | Path | What it is | | - | - | | `/` | A list of every live page with its description | | `/sitemap.xml` | Every live page with its last-modified date | | `/llms.txt` | Your organisation's name, then each live page as a link with its description | | `/robots.txt` | Allows every crawler. It names the answer engines' own crawlers one by one (OpenAI, Anthropic, Perplexity, Google, Bing, Apple, DuckDuckGo and Common Crawl) so it is plain each was let in on purpose, and points at the sitemap | Answer engines crawling these pages is the reason the site exists, so it allows them by design. Choosing hosted answer pages is agreeing to that. The site answers `GET` and `HEAD` only. When our store cannot answer, a request gets `503` with `Retry-After: 60` rather than `404`, so a crawler retries instead of dropping a page that is still there. ## Publishing A hosted page is an own-site change, so the own-site lane's [autonomy level](https://docs.attensira.com/agent/approval.md#autonomy-levels) decides whether it waits for you. At L3 and above it publishes after its 48-hour window unless you [stop it](https://docs.attensira.com/agent/approval.md#stopping-a-change-in-its-48-hours); below L3 it waits in your [Inbox](https://docs.attensira.com/agent/inbox.md) for a yes. Once approved, a page is live the moment it is written. A new site starts serving within about 30 seconds. A page is never cached on our side, so an update or a removal shows on the next request. ### When a page cannot be published A publish that a retry would not fix is not published, and you get one Inbox row titled **Couldn't publish:** with the page's title, saying why and what to do: | Why | What to do | | - | - | | Hosted answer pages are not chosen for the workspace | Choose hosted answer pages as where your changes go and approve it again, or copy the page into your site and mark it shipped | | Another page is already live at the same address | Give the new page a different title or address, or ask for a change to the page that is live. A new page never replaces a live one | | The page has no title, no text, or a question with no answer | Edit the page and approve it again | | The page would not display correctly after three tries | Edit the page and approve it again. A page is checked before it is stored, so a broken page is never served | A store that briefly does not answer is retried automatically and files nothing. ## Undo Undoing the change that published a page takes it down: * **A new page** answers `410 Gone` for 30 days and leaves the sitemap and `llms.txt`, so search and answer engines drop it rather than retrying. After 30 days its address is a plain `404`. * **An update to a page** puts back exactly what the update replaced. A page is taken down by undoing the change that published it, not by asking for a new change. If a later change edited the same page, undo that one first: an undo never overwrites a newer edit. ## Serving from your own subdomain By default the site is served at our address. To serve it from a host you own, connect a subdomain such as `answers.yourcompany.com`: **1. Name the host** `PUT /v1/destination/domain` with `{"host": "answers.yourcompany.com"}`. The answer names the one DNS record to add: a `CNAME` whose name is your host and whose value is a host of ours. Copy the value exactly. **2. Add the record at your DNS provider** Most DNS providers want only the part before your domain as the name (`answers`). If the provider offers to proxy the record, leave that off for this one. **3. Wait, or check now** We check every five minutes and turn the address on by ourselves once the record is in place: we issue its certificate, and the host starts serving. `POST /v1/destination/domain/check` checks right away, for the moment after you add the record. It has to be a subdomain: a `CNAME` record cannot sit on a bare domain such as `yourcompany.com`. A host under one of our own domains cannot be used, and a host already connected to another workspace answers `409`. A host another workspace had [disconnected automatically](#when-we-disconnect-a-host) is free: connecting it releases the old claim. ### Where the domain stands `GET /v1/destination` answers where the workspace's changes go, with a `domain` block for the hosted site's own domain, or `null` when there is none: | Field | Meaning | | - | - | | `host` | Your host | | `status` | `pending_dns`, `issuing_tls`, `live`, `broken` or `detached` | | `record` | The record to add: `{type, name, value}` | | `reason` | What stands in the way, in plain words; `null` when live | | `url` | The host's address once it serves; `null` before | | `checked_at`, `next_check_at`, `live_at` | When we last checked, when we check next, when it went live | | `next` | What to do now | | Status | What it means | What to do | | - | - | - | | `pending_dns` | We cannot see the record yet | Add the record. It goes live by itself once it is in place | | `issuing_tls` | The record is correct and the certificate is being issued, which usually takes a few minutes | Nothing | | `live` | Your pages are served at your host, and it is every page's canonical address | Nothing. We keep checking it | | `broken` | It was live and no longer serves securely | Set the record again (see below). It goes live again by itself | | `detached` | We disconnected the host (see [When we disconnect a host](#when-we-disconnect-a-host)) | Set the record again, then check now or connect the host again. A detached host is not checked on its own | While the host is anything other than `live`, the pages keep serving at our address, and our address stays their canonical one. ### When the record is wrong A host that breaks, or that is still waiting for its record a day after you connected it, becomes **one** Inbox row titled **Fix the DNS record for** your host. The row names the exact record to set. For a broken host it also asks you to check that no proxy or CDN sits in front of the record, and that any `CAA` record on your domain allows certificates for it. The check that finds the host live again closes the row by itself; the row is not repeated on every check. ### When we disconnect a host A host stays registered with us until something removes it. When the name no longer leads to your pages, we remove it ourselves, so a name pointed elsewhere is not left claimed by your workspace. We disconnect a host when: * **Its record points elsewhere for over an hour.** This applies to a host that has been live: its `CNAME` no longer points at our host, and it has not served for more than an hour. The hour keeps a record you are editing in place from being taken for one you removed. * **The workspace no longer has hosted answer pages.** * **The workspace was cancelled**: the organisation or the workspace was deleted, or an organisation that had a plan has none now. A workspace that never had a plan, such as one set up before paying, is not cancelled. We check this at most once an hour for each host, and a check that fails to get an answer never disconnects a host. The record and the hosted pages are checked every five minutes, with the other checks. A disconnected host has the status `detached`, and you get **one** Inbox row titled **We disconnected** with your host, saying why and naming the exact record. If the record points elsewhere, the row asks you to set it again with the value shown, or to remove the domain here if you moved the name on purpose. If the workspace has no hosted pages or was cancelled, the row asks you to remove the `CNAME` record at your DNS provider, so the name no longer points at pages you do not use. An open **Fix the DNS record for** row for the host is closed and replaced by this one. We do not check a detached host again on our own. To serve the pages there again, set the record and then `POST /v1/destination/domain/check`, or connect the same host again with `PUT /v1/destination/domain`. Either one connects the host again and checks it like a new one: it goes live by itself once the record is in place, and the **We disconnected** row closes. While the workspace stays cancelled, both answer `403`: choose a plan for the workspace, then check the domain again. A detached host no longer holds its name. Another workspace that connects the same host takes it, and the detached claim is released. ### Disconnecting `DELETE /v1/destination/domain` stops serving the pages at your host. They keep serving at our address. To use a different host, remove the current one first: a workspace has one host at a time, and connecting a different one while one is connected answers `409`. Connecting the same host again answers it as it stands, unless we [disconnected it](#when-we-disconnect-a-host), in which case it connects again. ### Keys and scopes Connecting and disconnecting a host needs `steer`; a read-only key can read where it stands and ask for a check, never connect or disconnect. Connecting, checking and disconnecting charge nothing and work on a spent balance. On an organisation-wide credential, name the workspace with `?project=`. See [API authentication](https://docs.attensira.com/api/authentication.md#scopes). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.