予約に最短で辿り着くサイト構成とページ設計

はじめに

宿のサイトを作るとき、つい「素敵な写真をたくさん載せた紹介ページ」から考えたくなります。ただ、直予約を目的にするなら発想は逆で、すべてのページは予約への通り道として設計する必要があります。

この記事では、瀬戸内海エリアの一棟貸しヴィラの公式サイトで実践した、ページ構成と情報設計の考え方を紹介します。4言語対応や検索エンジン対策（SEO）まで含めて、非エンジニアの方にも分かるよう整理しました。

サイト全体を3つの領域に分ける

公開ページ・予約フロー・宿泊者専用ページ

サイト全体は、性質の違う3つの領域で構成しました。誰でも見られる公開ページ、予約手続きのページ、そして予約者だけが使える専用ページです。

この分け方には理由があります。予約フローのページは日付や人数の組み合わせでURLが無限に生まれるため、検索エンジンに載せると重複だらけになります。また宿泊者専用ページには入室方法などの機密情報があるため、検索エンジンから隔離し、キャッシュも残さない設定にしました。

すべての公開ページに「予約への出口」を置く

施設紹介を読んだ人が「泊まってみたい」と思った瞬間に、予約へ進めなければ意味がありません。そこで、モバイルでは画面下部に予約ボタンを固定表示し、PCでは画面端に控えめなタブを常駐させました。

どのページを読んでいても、予約への出口は常に1タップ先。この「出口の一貫性」が、紹介サイトと予約サイトの一番の違いだと考えています。

事実情報は1か所にまとめる

チェックイン時刻、定員、駐車場の台数、キャンセル規定 — こうした「事実」は複数のページに登場します。ページごとに直接書いてしまうと、変更のたびに直し漏れが起きます。

そこで事実情報をすべて1つの設定ファイルに集約し、各ページはそこを参照する作りにしました。チェックイン時刻を変えたければ1か所直すだけ。FAQも予約ページもメールも、全部が自動で揃います。地味ですが、運用が長くなるほど効く設計です。

4言語対応をどう設計するか

URLと言語の関係を決める

海外からのゲストを迎えるため、日本語・英語・繁体字・韓国語の4言語に対応しました。言語の切り替えはURLで表現し、日本語は /villa、英語は /en/villa のように、デフォルト言語だけプレフィックスなしにしています。

各ページには「このページの英語版はここ」という言語間の対応情報（hreflang）も自動で埋め込み、検索エンジンが言語版を正しく理解できるようにしました。

翻訳の抜け漏れを仕組みで防ぐ

4言語×全ページの文章を手作業で管理するのは現実的ではありません。文章はすべて言語ごとの辞書ファイルに分離し、ページ側は「この場所にはこのキーの文章」とだけ書く方式にしました。

ブログやお知らせなど日々更新するコンテンツは、日本語で書けばAIが残り3言語へ翻訳する仕組みを管理画面に組み込んでいます（詳しくはCMSシリーズの記事で解説します）。

検索エンジンとの付き合い方

構造化データで「宿である」ことを伝える

検索エンジンは文章を読むだけでなく、「このサイトは宿泊施設で、所在地はここで、FAQはこれ」という構造化されたデータ（JSON-LD）も読み取ります。宿泊施設のページには宿泊施設としての、FAQページにはFAQとしての構造化データを埋め込みました。

これにより、検索結果にFAQが展開表示されるなど、通常より目立つ形で表示されるチャンスが生まれます。

載せるページと隠すページを明確にする

サイトマップ（サイト内のページ一覧を検索エンジンに伝えるファイル）には公開ページとブログ・お知らせだけを載せ、予約フロー・管理画面・宿泊者専用ページは除外しました。

大事なのは、機密ページの保護をrobots.txt（検索エンジンへのお願いファイル）に頼らないことです。あくまで認証とnoindexで守り、robots.txtは補助として使います。

まとめ

直予約サイトのページ設計で大事にしたのは、次の3点です。

1. 3つの領域で考える — 公開・予約フロー・宿泊者専用を分け、扱いを変える
2. 事実情報は1か所に — チェックイン時刻や規定は設定ファイルに集約し、直し漏れを防ぐ
3. 言語も検索対応もURL設計から — 4言語をURLで分け、載せるページと隠すページを明確にする

予約フロー自体の画面設計は「予約画面を自前で作る」で、周辺案内ページの作り方は「Google Places APIで作る周辺スポット紹介」で詳しく解説しています。