Issues & Fixes

1Understanding issues

The Issues list shows every finding from your project's latest crawl: its severity (Critical, Warning, or Notice), the issue type code, the affected URL, a plain-language message, and where relevant a detail line and an on-page location (which area of the page, and which line) pinpointing exactly where the problem sits. Each row also carries an impact score and an effort score so you can weigh how much a fix is likely to help against how much work it takes.

Above the table, issue type cards group all occurrences of the same problem together (for example, every missing meta description across the site), showing how many pages are affected. Clicking a card filters the list down to just that issue type; clicking it again clears the filter. You can also filter by severity, search for an issue type by name, or filter by part of a URL, and export the current view as a CSV.

Every issue also carries a disposition: whether it's still open, or someone has marked it Fixed, a False positive, or Not applicable. The view tabs (To do, Not applicable, False positive, Fixed, All) let you switch between what still needs a decision and what has already been ruled on; "To do" is the default so resolved findings don't clutter the list. If you have permission to make these calls, you can set a disposition yourself from a dropdown on each row, and add a short reason. There is also a Review with AI button that examines undecided findings and marks the ones that clearly don't apply to your real content, for instance a `noindex` tag that belongs on an admin page rather than a landing page. The AI only ever marks findings as Not applicable; it never claims something is fixed or a false positive, and every AI-made call shows its reasoning and a confidence level so you can override it.

2Reviewing and approving fixes

The Fixes page lists fix proposals: for a handful of issue types (currently title tag, meta description, and structured data), Visibilitas can generate a ready-to-write change directly from your latest analysis. Clicking Generate proposals creates new proposals for any qualifying findings that don't already have one. Every proposal row shows the affected page, the fix type, and a clear old → new diff: the current value struck through, the proposed value beside it, so you always know exactly what would change before you decide anything.

Proposals move through a small set of tabs: Needs review (freshly proposed, awaiting your decision), Applying (approved and queued or being written), Live on site (written and, once verified, confirmed live), Needs attention (a deploy or verification failure), and Rejected. Selecting one or more rows in Needs review lets you approve or reject them in bulk; approving optionally groups the selection into a named batch (a release) with an optional hypothesis, which makes it easier to trace later whether that batch of changes moved the needle. Nothing reaches your CMS without an explicit approval.

Once approved, a change is written through your connected CMS and then re-crawled to verify it actually took effect. The Verified status only appears once Visibilitas has confirmed the live page really shows the new value, and the detail view shows that observed value as proof. If a deploy or verification fails, the failed tab lets you retry it; changes already live can be rolled back to their old value, and changes still queued (not yet written) can be cancelled. Expanding a row's Details shows the full timeline (created, approved, deployed, verified) and, for changes applied through the browser assistant, plain-language wording of exactly what field was written on your site.

If no CMS connection is set up yet, the page shows a prompt linking to the CMS settings, since approved changes have nowhere to deploy until one is connected.

3Issue severity, status & re-checks

Every issue carries one of three severities (Critical, Warning, or Notice), set by the detector that raised it, and these drive the default sort and the filters on the Issues page. Alongside severity, each finding has an impact score and effort score, giving you a rough cost-versus-benefit read without having to open every row.

An issue's disposition is separate from severity: it tracks what happened to that specific finding rather than how serious it is. Fixed means someone has confirmed the underlying problem is resolved; False positive means the detector was wrong about this particular case; Not applicable means the rule doesn't apply here (an AI review pass can make this call automatically, but never the other two; those stay a human decision). A disposition can always be reversed by setting it back to "Needs a decision," so a wrong call is never permanent.

Fix proposals carry their own, more granular status rather than reusing issue disposition: Proposed, Approved, Rejected, Deploying, Deployed, Verified, Verification failed, Deploy failed, and Rolled back. The distinction between Deployed and Verified matters: a change can be successfully written to your site and still be waiting on the next automated re-crawl to confirm it actually took effect, which is what moves it from Deployed to Verified.

Because issues come from a crawl and fixes are verified through a re-crawl, both lists reflect the state of your site as of the most recent crawl, not necessarily this exact second. Re-running a crawl (or waiting for the scheduled one) is what surfaces newly fixed issues as resolved, or new issues as they appear.