Your first scan

Once you have at least one project, the Run Scan button in the top bar starts a scan immediately. SiteCMD checks your live site, then audits the linked source folder if you’ve connected one.

If you want to change settings before a run (different pages, accessibility deep-scan, that kind of thing), click the cog icon next to Run Scan to open the scan form. Most of the time you won’t need to.

What a scan actually checks

A scan does two things in sequence, both running off your machine.

The live site

SiteCMD fetches the URL for your active environment, parses the response, and runs the registry selected by the Web Scan type. There are two kinds of checks under the hood:

• HTML checks inspect response headers and initial HTML for directly observable fields and bounded patterns. Runtime-added content needs the optional browser phase.
• Probe checks make bounded follow-up requests for resources such as robots.txt, sitemap candidates, alternate URL forms, sampled destinations, exposed-path candidates, and certificate data. Independent probes generally run concurrently; redirect walks and fallback requests may be sequential.

A Health scan also runs polish signals: 30 review heuristics across CSS architecture, HTML quality, copy and content, visual patterns, meta and infrastructure, and framework defaults. These patterns help with human review; they do not identify authorship or prove that a referenced source map is publicly accessible.

The source folder (if linked)

If you linked a project folder when you added the project, the scan also audits your source. This stage walks the project directory and runs in phases:

1. Collect files. SiteCMD walks the project root for source files. It needs a recognizable root: a project manifest (package.json, composer.json, Cargo.toml, go.mod, pyproject.toml, and similar), a framework config, or a source layout like src, app, pages, or api. If none exist, the source audit stops and tells you to pick a different folder.
2. Analyze source. Bounded per-file checks for request-to-sink risks, route controls, secret-shaped literals, AI-runtime guardrails, and architecture clues.
3. Supply chain. Local npm manifest/import/lockfile, workflow, Dockerfile, and registry-configuration checks. Advisory and current-version lookup is a separate Updates workflow.
4. Operations and database. Deploy/readiness markers, CI/build/test and error-handling clues, schema/migration checks, and an optional per-run local-database metadata inspection that is off by default.
5. AI setup. Recognized agent instruction and MCP configuration structure.
6. Finalize. Severity/confidence policy, canonical IDs, sort, and exact-ID deduplication.

Source files are not uploaded. By default, Code Scan does not read values from local dotenv files or open a database. If you explicitly enable Inspect local database schemas for that run, SiteCMD reads local dotenv values only to discover a target and then reads schema and migration metadata, never application table rows. SQLite targets must stay inside the linked project. Every Postgres host and hostaddr must be loopback, or the connection must use a local Unix socket; remote and mixed-host targets are rejected. The Postgres inspection runs inside a read-only transaction. The option resets to off and is never enabled for scheduled scans.

If no folder is linked, this stage is skipped. You still get the full live-site picture.

Where the results go

When the scan finishes, SiteCMD updates the Dashboard. You’ll see:

• The SiteCMD Score for the project, with the change since the last scan.
• Top issues driving the score, ranked by severity and the impact each one has on your score.
• Category breakdown showing which areas (security, performance, SEO, accessibility, polish, and so on) are pulling the score down hardest.
• Recent activity including this scan, prior scans, and any deploy, uptime, or analytics events from the same window.

From there, the Issues page is the unified list of active findings across Web Scan, Code Scan, and connected integrations. Each group has a title, severity, confidence/evidence context, source instances, and available fix guidance. A file location exists for Code Scan findings when the detector can identify one; live-site findings instead carry page or probe context.

How long does a scan take?

It depends on your site. A small static site with no integrations finishes in seconds. A large site with many probe targets and a deep source folder takes longer. The live-site portion is bounded by network latency to your site plus the URLs it depends on. The source audit is bounded by how much source there is to walk.

The scan progress overlay shows you the current stage and lets you cancel at any time.

Running scans on a schedule

You can also run scans automatically on a schedule. SiteCMD runs scheduled scans in the background even if you’ve closed the app window: the app stays in the system tray and the scheduler wakes up to run any scan that’s due. If the score drops or a new critical issue appears, you get an OS notification.

For the full setup, see Scheduled scans.