site and base

A Reed build does not know where it will be served. Nothing infers it — not from git remotes, not from your config file’s location, not from a hosting provider’s environment. You state it.

site

json

{ "site": "https://docs.example.com" }

An absolute origin: scheme and host, no path, no query, no fragment. A path belongs in base.

Setting it enables, for free:

• sitemap-index.xml and sitemap-0.xml
• robots.txt, including the llms.txt comment line
• absolute URLs inside llms.txt
• canonical URLs on every page

Leave it unset and none of those are written. That is a deliberate refusal rather than a degraded mode: a sitemap full of guessed URLs is worse than no sitemap, because search engines act on it.

base

json

{ "site": "https://example.com", "base": "/docs" }

A mount path with a leading slash. Every internal link and asset reference is emitted with the prefix.

The built files still sit at the root of your output directory. base changes the URLs inside the HTML; it does not move files. The mount path has to exist in the tree you actually serve — see Deploy for what that means on a host that serves a directory verbatim.

The two link rules

This trips up everyone once, so it is worth stating flatly.

Where	Rule
Page prose and component attributes	You write the base prefix: /docs/quickstart
docs.json — footer links, redirects, head.link	Reed adds the prefix: write /quickstart

Reed does not rewrite links in your MDX. A root-relative link that forgets the prefix compiles cleanly and 404s in production, which is exactly the kind of failure a build should catch — so if you author for a based site, check your links mechanically rather than by eye.

Absolute http(s) URLs are passed through verbatim everywhere.

Changing the address later

site and base affect emitted URLs, not stored content. Moving a site to a new origin is a config change plus a rebuild. Moving it to a different base is the same, plus redirects from the old paths if anything already links to them.