式場サイトのFAQに構造化データを入れる前に、本文の答えを直す
「よくある質問のページに構造化データを入れると、検索結果にQ&Aが並んで目立つらしい」。制作会社やSEOの記事でそう聞いて、式場のサイトにも入れるべきかと迷っている方は多いと思います。
結論から言うと、僕は順番を逆にしたほうがいいと考えています。構造化データを入れる前に、ページ本文の答えを直す。入れるのは、そのあとです。理由は、検索結果の見た目に期待していた効果のほうが、すでに大きく変わっているからです。
この記事は、出典のある事実を1つだけ置いて、あとは仕組みと判断の条件から組み立てています。「業界全体でこうなっている」とは言いません。「仕組みとして、こうなりやすい」という範囲で書きます。
構造化データとは何か、先に整理する
構造化データは、ページの中身を検索エンジンに機械的に伝えるための書き込みです。ページを見ている二人には、何も表示されません。裏側に「ここからここまでが質問で、ここが答えです」というラベルを貼るイメージです。
よくある質問のページ向けには、FAQPageという種類があります。質問と答えのペアを、決まった書式で書き添えます。
大事なのは、ラベルを貼るだけでは答えは良くならない、という点です。ラベルは、ページに書いてある内容を説明するものです。本文に書いていないことは、ラベルにも書けません。書いたとしても、ページと食い違っていれば、検索エンジン側が信用しなくなります。
Googleは2023年8月に、FAQの特別な表示を絞った
見た目の話に移ります。Googleは2023年8月に、FAQのリッチリザルト（検索結果に質問と答えが折りたたみで並ぶ表示）を、よく知られた権威ある政府系・健康系のサイトに限る、と発表しました。それ以外のサイトでは、構造化データを入れても、この表示が常に出るわけではなくなりました。
出典は、Google検索セントラルの公式ブログ「Changes to HowTo and FAQ rich results」（2023年8月）です。式場のサイトは、政府系にも健康系にも当たりません。つまり、FAQの構造化データを入れて検索結果で目立たせる、という期待は、公式の発表の時点で当てにしにくくなっています。その後の扱いは変わりうるので、入れる前に、Googleの最新のドキュメントを自分で確かめてください。
では、入れる意味はゼロなのか。僕はゼロではないと考えています。ただ、期待する中身を変える必要があります。
入れる意味が残るとすれば、機械に正しく読ませること
見た目が変わらなくても、構造化データには役目が残ります。ページの内容を、機械が間違えずに読み取れるようにすることです。
ここ数年、式場名を検索する二人だけでなく、生成AIに質問する二人も増えています。AIが式場について答えるとき、ページのどこが質問でどこが答えなのかが明確なほうが、拾われやすい可能性があります。ただ、これは「可能性」の話です。構造化データを入れたら必ず引用される、という保証は、僕の知る限りどこにもありません。
なので、構造化データを「検索結果で目立たせる施策」としてではなく、「本文を正しく読ませる補助」として位置づける。それなら、入れても損はなく、費用が小さければやる価値があります。逆に、費用をかけて「目立たせる」ために入れるなら、見合わない可能性が高いです。
先に直すのは、本文の答えの書き方
順番の話に戻します。構造化データより先に、ページの本文を次の3点で点検します。
1. 質問が、二人の言葉で書かれているか
式場側の言葉で質問が書かれていると、検索される言葉と合いません。たとえば「挙式料金に含まれる内容について」より、「挙式の料金には何が含まれていますか」のほうが、二人が打ち込む言葉に近いです。
質問の言葉は、自社の問い合わせメールや、見学の最初に聞かれたことから拾えます。一般論でなく、実際に聞かれた言い方に寄せてください。
2. 答えが、最初の1文で言い切られているか
FAQの答えで多いのは、前置きから始まる文章です。「当式場では、お客様のご要望に合わせて…」と続いたあとに、やっと結論が来る。読む二人は途中で離れますし、機械も、どこが答えなのか判断しにくくなります。
最初の1文で結論を言う。「含まれます」「含まれません」「人数によって変わります」のどれかを先に置いて、そのあとに条件を書きます。
3. 条件つきの答えは、条件を書いているか
「状況によります」だけで終わる答えは、読む二人にとって、答えがないのと同じです。何によって変わるのかを書いてください。人数なのか、日取りなのか、持ち込みの有無なのか。条件が分かれば、二人は自分の場合を当てはめられます。
この3点は、構造化データを入れてもいなくても、読む二人にとって効きます。構造化データのほうは、ここが整ってはじめて意味を持ちます。
書き直しの例
たとえば「キャンセル料はいつから発生しますか」という質問に、「所定の規定に基づき、ご契約内容に応じて発生いたします」と答えているとします。これを直すなら、次のようになります。
「契約の日から発生します。金額は、挙式日までの残り日数で変わります。いつから何割になるかは、契約書の表に書いてあり、見学のときに先にお見せできます」
ここで書いているのは、仮の文面です。実際の割合や日数は、自社の契約書に合わせて入れてください。ポイントは、いつから発生するのかを最初の1文で言い切ったことと、何で金額が変わるのかを書いたことと、確かめる場所（契約書の表）を示したことです。この3つが入ると、読む二人は、自分の挙式日に当てはめて考え始められます。
直す順番は、問い合わせが多い質問から5つ程度で十分です。全部を一度に直そうとすると、途中で止まります。5つ直して、同じ質問が減るかを見てから、次を決めてください。
もう一つ、直すときに気をつけたいのは、答えの中に社内の言葉を残さないことです。「規定」「所定」「別途」のような言葉は、書く側には便利でも、読む二人には中身が見えません。金額や日数を書けないなら、書けない理由と、どこで分かるのかを書いてください。それだけでも、答えは前に進みます。
入れるかどうかは、費用と手間で決める
ここからは、出典の無い、前提を置いた計算です。数字は想定で、実際の値ではありません。
仮に、制作会社に構造化データの設定を頼んで、1回10万円かかるとします。仮に、成約1組あたりの粗利を80万円とします。10万円を回収するには、成約が0.125組、つまり8年に1組ぶん増えれば足ります。数字だけ見れば、回収のハードルは低いです。
ただ、ここで気をつけたいのは、「構造化データを入れたから成約が増えた」と言える測り方が、ほぼ作れないことです。検索結果の見た目が変わらず、AIの引用も追えないなら、効果を数えられません。数えられない施策に費用をかけるときは、「回収できたか」でなく、「やらなくても困らなかったか」で判断するのが現実的です。
僕なら、次の条件で分けます。
- 自社で設定できる、または追加費用がほぼかからない：本文を直したあとに入れる。効果は測れなくても、損は小さい
- 制作会社に追加費用を払う必要がある：本文の改善を先に頼む。構造化データは、ほかの修正に含めてもらえるときだけ
- 「検索結果で目立つ」と説明されて提案された：2023年8月の発表を示して、いまの表示の根拠を聞く。答えが曖昧なら見送る
3つ目は、制作会社を疑う話ではありません。検索の仕様は変わるので、数年前の説明がそのまま残っていることがあります。確認するだけで十分です。
入れたあとに、必ず確かめること
入れる場合は、ページの内容と構造化データが一致しているかを確かめます。構造化データに書いた質問と答えが、ページに見えている文章と違っていると、検索エンジンから信用されにくくなります。
確かめ方は2つです。1つは、Googleが公開している「リッチリザルトテスト」で、エラーが出ていないかを見ること。もう1つは、本文を直すたびに、構造化データの中身も同じ日に直す運用にすることです。後者を忘れる式場が、いちばん多いはずです。本文だけ更新して、構造化データが古いまま残る。料金や営業時間の変更は、特にこれが起きます。
更新の担当者が複数いる式場では、本文を直した人が構造化データも直す、と決めてください。分けると、必ずずれます。
見てほしいのは、本文を直したあとの問い合わせ
最後に、測る場所をひとつ。構造化データの効果は測れなくても、本文の改善の効果は測れます。
FAQのページを直したあとの数週間で、問い合わせメールや電話で同じ質問が減ったか。見学の最初に聞かれる質問が減ったか。減っていれば、答えが届いています。減っていないなら、質問の言葉か、答えの置き場所が合っていません。
構造化データは、その答えを、機械に間違えず渡すための封筒です。中身の手紙が読みにくければ、封筒だけ整えても意味がありません。
まとめ
- Googleは2023年8月に、FAQのリッチリザルトを政府系・健康系の権威あるサイトに絞った。式場のサイトでは、検索結果で目立つ効果は当てにしにくい
- 構造化データは、ページの内容を機械に正しく読ませる補助。本文に書いていないことは、ラベルにも書けない
- 先に直すのは本文。質問は二人の言葉で書き、答えは最初の1文で言い切り、条件つきの答えは条件を書く
- 効果は測りにくいので、費用がかからないときだけ入れる。「目立つ」と説明されて費用がかかる提案は、根拠を確かめる
- 入れたあとは、本文を直すたびに構造化データも同じ日に直す。担当者は分けない
- 効果は構造化データでなく、本文を直したあとの、同じ質問が減ったかで見る
