<?xml version="1.0" encoding="UTF-8"?>
<!--
  Three URLs: the homepage, the booking page and the About 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.

  about.html is the third, and it arrived by subtraction: the twenty-year
  experience record that used to close the homepage is a page of its own now,
  and the third item in the nav reads "About" rather than "Experience" on all
  three pages. It belongs here on the same rule as the other two — it is a file
  in this folder, every header links to it, and it is the one page on this site
  a reader is sent to directly from a proposal or a profile when what they want
  is the person rather than the offer.

  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.

  This file is the only inventory the project has. The three-page list above it
  and the three documents on disk are the same set, and the test for whether a
  page belongs here is whether it is a file in this folder — not whether it is
  mentioned somewhere else. If a page is added, add it here in the same change;
  if one is removed, remove it here. There is nothing else to keep in step.

  No fragments. None of the section ids on these pages belong here — the
  homepage's #engagements, #services and #contact, and the #top that book.html
  and about.html each carry as the name of their only section. A fragment is a
  position within a document, not a document. Listing experttechpilot.com/#contact
  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. #experience is gone from that list because the section is gone from the
  homepage; it is the illustration this paragraph would otherwise have to invent,
  since a fragment pointing at a section that no longer exists is the other half
  of the same mistake.

  <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, were the same at 1.2.0.0, and are
  different again, and every one of those states is 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-10-12 is one day carrying three revisions, and between them they move
  all three dates. The first was the hero: the credential line came out of the
  byline, "Founder & Principal Software Architect" went in beside the name, the
  founder note that closed the section went with it, and the lede was rewritten
  under the headline. The second replaced the accent colour site-wide with the
  logo blue, and it is the one part of the day that moves no date, on the rule
  this paragraph has always used — a stylesheet changed and no document did.
  The third moved the twenty-year experience record out of the homepage and into
  about.html, which is also the revision the nav label changed in. That one
  moves book.html's date for the first time since the logo, and for the same
  reason: its own nav item now reads "About", and a reader sees that. The
  homepage's date was already moving; about.html's date is its first. The 1.2.1.0
  revision before all of this moved no date at all — it rewrote comments and one
  `robots.txt` rule and left every page's copy alone — which is the same rule
  read the other way.

  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-12</lastmod>
  </url>
  <url>
    <loc>https://www.experttechpilot.com/book.html</loc>
    <lastmod>2026-10-12</lastmod>
  </url>
  <url>
    <loc>https://www.experttechpilot.com/about.html</loc>
    <lastmod>2026-10-12</lastmod>
  </url>
</urlset>
