When you click Run Scan, SiteCMD runs two engines in sequence and merges their findings into one Dashboard. You don’t pick which engine to run. The combination is the scan.

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 every check against what it got back.

Two kinds of checks make up this stage:

HTML checks look at the page you just fetched. “Is there an <h1>?” “Is lang set?” “Are heading levels in order?” These run against the HTML already in memory, so adding more of them is essentially free.
Probe checks make their own follow-up HTTP requests. They fetch /robots.txt, your sitemap, alternate URLs for security headers, look up SSL, and so on. Each one is a real round-trip to your server. They run concurrently, so the total time grows with the slowest probe rather than the count.

On top of those, the live-site engine also runs polish signals: a separate batch looking for the telltale signs of vibe-coded sites. Excessive inline styles, AI-aesthetic gradients and glow shadows, default page titles, missing Open Graph tags, source maps shipped to production, and more. Polish runs in six groups: CSS architecture, HTML quality, copy and content, AI aesthetic, meta and infrastructure, and framework defaults.

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, the source audit walks your project root in phases:

Collect files. SiteCMD walks the directory looking for a recognizable project root. It needs at least one of: package.json, src, app, pages, functions, schema, or config. If none of those are present, the audit stops and asks you to point at a different folder.
Analyze source. Per-file checks for vibe-code patterns, AI-generated code smells, exposed secrets, unsafe queries, missing auth checks, and similar.
Supply chain. Dependency lockfile analysis. SiteCMD parses lockfiles from npm, pip, composer, cargo, go, ruby, drupal, and wordpress projects, then checks each package against the registry for known-bad versions and outdated pins.
Operations. Project-level checks for deploy config, error handling, missing observability, and operational gaps.
Finalize. Severity normalization, sort, and deduplication.

Nothing in this audit leaves your machine. The walk reads files, the analysis is local, and the results are written to SiteCMD’s local SQLite database. Lockfile registry lookups are the one outbound part, and they only send package names and versions, never your source.

Why both engines

Most “site health” tools pick one of these and call it the answer. They miss things.

Live-site-only tools see what you shipped, but they can’t see why a problem is there. They can tell you a meta tag is missing, but not that the template that generates it has a typo. They can flag a slow page, but not that a useEffect runs a fetch on every render.

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. A failing live-site check often pairs with a source-folder finding that explains it, and the dashboard surfaces those correlations directly.

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.

The list is deduplicated. If both engines find the same underlying problem, it appears once, with both sources attributed.

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 scans or source. See Local-first architecture for the full network behavior breakdown.
It does not run code. The source audit is static analysis. It doesn’t execute scripts, doesn’t spawn subprocesses against your project, doesn’t run your build.
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.