<?xml version="1.0" encoding="UTF-8"?>
<!--
  Sitemap protocol 0.9 (sitemaps.org), served from the web root as
  /sitemap.xml and announced in robots.txt beside it.

  ONE URL, because the site is one page. The section anchors the nav
  scrolls to — #build, #nda, #process, #faq, #contact — are fragments of
  this URL and not URLs of their own: the protocol wants a distinct page
  per <loc>, and crawlers discard the fragment and collapse them all
  back to the homepage. Listing them would report five pages that do not
  exist. docs/seo-audit.md's third priority is to add real URLs; when
  those ship, they belong here.

  <loc> carries the trailing slash and the https scheme because it has
  to be the canonical form, byte for byte — the same string as og:url in
  index.html. A sitemap that lists a variant of the canonical URL asks
  the crawler to pick between them.

  <lastmod> is the date the page's content last changed, and it is
  maintained by hand: bump it when the copy or the markup changes, and
  leave it alone for a rebuild that only rehashes the bundle. An
  inaccurate lastmod is worse than no lastmod, because a crawler that
  catches the field lying stops trusting it. Date-only is valid W3C
  Datetime.

  No <changefreq> and no <priority>. Both are legal in 0.9 and both are
  ignored by Google, and on a single-URL sitemap a priority is
  meaningless by construction — there is nothing for it to be relative
  to.

  Not in the .htaccess immutable FilesMatch (js|css|woff2?|webp|svg|mp4),
  deliberately: a sitemap cached for a year cannot announce a change.
-->
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://spirixx.com/</loc>
    <lastmod>2026-09-25</lastmod>
  </url>
</urlset>
