「秋葉原 × 貸し会議室」という検索の、正体
予約ポータルと公式サイトは役割が違います。ポータルは探す場所です。公式サイトは、探し終えた人が確かめる場所です。どちらが上という話ではありません。ポータルは大切な集客チャネルで、使っていること自体が問題になるわけでもありません。そのうえで、公式サイトから直接選ばれ、問い合わせや予約まで進む経路を自社でも持てるか。運営する会社にとっては、ここが大きな違いになります。
地域名と用途を組み合わせたこの種の検索では、予約ポータルや比較メディア、一括問い合わせサービスが上位を占めます。掲載施設が増えればページが増え、検索語の組み合わせを面で覆えるからです。探す場所として設計されている以上、これは自然な結果です。
ただ、公式サイトが一覧の後ろに回る理由は量だけではありません。多いのはむしろ、主催者が知りたい順番と公式サイト側の並び順がかみ合っていないケースです。
主催者の確認順はだいたい決まっています。まず、その規模の集まりを開けるのか。次に、人数が前後しても耐えられるか。それから費用がどこまでで収まるか。最後に、当日の運用を自分たちで回し切れるか。研修も説明会も展示会も、決めるのは主催者です。うまくいかなければ責任もその人に返ります。
一方の公式サイトは、施設ごとの紹介ページとして作られていることが多くあります。一施設ずつ丁寧に説明されていても、横に並べて比較できる面がない。すると主催者は比較するためにポータルへ戻ります。検索で公式サイトに辿り着いていても、判断はよその面で行われる。これが、見つかっても相談まで届かない理由です。
では、公式サイトには何ができるのか
ポータルの一覧に並べられるのは、どの施設にも共通してある項目だけです。収容人数、面積、料金、場所。同じ項目が揃っているから、横に並べて比較できます。逆に言えば、項目の形にできない情報は、そこには載りません。
載らないのは、たとえばこんな情報です。この使い方はできる。この使い方はできない。この時間帯なら搬入に余裕がある。この設備は事前申請がいる。当日は誰がどこまで対応する。運営している側にしかない情報で、しかも主催者が最後に確かめたい部分です。
公式サイトに置くのは二種類あります。ひとつは、ポータルにも並ぶ基本条件です。施設特徴、収容人数、広さ、料金。同じ項目でも自社の面に置き直せば、そこで比較を終えてもらえます。もうひとつが、ポータルには載らない一次情報です。利用シーン、当日の運用、運営側の強み。ここは運営している会社にしか書けません。この二つが揃えば、選ばれる理由が伝わります。入口から相談までを、自社の考え方で一本の導線として設計できるのが公式サイトです。
そこで弊社では、予約ポータルへの掲載だけに依存するのではなく、公式サイト自体が検索で見つかり、比較検討の材料になる状態を目指しました。
この案件の方針も、そこに置きました。検索で見つかるための内部施策と、問い合わせまでの体験設計を、別々の工程にしない。順位のための施策だけを積んでも、着地したページが比較できない面のままなら主催者はポータルへ戻ります。逆に体験だけ整えても、探している人に届かなければ始まりません。両方をひとつの設計として扱う。それを最初に決めました。
この案件で、何を・どの順で考えたか
弊社では、東京都千代田区の秋葉原エリアで貸し会議室・レンタルスペースを運営されている企業様の公式サイトを、SEO改善とサイトリニューアルによって改善しました。なお本記事では、お客様への配慮から、実名での掲載は控えています。読んでいただきたいのは会社名ではなく、同じ課題を持つ運営会社が自社に置き換えられる設計の中身だからです。
実現したのは、検索から入った人が施設を比べ、そのまま問い合わせまで進める構造です。施設が増えても同じ型で情報を足せるので、運用の品質も落ちません。
最初に決めたのは、順位のための施策と体験設計を別の仕事にしないことでした。この公式サイトが担うのは、検索から入った人の判断を自社の面で完了させることです。そこから逆算して、変えるものを決めました。
情報設計：比較するための材料を、先に置く
情報設計は二段に分けました。一覧の面に置いたのは、施設特徴・収容人数・広さ・料金です。その場で見比べられるようにしました。詳細の面へ回したのは、備品、オプション、利用シーン、事例。決める直前に必要になる情報をこちらへ集めています。全体をつかんでから、気になったものだけを開く。その順で動ける形です。
UX検証：5名のユーザビリティテストで明らかになったこと
この形にしたのは、ユーザビリティテストを実施したからです。会社経営者1名、役員2名、課長・主任クラス2名。会場を決める立場に近い5名に、実際の画面で操作を確認していただきました。
ユーザビリティテストでは、情報を見る順番に特徴がありました。詳しい説明から順に読み進める、という動き方ではありません。まず施設全体を並べて比べる。比べてから、気になったものだけを開く。説明を読むのは、そのあとです。
それなら第一階層に置くべきものは説明ではありません。比較するための材料です。施設特徴・収容人数・広さ・料金を先に把握できる構造へ。この発見が、その設計変更につながりました。
SEO改善：検索から見つけてもらうための内部設計
検索側で変えたのは5つです。
sitemapは、施設のページが漏れなく検索エンジンの対象に入るよう整えました。canonicalは設定し直しています。条件の近いページどうしが評価を分け合わないようにするためです。内部リンクでは、一覧と詳細、それに関連する施設のあいだを行き来できるようつなぎました。ページ構造は、見出しと情報の並びを主催者の確認順に合わせています。index設計で分けたのは、検索結果に出す意味のあるページと、そうでないページです。
「SEOをやりました」ではなく、この五つを変えました。そう書くほうが正確です。
CMS・運用設計：施設が増えても、品質が落ちない仕組み
最後に、運用が続く形にしました。施設は増えます。増えたときに情報の粒度が揃わなくなると、比較できる面はすぐ壊れます。
そこでカスタム投稿とカスタムフィールドで施設情報の入れ物を決め、テンプレートで出力の形を固定しました。そのうえで更新ルールと運用マニュアルを用意しています。どの項目を欠かさず埋めるかを決めておけば、設計した人がその場にいなくても、同じ品質で追加できます。
持ち帰っていただきたいこと
もし施設をいくつも運営していて、公式サイトが問い合わせにつながっている実感がないなら、一度、自社の一覧ページだけを開いてみてください。そこに並んでいるのは、比較するための材料でしょうか。それとも施設ごとの紹介文でしょうか。
検索で見つかることと、見つかったあとに比較を終えてもらうこと。この二つは地続きですが、必要な設計は別物です。前者はページと構造の問題で、後者は情報の順番の問題です。片方だけ整えても、もう片方で止まります。
もうひとつ。読まれ方は、想像するより実際に見ていただいたほうが早く分かります。この案件で第一階層を作り替えたのも、5名によるユーザビリティテストで得られた発見があったからです。大人数は必要ありません。会場を決める立場に近い方に、実際の画面で操作していただく。それだけで、情報の順番が合っているかどうかは見えてきます。
予約ポータルを使うこと自体が問題なのではありません。ただ、そこを経由しなければ新しい顧客と出会えない状態になっていないかは、確認する価値があります。公式サイト自身も、検索から問い合わせまでを担える集客経路にできます。
自社サイトが検索から問い合わせまで、どこで止まっているのか。確認したい場合は、お気軽にお問い合わせください。
