Launch Signals

What you get per domain

Why most sitemap dates can’t be taken at face value

Many sites write their build date on every URL, or rewrite hundreds of dates in one batch job. Read those sitemaps naively and a quiet company looks like it changed 3,000 pages last week. Launch Signals checks each site before it counts anything:

• Build-date stamps. 60% or more of dated pages on one recent day (50% when that day is within 2 days of the check or matches the sitemap file’s own Last-Modified day): the domain is lastmod_unreliable and gets no counts.
• Batch restamps. 5 or more URLs on the same second, a chain of 10 or more each within 60 seconds of the last, or 8 or more pages of one section inside an hour are excluded.
• Restamped and rolling sections. A section 80% dated on one day, or careers pages that all “change” every week from a job feed, are excluded.
• Echoes. Category, tag and author pages that update when a post is published count as one change with it, never on their own. The same page in several languages counts once.
• Too little left. If more than 90% of the last 90 days’ dates fail these checks, or fewer than 5 trustworthy changes remain, no counts are reported and the row is free.

The filter errs toward under-counting: a real launch that touched 200 pages in one deploy is excluded as a batch. For the hand-run version of these checks, see how to find recently updated pages on a website.

Example run

Input {"domains": ["linear.app", "intercom.com", "vercel.com", "stripe.com"]}, run on 27 September 2026:

The run cost $0.06. Intercom changed more pages than Linear, but 194 of its 197 were docs and help-center pages, so it scores 45 to Linear’s 82. The linear.app row, trimmed:

{
  "input": "linear.app",
  "status": "ok",
  "launchScore": 82,
  "changes": { "last7d": 22, "last30d": 68, "last90d": 166 },
  "bySection": {
    "changelog":    { "urls": 255, "dated": 162, "last7d": 1,  "last30d": 3,  "last90d": 9 },
    "integrations": { "urls": 325, "dated": 268, "last7d": 3,  "last30d": 16, "last90d": 54 },
    "customers":    { "urls": 43,  "dated": 28,  "last7d": 0,  "last30d": 2,  "last90d": 6 },
    "docs":         { "urls": 203, "dated": 160, "last7d": 17, "last30d": 42, "last90d": 77 }
  },
  "latestChangeAt": "2026-09-26T12:50:49.000Z",
  "notableUrls": [
    { "url": "https://linear.app/integrations/teamretro",
      "section": "integrations", "lastmod": "2026-09-26T12:50:49.000Z" },
    { "url": "https://linear.app/changelog/2026-09-24-new-controls-for-linear-coding-agent",
      "section": "changelog", "lastmod": "2026-09-25T07:59:41.000Z" }
  ],
  "pitchReasons": [
    "3 changelog/release pages updated in the last 30 days (latest: /changelog/2026-09-24-new-controls-for-linear-coding-agent): shipping actively; reference a recent release in outreach",
    "16 integration pages updated in the last 30 days (e.g. /integrations/teamretro): expanding their ecosystem; partnership or integration pitch",
    "2 customer stories updated in the last 30 days (e.g. /customers/commure): investing in social proof and sales enablement"
  ],
  "reason": "Counts exclude 61 of 227 URLs dated in the last 90 days as machine restamps (1 same-timestamp batch in the last 90 days, largest 10 URLs at 2026-07-23T15:28:23.000Z (over 265s); 2 one-by-one sweeps in the last 90 days, largest 23 blog pages from 2026-07-23T15:02:07.000Z over 80 min)."
}

And the vercel.com row, free:

{
  "input": "vercel.com",
  "status": "lastmod_unreliable",
  "lastmodReliable": false,
  "launchScore": null,
  "changes": null,
  "reason": "5712 of 6055 URLs dated in the last 90 days (94%) don't count as trustworthy changes: 5488 are machine restamps (127 same-timestamp batches in the last 90 days, largest 809 URLs at 2026-08-18T06:10:12.000Z; ...). When over 90% of a site's recent dates don't hold up, the rest can't be trusted either, so no counts are reported. Not charged."
}

Use cases

• Sales: open with something the account shipped this month (“saw the new controls in your changelog”) instead of a generic line.
• Partnerships: find companies adding integration pages fast; they’re building out an ecosystem.
• Competitor watching: see which competitors touched pricing, changelog or product pages recently, then open those pages.
• Account prioritisation: rank a list by launchScore and work the active ones first. Pair with Hiring Signals to see who is also hiring.
• Weekly runs: schedule it on Apify, call it from Clay, or give it to an AI agent through MCP.

Limits worth knowing: a sitemap date can’t say what changed on a page or whether it’s new, and pages left out of the sitemap (often pricing) can’t be seen. The crawler identifies itself as SiftsmithBot, obeys robots.txt, and fetches only robots.txt and sitemap files, never the pages themselves.

Pricing

A row is ok only when at least 80% of the site’s sitemap files were read, under 25% failed to download (none of them a high-signal file such as a changelog, pricing, product or blog sitemap), at least 5 trustworthy changes remain in the last 90 days, and something changed in the last 30 days: at least one pitch reason, or a changelog, pricing, integration, product or customer page updated in that time.

Free: lastmod_unreliable, no_lastmod, stale_sitemap, too_few_changes, no_notable_changes, partial_coverage, no_sitemap, sitemap_empty, sitemap_fetch_failed, blocked_by_robots, redirected, nxdomain, unreachable, not_public, invalid inputs, errors and duplicates (https://www.linear.app/pricing and linear.app are one domain). Free rows carry changes: null, never zeros. Set a max charge per run and the tool stops cleanly at that limit; any inputs left get a free skipped row.