The desktop app is the daily driver. The CLI is what you reach for when you want SiteCMD inside an automated pipeline: a CI job, a pre-push hook, a deploy gate, a cron-driven scan.

The sitecmd binary runs the same live-site checks as the desktop app, but with no UI, no database persistence (by default), and no auth. It’s a single static binary built for Linux, macOS, and Windows.

The CLI runs the Web Scan (live-site checks) only. Code Scan (source audit), Core Web Vitals, and the axe-core accessibility deep scan are desktop-only.

This page is the reference: what every command does, every flag, every exit code. For task-oriented usage, see Quality gates in CI and Pre-push hooks.

Installation

Downloads aren’t open yet. SiteCMD is in pre-launch. Get on the launch list at /download. The CLI ships at the same time as the desktop app.

At launch, the CLI is available three ways:

Bundled with the desktop app. Install the desktop app and the sitecmd CLI lands in your $PATH.
Standalone binary. Direct download for Linux, macOS, and Windows. Use this on CI runners that don’t need the GUI dependencies.
Docker image. For embedding the CLI in containerized pipelines.

Commands

The CLI exposes five subcommands:

Command	What it does
`init`	Set up a `.sitecmd/` project config in the current directory.
`scan`	Run a scan and write results to `.sitecmd/` (or stdout with `--json`).
`fix`	Output fix prompts from the last scan.
`watch`	Re-scan on an interval.
`check`	Regression check designed for git hooks.

Run sitecmd <command> --help for the full flag list per command.

`sitecmd init`

Bootstraps a .sitecmd/ directory at the project root.

sitecmd init [url] [options]

Flag	What it does
`[url]`	Positional. The site URL for this project.
`--name <NAME>`	Project name (defaults to the directory name).
`--yes`, `-y`	Non-interactive mode (use detected values without prompting).
`--no-deep-link`	Skip opening the desktop app after init.

init writes two files into .sitecmd/:

config.json - project URL, default scan type, environments, thresholds
.gitignore - preconfigured to commit only config.json

After your first sitecmd scan, the directory also holds last-scan.json - the most recent scan result, which --diff compares against.

Commit .sitecmd/config.json so your team and CI share settings. The result file (last-scan.json) is gitignored by default.

`sitecmd scan`

Runs a scan against the configured (or passed) URL.

sitecmd scan [options]

Flag	What it does
`--url <URL>`	URL to scan. Falls back to `.sitecmd/config.json` if omitted.
`--type <TYPE>`	Scan type: `health`, `security`, `accessibility`, `polish`. Default: `health`.
`--diff`	Compare with the last scan and show what changed.
`--env <NAME>`	Use a named environment URL from config.
`--fail-under <N>`	Exit 1 if the score is below N. The quality-gate flag.
`--json`	Output JSON to stdout, skip writing to `.sitecmd/`.
`--output json`	Alias for `--json`.
`--timeout <SECS>`	HTTP timeout per request. Default 30s.
`--categories <LIST>`	Comma-separated category filter.

Exit codes

Code	Meaning
`0`	Scan passed (or no threshold set).
`1`	Score below the `--fail-under` threshold.
`2`	Scan error (network problem, invalid URL, etc.).

These exit codes are the basis for every CI integration. See Quality gates in CI.

Examples

# Scan with current config
sitecmd scan

# Scan a specific URL
sitecmd scan --url https://example.com

# Quality gate: fail the build if security score drops below 90
sitecmd scan --type security --fail-under 90

# Diff against last scan
sitecmd scan --diff

# Pipe results to a file for further processing
sitecmd scan --json > results.json

`sitecmd fix`

Outputs fix prompts from the most recent scan.

sitecmd fix [options]

Flag	What it does
`--all`	Show all issues (default: top 5).
`--id <CHECK_ID>`	Show the fix for a specific check ID.
`--type <TYPE>`	Filter by issue type.
`--category <CAT>`	Filter by category.

Useful for piping into an AI tool from a script, or for printing a quick to-do list after a CI scan.

`sitecmd watch`

Re-scans on an interval. Useful when you’re actively fixing issues and want to see them tick down.

sitecmd watch [options]

Flag	What it does
`--url <URL>`	URL to monitor.
`--interval <SECS>`	Rescan interval. Default 300s (5 minutes).
`--env <NAME>`	Use a named environment from config.

`sitecmd check`

Regression check designed for git hooks.

sitecmd check [options]

Flag	What it does
`--install`	Install as a git `pre-push` hook.
`--strict`	Fail on any new issue, not just score drops.
`--threshold <N>`	Minimum score to pass (defaults to the value in config).

See Pre-push hooks for the recommended setup.

Core Web Vitals and axe-core

Core Web Vitals (Largest Contentful Paint, First Contentful Paint, Cumulative Layout Shift, Time to First Byte) and the axe-core accessibility deep scan run a real browser, and the standalone CLI binary ships without the browser engine. Run them from the desktop app instead.

The CLI’s live-site checks already cover performance signals without a browser: response time and TTFB, compression, caching headers, render-blocking resources, and image hygiene. For the static accessibility checks the CLI runs, see Live-site checks.

Authentication and data

The CLI doesn’t require a login. It doesn’t talk to a SiteCMD server. It writes results to the local .sitecmd/ directory and exits.

Two consequences:

Free to scan; fix needs a license. sitecmd scan and sitecmd check run the free-tier checks with no login. sitecmd fix (AI fixes) is a licensed feature and needs an active Core or Pro license, as do cross-source correlation, framework-specific fix guides, and ticket mirroring.
No shared history. The CLI’s .sitecmd/ directory is local to wherever it ran. If you want shared history across machines, run the desktop app on one machine and use the CLI for ephemeral CI checks.

When to use CLI vs. desktop

Use the desktop app for	Use the CLI for
Day-to-day triage	CI quality gates
Reading scan results in detail	Headless scans on schedules
Connecting integrations	Pre-push git hooks
AI editor workflows (via MCP)	Build pipelines
Long-running history	One-shot regression checks

The two are designed to coexist. Many teams run the desktop app locally for triage and the CLI in CI for enforcement.