<?xml version="1.0" encoding="UTF-8"?>
<!--
  /sitemap.xml — the SITE sitemap, as a sitemap INDEX (#1117).

  Why an index rather than one merged <urlset>:

  1. ONE canonical entry point that really does cover the whole site. robots.txt
     names exactly this URL, and every page — static or blog — is reachable from
     it transitively. A single static <urlset> could not contain the articles (it
     has no way to know them) and a robots.txt naming two sibling sitemaps would
     leave no single "the sitemap" URL.

  2. EXACTLY ONE SOURCE OF TRUTH for article URLs. /blog/sitemap.xml is a Pages
     Function (#1116) that renders the published, non-held posts from Supabase at
     request time. If this file also emitted article URLs it would be a second,
     silently-diverging copy of that list — the duplication #1117 was told to
     avoid.

  3. FAILURE ISOLATION. If Supabase is unreachable, the blog Function answers 503
     and only that child sitemap is affected; crawlers report an error against
     that one child and still read the static pages below. A merged
     Function-generated sitemap would 503 as a whole and serve nothing.

  Cost of the choice, stated: crawlers make one extra request (the index, then
  each child). That is the entire downside, and it is paid once.

  No <lastmod> on either child: this file is static and hand-edited, so any date
  written here would be a guess that silently re-stales. <lastmod> is optional in
  the sitemap protocol, and the blog child emits a real one per article.
-->
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://dmeer.app/sitemap-pages.xml</loc>
  </sitemap>
  <sitemap>
    <loc>https://dmeer.app/blog/sitemap.xml</loc>
  </sitemap>
</sitemapindex>
