Publish a website from Content Studio (with llms.txt built in)

Q: Does AxisIQ generate llms.txt automatically?

Yes, along with llms-full.txt, sitemap.xml and robots.txt. All four are built on each request from the pages published at that moment, so a page you publish now shows up in them now.

Publish pages from a headless CMS and get sitemap.xml, robots.txt and llms.txt generated automatically — so search engines and AI crawlers both read you.

By the end of this guide you will have a working website whose pages are written and published inside AxisIQ. Content Studio is AxisIQ's headless CMS: you write pages in the same workspace that holds your orders, customers and invoices, publish them, and your site reads them through a small read-only API. You also get sitemap.xml, robots.txt, llms.txt and llms-full.txt generated from whatever is published at that moment — the files that decide whether search engines and AI assistants describe your business accurately.

axisiq.co is built this way: this page was published at a path, and that path became a live URL with no deploy.

What you need first

An AxisIQ workspace — the getting-started guide covers signing up and inviting your team.
The address the site will live at, even if nothing is served there yet.
A site shell: any framework, a static site generator, a PHP or Python backend, or one HTML page with two fetch calls. AxisIQ does not design pages for your visitors, so the shell is yours to bring.

Step 1 — Create a content space and set its site URL

Open Content Studio and create a content space (New bucket, in the left rail) — one publishing surface: your marketing site, your documentation, your help centre. Start with one; add a second only when the audience differs, since public access is granted per space.

You give it a key (it shows up in the public delivery URLs), a name, a one-line description that becomes the site summary at the top of llms.txt, and the site URL. Absolute links in the sitemap and both llms files are built from that URL; leave it empty and they fall back to whatever origin asked for the file — fine while you test, wrong once something proxies you.

Step 2 — Write the first page

The editor is a writing surface, not a form: title, public URL, body. Select a phrase and a formatting bar appears with a link field; an empty line offers an insert menu; an image dropped or pasted in uploads as you write, so there is no second media account to open.

What gets stored is markdown, not editor markup, so the same text feeds your site today, a rebuilt front end in three years, and any model reading you. A toggle switches the document to that raw source when you would rather edit it directly.

If the blank page is the blocker, the AI drafting panel turns a prompt into a draft you can replace or append into the document — structure to edit, not finished copy.

Step 3 — Decide the path, because the path is the URL

What you type as a document's path is the address visitors will use, and it is also where that document sits in your folder tree. A page saved as blog/2026/warehouse-move answers on that URL and appears inside blog/2026. Nothing else is created — a folder is only a prefix some document starts with.

Three consequences to plan around:

Moving a page to another folder means editing its path, which changes its URL — so settle your top-level sections (blog, guides, pricing) before fifty pages point at each other.
There is no bulk folder rename — renaming a section means editing each document in it.
The empty path is the space's root, so your homepage is a document like any other.

Paths are unique within a space, so two pages can never quietly claim the same URL.

Step 4 — Fill in the SEO block and tags

Each document carries its own meta title, description, keywords, canonical URL and social preview image, plus a not-indexed switch. The description does double duty: it is the snippet under your search result, and it is the line describing this page in llms.txt. Write it as a complete sentence that informs someone who read nothing else.

Tags are free-form and roll up across the space, which is what index pages filter on later.

Step 5 — Publish, which freezes a snapshot

Publishing copies the current title, body, SEO block and tags into a frozen public version. Your next edit goes to the draft and stays there, so a page can be rewritten over three days while visitors keep seeing what you last signed off. The list view flags any document whose draft has moved ahead of what is public.

Unpublishing removes a page from the public surface without deleting it.

Two honest limits: no version history to roll back to, and no scheduled publishing.

Step 6 — Open the space to the public

Until you say otherwise, nothing in a space is reachable from the web. Public access is an explicit grant in Team & Permissions: go to Roles, create a role from the Public visitors template, and set Published pages to Readable by anyone. That covers the space's pages, its uploaded images and its generated files. Without it, every public URL returns a plain not-found that names no page, path or space.

While you are there, split authoring from publishing: they are separate permissions, so a marketing hire drafts freely while a named person decides what goes live. Both are scoped to one space, so the docs team never reaches your pricing page.

Step 7 — Point your site at the delivery API

Your site now consumes two read-only endpoints, both under the space's public address (https://axisiq.co/content/<workspace id>/<space key>/…). The space's settings in Content Studio list the exact URLs, ready to copy.

Resolve — give it a path, get back that page's published title, body, SEO block and tags. The body comes twice: as markdown, and as HTML that is already sanitized, so a stack without a markdown library can drop it straight into a template. It is your catch-all route: resolve the URL the visitor asked for, render the page, put the SEO fields in the head.
List — give it a folder prefix, get back published summaries. This is your blog index or your guides listing.

Image URLs come back absolute, so they load on your domain without any proxying. The API answers browser requests from any origin, and server requests from any language.

Working code for Next.js, Nuxt, SvelteKit, Astro, Eleventy, Hugo, plain HTML, WordPress and PHP, Django, Rails and mobile apps is in connecting Content Studio to your website or app. Every field and limit is in the delivery API reference.

That is the whole integration. Because your site asks for content at request time, publishing at a new path makes that URL live immediately; responses are publicly cacheable — about a minute for documents, an hour for images — so a CDN in front helps without serving yesterday's copy.

Step 8 — Serve the discovery files from your own domain

Four files are generated on each request from what is published right then — no build step to rerun, nothing that can go stale:

File	What it is for
`sitemap.xml`	Every published page you have not marked not-indexed, with the date it last changed
`robots.txt`	Names the sitemap's address for crawlers
`llms.txt`	A contents page for machines: one line per published page with its description, grouped by top-level folder under your space's name
`llms-full.txt`	That same index with every page's text inlined, so one request returns the whole site

Serve them from your own root — example.com/sitemap.xml — by having your web server pass those paths through to AxisIQ, which is how axisiq.co does it.

The generated robots.txt is fixed — crawling allowed, sitemap named — and per-path rules are not configurable. To keep a page out of the index while its URL still works, use the not-indexed switch, which also drops it from the other three files.

Why `llms.txt` matters

More of the "which tool should I use" questions your buyers ask are answered by an assistant than by a page of blue links, and an assistant works from what it can fetch cheaply — on a JavaScript-heavy site, close to nothing. The two llms files decide whether it describes you from your current pages or from an old summary of them, and neither is a file you maintain.

What headless costs you, honestly

AxisIQ does not design your site. There is no theme gallery, no template marketplace and no drag-and-drop page designer — you bring the site shell and you write the markup around the content.

For most teams that is the point: your design stays yours, and switching your front end later touches none of the pages you have written. But it is real work up front and needs someone comfortable with a codebase. If you want a site live this afternoon with no code at all, a hosted website builder is the honest answer.

One trade-off: if your shell renders pages in the browser, the bots that build the preview card when your link is shared in a chat see an empty page, because they run no JavaScript, and so do most AI crawlers. Render on the server if those readers matter. If you cannot, every space also serves a render version of each page: the same published content as plain, unstyled HTML with the SEO tags, Open Graph tags and structured data filled in. Point crawler traffic at it from your web server; the integration guide shows how.

Variations worth knowing

Documentation alongside marketing. A second space with its own site URL, permissions and generated files. The two never mix.
Content beside your business data. Pages live in the same workspace as your records, so writers are already in your team structure and access is managed in one place.

More on the writing side in Content Studio, and on scoping who may publish in permissions.

FAQ

Can I use AxisIQ as a headless CMS for a Next.js or Astro site? Yes. The delivery API is plain HTTP and framework-agnostic — resolve a path, list a folder. A server-rendered app fetches per request and skips rebuilds entirely; a static generator can fetch at build time, but there is no publish webhook yet, so you rebuild on a schedule or by hand. The integration guide has code for both, plus Nuxt, SvelteKit, WordPress, Django, Rails and mobile apps.

Does it work with WordPress, PHP or a site without a JavaScript framework? Yes. Each document comes with ready, sanitized HTML as well as markdown, so any server-side language can fetch it and print it into a template. A plain HTML page can also fetch it from the browser, because the API accepts requests from any domain.

Can I preview drafts before they go live? Yes, on a site you control. The public API only serves published pages, but a staging site can read drafts through the management API with an access key kept on its server. See reading drafts privately.

Does AxisIQ generate llms.txt automatically? Yes, along with llms-full.txt, sitemap.xml and robots.txt. All four are built on each request from the pages published at that moment, so a page you publish now shows up in them now.

Do I have to redeploy my site to publish a page? No, provided your shell fetches content at request time. Publishing a document at a new path makes that URL live without touching your codebase.

Can I keep a page private while I work on it? Yes. An unpublished document is not reachable publicly at all, and after the first publish your edits stay in the draft until you publish again.

Who in my team can publish? Whoever you grant it to. Writing and publishing are separate permissions and both are scoped to one content space, so drafting access does not imply the authority to put something on your homepage.