Afield1. 输入公开网址并开始检测
打开「网站 SEO 审计」，粘贴要检查的网址，选择「开始检测」。使用访客能访问的公开页面，不要填 CMS 编辑地址、登录后的控制台或临时预览链接。公开检查这一步不需要连接 Google、CMS 或 GitHub。
如果你发现的是某篇文章中的坏链接，保留那篇文章的准确网址。只检查首页，不能证明文章里的问题也被覆盖到了。
2. 先确认检查范围
先看「扫描页面」「检查链接」和「检测时间」。报告只能覆盖发现并成功读取的页面。读取失败或扫描范围被截断，意味着还有未检查的部分，不能把没有结果当成通过。
如果报告说页面没有 H1 或正文，先在浏览器里打开它。有些网站在初始 HTML 加载后才通过 JavaScript 显示内容。核对检测依据来自哪个版本，避免把渲染问题误判成缺少正文。
3. 打开具体问题，决定修哪一处
查看「受影响页面」「检测依据」「怎么修」，确认 URL 正确，而且问题仍然存在。例如，导航链接指向旧价格页时，应先确认新的价格页地址；只改链接文字，不改目标地址，问题依然没有解决。
多个页面出现同一标题时，先检查是否共用了模板。若问题来自模板，应修改源头，而不是逐篇改完以后又被下一次构建覆盖。
4. 生成修复内容，并放回上下文审阅
选择「生成修复内容」，把建议与原页面一起看。如果界面提示 AI 不可用、已生成基础修复模板，这份内容还需要结合页面调整，不能直接当成定制修复。
针对这个页面，列出原始标题和建议标题。把开头改成帮助买家比较产品的内容。保留真实支持的功能；需要我确认的产品声明单独标明，其余内容写成可以直接审阅的版本。尤其检查描述是否承诺了页面没有的内容。例如，写了“附完整对比表”或“下载报告”，正文里就应有对应内容和可用入口。
5. 在正确的位置应用修改
代码网站可选择「通过 GitHub 修复」，按仓库连接步骤确认目标仓库，再检查文件差异与预览。WordPress 文章则使用目标站点的草稿和发布流程。
草稿、待合并的代码修改和已经上线的页面是不同状态。确认发布完成，再把任务记为已修复。
6. 复查页面，再单独看效果
重新打开发布后的准确网址，点击修复的链接，并重跑相关检查。记录修改内容与发布时间，方便以后分辨哪一次改动对应什么结果。
若要观察搜索表现，连接 Search Console，保持页面、查询范围和统计周期一致。健康分变高只能说明检查项发生变化，不能直接写成访问量、咨询量或 AI 引用增加。