Issues
How Loomaly lists problems through todo and problem, what to fix first, what each severity and state means, and how check confirms a fix on the live page.
Every problem a scan finds is available through your assistant: todo for this week's plan and the rest of the queue, problem for one finding's evidence and fix steps. Each problem is one rule that fails, on however many pages it fails. This page explains how problems are ranked and how one moves from Open to Fixed.
Account settings (sites, Google, billing, connected assistants) stay under /account. Day-to-day SEO work runs in chat over MCP.
One finding per problem
todo returns one item per problem, with the one to fix first at the top. Each item includes:
- the problem's name and severity,
- how many pages it affects,
- whether it is new (first seen in the last day),
- a short line of evidence,
- on the top open item:
fixPrompt, url, and verify next step.
problem with that item's findingId expands it when you need more: the sample URL, what was found, when it was first and last seen, how many times it came back, a link to the Rules reference, and the same fix prompt for your coding assistant. Path templates such as /products/* or /blog/* group pages that share a layout — "Missing meta description" on 1,200 product pages is one finding with one template, because it is usually one fix in one template.
From there:
- Solo or
dev: apply the fix in the repo, open a PR, thencheckwithtarget: fixandrefset to the PR URL. - Ops or
product:send_to_devfor paste-ready task text, then the samecheckafter the PR is open. triagewithignore(needs a reason) ignores the problem on that template; restore reopens it.triagedoes not mark fixes — usecheck(target: fix).
Issues come from four kinds of checks: rule checks and AI judgment on every page, performance tests on representative pages, and page judgments that compare pages across the site. How a scan works explains each one; the Rules reference says which finds each rule.
Page judgments the model is sure about (confidence 0.85 or above) sit with everything else. Judgments it is less sure about (0.60 up to 0.85) stay stored and stay out of todo and the weekly report until you turn on lower-confidence AI judgments under /account. Checks that do not use the model, such as a duplicated title, are always listed. Hidden judgments still count toward the health score.
todo with view: links lists internal links worth adding and pages nothing links to. See How a scan works. triage with decide_link marks a suggestion accepted or dismissed.
Severity
Every rule has a fixed severity. The AI does not choose it, so the same problem always gets the same one.
| Severity | Meaning |
|---|---|
| Error | Stops the page from being indexed or badly hurts it: noindex, a missing title, an error status, poor Core Web Vitals. |
| Warning | Costs you rankings or clicks and is worth fixing soon. |
| Notice | A smaller improvement or best practice. |
Each rule also has a weight, which decides how much it lowers your health score. See how rules affect your health score.
What to fix first
When Search Console has data for the site, problems are ordered by the search traffic of the pages they affect: clicks first, then impressions. Severity is part of that weight — an error counts four times a notice, a warning twice — so a notice does not sit above an error on a page people actually find, unless the notice's pages get more than four times the traffic. Health-score points, then an hourly comparison, then severity and how many pages are affected, break the remaining ties.
When there is no Search Console data, the order is the health-score points fixing the problem would add, then the hourly comparison, then severity and reach.
The hourly comparison asks, for up to 40 problems: if you could fix only one of these two this week, which would it be? It sees the rule, a line of evidence, how much of the site it affects, and the pages' search traffic when Search Console is connected. It only breaks ties.
The same order drives todo, the weekly report, and the "top things to fix" in status / report. When the comparison has an answer, the report says why that problem comes first:
- Search engines can't index these pages until it's fixed
- It's costing you visitors or rankings right now
- Visitors or AI crawlers are shown something wrong
- A small change with an immediate payoff
- It gets more expensive the longer it's left
Issue states
Findings move through these states:
| State | What it means |
|---|---|
| Open | Found by a scan, and not yet closed. |
| Fixed | Closed: a later scan or a fix re-check no longer finds it. |
| Ignored | Someone decided not to fix it and gave a reason. It no longer counts against your health score. |
| Needs re-measuring | A performance issue whose page hasn't been measured for 45 days. It stops counting until the page is measured again. |
Behind the scenes there is one more state, superseded. When a new scan finds the same issue again, the new result takes over and the older copy is kept only as history.
A fix re-check may sit in awaiting deploy on Loomaly's side (the live page has not changed yet). That is not a separate finding state — call status later for the announcement.
How a problem changes state
| From | To | How |
|---|---|---|
| Open | Fixed | check with target: fix (PR ref) no longer finds it, or a later full scan of the page is clean. |
| Open | Ignored | triage with ignore and a reason. |
| Ignored | Open | triage with restore. |
| Fixed | Open | The issue shows up again in a later scan. Its details say how many times it has come back. |
Ignoring is remembered: later scans keep an ignored issue ignored and never report it as fixed.
How a scan confirms a fix
A fix is confirmed by scanning the live page again, not by trusting a claim.
Ship the change
Deploy the fix to your live site. Loomaly reads the page as visitors and search engines see it, not your code.
Re-check with the PR
Ask your assistant to run check with target: fix for that finding and ref set to the PR URL. You can call it right after opening the PR — if the page is unchanged, Loomaly awaits deploy (under your plan's awaiting-deploy cap) and re-checks automatically at no charge. The next status announces settled results.
A problem on many pages closes page by page. To check them all at once, check with target: site, or wait for the weekly re-scan.
Read the result
If the issue is gone, it moves to Fixed. If it is still there, it stays Open with fresh evidence. Your health score updates with it.
Scanning a single page loads it again, runs the rule checks and AI judgment, and measures performance again if PageSpeed Insights returns data. A few limits follow from that:
- A performance issue is only closed by a scan that actually measured performance.
- Page-judgment issues (such as two pages competing for the same search) are closed only by the next page-judgment pass, which runs after a full site scan. A single-page check does not re-ask those questions.
- The site-wide pass can close rule-check issues, and AI-judgment issues on pages where AI judgment ran. It can't close performance issues, because it doesn't measure speed.
- If AI judgment couldn't run for a page, that page's AI-judgment issues stay open until a later scan judges it again.
Plan pages
A full-site or single-page check that measures representative pages uses your plan's monthly pages. When they're used up, Loomaly asks you to upgrade instead. Re-checking a fix with check target: fix uses the fix-check quota (not an in-depth page); auto re-checks while awaiting deploy are free. See Plans & pages.