我在 CI 中审计 JSON-LD 数据学到的经验
JSON-LD 结构化数据可能会从你的网站上消失，而不会破坏任何可见的内容。你的构建会成功，部署会完成，页面在浏览器中看起来也一切正常。
但 Googlebot 会读取 script 标签来决定你的富媒体搜索结果 (rich results)。如果数据缺失或损坏，你可能要等到几周后 Search Console 发出警告才会察觉。
我在 CI 流水线中增加了一个部署后审计步骤。它能在 60 秒内发现这些错误。
工作原理：
我运行了三个使用 Astro 构建并通过 Cloudflare Pages 部署的静态网站。这些网站使用了 SoftwareApplication、VideoGame 和 ItemList 等 schema。由于它们是静态的，模板更改可能会导致成千上万个页面的 schema 丢失，而不会触发构建错误。
审计脚本执行以下操作：
• 获取在线首页和示例详情页。 • 读取在线 sitemap 以查找真实的 URL。 • 使用正则表达式提取所有 JSON-LD 代码块。 • 检查 @graph 解包以查找嵌套项。 • 将找到的 @type 值与我的预期列表进行对比。
我针对已部署的在线页面运行此脚本，而不是构建产物 (build artifacts)。这可以捕获 CDN 缓存或边缘交付 (edge delivery) 相关的问题。
脚本在第一次运行时发现了三个问题：
- ossfind.com：特定页面缺少 ItemList。这把一个模糊的想法变成了一个具体的任务。
- findindiegame.com：WebSite @id 中使用了错误的 http:// 协议。这是一个复制粘贴错误，人类看起来没问题，但对 Google 来说是不一致的。
- aiappdex.com：在 SoftwareApplication schema 中使用了原始数据库 ID，而不是人类可读的名称。
这些都是真实的 Bug。它们既不会出现在构建日志中，也不会在浏览器检查中显现出来。
我将 CI 步骤设置为非致命的 (non-fatal)。如果审计发现问题，部署仍会完成，但错误会出现在日志中。这让我可以在决定让该检查阻塞流水线之前，先观察实际运行情况。
这是一项冒烟测试 (smoke test)，而不是完整的验证套件。它每个网站只检查两个样本。它无法捕获所有边缘情况，但能在重大错误在生产环境中存在一个月之前将其揪出来。