<?xml version="1.0" encoding="UTF-8"?>
<!--
  Two URLs: the homepage and the booking page.

  book.html is the second. It is a real document at its own address — linked
  from the header nav and the contact block on the homepage — so it belongs
  here on the same rule the homepage does: the file lists what exists. A
  booking page is also the one page on a consultancy site that gets linked
  from outside it (an email signature, a LinkedIn profile), which makes it
  worth being indexable under its own name rather than reachable only by
  clicking through.

  The Knowledge Center was five of the six here — the hub and its four articles.
  They are out because the pages are not in this build: there is no knowledge/
  directory on disk and `index.html` contains no link to one, so each of those
  five blocks was a machine-readable claim the site could not honour. A sitemap
  that lists a 404 is worse than a short one, because the file's whole value is
  being trustworthy about what exists. Put them back when the pages do.

  Note what this does NOT fix: `_shots/_manifest.js` still lists those five
  pages, and `_seo.js` checks this file against that list, so the structural
  checks still disagree until the manifest follows. That is a separate change
  and it touches `_links.js` too, which reasons about hub-and-spoke depth — see
  the README before doing it.

  `_shots/_manifest.js` needs book.html added for the same reason, and this
  one is the live case rather than the stale one: the manifest is what `_seo.js`
  and `_links.js` read to know which pages exist, so a page missing from it is
  a page those checks will report as an orphan link from the homepage nav —
  which it is not. Neither script is in this folder, so this note is the only
  place the two files are tied together.

  No fragments. The homepage has three section ids — #engagements, #experience,
  #contact. None of them belong here. A fragment is a position within a document,
  not a document. Listing experttechpilot.com/#experience as its own <url> asks
  Google to index a URL that serves identical content under a different address,
  which is the duplicate content problem this file exists to avoid.

  <lastmod> is the date the content last actually changed, not the date the file
  was saved. It is the only field here Google uses: <changefreq> and <priority>
  were ignored years ago, and are omitted rather than filled with guesses that
  look like data. Update it when the copy changes — a lastmod that never moves
  teaches Google to stop trusting the field.

  The dates have been different before and are the same again, and both states
  are the rule working. At 1.1.0.0 the homepage carried 2026-10-05, the heading
  restructure — the h1, three service names, the contact heading, the title and
  the description all changed, which is a content change by any reading — while
  book.html kept 2026-10-02, because nothing in that file had changed. A date
  that moves when the file did not is the failure this field is most prone to,
  and it is the reason the two were separate fields to begin with.

  2026-10-06 is the logo, and it moves both dates because it changed both
  documents: each header now carries an <img> it did not have. No copy changed,
  and that is the honest reason this one is arguable — an image swap is a weaker
  signal than a rewritten heading. It is recorded as a change rather than passed
  over because the header is the first thing on the page and a returning visitor
  sees a different page; the alternative reading, that lastmod tracks copy
  alone, would leave both dates at 2026-10-05 and 2026-10-02. Either is
  defensible. This one is written down so the next revision can see which was
  taken rather than guess.

  2026-09-28 was the hero rewrite, and is the date to compare against if the
  homepage ever needs its previous state.
-->
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://www.experttechpilot.com/</loc>
    <lastmod>2026-10-06</lastmod>
  </url>
  <url>
    <loc>https://www.experttechpilot.com/book.html</loc>
    <lastmod>2026-10-06</lastmod>
  </url>
</urlset>
