You ran a scan. You have findings. Now what?

This page is the playbook for working through them. If you want the concepts behind severity, confidence, and status first, start with Understanding findings.

The Issues page

Open Issues from the sidebar. By default it shows everything in the New state for the active project, sorted by impact (highest first).

Three controls do most of the work:

Severity filter. Critical / High / Medium / Low. Combine freely.
Source filter. Live site, source audit, or specific integrations (analytics, deploys, etc).
Category filter. Security, performance, SEO, accessibility, polish, dependencies, and the rest.

The filters compose. “Critical security issues from the source audit only” is one click in each filter.

A useful triage order

There’s no rule here, but a common sequence:

Confirmed criticals first. They cap your score at 49 and they’re usually genuinely urgent (exposed secrets, broken pages, security gaps). Either fix them or, if they really don’t apply, mark them not applicable.
Confirmed highs next. Same story, capping your score at 79. Often where the bulk of meaningful work lives.
Needs-review findings. Quick pass to decide: is this real? If yes, promote it or fix it. If no, dismiss with a reason. Doing this once means the next scan doesn’t surface the same noise.
Mediums and lows. Now you’re cleaning. Filter by category if you want to do a focused pass (e.g. “let me knock out the accessibility mediums on the marketing pages”).

Actions you can take on a finding

Every finding has the same set of actions, available from the issue row or the detail view:

Verify

Re-runs the relevant check right now. For live-site findings, this is a fresh probe of the specific check. For source-audit findings, this re-runs the full code scan.

Use it after you’ve made a fix and want immediate confirmation, without waiting for the next scheduled scan.

If the check now passes, the issue moves to Verified automatically. If it still fails, you’ll see the latest evidence on the detail view.

Mark fixed

Sets the status to Verified manually, without re-running anything. Useful when you know the fix shipped and you don’t want to wait for verification.

This isn’t a way to game the score: the next time a scan runs (manual or scheduled), the check runs against the live site or source. If it fails, the issue reopens to New automatically. Self-reported fixes that didn’t actually work get caught.

Snooze

Sets the issue aside until a specific date. Drops it out of the active list and the score until the date passes, then it comes back automatically.

Use snooze for “we’ll deal with this next sprint” or “I’m going on vacation, surface this when I’m back.” Don’t use it to make the score look better on a Tuesday.

Mark not applicable (Ignore)

Permanently dismisses the issue for this project. The Dashboard exposes this as the Not applicable button on the issue detail view.

Use it for findings that don’t apply to your stack:

“Missing favicon” on a backend API that doesn’t have a UI
“Add a viewport meta tag” on a print-only document
A specific recommendation we make that conflicts with a design decision you’ve made

The issue stays dismissed forever for this project. Future scans won’t surface it. If you change your mind, you can reopen it from the Dismissed view.

Block

Flag the issue with a written reason. Stays out of the active list and the score, but appears under a Blocked filter so you can see everything that’s tracked-but-paused.

Use block when an issue is real but you can’t fix it right now and the reason isn’t “later”:

“Waiting on a vendor patch”
“Legal said keep this until contract renewal”
“Depends on a framework upgrade we can’t do this quarter”

The reason is shown in the Blocked view, so you (or whoever else looks at this project) can see what’s gating each one.

Reopen

Puts a verified, ignored, or blocked issue back to New. Useful if you marked something fixed prematurely, or if you’ve changed your mind about a dismissal.

Filters at a glance

Filter	What it shows
All	Every active finding for the project
By severity	Just critical, high, medium, or low
By category	Security, performance, SEO, accessibility, polish, dependencies, and the rest
By source	Live site only, source audit only, or specific integrations
Quick wins	Findings whose fix-guide marks the work as `quick` effort
Snoozed	Issues currently set aside until a date
Blocked	Issues paused with a reason
Dismissed	Issues marked not applicable or verified

Bulk actions

For repeating decisions, the Issues page supports multi-select. Click the row checkbox, then use the bulk action bar at the bottom:

Bulk mark not applicable (with a single reason that gets attached to all)
Bulk snooze (same date applied to all)
Bulk block (same reason for all)
Bulk export to CSV

Bulk actions are most useful right after the first scan of a real site, when 30 findings come back at once and you can identify a clear “all of these don’t apply to us” set.

How triage affects your score

The score updates immediately when you change a status, because the score math runs on active findings (those in New). Snooze, ignore, block, or verify any active finding and the score recomputes.

For the full math, see The SiteCMD Score. The short version: any status other than New removes the issue from the score until it comes back.

Don’t dismiss things just to clear the number. A score that lies about the state of your site is worse than no score at all.

When to fix vs. dismiss

A useful rubric, after triaging a few thousand findings yourself:

Fix when the issue is real and the fix is in your hands.
Snooze when the fix is real but the timing is wrong.
Block when the fix is real but you can’t act on it (vendor, legal, blocked dependency).
Mark not applicable when the finding doesn’t apply to your project, stack, or context.
Verify when you think you fixed it and want SiteCMD to confirm.
Mark fixed when you definitely shipped a fix and don’t want to wait for verification.

When in doubt, leave it in New. The score is meant to reflect reality.