<?xml version="1.0" encoding="UTF-8"?>
<!--
  Only CANONICAL URLs belong here.

  /privacy was listed alongside /terms until 2026-08-19. Both routes serve the
  same legal.html, and that page canonicalises to /terms, so listing /privacy
  told a crawler to index a URL the page itself disclaims. A sitemap that
  disagrees with a canonical is not a stronger signal, it is a contradictory
  one, and the crawler settles it by trusting neither.

  /login and /app are absent for the same reason they sit in robots.txt: one is
  the team's sign-in, the other needs a session. /soon, the launching-soon
  door behind every "Sign in" on the landing, is absent because it is noindex:
  a sitemap entry for a page that asks not to be indexed is a contradiction.

  /pricing is absent because it is a 301 to the landing's #pricing section, and
  a sitemap entry that redirects points a crawler at a URL which does not
  resolve to a page. The path is kept as a redirect only so that the obvious
  guess, and any link someone has already made to it, still arrive somewhere.

  The comparison pages carry a HIGH priority relative to the legal pages, and
  deliberately so: "x vs y" and "best tool for x" are the queries this category
  is actually won on, and these are the pages written to answer them. Priority
  is only a hint to a crawler about our own ranking of our own URLs, so the
  ordering it expresses should match where we genuinely want attention.
-->
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <!--
    `/` is the landing again since 2026-09-02, and it claims itself as the
    canonical.

    `/welcome` and `/tour` are NOT listed, even though both answer the landing
    to anyone. They are aliases: the page served there points its canonical at
    `/`, and this file lists canonical URLs only, for the reason the /privacy
    note above gives. Listing an alias here would tell a crawler to index a URL
    the page itself disclaims. (docs/at-launch.md once said to restore the
    /welcome entry; that was written while the landing claimed /welcome as its
    own canonical, and it stopped being right the moment the landing claimed
    the root instead.)
  -->
  <url>
    <loc>https://wireagent.co/</loc>
    <!--
      2026-09-07. The landing copy was rewritten in 335bbb8 ("sell the words,
      not just the machine that sends them") and this date stayed on the 4th.
      That is exactly the failure test/markup.mjs was written for in August: a
      lastmod older than the page is a positive claim that nothing changed, so
      the one signal telling a crawler to come back says the opposite on the
      day it matters most.

      These dates are hand-kept. scripts/build-site.mjs:212 copies this file
      and writes no lastmod, so nothing updates them when a page is committed
      and the test in test/markup.mjs is the only thing that notices. Another
      branch corrected the same date independently on the same day, which is
      what a hand-kept field looks like when two people are working.

      2026-09-09. Pricing went to four tiers with seats on Growth and Scale
      (PR #137), and the deploy's own test run caught this date still on the
      7th: the branch suite had passed because the edits were uncommitted when
      it ran, and the check reads git commit dates. Same for the five
      comparison routes below, whose per-account rows changed in the same PR.
      2026-09-10: the footer gained the three social buttons.

      2026-09-11. The pricing section was reworked: the recommendation moved
      from Growth to Starter and became "Recommended" rather than "Most
      popular", the grid gained two group labels splitting it into the one
      person and the team halves, Starter's card was rewritten, and two false
      annual-price claims were corrected.

      Caught by the DEPLOY's test run, for the third time, by exactly the
      mechanism the 2026-09-09 note above describes: the branch suite passed
      because the edits were still uncommitted when it ran, and this check
      reads git COMMIT dates, so it can only become true once the commit
      exists. Three occurrences is not bad luck. If you are editing a page
      listed in this file, bump its date in the SAME commit rather than
      waiting for the deploy to tell you.

      2026-09-11, the same day: the page was rebuilt around the agents. New
      hero copy and a new Home replica, a new #plan section, the veto strip
      under the wipe, a new Inbox replica in place of the removed Approval
      row, a new #approval band, rewritten FAQ answers, and the in-page
      #compare section deleted. Two sessions changed this page on one day and
      met at the merge; the date is the same either way.
    -->
    <lastmod>2026-09-11</lastmod>
    <changefreq>weekly</changefreq>
    <priority>1.0</priority>
  </url>
  <!--
    The differentiator page, added 2026-09-04. Priority just under the hub:
    docs/seo-strategy-2026-08-30.md section 2 argues it is the highest-value
    page on the site because it is the one query with demand and no incumbent.
  -->
  <url>
    <loc>https://wireagent.co/linkedin-automation-on-your-own-machine</loc>
    <lastmod>2026-09-07</lastmod>
    <changefreq>monthly</changefreq>
    <priority>0.9</priority>
  </url>
  <url>
    <loc>https://wireagent.co/compare</loc>
    <lastmod>2026-09-09</lastmod>
    <changefreq>monthly</changefreq>
    <priority>0.9</priority>
  </url>
  <url>
    <loc>https://wireagent.co/compare/linked-helper</loc>
    <lastmod>2026-09-09</lastmod>
    <changefreq>monthly</changefreq>
    <priority>0.7</priority>
  </url>
  <url>
    <loc>https://wireagent.co/compare/dripify</loc>
    <lastmod>2026-09-09</lastmod>
    <changefreq>monthly</changefreq>
    <priority>0.7</priority>
  </url>
  <url>
    <loc>https://wireagent.co/compare/waalaxy</loc>
    <lastmod>2026-09-09</lastmod>
    <changefreq>monthly</changefreq>
    <priority>0.7</priority>
  </url>
  <url>
    <loc>https://wireagent.co/compare/dux-soup</loc>
    <lastmod>2026-09-09</lastmod>
    <changefreq>monthly</changefreq>
    <priority>0.7</priority>
  </url>
  <url>
    <loc>https://wireagent.co/terms</loc>
    <!--
      2026-09-09: legal.html changed in 7452e09 and this date stayed on the 7th,
      which is the same hand-kept-field failure the comment on the landing entry
      above describes, on a different row. A lastmod older than the page is a
      positive claim that nothing changed, aimed at the one crawler signal that
      would otherwise bring them back.

      TWO SESSIONS CORRECTED THIS ROW WITHIN THE HOUR, independently, and the
      merge of the two is where this comment came from. The note on the landing
      entry above says that is what a hand-kept field looks like when two people
      are working; it has now happened twice on two different rows. The dates
      are still hand-kept and build-site.mjs still writes none.
    -->
    <lastmod>2026-09-09</lastmod>
    <changefreq>yearly</changefreq>
    <priority>0.3</priority>
  </url>
</urlset>
