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:

• Category filter. One dropdown covers findings from both scanners: web categories (Security, Performance, SEO, Accessibility, Privacy & Policies, Config, Polish) and code-scan categories (Security, Database, AI Safety, Architecture, Operations, Dependencies, AI Setup), each with a live count. Code findings show their category on the row, so a Database finding reads "Database" rather than "Code".
• Search. A search box narrows the list to issues whose title contains what you typed.
• 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" is one click in each dropdown, and the list pages twenty issues at a time with numbered page links.

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, block it so future scans keep it out of the way. 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

Temporarily hides the finding until the next scan. It drops out of the active list and the score for now, and sits under the Ignored status filter. If the next scan detects it again, it returns to your active list and counts against your score again.

Use ignore to clear the deck without making a permanent call: something you're about to fix anyway, or a finding you want the next scan to rule on before you decide.

Block

Permanently hides the finding across future scans. It stays out of your active list and score until you restore it from the Blocked status filter.

Use block 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

Reopen

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

Report a false positive

If a finding is flat-out wrong - the check fired on something that isn't there - don't just block it: report it with the false-positive form on the public repository. Reports get accuracy labels and feed directly into tightening the check for everyone.

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.
• Ignore when you want it out of the way for now and the next scan should rule on it again.
• Block when the finding doesn't apply to your project, stack, or context, and shouldn't come back.
• 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.