ページとサポートされる機能から始める
ビジネスに関連しそうな schema.org のすべての型を片っ端から追加するところから始めないでください。schema.org は広範な共有語彙であり、Google の Search Gallery は Google がサポートするリッチリザルト機能とそのために必要なプロパティを文書化しています。商品、イベント、記事ページはまずマークアップなしでも有用であるべきです。
各テンプレートについて、その主要な主題と表示される補助的事実を特定し、対応する機能の最新ガイドを読みます。Product、Recipe、Article、Breadcrumb、Event、Organization、Local business、Video などが例です。語彙の型だけでは Google の機能は生まれません。機能の『必須プロパティ』が適格性を決めます。
主要に表示される項目を主要なマークアップにしてください。
機能の振る舞いは Google のガイドを、語彙は schema.org を参照してください。
表示されるページを真実のソースにする
マークアップは主要なページコンテンツを表現しなければなりません。隠された、無関係な、誤解を招くような情報を記述してはいけません。出演者が出るとマークアップにあるなら、ページ上でその出演者の説明が必要です。集計評価をマークアップするなら、訪問者はその評価をページで確認できる必要があります。これによりテンプレートが誤った要約に流れていくのを防げます。
ページ本文とマークアップは同じ承認済みのデータから構築してください。商品フィード、イベント管理システム、CMS が両方に値を供給できますが、公開前に値をレビューする必要があります。価格、在庫状態、日付、レビュー合計をマークアップ専用フィールドにコピーして放置しないでください。表示情報が変わったらマークアップも更新または削除してください。
名前、日付、価格、在庫、評価をページと一致させてください。
欠けている値や古い値を推測して埋めないでください。
保守可能なデータ層として JSON-LD を使う
JSON-LD は HTML ドキュメントに置く JSON ベースのリンクデータ形式です。Google は JSON-LD、Microdata、RDFa をサポートしており、一般的に JSON-LD が大規模な運用では実装と保守が容易だとしています。可視マークアップから分離できるため、入れ子になった情報のモデリングがしやすくなります。
実際のアイテムごとに一つの明確なデータオブジェクトを用意し、適切な schema.org の型と正確なサポートされるプロパティを付与してください。各テンプレートについて、機能ガイド、ソースフィールド、必須フィールド時の挙動、責任者を文書化します。レンダリング後の出力を確認することも重要です：プラグインやコンポーネントが重複や競合するマークアップを追加することがあります。
チームが一貫して保守できる形式を選んでください。
ソースデータがないときに必須値をでっち上げないでください。
コードとアクセスできるページを検証する
検証は二つの問いに答えます。まず、マークアップはサポートされる機能に対して十分に完成していますか？Rich Results Test は貼り付けたコードか公開 URL を受け入れ、構造化データから生成可能なリッチリザルトを報告します。どのテンプレートに対しても代表的な事例をテストし、特に異常に完全なページだけを試験対象にしないでください。
次に、Google は公開ページとそのリソースにアクセスできますか？robots.txt、noindex、アクセス制御でマークアップ済みページをブロックしないでください。関連する画像 URL もチェックしてください。テストは品質の保証ではありません：可視コンテンツやポリシーの問題が表示を妨げることがあります。
まずコードを検証し、次に公開可能な URL をテストしてください。
ツールがマークアップを追加する場合は、レンダリング結果、ソース、テスト結果を比較してください。
潜在的な表示は将来の表示を保証するものではありません。
ユーザー向けテンプレート変更のようにリリースする
構造化データはテンプレート、フィード、公開ルールに依存することが多いです。リデザイン、在庫統合の変更、ローカリゼーション更新、コンポーネント削除は多数の項目を壊す可能性があります。代表的なマークアップチェックを、カノニカルタグ、タイトル、画像に使う事前レビューに組み込んでください。テンプレート、ページ例、ソースフィールド、リリース日時を記録します。
テンプレートが間違ったマークアップを出力した場合は、共有ソースかテンプレートを修正し、小さなサンプルで検証してから最小限の安全な変更をデプロイし、影響を受ける URL を再テストしてください。修正が予期せず動作するなら通常のロールバック手順を使います。目的は劣化したウェブ能力の証拠に基づく修復であり、障害アラートではありません。
単一の URL ではなく代表的なページセットをチェックしてください。
フォローアップの修正前に変更内容とマークアップ構成を記録してください。
維持、測定、表示の限界を受け入れる
デプロイ後は該当する Search Console のリッチリザルトレポートを使って問題を調査し、修正を確認してください。レポートは完全なインベントリではなくサンプルであり、件数はページではなく『アイテム』を指すことに注意してください。必要に応じて特定の URL を検査してください。
測定は慎重に行ってください。Google は Search Console 上で、十分にトラフィックのある安定したページの前後比較を数か月単位で行うことを提案しています。リリース日やその他のページ変更を記録してください。正しいマークアップはあくまで『適格性』を可能にするだけで、検索表示の最終決定は Google が行います。
CMS、テンプレート、フィード、ポリシー、コンテンツモデルの変更後に再チェックしてください。
他の大きなページ変更が異なる比較は避けてください。