CIにおけるJSON-LDデータの監査から学んだこと
JSON-LDの構造化データは、見た目に影響を与えることなくサイトから消えてしまうことがあります。ビルドは成功し、デプロイも完了します。ブラウザでページを見ても、何も問題はありません。
しかし、Googlebotはリッチリザルトを決定するためにscriptタグを読み取ります。データが欠落していたり壊れていたりしても、Search Consoleが数週間後に警告を発するまで気づくことはできません。
そこで、私はCIパイプラインにデプロイ後の監査ステップを追加しました。これにより、60秒以内にこれらのエラーを発見できます。
仕組み:
私はAstroで構築し、Cloudflare Pages経由でデプロイしている3つの静的サイトを運営しています。これらのサイトでは、SoftwareApplication、VideoGame、ItemListなどのスキーマを使用しています。静的サイトであるため、テンプレートの変更によって、ビルドエラーを発生させることなく数千ページからスキーマが消失してしまう可能性があるのです。
監査スクリプトは以下の処理を行います：
• 公開されているホームページとサンプル詳細ページを取得する。 • 公開されているサイトマップを読み込み、実際のURLを見つける。 • 正規表現を使用して、すべてのJSON-LDブロックを抽出する。 • @graphの展開（unwrapping）を確認し、ネストされたアイテムを見つける。 • 見つかった@typeの値を、想定しているリストと比較する。
私はこれをビルド成果物に対してではなく、実際にデプロイされたページに対して実行しています。これにより、CDNのキャッシュやエッジ配信に関する問題をキャッチできます。
初回の実行で、スクリプトは3つの問題を発見しました：
- ossfind.com: 特定のページでItemListが欠落。これにより、漠然とした懸念が具体的なタスクへと変わりました。
- findindiegame.com: WebSiteの@idにおける不適切なhttp://プロトコル。これはコピー＆ペーストによるミスで、人間が見れば問題ありませんが、Googleにとっては不整合でした。
- aiappdex.com: SoftwareApplicationスキーマにおいて、人間が読める名前の代わりに生のデータベースIDを使用している。
これらは実在するバグでした。ビルドログにもブラウザでの確認にも現れませんでした。
私はCIステップを非致命的（non-fatal）に設定しています。監査で問題が見つかってもデプロイは完了しますが、エラーはログに表示されます。これにより、チェックがパイプラインをブロックするように設定する前に、実際の挙動を観察することができます。
これはフルセットのバリデーションスイートではなく、スモークテストです。サイトごとに2つのサンプルをチェックします。すべてのエッジケースをキャッチできるわけではありませんが、大きなミスが本番環境に1ヶ月間放置される前に食い止めることができます。