Public sites and SEO

Some Docent sites face the open internet: a help center on your marketing domain, product guides you want people to find from a search engine. For those sites, Docent handles the search-engine plumbing that a standalone docs platform would: a sitemap, canonical URLs, social preview tags, and structured data. None of it needs configuration, and all of it respects your gates.

The sitemap

Every site serves a sitemap at its own prefix:

https://example.com/docs/sitemap.xml

The entries come from the same permission-pruned navigation that builds the sidebar and llms.txt, evaluated as a guest. That one sentence carries the guarantee that matters: a page gated by an ability or audience never appears in the sitemap, even when the person requesting the sitemap is signed in and authorized. Search engines only ever learn about pages an anonymous visitor could open. Hidden pages, redirect stubs, and pages marked search.exclude stay out too.

There is nothing to maintain. Add a page and it joins the sitemap; gate a page and it leaves. On a fully gated internal site the sitemap is simply empty, which is correct.

If you'd rather not serve one at all, turn it off in the shared config, or inside one site's entry:

'seo' => [
    'sitemap' => false,
],

Like theme and search, the seo section is shared: set it once at the top level and every site follows, or override it per site.

Canonical URLs and page metadata

Every reader page emits:

• a <link rel="canonical"> pointing at the page's own URL, so alternate routes to the same content never split your search ranking;

• Open Graph and Twitter card tags built from the page's title and description, so shared links unfurl properly in chat and social apps;

• a JSON-LD TechArticle block with the page's headline, description, URL, and language.

All of it derives from front matter you already write. A good description line is doing double duty now: it feeds search results, link unfurls, and structured data at once.

Social preview images

Text-only unfurls work, but a card image is what makes a shared link look finished. Point the shared config at one:

'seo' => [
    'image' => '/img/help-center-card.png',
],

The value is a path or an absolute URL; paths resolve against your application URL so crawlers always receive a full address. When an image is set, pages emit og:image and twitter:image and the Twitter card upgrades to the large format. Aim for an opaque raster around 1200×630 — your logo file is usually a transparent SVG and makes a poor card, which is why Docent never falls back to it silently.

A page can override the site image with its own front matter:

---
title: Give your app a guide
image: /img/landing-card.png
---

The landing page is the one most worth a bespoke card, since it's the URL people actually share.

What stays out of the index

The machine-facing endpoints — llms.txt, llms-full.txt, and the .md variant of each page — already send noindex headers, so agents can read them without search engines listing them alongside your real pages. Your application owns robots.txt; Docent doesn't touch it.

Pages opened through a share link send the same headers and stay out of the sitemap too, so handing one page to a customer never hands it to a crawler.

One practical note for mixed installs: on a multi-site setup with a public site and a gated one, each site has its own sitemap under its own prefix. The public site's sitemap lists its pages; the gated site's lists nothing. You don't have to configure the difference.