---
title: site and base
description: What a site can only do once it knows its own address.
---

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](/docs/ship/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.