<?xml version="1.0" encoding="UTF-8"?>
<!--
  Hand-maintained sitemap for a five-page static site. Add/remove a <url>
  when a page is added or removed — that's the only edit this file needs.

  Deliberately NO <lastmod>: it was hand-set to a single date for every URL
  and went provably stale the moment any page changed (it lagged real edits by
  days). A <lastmod> that under-reports changes is worse than none — Google
  learns to distrust and then ignore the value, and its whole purpose (nudging
  recrawl of changed pages) inverts. Rather than wire a build-time generator
  (@astrojs/sitemap would change the output to /sitemap-index.xml + a new URL,
  needs `site` configured, and still emits no per-page lastmod), we drop the
  one field that can rot. changefreq/priority are crawl *hints*, not factual
  claims, so they can't go "wrong" the way a concrete date can. See #40.
-->
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://www.inveya.com/</loc>
    <changefreq>monthly</changefreq>
    <priority>1.0</priority>
  </url>
  <url>
    <loc>https://www.inveya.com/about/</loc>
    <changefreq>monthly</changefreq>
    <priority>0.6</priority>
  </url>
  <url>
    <loc>https://www.inveya.com/contact/</loc>
    <changefreq>monthly</changefreq>
    <priority>0.6</priority>
  </url>
  <url>
    <loc>https://www.inveya.com/privacy/</loc>
    <changefreq>yearly</changefreq>
    <priority>0.3</priority>
  </url>
  <url>
    <loc>https://www.inveya.com/privacy/visitor/</loc>
    <changefreq>yearly</changefreq>
    <priority>0.3</priority>
  </url>
</urlset>
