Feeds, Sitemaps and robots.txt

Four of the files at the root of your published site exist for machines: three feeds, a sitemap index, and robots.txt. Three of them are generated for you on every build. The fourth is a file in your own repository. And a single checkbox on the page type decides what goes into most of them.

All of it ships on every plan, including Free.

The switch: Show In Feeds

Settings → Page Types → your type → Show In Feeds is a checkbox, stored as includeInFeeds, and it is on by default for a new page type.

What it controls:

• Whether the type’s pages appear in RSS, Atom and JSON Feed.
• Whether each page emits og:type: article and the article:published_time, article:modified_time, article:publisher, article:author and article:tag properties — with it off, the page is og:type: website instead.
• Whether the page appears in llms.txt, llms-full.txt, and its own flattened <page-url>/index.md.

What it does not control: sitemaps. Every page type is sitemapped regardless.

flowchart TD
  P["A published page"] --> Q{"Its page type's<br/>Show In Feeds"}
  Q -- "on" --> F["rss.xml · atom.xml · feed.json"]
  Q -- "on" --> A["llms.txt · llms-full.txt<br/>page-url/index.md"]
  Q -- "on" --> O["og:type: article<br/>+ the article:* properties"]
  Q -- "off" --> N["none of the above<br/>og:type: website"]
  P --> S["sitemap-pagetype.xml<br/>always, either way"]

The three feeds

Every build writes all three, whether or not any page type is feed-eligible. An empty feed is still a valid feed.

The channel-level metadata comes from your identity settings: the site title becomes the feed title, the site description becomes the RSS <description> / Atom <subtitle> / JSON Feed description, the site locale becomes the RSS <language> and the JSON Feed language, and the logo becomes the RSS <image>, the Atom <logo> and the JSON Feed icon. Site Identity and Branding is where you set all four.

The three formats do not carry the same fields, and the differences matter if you are consuming one of them.

<item>
    <title>Publishing your first page</title>
    <link>https://leed.ai/blog/publishing-your-first-page/</link>
    <description>A walk through the Deploy screen, from pending change to live URL.</description>
    <pubDate>Tue, 01 Sep 2026 12:00:00 GMT</pubDate>
    <guid>https://leed.ai/blog/publishing-your-first-page/</guid>
    <category>Releases</category>
    <author>ada@example.com (Ada Lovelace)</author>
</item>

<entry>
    <id>https://leed.ai/blog/publishing-your-first-page/</id>
    <title>Publishing your first page</title>
    <published>2026-09-01T12:00:00Z</published>
    <updated>2026-09-04T09:15:00Z</updated>
    <link rel="alternate" href="https://leed.ai/blog/publishing-your-first-page/" />
    <content type="text">A walk through the Deploy screen, from pending change to live URL.</content>
    <category term="Releases" />
    <author>
        <name>Ada Lovelace</name>
        <email>ada@example.com</email>
    </author>
</entry>

{
  "id": "c4b1f0a2-8e3d-4f2a-9c7b-5d1e2f3a4b5c",
  "url": "https://leed.ai/blog/publishing-your-first-page/",
  "title": "Publishing your first page",
  "content_text": "A walk through the Deploy screen, from pending change to live URL.",
  "banner_image": "https://leed.ai/static/images/deploy-screen.png",
  "date_published": "2026-09-01T12:00:00Z",
  "date_modified": "2026-09-04T09:15:00Z",
  "tags": ["Releases"],
  "authors": [{ "name": "Ada Lovelace" }]
}

Who appears as an author

A page’s authors reach the feeds only if their profile is marked visible. An author whose profile is not visible is silently skipped in all three formats.

Finding the feeds

Leed writes four discovery links into every page head, so a feed reader or crawler finds them without being told:

<link rel="sitemap" title="Leed - Sitemap" type="application/xml" href="https://leed.ai/sitemap.xml">
<link rel="alternate" title="Leed - JSON Feed" type="application/feed+json" href="https://leed.ai/feed.json" />
<link rel="alternate" title="Leed - RSS Feed" type="application/rss+xml" href="https://leed.ai/rss.xml">
<link rel="alternate" title="Leed - Atom Feed" type="application/atom+xml" href="https://leed.ai/atom.xml">

Sitemaps

/sitemap.xml is not a list of your URLs. It is a <sitemapindex> — a list of other sitemaps, one per page type, each at /sitemap-<pageTypeSlug>.xml.

A page type earns an entry in the index only if at least one of its pages has a publishedAt date. A type with no dated page is skipped entirely — no entry in the index, and no per-type file. That is the single most common cause of “a whole section is missing from my sitemap”.

Each per-type sitemap is a plain <urlset>, one <url> per page, carrying an absolute <loc>, an ISO-8601 <lastmod> built from publishedAt, and a <priority>.

The two dates behind every feed and sitemap entry

publishedAt and modifiedAt are real fields on the page, written into its file’s JSON front matter, and they are what all of this is built from:

You control publishedAt from the editor’s Page Settings panel — it is the Target Date, which becomes Published Date once the page has gone live. A page with no publishedAt does not merely lose a date in the feed; it takes its whole page type out of the sitemap index. If you write page files by hand, the Dates section of the front matter reference is the contract to follow.

Sitemap priority

<priority> is resolved per page, in this order:

robots.txt is yours

Unlike everything else on this page, robots.txt is not generated. It is src/robots.hbs in your own repository — an ordinary file you edit like any other, locally or from the Layouts workspace. A new repository is scaffolded with a minimal one; here is leed.ai’s, in full:

---
{
    "permalink": "/robots.txt",
    "eleventyExcludeFromCollections": true
}
---
user-agent: *

Disallow: /email/*

sitemap: {{ siteUrl }}/sitemap.xml

Three things to notice. The permalink is what puts the output at /robots.txt rather than at a path derived from the filename. eleventyExcludeFromCollections keeps the file out of your own listings. And {{ siteUrl }} is a Leed template helper that resolves to the domain of the build in progress — so the preview build points crawlers at the preview sitemap and the live build at the live one, with no second copy of the file.

robots.hbs is a real file in your repository, not one of the templates Leed copies in for the build and deletes afterwards. If you delete it, your site simply has no robots.txt — nothing regenerates it, and the URL returns your 404 page. That is a legal configuration, but it also drops the sitemap: line that points crawlers at your sitemap index. Your Site Repository covers how to get the file back.

What a preview site tells crawlers

Leed writes X-Robots-Tag: noindex rules into the _headers file, and they differ between a preview build and a live one.

A preview site is therefore noindex from top to bottom, on every URL — which is one of several ways preview differs from live. Preview traffic is also never counted: the Worker answers event and form posts on a preview site with a 204 and records nothing.

The same _headers file carries your security headers and the /static/* cache policy — Headers, Caching and Security covers the rest of it. And old URLs keep working through the _redirects file the build generates from your aliases, which sits beside it.

When a feed or sitemap looks wrong

Work down this list in order — the first item accounts for most reports.

1. A whole section is missing from the sitemap index. No page in that page type has a publishedAt date, so the index skipped it. Publish one dated page and it appears.
2. A page type is missing from the feeds but present in the sitemap. Its Show In Feeds checkbox is off. That is the intended behavior of the checkbox, and it removes the type from llms.txt too.
3. The feeds are empty. Nothing has been published yet in any feed-eligible page type. Feeds are generated whether or not there is anything to put in them.
4. An author is missing from an item. Their profile is not marked visible.
5. A recent change is not there. Nothing regenerates until the next deployment — every one of these files is rewritten from scratch when a build runs, and never in between.