<?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. Both carry 2026-10-02: book.html
  because it is new, the homepage because its nav and its contact block both
  changed to point at it, and the new link is how a crawler finds the page
  soonest. 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-02</lastmod>
  </url>
  <url>
    <loc>https://www.experttechpilot.com/book.html</loc>
    <lastmod>2026-10-02</lastmod>
  </url>
</urlset>
