<?xml version="1.0" encoding="UTF-8"?>
<!--
  Sobre's HAND-MAINTAINED pages. Eight URLs, and there are not more.

  ⚠️ THIS FILE STOPPED BEING THE WHOLE PUBLIC SURFACE ON 2026-09-02, AND IT USED
  TO SAY IT WAS. It was `sitemap.xml` and it opened "Sobre's public surface, in
  full". The blog changed that: the backend writes `sitemap-blog.xml` to this
  same origin, so the surface is now two files and `sitemap.xml` is a
  <sitemapindex> naming both. Read that one first; this is one of its two halves.

  The split is a RACE, not tidiness. This file ships with the app through the
  deleting `aws s3 sync dist/`; the blog's is written by the backend between
  deploys. One key with two writers is a race the deploy always wins and never
  reports — so they are separate keys, and `blog/*` and `sitemap-blog.xml` are
  excluded from that deletion in both deploy workflows.

  ⚠️ THE SYNC'S DELETE FLAG IS DESCRIBED AND NEVER SPELLED. Its two leading
  hyphens are a double hyphen, XML forbids one inside a comment, and nothing
  escapes it — so the only legal way to write the flag is not to. This file and
  the index were BOTH invalid on the day they were split apart, because the same
  sentence was copied into both; Search Console reported a parsing error and zero
  discovered pages. A parser drops the whole document, not the comment.

  IT SAID FIVE UNTIL 2026-08-31, and it was right until /contact landed. It said
  SIX for the rest of that same day, until /get landed. A file that states its own
  completeness is a file that has to be edited when the set changes — which is
  the point of stating it, and the reason this line is worth more than a count
  nobody maintains. Twice in one day is the observed rate, not an anomaly.

  ⚠️ AND "SEVEN" IS NOW ONLY TRUE OF THIS FILE. A reader counting Sobre's indexed
  URLs has to add the blog's, which nobody here maintains by hand and which is
  the point of it being generated.

  EVERY ENTRY IS A PAGE A SIGNED-OUT PERSON CAN READ. The rest of this origin is
  a household's own money behind an auth wall, and listing it would be asking a
  crawler to index the sign-in screen five hundred times over — CloudFront
  answers every unknown path with 200 and index.html, so those URLs do not
  announce themselves as unavailable.

  THE APEX, NEVER www. Both sobre.ph and www.sobre.ph serve this app, so the two
  are duplicates of each other by construction. The apex is the canonical form
  here, in the <link rel="canonical"> the app writes at runtime, and in the
  marketing copy. One answer in three places is the only way that stays true.

  NO <lastmod>. A date that is not maintained is worse than an absent one: it
  tells a crawler the page is fresh when nobody has touched it, and the first
  time it is wrong it stops being believed. These pages change when the product
  or the lawyers change them, which is not on a schedule this file could predict.
-->
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <!-- What the product is. The only page written to be found. -->
  <url>
    <loc>https://sobre.ph/</loc>
    <priority>1.0</priority>
  </url>

  <!-- Where somebody acts on having found it. -->
  <url>
    <loc>https://sobre.ph/register</loc>
    <priority>0.8</priority>
  </url>

  <!-- Both required to be reachable by Google Play, and both are things people
       genuinely search for by name. -->
  <url>
    <loc>https://sobre.ph/legal/privacy</loc>
    <priority>0.5</priority>
  </url>
  <url>
    <loc>https://sobre.ph/legal/terms</loc>
    <priority>0.5</priority>
  </url>

  <!-- Play requires an account-deletion route reachable WITHOUT signing in, and
       a person looking for it is usually looking for it by search. -->
  <url>
    <loc>https://sobre.ph/delete-account</loc>
    <priority>0.5</priority>
  </url>

  <!-- How to reach Sobre without an account. /support is the real contact
       surface and is behind the auth wall, correctly — so this is the page for
       somebody who cannot get to it, and somebody who cannot sign in searches
       for it rather than finding it in a menu they cannot open. -->
  <url>
    <loc>https://sobre.ph/contact</loc>
    <priority>0.5</priority>
  </url>

  <!-- Where to install Sobre and where the group is. Its traffic arrives from a
       pasted link rather than from search, so it is here for completeness rather
       than because anybody will find it this way — which is also why it does not
       outrank /register, the page somebody who HAS searched should land on. -->
  <url>
    <loc>https://sobre.ph/get</loc>
    <priority>0.5</priority>
  </url>

  <!-- The blog's INDEX, and only the index. Every article is in
       sitemap-blog.xml, which the backend writes; listing one here would put an
       article's address in a file the backend cannot update when it is
       withdrawn.

       ⚠️ /blog HAS NO TRAILING SLASH AND MUST NOT GAIN ONE. CloudFront sends
       /blog/* to S3, where the static articles are, so /blog/ answers 403 —
       only the bare path falls through to the app that renders this list. -->
  <url>
    <loc>https://sobre.ph/blog</loc>
    <priority>0.5</priority>
  </url>
</urlset>
