構造化データを公開前に確かめる4工程｜出てこない事故を防ぐ

会議室の画面に、検索結果の見え方を比べた2枚の画像が並んでいます。左は競合の頁で、評価の星と価格が結果の中に出ている。右は自社の頁で、題名と説明文だけが並んでいる。構造化データは入れたはずなのに、なぜ出ないのか。この問いに答えるには、書いた内容が正しく読み取れているかを確かめる工程が要ります。この記事では、公開前の検査と公開後の監視の違い、4つの工程、そしてエラーの読み方を実務の手順として整理します。

構造化データが反映されない理由は3種類ある

入れたのに出てこない、という状態には大きく3つの原因があります。1つ目は、書き方そのものが壊れているか、必須の項目が抜けている場合。2つ目は、書き方は正しいが、検索の場がその型に対応していないか、対応していても表示の対象として選ばれていない場合。3つ目は、正しく書けており対応もしているが、反映されるまでの時間がまだ経っていない場合です。

この3つは対処が全く違います。1つ目は書き直せば解決しますが、2つ目は書き直しても解決しません。3つ目にいたっては、何もしないのが正解です。にもかかわらず、多くの現場では区別せずに「出ないから書き直す」を繰り返してしまいます。その結果、正しく書けていたものを壊してしまうことすらあります。

だからこそ、最初に切り分ける工程が要ります。書き方が壊れているかどうかは道具で判定できます。対応している型かどうかは公式の資料で調べられます。時間の問題かどうかは、公開からの経過日数で見当がつきます。この3点を順に確かめるだけで、無駄な書き直しの大半は避けられます。

さらに前提として、構造化データを入れれば必ず結果の見え方が変わる、という理解自体が正確ではありません。検索の場は、書かれた内容を理解の助けとして受け取りますが、それを結果の画面でどう見せるかは相手側の判断です。「出る資格を得る」ところまでが自分たちの仕事で、「実際に出す」かどうかは相手の裁量だと捉えておくと、期待の置き方を誤りません。

公開前の検査と公開後の監視は道具が違う

最も混乱しやすいのが道具の使い分けです。公開前あるいは公開直後に、特定の1頁を対象として「今この頁はどう読み取られるか」を見る道具と、公開後にサイト全体を対象として「どの型でどれだけエラーが出ているか」を追う道具は、別のものです。

前者は住所を入れるか、あるいは書いたコードをそのまま貼り付けて検査します。公開していない状態のコードでも検査できるので、公開前の確認に使えるのが大きな利点です。結果には、読み取れた型と項目、エラーと警告の一覧、そして結果の見え方の見本が出ます。

後者は、サイトを登録している管理画面の中にあり、検索の側が実際に収集して読み取った結果を型ごとに集計して見せてくれます。こちらは実際に収集されたあとのデータなので、反映までの時間差があります。その代わり、どの頁で何件エラーが出ているかを一覧で追えるので、サイト全体の状態を把握するには欠かせません。

	1頁ずつの検査	サイト全体の監視
使う場面	公開前、修正の直後	公開後の定期確認
対象	指定した1つの住所かコード	収集済みのサイト全体
時間差	その場で結果が出る	収集されるまで反映されない
分かること	読み取れた項目と見え方の見本	型ごとのエラー件数と推移

この2つに加えて、語彙そのものの妥当性を見る第3の道具もあります。構造化データの語彙は共通の辞書として公開されており、その辞書に照らして書き方が正しいかを判定する検証の道具です。検索の場が対応している型は辞書の一部でしかないため、辞書としては正しいが検索では使われない、という状態が起こりえます。そこを見分けるために、辞書の検証と検索向けの検査は別に走らせます。

工程1：どの型を使うかを先に決める

書き始める前に、どの型を使うのかを決めます。ここを曖昧にしたまま書くと、検索の場が対応していない型に労力を割くことになります。対応している型は公式の資料に一覧としてまとまっており、その一覧に載っている型だけが結果の見え方に関わります。

法人向けのサイトでよく使う型は限られています。記事の型、よくある質問の型、パンくずの型、催しの型、求人の型、会社情報の型あたりが中心です。自社のどの頁にどの型を当てるかを、頁の種類ごとに表にして決めておくと、書き手が変わってもばらつきません。

型を決めるときの基準は「その頁の主役は何か」です。セミナーの案内頁なら主役は催しであって記事ではありません。サービスの紹介頁で、料金や提供者の情報が主役なら、記事の型を当てるのは不自然です。頁の主役と型がずれていると、書き方が正しくても意図した見え方にはつながりません。

なお、同じ頁に複数の型を書くことは可能です。パンくずの型と記事の型を同時に書くのはごく普通の使い方です。ただし、主役が2つあるように書くとどちらも中途半端に扱われることがあるため、主役の型を1つ決め、それを補う型を足していく順番で設計します。

工程2：必須の項目を埋めてから書き始める

型ごとに、必ず書かなければならない項目と、書くことが推奨される項目が定められています。必須の項目が1つでも欠けていると、その構造化データは結果の見え方の対象になりません。書き始める前に必須の一覧を手元に出しておき、埋められる材料が揃っているかを確かめます。

ここで多いのが「材料が揃わないまま書き始める」失敗です。たとえば催しの型では開催の日時と場所が必須ですが、会場が未定の段階で頁を作ると、必須の項目を空にしたまま公開してしまいます。空の項目を書くくらいなら、確定してから書き足すほうが安全です。

推奨の項目は、埋めなくてもエラーにはなりません。ただし、埋めることで結果に出せる情報が増えます。たとえば画像や日付を足しておくと、結果の見え方が豊かになる可能性が上がります。必須をまず全て埋め、そのうえで推奨のうち材料のあるものを足す、という順番が無理のない進め方です。

工程3：公開前に1頁ずつ検査する

書き終えたら、公開する前に検査します。住所を入れる方法と、コードを直接貼り付ける方法があり、公開前ならコードを貼り付ける方法を使います。検査の結果は、読み取れた型ごとにまとまって表示され、エラーがあれば該当の項目名とともに指摘されます。

見るべきは3点です。第1に、想定した型が認識されているか。認識されていなければ、書き方の入れ物そのものが壊れています。第2に、エラーの件数がゼロか。第3に、項目の値が意図したとおりに読み取れているか。値が空だったり、想定と違う文字列が入っていたりすることがあります。

値の確認は特に大切です。書き方としては正しくても、テンプレートの変数が展開されずに文字列がそのまま出ている、改行や引用符の扱いで文字が欠けている、といった事故がここで見つかります。エラーがゼロだからと安心せず、読み取れた値を目で追ってください。

検査は公開のたびに行うのが理想ですが、毎回は現実的でない場合もあります。その場合は、テンプレートを変えたとき、新しい型を足したとき、頁の種類を新設したときの3つの場面では必ず行う、と決めておきます。同じテンプレートから作られる頁は同じ結果になるので、1本確かめれば残りは推測できます。

工程4：公開後にサイト全体を監視する

公開したあとは、管理画面の一覧で追います。型ごとに、有効な頁の数、警告のある頁の数、エラーのある頁の数が表示され、推移も見られます。毎日見る必要はありませんが、エラーの件数が急に増えたときに気づける仕組みは要ります。

急増の原因として多いのは、テンプレートの改修です。デザインの変更に伴って構造化データの出力が壊れ、その形式で作られた全ての頁が一斉にエラーになります。1頁ずつ検査していれば公開前に気づけますが、改修の規模が大きいと見落とすことがあります。改修の直後は、一覧を2週間ほど意識して見ておくと安全です。

• 一覧に出るのは収集された頁だけ。新しい頁は反映まで数日から数週間かかることがある
• エラーが直っても一覧の数字はすぐ戻らない。再収集を待つ必要がある
• エラーがゼロでも、必ず結果の見え方に反映されるとは限らない

修正したあとの確認も忘れがちです。管理画面には、修正を申告して再確認を依頼する機能がある場合があります。依頼を出しておくと、通常の巡回を待つより早く結果に反映されます。ただし、直っていない状態で依頼を出すと再び失敗として戻ってくるので、1頁ずつの検査でエラーがゼロになったことを確かめてから依頼します。

エラーと警告の違いを取り違えない

検査の結果には、エラーと警告の2種類が出ます。エラーは必須の項目が欠けている、値の形式が仕様と合っていない、といった致命的な指摘で、この状態では結果の見え方の対象になりません。警告は推奨の項目が空である、という指摘で、警告があっても対象にはなります。

実務では、エラーはゼロにし、警告は費用対効果で判断します。推奨の項目を埋めるために新しいデータの入力欄を作り、全ての頁の担当者に入力してもらう、という運用の負担が見合うかどうかです。画像のように既に持っているデータを渡すだけなら埋める価値がありますが、新たに収集が必要な項目なら、まず本当に効果があるのかを見極めます。

• 警告をエラーと同じ扱いにして、埋められない項目に仮の値を入れる
• エラーが出たまま公開し、後で直せばよいと放置する
• 検査で対象になったからといって、結果に必ず出ると社内に説明する
• 頁の見た目に存在しない情報を構造化データにだけ書く

最後の項目は特に重要です。構造化データに書いてよいのは、その頁を見た人にも確認できる情報に限られます。画面には載せずに構造化データだけで良い評価を書く、といった使い方は指針で明確に禁じられており、手動での対応の対象にもなり得ます。見えている情報を機械にも分かる形で渡す、という原則を外さないでください。

書き方の形式は3つあるが、実務では1つに絞る

構造化データの書き方には、頁の中に独立した塊として書く形式、既存のタグに属性として書き足す形式、そして別の語彙体系を使う形式の3つがあります。このうち検索の場が推奨しているのは1つ目で、実務では1つ目に統一するのが管理の面でも有利です。

1つ目の形式は、頁の見た目に影響しない独立した塊として書けるため、デザインの変更で壊れにくいという利点があります。2つ目の形式は見た目の要素に紐づくため、デザインを変えると構造化データも一緒に壊れます。改修の多い法人サイトでは、この違いが運用の負担の差になって現れます。

既存のサイトで2つ目の形式が混在している場合は、移行のタイミングで1つ目に寄せます。同じ内容を2つの形式で二重に書くと、片方を直し忘れたときに矛盾が生じます。矛盾があると、どちらが正しいのか判断できず、無視されるか、意図しないほうが採用されることになります。

検索の場が対応している型かどうかを調べる

辞書としての語彙は膨大で、その大半は検索結果の見え方には関係しません。対応している型の一覧は公式の資料にまとまっており、そこに載っている型だけが結果の見え方に関わります。この一覧は増減するので、新しく型を足すときは必ず最新の一覧を見に行きます。

実際、過去には対応していた型が対象から外れた例もあります。外れた型を書き続けても害はありませんが、その型の効果を期待して運用の手間をかけているなら、その手間は無駄になります。年に1度は一覧を見直し、書いている型が今も対象かを確かめる作業を、年次の点検に入れておくと安心です。

また、対応している型であっても、業種や国によって表示されない場合があります。対応の状況は段階的に広がることがあるため、日本語圏でまだ見かけない見え方は、対応の範囲外である可能性を疑います。海外の事例を見て導入を決めるときは、国内での表示例があるかを併せて確かめてください。

複数の頁で同じ内容を書くときの注意

会社情報の型のように、サイト全体で1つあれば足りる情報を全ての頁に書くべきかは判断が分かれます。公式の案内では、会社情報のような組織の情報は会社を説明する単一の頁に置けばよいとされており、サイト全体への配置は不要とされています。

一方、記事の型やパンくずの型は、頁ごとに内容が違うのでそれぞれの頁に書く必要があります。この違いは「サイトの属性を伝えるもの」と「その頁の内容を伝えるもの」の差です。どちらなのかを型ごとに整理しておくと、テンプレートの設計で迷いません。

同じ情報を複数の頁に重複して書いた場合、内容が食い違ったときに問題が起きます。会社名の表記が頁によって違う、住所の書式が揃っていない、といった不一致は、情報の信頼性を下げます。書く場所を1か所に絞れるものは絞る、というのが管理の基本です。

画像に関する情報は不一致の扱いが決まっている

画像の権利に関する情報は、頁の中の構造化データと、画像ファイルそのものに埋め込む記録の2つの経路で伝えられます。この2つで内容が食い違った場合、構造化データの側が使われることが公式に明示されています。どちらを正としてよいか迷わずに済む、数少ない明文の規定です。

ただし、それぞれに利点があります。構造化データは頁ごとに書く必要があるため、同じ画像を複数の頁で使うなら全ての頁に書かねばなりません。一方、画像に埋め込む記録は画像そのものに付いて回るので、画像が別の場所に移っても情報が残ります。両方を使い、内容を揃えておくのが確実な運用です。

なお、地域の法令によっては画像から権利に関する記録を削除する行為が違法となる場合があるとされ、少なくとも著作権と識別に関する記録は保持することが推奨されています。画像を軽くするために記録を一括で消す処理を入れている場合は、何を消しているのかを一度確かめておいてください。

よくある質問の型は今も同じように出るのか

よくある質問の型は、かつて多くのサイトで導入され、検索結果の中に質問と答えが折りたためる形で並ぶ見え方を得ていました。その後、この見え方の対象は大きく絞り込まれ、現在は限られた種類のサイトにしか表示されないという整理がなされています。以前の記事や事例をもとに導入を判断すると、期待した見え方にならない代表例です。

では書く意味がないのかというと、そうとも言い切れません。結果の見え方に出なくても、頁の内容の構造を伝える手がかりにはなります。ただし、見え方が得られる前提で工数を割く判断は成り立ちません。導入の判断は、現在の対応の一覧と、国内での表示の実例を確かめたうえで行ってください。

この事例が示しているのは、対応の状況が変わるということそのものです。一度書いた構造化データを何年も放置していると、対象から外れた型のために運用の手間を払い続ける状態になります。定期的な見直しを手順に入れておく理由は、ここにあります。

日付や数値は決まった書式で書く

値の書き方でつまずくのが、日付と時刻です。画面に表示する日本語の書き方と、構造化データに書く書式は別で、後者は国際的に決められた並び方を使います。年、月、日をハイフンでつなぐ形が基本で、時刻まで書く場合は時差の情報まで含めるのが確実です。

時差を書かないと、催しの開始時刻が別の地域の時刻として解釈される恐れがあります。国内向けの催しであっても、時差の情報まで書いておけば取り違えは起きません。テンプレートで日付を出力している場合は、画面向けの書式と構造化データ向けの書式を別々に用意しておきます。

数値も同様です。価格を書く欄には通貨の単位を数字と一緒に入れず、通貨は別の項目として書きます。従業員の数のように範囲で書ける項目もありますが、書式が決まっているので公式の資料の書き方をそのまま写すのが安全です。見た目を整えるための記号を値に混ぜると、読み取りに失敗します。

テンプレートに埋め込むときの設計

頁ごとに手で書くのは現実的ではないので、実務ではテンプレートに埋め込みます。このとき決めておくのは、値の出どころです。題名は頁の題名から、日付は公開日から、画像は代表の画像から、というように、どの項目がどのデータを参照するのかを一覧にしておきます。

出どころを決めておくと、値が空になる条件も見えてきます。代表の画像を設定していない記事では画像の項目が空になる、著者を登録していない記事では書き手の項目が空になる、といった具合です。空になる可能性のある項目は、値がないときにその項目ごと出力しない作りにしておきます。空の値を書くとエラーになるためです。

もうひとつ決めておくのが、文字の扱いです。題名に引用符や記号が含まれていると、構造化データの書き方が壊れることがあります。テンプレートの側で適切に変換する処理を入れておかないと、特定の記事だけエラーになる、という追いにくい不具合になります。記号を含む題名でテンプレートを一度試しておくと確実です。

担当が変わっても壊れない体制にする

構造化データは画面に見えないため、壊れていても誰も気づかないまま時間が過ぎます。これを防ぐには、担当が変わっても引き継げる形で残すことです。残すべきは、頁の種類と型の対応表、項目ごとの値の出どころ、そして確認の手順の3点です。

対応表があれば、新しい頁の種類を作るときにどの型を当てるかで迷いません。値の出どころが分かれば、データの入力欄を変えたときに構造化データへの影響を予測できます。確認の手順があれば、誰が担当しても同じ品質で公開前の確認ができます。この3点は、多くても1枚の資料にまとまります。

加えて、サイトの改修を外部に依頼するときは、この資料を仕様として渡します。渡さないまま改修すると、デザインは新しくなったのに構造化データが消えている、という結果になりがちです。見えないものは、明示的に伝えないと引き継がれません。

公開前の確認を手順に組み込む

道具を知っていても、確認する場面が決まっていなければ実行されません。公開前の確認の一覧に、構造化データの検査を1行足すのが最も確実です。「新しい型を足した頁は、公開前に1頁ずつの検査でエラーがゼロであることを確かめる」という一文があれば、担当が変わっても手順が残ります。

• 頁の種類ごとに、当てる型を決めた一覧があるか
• 必須の項目を全て埋めたうえで書いているか
• 公開前に1頁ずつの検査でエラーがゼロになっているか
• 画面に見えない情報を構造化データにだけ書いていないか
• テンプレートの改修後に、サイト全体の一覧を確かめているか

加えて、年に1度の点検を入れます。対応している型の一覧が変わっていないか、書いている値が古くなっていないか、エラーの件数が徐々に増えていないか。この3点を確かめるだけで、気づかないうちに壊れていた、という事態はかなり防げます。

まとめ

構造化データが反映されない理由は、書き方の不備、対応していない型、そして時間の3つに分かれます。この切り分けを最初に行えば、無駄な書き直しを避けられます。道具は公開前の1頁ずつの検査と、公開後のサイト全体の監視の2つを使い分け、エラーはゼロにし、警告は費用対効果で判断する。書き方の形式は独立した塊に統一し、画面に見えない情報は書かない。この原則を公開前の確認の一覧に組み込んでおけば、担当が変わっても品質が落ちない仕組みになります。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。