Your first scan
What a scan actually checks, what it needs from you, and where the results show up.
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 HTML, and runs every check against what came back. There are two kinds of checks under the hood:
- HTML checks look at the page you just fetched. Things like “is there an
<h1>?”, “islangset?”, “are heading levels in order?”. These are essentially free per scan because the HTML is already in memory. - Probe checks make their own follow-up requests. They fetch
/robots.txt, your sitemap, check security headers on alternate URLs, look up SSL, and so on. These take longer because each one is a real round-trip, but they run concurrently.
On top of those, the scan also runs polish signals: a separate batch of checks 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 so on. Polish runs in six categories: CSS architecture, HTML quality, copy and content, AI aesthetic, meta and infrastructure, and framework defaults.
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:
- Collect files. SiteCMD walks the project root for source files. It needs a recognizable root that contains
package.json,src,app,pages,functions,schema, orconfig. If none of those exist, the source audit stops and tells you to pick a different folder. - Analyze source. Per-file checks for vibe-code patterns, AI-generated code smells, exposed secrets, and similar.
- Supply chain. Dependency lockfile analysis (npm, pip, composer, cargo, go, ruby, drupal, wordpress) for known-bad or outdated packages.
- Operations. Project-level checks for deploy config, error handling, and operational gaps.
- Finalize. Severity normalization, sort, and deduplication.
Everything the source audit touches stays on your machine. Source files are never uploaded.
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 every active finding across the live-site checks, the source audit, and any connected integrations. Each row has a title, severity, location, and (if a fix guide exists) a step-by-step path to a fix tailored to your detected framework.
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.