Sitemaps

import type {
  SitemapEntry,
  SitemapAdditionalEntry,
  SitemapResolver,
  SitemapsConfig,
} from '@systhemaui/payload'

Per-collection sitemap generation lives behind these types; configure it with the plugin's sitemaps option. Pages are included automatically. Enabling the Posts module also registers its native resolver automatically; a consumer resolver may share the posts group without replacing the native entries.

Localized sitemapsLink to this section

On localized frontends, Pages and Posts receive an independent, fallback-disabled scan for every configured content locale. Translations are joined by stable document ID, then every real localized URL receives its own <url>/<loc> entry. Every entry in that cluster repeats the same complete self-referencing hreflang set plus x-default, with the configured default locale selected for x-default when it exists. A missing translation is omitted instead of borrowing its fallback-language slug. Localized Page paths, Post slugs, category slugs, permalink patterns, prefix policy, and locale-domain origins therefore flow into the generated URLs. Exact-one-locale and locale-off sites retain the unlocalized sitemap shape.

Collections without sitemap entriesLink to this section

Pages and Posts are the only Systhema-native collections that own indexable HTML routes. The other native collections are deliberately excluded: Components has an authenticated preview-only route; Categories and Tags are archive filter/permalink data rather than standalone pages; Uploads are asset records; Users supply authentication and public byline data; Redirects are routing rules; and Forms/Form Submissions are embedded content and captured data. If a project gives any of these or a custom collection a real public detail/archive route, add an explicit sitemaps.additional resolver for that route surface.

Multiple hostsLink to this section

When locale domains make one sitemap contain canonical URLs from multiple hosts, production discovery must cover every host. The scaffolded src/app/robots.txt/route.ts handles the pointer: it is a Route Handler, not Next's static robots.ts, so its Sitemap: line names the host the request arrived on (x-forwarded-host behind a proxy, then host), as long as that host is NEXT_PUBLIC_SERVER_URL's or a configured locale domain; anything else falls back to NEXT_PUBLIC_SERVER_URL (see resolveSysthemaPublicOrigin). Every locale domain advertises its own /sitemap.xml rather than the primary domain's. A static robots.ts cannot do this: it is one build output with no request context, and a Sitemap: directive naming a different host is ignored unless that host is verified too.

The sitemap CONTENT is still global — each host serves the same complete, cross-linked document. That is valid for an hreflang cluster whose properties are all verified, so verify ownership of every domain/subdomain and submit each host separately; a sitemap submitted only under the default locale property does not automatically cover the other locale hosts.