Triaging issues

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 every active finding for the project, sorted by severity and then by impact (highest first).

Four controls do most of the work:

• Show filter. All, Web Scan, or Code Scan. Narrows the list to one engine’s findings.
• Category filter. Once you’ve picked an engine, a second dropdown filters by its categories: web categories (Security, Performance, SEO, Accessibility, Compliance, Config, Polish) or code-scan categories (Security, Database Analysis, AI Safety, Architecture, Operations, Dependencies, AI Setup), each with a live count.
• Severity filter. Critical / High / Medium / Low.
• Status filter. Active, Ignored, Blocked, Resolved, or All. Active is the default: everything that currently counts toward your score.

The filters compose. “Critical security issues from the code scan only” is one click in each dropdown.

A useful triage order

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

1. Criticals first. They carry the highest potential impact and the largest deduction. A Critical finding only invokes the 49-point security cap when its check class and confidence also meet the narrow cap rules; many static Critical review findings do not. Read the evidence before choosing the response.
2. Highs next. The next-biggest deductions, and often where the bulk of meaningful work lives.
3. Needs-review findings. Quick pass to decide: is this real? If yes, fix it. If no, ignore it. Doing this once means the next scan doesn’t surface the same noise.
4. 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

Click any row to open the finding’s detail view (the dossier). The actions live there:

Verify

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

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

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

Fix with Agent

Briefs your coding agent on the finding, waits for the change, then re-runs the check to confirm the fix actually worked. The verified agent fix loop is included without a local usage cap. See Fixing with AI editors.

Ignore

Dismisses the issue for this project. 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 ignored until you say otherwise: future scans won’t resurface it, and it sits under the Ignored status filter. If you change your mind, open it there and reopen it.

Block

Pauses the issue without dismissing it. Stays out of the active list and the score, but appears under the Blocked status filter so you can see everything that’s tracked-but-paused.

Use block when an issue is real but you can’t act on it right now:

• Waiting on a vendor patch
• A dependency upgrade you can’t do this quarter
• A call someone else on the project has to make

Reopen

Puts an ignored or blocked issue back to active. Open the Ignored or Blocked filter, click the issue, and hit Reopen.

What happens when a fix doesn’t stick

Verified issues aren’t taken on faith. The next time a scan runs the relevant check, one of two things happens: the check passes and the issue stays Verified, or it fails and the issue moves to Regressed. Regressed issues count toward your score again and sit in the active list marked as regressions, so a fix that didn’t hold is impossible to miss.

How triage affects your score

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

For the full math, see The SiteCMD Score. The short version: ignored, blocked, and verified issues don’t count against you.

Don’t ignore 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 practical decision rubric:

• Fix when the issue is real and the fix is in your hands.
• Block when the fix is real but you can’t act on it right now (vendor, legal, blocked dependency).
• Ignore when the finding doesn’t apply to your project, stack, or context.
• Verify when you think you fixed it and want SiteCMD to confirm.

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