<?xml version="1.0" encoding="UTF-8"?>
<!--
  The sitemap INDEX — the single URL to submit to Search Console and Bing
  Webmaster Tools. Everything else hangs off it.

  ## Why an index rather than seven Sitemap: lines in robots.txt

  Both are valid and Google reads both. The index wins on three practical
  points, and only the third is really about SEO:

    1. One submission instead of seven, and Search Console then reports
       coverage per CHILD — which is the only way to see that (say) tools are
       indexing while templates are not. Seven flat submissions make that a
       manual comparison.
    2. robots.txt is a static file in the web build; this index is too, but a
       reader following one URL does not have to know that. The structure of
       the site lives in a sitemap, where it belongs, rather than in a crawler
       directive file.
    3. It is the documented mechanism for exactly this shape — a set of
       related sitemaps covering one site — so it is what every tool that
       consumes sitemaps expects to find.

  ## One file cannot be both

  This used to be a <urlset> holding twelve hand-written marketing URLs. A
  sitemap is either a <urlset> or a <sitemapindex>, never both, so those twelve
  moved to sitemap-pages.xml and this became the index.

  ## No lastmod on the children, deliberately

  A <sitemap> entry may carry a lastmod, and every child below except
  sitemap-pages.xml is GENERATED LIVE by the gateway from a catalog that
  changes between deploys. A date written into this static file could only ever
  be the date of the last web deploy, which is not when the catalogs changed —
  so it would be wrong most of the time, and a lastmod Google finds to be wrong
  is one it stops trusting.

  The same argument is why four of the children carry no per-URL lastmod
  either. Only the three whose rows have a real timestamp use one:
  sitemap-pages (hand-maintained), sitemap-blog (published_at) and
  sitemap-products (updated_at). Tools, forms, templates and connectors are
  compiled into the gateway binary, so the only date available for those 751
  URLs is the build — one value, shared by all of them, moving on every deploy
  whether or not a single row changed. That is a date Google learns to ignore,
  and the lesson does not stay confined to the sitemap that taught it. Omitting
  the field says "we do not know", which is true.

  So: do not "fix" the missing lastmod in the catalog sitemaps by reaching for
  the build time. It only becomes right if those catalogs grow a per-row
  modified date of their own.

  ## Adding a family

  Add the child here, add its nginx location, and register the namespace in
  gateway/internal/api/pseo.go. The nginx step is the one that needs a
  production SSH, so the namespace list there is deliberately wider than what
  is built — see the comment at the top of pseo.go.
-->
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <!-- Hand-written marketing and legal pages. The only static child. -->
  <sitemap>
    <loc>https://xenition.com/sitemap-pages.xml</loc>
  </sitemap>

  <!-- One page per built-in tool and per smart form. Both catalogs are
       compiled into the gateway, so these are complete and cannot go stale
       between deploys. -->
  <sitemap>
    <loc>https://xenition.com/sitemap-tools.xml</loc>
  </sitemap>
  <sitemap>
    <loc>https://xenition.com/sitemap-forms.xml</loc>
  </sitemap>

  <!-- One page per full-stack app template. Only templates with a live demo
       deployment are listed — the running app is what makes the page worth
       landing on. -->
  <sitemap>
    <loc>https://xenition.com/sitemap-templates.xml</loc>
  </sitemap>

  <!-- One page per connectable app. Only apps whose action list has actually
       loaded are listed: submitting a URL asserts there is something there
       worth reading, and asserting that 121 times about a logo and a sentence
       is how a domain gets reclassified. -->
  <sitemap>
    <loc>https://xenition.com/sitemap-connectors.xml</loc>
  </sitemap>

  <!-- Blog and changelog posts, generated live — the changelog publishes on
       its own cadence and the site does not redeploy when it does. -->
  <sitemap>
    <loc>https://xenition.com/sitemap-blog.xml</loc>
  </sitemap>

  <!-- Marketplace listings, generated live: sellers publish between deploys. -->
  <sitemap>
    <loc>https://xenition.com/sitemap-products.xml</loc>
  </sitemap>
</sitemapindex>
