问题列表
如何通过 todo 和 problem 查看问题、先修什么、各严重程度和状态的含义，以及 check 如何确认线上修复生效。
扫描发现的每个问题，都可以通过助手拿到：todo 看本周计划和其余队列，problem 看某一条的证据和修复步骤。一个问题就是一条规则没通过，不管它出现在多少个页面上。本页说明问题如何排序，以及如何从未解决走到已修复。
账户设置（站点、Google、账单、已连接的助手）在 /account。日常 SEO 工作在对话里通过 MCP 完成。
每个问题一条 finding
todo 每个问题一条，最该先修的排在最上面。每条包括：
- 问题名称和严重程度；
- 影响了多少个页面；
- 是否最近一天内首次发现；
- 一句话证据；
- 置顶待办还带：
fixPrompt、url、以及 verify 下一步。
用该条的 findingId 调 problem 可在需要时展开：示例 URL、发现了什么、首次和最近发现时间、重新出现过几次、指向规则说明的链接，以及同样的修复说明。/products/*、/blog/* 这类路径模板会把共用布局的页面归在一起——1,200 个商品页都缺 meta description，只算一条 finding、一个模板，因为通常就是模板里改一处。
接下来：
- Solo 或
dev：在仓库里改、开 PR，再check（target: fix，ref= PR 链接）。 - Ops 或
product：用send_to_dev生成可贴给开发的任务，PR 开好后同样check。 triage的ignore（需要原因）按模板忽略；restore重新打开。triage不再标记已修复——确认修复用check（target: fix）。
问题来自四类检查：对每个页面做的规则检查和 AI 判断、在代表页上的性能实测，以及在全站比较页面的页面判断。详见扫描是怎么工作的；每条规则由哪一类发现，见规则说明。
模型把握足够的页面判断（置信度 0.85 及以上）和其他问题列在一起。把握较低的（0.60 到 0.85）仍会保存，但不会出现在 todo 和周报里，除非在 /account 打开较低置信度的 AI 判断。不用模型的检查（例如重复的标题）始终列出。被隐藏的判断仍然计入健康分。
todo 的 view: links 列出值得补的内部链接，以及没有任何页面链接到的页面。详见扫描是怎么工作的。triage 的 decide_link 可标记接受或忽略某条建议。
严重程度
每条规则的严重程度是固定的，不由 AI 决定，所以同一个问题每次都是同一个级别。
| 严重程度 | 含义 |
|---|---|
| 错误 | 让页面无法被收录，或严重拖累页面：noindex、缺少标题、返回错误状态码、Core Web Vitals 很差等。 |
| 警告 | 正在让你损失排名或点击，值得尽快修。 |
| 提示 | 较小的改进或最佳实践。 |
每条规则还有一个权重，决定它会扣掉多少健康分，详见规则如何影响健康分。
先修什么
站点有 Search Console 数据时，问题按受影响页面的搜索流量排序：先看点击，再看展示。严重程度算进这个权重——错误按提示的四倍计，警告按两倍计——所以有真实点击的页面上，提示不会排在错误前面，除非提示所在页面的流量超过错误的四倍。剩下的平局按修好后能涨的健康分、每小时的两两比较、严重程度和影响页面数依次决定。
没有 Search Console 数据时，顺序是修好后能涨的健康分，再是两两比较，再是严重程度和影响面。
每小时的两两比较最多对 40 个问题提问：如果这周只能修其中一个，该修哪个？它看得到规则、一行证据、影响面，以及连接 Search Console 时的搜索流量。它只用来打破平局。
同一套顺序驱动 todo、周报，以及 status / report 里的「先修什么」。比较有结论时，报告会说明为什么这条排第一：
- 不修的话搜索引擎无法收录这些页面
- 正在损失访客或排名
- 访客或 AI 爬虫看到的内容不对
- 小改动立刻有回报
- 拖得越久越贵
问题状态
问题会经过这些状态：
| 状态 | 含义 |
|---|---|
| 未解决 | 扫描发现了，尚未关闭。 |
| 已修复 | 已关闭：后来的扫描或修复复查不再发现。 |
| 已忽略 | 有人决定不修并写了原因。不再计入健康分。 |
| 需重新测量 | 性能问题，页面超过 45 天没再测。在重新测量前不计分。 |
背后还有一种 superseded：新扫描再次发现同一问题时，新结果接管，旧副本只作历史。
修复复查可能在 Loomaly 侧处于等待上线（线上页面还没变）。那不是单独的问题状态——稍后再调 status 看宣布。
状态如何变化
| 从 | 到 | 怎么变 |
|---|---|---|
| 未解决 | 已修复 | check（target: fix，附 PR ref）不再发现，或后续整页扫描干净。 |
| 未解决 | 已忽略 | triage 的 ignore，并写原因。 |
| 已忽略 | 未解决 | triage 的 restore。 |
| 已修复 | 未解决 | 后来的扫描又发现了。详情里会写复现次数。 |
忽略会被记住：之后的扫描会继续忽略，不会把它报成已修复。
扫描如何确认修复
修复要靠再扫线上页面确认，不能只信声称。
先上线
把改动部署到线上站点。Loomaly 读的是访客和搜索引擎看到的页面，不是你的代码。
用 PR 复查
让助手对这条 finding 跑 check（target: fix，ref = PR 链接）。可以刚开 PR 就调——页面未变时，Loomaly 进入等待上线（受套餐等待上线上限约束）并自动复查，不另收费。下次 status 宣布结果。
影响很多页面的问题会随每个页面被复查而逐个关闭。要一次查全部，用 check（target: site），或等每周自动复查。
看结果
问题消失了，就会变成已修复。还在，则保持未解决并带上新证据。健康分随之更新。
单页扫描会重新加载该页、跑规则检查和 AI 判断，并在 PageSpeed Insights 有数据时再测性能。由此有几条限制：
- 性能问题只有真正测过性能的扫描才会关闭。
- 页面判断类问题（例如两个页面抢同一个搜索）只有下一次整站扫描后的页面判断才会关闭。单页 check 不会重问那些问题。
- 全站 pass 可以关闭规则检查问题，以及跑过 AI 判断的页面上的 AI 判断问题。它关不了性能问题，因为不测速度。
- 某页没跑成 AI 判断时，该页的 AI 判断问题会一直开着，直到以后再判断一次。
套餐页数
会实测代表页的整站或单页 check 占用套餐月度页面数。用完后会提示升级。用 check target: fix 复查修复占用修复复查配额（不占深度页）；等待上线期间的自动复查免费。详见套餐与页面数。