---
title: "Sitemaps"
description: "Flat and grouped sitemaps and the sitemap utilities."
requested_language: cs
language: en
translation_notice: "This page isn't translated yet"
url: https://docs.systhema.app/cs/next/payload/frontend/sitemaps
version: unreleased (main)
docs_index: https://docs.systhema.app/cs/next/llms.txt
---
> This page isn't translated yet. Showing English.


```ts
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 sitemaps

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 entries

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 hosts

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`](https://docs.systhema.app/cs/next/nextjs/public-origin.md)). 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.