How a scan works

SiteCMD has two scan engines. A Full Scan runs Web Scan first and then Code Scan when a project folder is linked. You can also run either engine by itself. Their active findings feed the same Issues list and one SiteCMD Score.

This page explains what each engine looks at and why both matter. If you just want to start, read Quickstart. If you want the score math, read The SiteCMD Score.

Engine 1: live-site checks

The first engine fetches your URL, parses the response, and runs the registry selected by the Web Scan type. A normal Health scan covers the live-site categories and polish signals; focused Security, Accessibility, and Polish scans intentionally run smaller subsets.

Two kinds of checks make up this stage:

• HTML checks inspect the fetched response headers and initial body. Examples include language markup, heading-order signals, metadata, cookies, and resource declarations. They do not see runtime-added DOM content unless browser analysis is enabled.
• Probe checks make bounded follow-up HTTP requests. They fetch robots.txt, sitemap candidates, alternate URL forms, sampled link/asset destinations, exposed-path candidates, and certificate data. Independent checks generally run concurrently, while redirect walks and method fallbacks can require sequential requests.

On a Health or focused Polish scan, the engine also runs polish signals: 30 review heuristics across CSS architecture, HTML quality, copy and content, visual patterns, meta and infrastructure, and framework defaults. They surface source signatures such as inline-style density, repeated copy formulas, default metadata, and source-map references. They do not identify authorship, and a source-map reference does not prove that the map is publicly accessible.

The live-site engine needs nothing from your machine except network access to your URL. You can run it against any site SiteCMD can reach.

Engine 2: source-folder audit

The second engine runs only if you linked a project folder when you added the project. If you didn’t link one, this stage is skipped and the scan ends after the live-site portion.

When it does run, Code Scan walks the linked root in phases:

1. Collect files. SiteCMD walks the directory looking for a recognizable project 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 are present, the audit stops and asks you to point at a different folder.
2. Analyze source. Bounded per-file checks for request-to-sink patterns, route protections, secret-shaped literals, AI-runtime controls, and architecture clues across supported source extensions.
3. Supply chain. Local npm graph, lockfile, registry-host, integrity, workflow, Dockerfile, and build-input checks. Code Scan does not query advisories or current package versions.
4. Operations and database. Project readiness, CI/build/test markers, scrubbed example-env coverage, debug posture, schema/migration checks, and optional per-run inspection of an explicitly local SQLite or loopback Postgres target.
5. AI setup. Recognized agent instruction and MCP configuration structure.
6. Finalize. Severity/confidence policy, sort, canonical IDs, and exact-ID deduplication.

Source analysis and npm dependency inspection are local, and results are written to SiteCMD’s local SQLite database. Code Scan does not perform lockfile registry/advisory requests. Ordinary scans do not read values from non-example dotenv files or open project databases. Enabling Inspect local database schemas for one run permits local dotenv target discovery and bounded, read-only inspection of schema and migration metadata in a project-contained SQLite file or an all-loopback or Unix-socket Postgres target. Application table rows are never queried, and remote or mixed-host targets are rejected. The option resets to off and scheduled scans never enable it.

Why both engines

Most site-health tools do one or the other. Each misses what the other would have caught.

Live-site-only tools see what you shipped, but they usually cannot see the source condition behind it. They can observe a missing meta tag or a slow response, but not inspect the template or data-access code that may explain it.

Source-only tools see your code, but they can’t see what your live deployment actually serves. CDN-injected scripts, third-party widgets, runtime feature flags, server-rendered values that didn’t make it into the build: the source folder doesn’t know about any of that.

Running both together lets SiteCMD cross-reference known equivalent or causally related signals. Correlation is supporting evidence, not proof that one finding caused another.

What gets merged

After both engines finish, the findings flow into one ranked list of active issues on the Issues page. Web-scan findings, code-scan findings, and any signals from connected integrations (analytics, search console, uptime, deploys) all sit in the same list, sorted by severity and the impact each issue has on your SiteCMD Score.

Known equivalent check IDs are grouped into one issue with separate source instances. SiteCMD does not claim semantic deduplication for every pair of differently named findings.

What a scan does not do

• It does not push changes. SiteCMD reads only. It can write to your local database; it does not modify your source code, your live site, or anything in your connected integrations.
• It does not upload your source, and does not upload your scans unless you connected that site. See Why local-first for the full network behavior breakdown.
• It does not run application code. Code Scan does not execute project scripts, builds, or tests. Its explicitly enabled local database phase performs read-only schema/catalog inspection.
• It does not fix things. SiteCMD surfaces issues, suggests fixes, and (if you connect an AI editor via MCP) hands the context to your AI tools. The fix is your call.