Content types & endpoints

A Quillly website is a set of content endpoints — each one a path on your domain that holds one of four content types. This page explains those content types, how their path prefixes work, how pages are served on your domain, and where the sitemaps, RSS feeds and llms.txt files live.

The four content types#

• Blog — your posts, at /blogs by default. Every site has exactly one default blog endpoint.

• Docs — documentation pages like this one, at /docs.

• Changelog — product updates, at /changelog. Entries share one timeline page.

• Pages — your own existing site pages, such as pricing, features, or landing pages. Quillly tracks these for SEO and freshness; it does not author them.

You author blogs, docs, and changelogs with the same content tools — create_content, update_content, publish_content — by passing content_type: "blog" | "docs" | "changelog". There are deliberately no separate docs or changelog tools. "Page" items cannot be authored; they are discovered from your sitemap.

Choosing the right type#

The three authored types differ in how they're organised, not in how they're written.

• Use blog for anything dated and standalone — guides, announcements, opinion pieces. Posts are listed newest-first and each gets its own URL.

• Use docs for reference material that's meant to be browsed rather than read once. Docs pages support folders, so they render as a nested sidebar tree.

• Use changelog for release notes. Entries don't get standalone pages; they stack onto a single timeline and each is addressable by an anchor, like /changelog#entry-my-release.

If you're unsure, ask whether the reader arrives from search (blog), from your product (docs), or from a release announcement (changelog).

Path prefixes#

Each endpoint maps to a single path segment: /blogs, /docs, /changelog. A "pages" endpoint can sit at the root (/). The default blog endpoint mirrors your site's blog path; additional endpoints are independent and additive — adding docs never changes where your blog serves.

How serving works#

For a custom domain, you put a reverse proxy in front of each endpoint: a rule that forwards yourdomain.com/docs/* (and /blogs/*, /changelog/*) to your Quillly serve URL. The page renders on Quillly and streams back through your domain, so visitors and search engines only ever see yourdomain.com. Quillly verifies each path independently by fetching it and detecting the <meta name="quillly-site"> tag in the HTML.

A Quillly-hosted *.quillly.com subdomain works differently. It's included with your plan rather than being a separate free tier, and it needs no proxy — but it serves from the subdomain root, so it doesn't carry the /docs and /changelog path prefixes. Use a custom domain when you want path-prefixed endpoints alongside your existing site, which is also where the SEO equity accrues to a domain you own.

Verification is per-path, which means a partial setup is a normal state. Your blog can be live and verified while a docs endpoint is still pending — nothing about adding the second endpoint disturbs the first.

Sitemaps#

On a custom domain, every endpoint serves its own sitemap on its own path:

https://yourdomain.com/blogs/sitemap.xml
https://yourdomain.com/docs/sitemap.xml
https://yourdomain.com/changelog/sitemap.xml

Blog and docs sitemaps list per-item URLs; the changelog sitemap points at the timeline page. On a Quillly-hosted subdomain a single root /sitemap.xml covers every type instead.

Quillly only advertises a non-default endpoint's sitemap to search engines once that endpoint's proxy is verified and sitemaps are enabled — so engines never get a URL that 404s.

RSS feeds#

Blog and changelog endpoints also serve an RSS feed at {prefix}/rss.xml. This matters more than it looks: Google and Bing accept RSS and Atom feeds through the same sitemap submission, and a feed's freshness signal is a primary discovery path for newly published items.

https://yourdomain.com/blogs/rss.xml
https://yourdomain.com/changelog/rss.xml

Docs deliberately has no RSS feed — reference pages are revised continuously rather than published on a timeline, so a feed would emit noise rather than news.

llms.txt#

Quillly generates an llms.txt index — the llmstxt.org convention — for AI assistants and crawlers, straight from your live content so it never drifts. Each endpoint exposes one on its prefix:

https://yourdomain.com/docs/llms.txt

You can also append /llms.txt to any individual post URL to get its full text as clean markdown. On a hosted subdomain, a single root /llms.txt covers every type.

Frequently asked questions#

Can I add docs without changing where my blog lives?#

Yes. Endpoints are additive and independent. Adding a /docs endpoint never moves, renames, or re-verifies your existing blog path.

Why isn't my new endpoint's sitemap being submitted?#

Quillly withholds a non-default endpoint's sitemap until that endpoint's reverse proxy is verified and sitemaps are enabled for it. Check that yourdomain.com/docs/ returns a Quillly-rendered page containing the quillly-site meta tag.

Do changelog entries get their own URLs?#

No. Entries share one timeline page and are addressed by anchor, such as /changelog#entry-my-release. That's why the changelog sitemap points at the timeline rather than listing per-entry URLs.

Can Quillly edit my existing marketing pages?#

No. "Page" items are tracked read-only — Quillly monitors them for SEO issues and freshness but never authors or rewrites them. Only blog, docs and changelog items are authored.

Keep it fresh#

Tracked pages are re-checked on a schedule, but you can trigger an immediate re-check the moment you deploy — see Deploy hook: keep tracked pages fresh. To connect an AI client and start publishing, see Connect Claude, ChatGPT or Cursor. For how each published item is scored before it goes live, see How Quillly scores your content.