<?xml version="1.0" encoding="UTF-8"?>
<!--
  E1-23: `/` and `/product-landing.html` served IDENTICAL content under
  CONFLICTING canonicals and were both listed here, so the landing page
  competed with itself. The landing content is now consolidated on `/` — the
  URL everybody links to — and `/product-landing.html` declares `/` as its
  canonical, so it is deliberately NOT listed here. Do not re-add it.
  NOTE (escalated, not fixable in this file): `/` still reaches its content
  through a client-side JS redirect and ships no server-rendered text; the real
  fix is a Vercel rewrite so `/` serves the landing HTML directly.
-->
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url><loc>https://bookiq.ai/</loc><lastmod>2026-08-02</lastmod><priority>1.0</priority></url>
  <url><loc>https://bookiq.ai/features.html</loc><lastmod>2026-08-02</lastmod><priority>0.8</priority></url>
  <url><loc>https://bookiq.ai/pricing.html</loc><lastmod>2026-07-27</lastmod><priority>0.8</priority></url>
  <url><loc>https://bookiq.ai/faq.html</loc><lastmod>2026-08-02</lastmod><priority>0.7</priority></url>
  <url><loc>https://bookiq.ai/industries.html</loc><lastmod>2026-08-02</lastmod><priority>0.7</priority></url>
  <!--
    T370 (backlog rank 22, "de-scope the marketplace"): `/discover` is
    DELIBERATELY NOT LISTED. `MarketplaceService.searchProviders` opens on
    `business_visibility_settings` where `show_in_marketplace = true AND
    network_visibility = 'public'` and returns an empty page the moment that set
    is empty. Production holds ONE row of that table with `show_in_marketplace =
    false` and `network_visibility = 'network'`, against 16 active businesses,
    and `network-service.ts` seeds every new row the same way — so the directory
    returns zero providers for every query BY CONSTRUCTION, and no owner-facing
    control exists that could change it (the only `network_visibility` <select>
    in the tree is in an unmounted file, and nothing calls
    `PUT /api/network/visibility-settings`). Submitting a permanently-empty
    directory for indexing earns thin-content treatment and sends real consumers
    to a dead end. The route stays mounted but renders a withdrawn page behind
    the `marketplace` flag (`routes/public.tsx`), and the DEC-137 door is gone
    from the shared marketing nav and footer (T371 lane B1 corrected this note:
    it used to say the link stayed, which stopped being true in T370).
    RE-ADD IT when a real query returns at least one provider — not before.
  -->
  <url><loc>https://bookiq.ai/signup.html</loc><lastmod>2026-08-02</lastmod><priority>0.9</priority></url>
  <url><loc>https://bookiq.ai/signin.html</loc><lastmod>2026-06-12</lastmod><priority>0.8</priority></url>
  <url><loc>https://bookiq.ai/forgot-password.html</loc><lastmod>2026-06-12</lastmod><priority>0.5</priority></url>
  <url><loc>https://bookiq.ai/privacy-policy.html</loc><lastmod>2026-09-06</lastmod><priority>0.3</priority></url>
  <url><loc>https://bookiq.ai/terms-of-service.html</loc><lastmod>2026-09-10</lastmod><priority>0.3</priority></url>
  <url><loc>https://bookiq.ai/refund-policy.html</loc><lastmod>2026-09-04</lastmod><priority>0.3</priority></url>
  <!--
    T383 (backlog ranks 44 and 45). The Acceptable Use Policy and the Data
    Processing Agreement are named in Terms of Service 2026-09-10 (clause 4 and
    clause 4b) as forming part of the contract, so they are documents a reader
    is bound by and must be able to find. Until this entry existed neither had a
    link anywhere on the marketing site and neither was submitted for indexing.

    THE .html PATH IS THE CANONICAL ONE ON PURPOSE. Both are hand-authored
    static files under public/legal/ with no bundle, which Vercel resolves from
    the filesystem before any rewrite; the clean forms (/aup, /dpa and their
    /legal/ twins in vercel.json) are rewrites that could be shadowed by the SPA
    catch-all if the file ever went missing, and an unmatched path under /legal/
    answers 200 with the ~9.7 KB SPA shell rather than 404 — so a clean URL is
    the wrong thing to hand a crawler as the canonical location.

    lastmod on the THREE legal lines above is corrected in the same edit. All
    three said a date older than the document's newest publication:
    privacy-policy 2026-08-02 -> 2026-09-06, terms-of-service 2026-08-02 ->
    2026-09-10, refund-policy 2026-07-27 -> 2026-09-04. The dates are the
    publication dates in public.platform_legal_versions, not the date this file
    was touched.

    ⚠️ THE FIRST PASS OF THIS EDIT CORRECTED TWO OF THE THREE AND LEFT
    privacy-policy AT 2026-08-02, i.e. it stated the rule immediately above a
    line that broke it. Re-measured read-only against prod (ref
    mhbphdiczqtgsscdwfov) on 2026-09-10:
      select document, version, published_at::date
        from public.platform_legal_versions order by document, published_at;
    privacy-policy's newest publication is 2026-09-06 (five later than
    2026-08-02: 08-05, 08-08, 08-09, 08-29, 09-06); refund-policy's is
    2026-09-04. NOTHING GUARDS THESE DATES (no test reads them, and no build
    step regenerates this file), so the only thing that keeps them true is
    re-running that query on every legal publication.

    ⚠️ A DOUBLE HYPHEN IS ILLEGAL INSIDE AN XML COMMENT, and this file is the
    one place in the repo where that matters: case 13 of
    __tests__/unit/legal/t382-aup-dpa-published.test.ts reads it with a REGEX,
    so a malformed sitemap stays green here and is rejected by the crawler
    instead. Written with parentheses rather than the repo's usual double-hyphen
    aside for exactly that reason; python3 -c "xml.dom.minidom.parse(...)" is
    the check.
  -->
  <url><loc>https://bookiq.ai/legal/acceptable-use-policy.html</loc><lastmod>2026-09-10</lastmod><priority>0.3</priority></url>
  <url><loc>https://bookiq.ai/legal/data-processing-agreement.html</loc><lastmod>2026-09-10</lastmod><priority>0.3</priority></url>
</urlset>
