<?xml version="1.0" encoding="UTF-8"?>
<!--
  One URL, and that is not an oversight.

  The app is a single page whose client routes with a hash, so /#/camino and
  /#/practice are the same URL to a crawler. Listing them would be listing the
  same page four times.

  The sign-in and password-reset pages are deliberately absent: they are
  disallowed in robots.txt and carry noindex, because a login form ranking for
  the product's own name is a liability.

  The legal pages ARE listed, at a low priority. They are real pages at stable
  URLs, and a payment provider or app store checking that a privacy policy
  exists is a crawler like any other.
-->
<!--
  lastmod is here by hand, and that is a decision rather than laziness.

  It cannot be generated honestly. File mtimes are useless: Railway builds from
  a fresh checkout, so every file is stamped with the deploy time and every
  page would claim to have changed on every deploy, whether or not anything
  did. Google uses lastmod only where it is consistently accurate and ignores
  it everywhere else, so a date that moves on every deploy is worth less than
  no date at all.

  KEEP THESE CURRENT BY HAND. Move the date on / when the bundles or the copy
  change, and the legal ones when the documents change - those two should match
  the version date stated inside the documents themselves.
-->
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://spanish.caminantes.co/</loc>
    <lastmod>2026-08-19</lastmod>
    <changefreq>weekly</changefreq>
    <priority>1.0</priority>
  </url>
  <url>
    <loc>https://spanish.caminantes.co/privacy.html</loc>
    <lastmod>2026-08-18</lastmod>
    <changefreq>yearly</changefreq>
    <priority>0.3</priority>
  </url>
  <url>
    <loc>https://spanish.caminantes.co/terms.html</loc>
    <lastmod>2026-08-18</lastmod>
    <changefreq>yearly</changefreq>
    <priority>0.3</priority>
  </url>
</urlset>
