网站审计别只等 Lighthouse：用 OptiQra 把 AI 可见性、代码库修复与周期复检串成闭环
网站质量治理常是一次性动作：上线前跑一遍单页性能检查，发现标题、替代文本或安全响应头有问题，再把截图交给开发人员。这个流程能发现局部缺陷，却很难回答工程问题：整站哪些页面被内部链接遗漏？客户端渲染后的正文是否真的可抓取？修复的是生产页面，还是仓库里的源文件？下一次扫描时，哪些问题已经消失、哪些又出现了？
OptiQra 是一个 MIT 许可的开源网站工程审计工具，仓库以 Next.js、TypeScript 为主，并提供 Tauri 2 桌面应用。它把 SEO、性能、无障碍和安全检查，与 GEO/AEO（面向生成式搜索与问答系统的可见性）放进同一份报告。它不只列出问题：规则明确的项可以走确定性修复；需要文案判断的项可使用开发者自行提供的模型 API；桌面版还能在窗口关闭后执行周期复检。
不要把“让 AI 引用网站”当作工具可以保证的结果。模型或搜索系统是否采用内容由外部策略决定。实际可验证的目标是：页面可访问、关键事实有来源、内容结构易于提取，并且每次修改都能进入代码审查和复测闭环。
线上站点与代码库要分别审计
OptiQra 支持粘贴 URL 扫描，也支持上传项目压缩包做代码库审计。线上扫描适合检查最终部署的 robots.txt、sitemap、重定向链、HTTP 安全头、资源加载与内部链接；它能看到 CDN 和反向代理共同形成的结果，却看不到尚未部署的源码。项目审计则能检查 HTML、JSX/TSX、Vue、Svelte、Astro 等文件，以及配置层可修复的问题；但它不能证明生产环境的缓存和响应头已经生效。
因此建议先对线上 URL 建立基线，再对能定位到源文件的问题运行项目审计，最后把修复提交进仓库并重新扫描线上站点。不要把“本地已改”当成“用户已经获得修复”。
GEO/AEO 是检查工程信号，不是神秘评分
工具会检查几个可落地的信号。第一是抓取权限：读取 robots.txt，检查 GPTBot、ClaudeBot、PerplexityBot、Google-Extended 等是否被允许或阻止；这只是访问策略，不保证收录。第二是客户端渲染可见性：工具在沙箱中运行页面 JavaScript，并检查 hydration 后的 DOM，以发现正文是否只在浏览器执行后才出现。不同爬虫的执行能力并不相同，关键内容仍应尽量以可访问的 HTML 提供。
此外，实体关联和出处线索会关注 sameAs 一类指向权威资料的链接；可回答内容则关注清晰层级、可提取段落和问答结构。它们能减少技术实现遮蔽内容的概率，却不能替代事实质量。页面缺少可核验主张、来源或维护责任时，单独增加 llms.txt 并不能建立可信度。
从可复现的本地基线开始
官方 README 给出的最小本地流程如下：
npm install npm run dev npm run lint npm run type-check npm test
先扫描生产 URL，再选择一个由仓库维护的页面做项目审计。处理报告时，按性质分组比盯着总分更有效。缺失替代文本、错误属性或可直接复用的元数据，属于确定性结构问题，优先查看工具生成的 diff。标题、描述、CTA 和表单标签属于业务判断问题，即使 AI 能生成候选文案，也必须核查产品术语、合规表述和事实。安全头、重定向、爬虫规则和性能数据属于环境问题，必须用部署后的 URL 复扫确认。
OptiQra 的 README 说明，AI 修复可使用用户在界面中提供的 OpenAI、Anthropic、Google、Groq、OpenRouter、Mistral、DeepSeek 或 xAI 密钥；密钥直接发送到所选提供商，工具自身服务器不保存它。生产场景仍应采用权限受控、额度受限的专用密钥，并把生成后的内容当作普通变更审查。
自动修复必须进入 PR
一套稳妥流程是：扫描报告提出候选，修复写入工作分支，CI 运行现有测试与构建，部署后再扫描 URL 确认最终效果。工具支持针对 HTML、JSX/TSX、Vue、Nuxt、Angular、Svelte 与 Astro 的框架感知修复，但不代表所有自定义组件、模板宏或构建插件都能被安全重写。
PR 中至少记录扫描目标、问题类别、实际修改的文件及理由、部署后的复扫结论。对文本拼接类修改，README 说明工具会检查结构不变量，异常时丢弃变更；这只能保护结构，不替代业务测试、视觉回归或安全审查。
把报告转成可执行的验收清单
扫描分数适合观察趋势，却不适合作为发布门槛。更好的做法是把每次重要修复写成可复查的验收条件。例如修复 robots 规则后，保存部署前后的 robots.txt，并明确哪些 bot 的访问策略发生变化；修复客户端渲染后，分别检查原始响应和渲染后 DOM 是否含有页面的核心标题、正文与规范链接；修复结构化数据后，用独立校验器检查 JSON-LD 的语法，再确认页面中确实存在与标记一致的可见内容。
对于代码库扫描给出的自动修复，验收还应包括框架级测试。修改 React 或 Vue 组件的属性后，至少运行类型检查与相关组件测试；修改 sitemap、headers 或容器配置后，则应在预发布环境请求真实 URL，不能只凭配置文件的 diff 判断。OptiQra 本身提供 POST /api/analyze、POST /api/auto-fix 和 POST /api/auto-fix-project 等接口，但把它接进 CI 前，要先确认上传代码、调用外部 AI 提供商、扫描第三方 URL 是否符合团队的数据边界。
一个简单的失败处理原则是保留原始报告和修复前的文件哈希。当后续扫描提示回归时，先比较部署版本、站点配置与爬虫规则是否变化，再判断是否需要重新运行 AI 修复。不要让模型反复改写同一段内容来追逐波动分数；有些波动来自 PageSpeed 外部数据、第三方脚本或审计环境，正确动作可能是记录原因并降低告警优先级，而不是修改产品页面。
周期扫描应发现回归，而非制造噪声
Web 版把扫描历史与计划保存在浏览器 IndexedDB；应用标签页或 PWA 正在运行时，调度器会检查到期任务。README 明确把 Periodic Background Sync 定义为尽力而为，不能当作可靠后台任务。需要窗口关闭后继续扫描时，应使用桌面版：Tauri 外壳以 sidecar 运行同一套 Next.js 引擎，后台调度器保存本地计划与结果；关闭窗口默认只是隐藏，托盘菜单的退出才会停止调度。
频率应匹配变更速度。文档或落地页可每日扫描，稳定官网每周或每月即可。只对抓取权限变化、站点地图缺页、严重安全头回退、重复内容明显增加或已修复问题复发触发人工处理，才不会让报告变成告警噪声。
一个从报告到复扫的具体例子
假设团队维护一个由 Next.js 渲染的产品文档站。线上扫描发现三个现象：部分教程页在初始 HTML 中只有加载占位符；若干图片缺少替代文本；robots.txt 对某类爬虫使用了团队并未预期的规则。此时不要一次点完所有建议。先把问题拆成三个独立提交。第一项调整服务端渲染或预渲染策略，并在部署后抓取 HTML 响应，确认标题和正文不是仅靠客户端脚本出现。第二项把图片替代文本补进组件数据源，而不是在最终 HTML 中手工打补丁；这样后续内容更新仍会带上字段。第三项由负责边缘配置的成员修改 robots 规则，并将变更原因写入配置注释和发布记录。
三项部署完成后再对同一 URL 扫描。若页面正文仍只在渲染后 DOM 出现，就说明问题不应被报告分数掩盖：需要继续检查路由缓存、鉴权中间件或数据加载分支。若替代文本问题消失但新增了重复标题，应把它作为新的独立回归处理，而不是回滚已经正确的无障碍改动。这里的关键不是让工具替人决定优先级，而是让每个扫描结论都有可追溯的源文件、部署版本和复测证据。
当团队开始积累历史报告时，还可以把它当作变更风险的辅助信号。例如一次框架升级后，若许多页面同时失去 canonical、结构化数据或首屏正文，报告能帮助把现象关联到同一个发布批次；但根因仍须通过 Git diff、构建日志和真实浏览器测试确认。审计工具擅长缩小排查范围，不应该被误用为因果证明器。
适用边界
OptiQra 适合有可维护源码、愿意通过 PR 审查修复的网站团队。它不替代 Lighthouse、真实用户性能数据、渗透测试、内容编辑流程或搜索平台诊断。最小落地不必开启所有 AI 功能：先建立一个重要 URL 的基线，挑两三项确定性问题进入 PR，部署后复扫，最后再设置周期检查。这样，生成式搜索相关审计才能成为一条可回滚、可验证的工程改进链路。