結婚式場サイトの多言語対応。英語・中国語・韓国語ページのURL、hreflang、翻訳の更新、海外からの問い合わせの受け方

この記事の結論：式場サイトを多言語対応させるとは、「翻訳ボタンを付ける」ではなく「言語ごとに別のページ（URL）を作り、hreflang で日本語ページとの対応を示し、問い合わせの受け口まで各言語でそろえる」ことです。具体的には、①英語・中国語・韓国語の中から、問い合わせを受けたい相手に合わせて言語を絞る、②/en/ /zh-hans/ /ko/ のように言語ごとのディレクトリを作る、③各ページの hreflang に自分自身と他の言語版をすべて書き、相互に参照させる、④訳すのは会場・アクセス・プラン・問い合わせなど申込みに直結するページから始め、日本語版を更新したら訳も追いかける手順を決める、⑤海外の人が入力できる問い合わせフォームを用意する、の順に進めます。

読んでほしいのは、婚礼施設のサイトを任されている担当者と、式場サイトを作る制作会社・開発者です。大阪や神戸のように海外から人が訪れる地域では、海外在住の新郎新婦や、海外から参列する家族からの問い合わせを想定する式場もあると思います。根拠には Google と W3C が公開している資料を使い、特定の式場の事例は扱いません。

多言語対応で最初に決めるのは、言語の数ではなく問い合わせの相手

最初に決めるべきは「誰からの問い合わせを受けたいか」で、言語はそこから逆算します。英語・中国語・韓国語を一度に全部作るより、受けたい相手の言語から順に作るほうが、訳の質も更新も保ちやすくなります。

中国語は、簡体字と繁体字で読み手が分かれます。どちらの読み手を想定するかを決めずに作ると、どちらにも読みにくいページになります。

言語ごとにURLを分け、ディレクトリで並べる

言語ごとに別の URL を用意し、example.com/en/ のようなサブディレクトリで並べるのが、式場サイトでは扱いやすい形です。Google は、Cookie やブラウザの設定で同じ URL の中身を切り替える方法をすすめておらず、言語ごとに異なる URL を使うよう説明しています（参照：多地域・多言語サイトの管理（Google））。

同じ資料では、訪問者の言語や位置情報を見て、別の言語版へ自動で移動させることも避けるよう書かれています。移動させる代わりに、各ページのヘッダーに言語を切り替えるリンクを置きます。海外の端末で日本語版を見たい人や、日本にいる外国籍の人もいるためです。

hreflangは、自分自身を含めて全言語を相互に書く

hreflang は「このページには、この言語版もある」と Google に伝える印で、各ページに自分自身と他の言語版のすべてを書き、相互に参照させます。片方からしか参照していない場合、その指定は無視されます（参照：ローカライズ版を Google に伝える方法（Google））。

チャペルを紹介するページを4言語で持つ場合、4つのページすべての head に同じ組み合わせを書きます。

<link rel="alternate" hreflang="ja" href="https://example.com/chapel/">
<link rel="alternate" hreflang="en" href="https://example.com/en/chapel/">
<link rel="alternate" hreflang="zh-Hans" href="https://example.com/zh-hans/chapel/">
<link rel="alternate" hreflang="ko" href="https://example.com/ko/chapel/">
<link rel="alternate" hreflang="x-default" href="https://example.com/en/chapel/">

書くときに間違えやすい点を挙げます。

• 言語コードは言語から書く。 ja en ko のように ISO 639-1 の言語コードを先に書き、地域を付けるなら en-US のように後ろに続けます。国のコードだけを書いても、Google は言語として扱いません
• 中国語は文字で分ける。 簡体字は zh-Hans、繁体字は zh-Hant と書けます
• x-default は「どれにも当てはまらない人」の行き先。 閲覧者の設定がどの言語とも合わないときに表示したいページを指定します。言語を選ぶページや、英語版を指定することが多い値です
• 方法は1つにそろえる。 HTML の link 要素、HTTP ヘッダー、サイトマップのどれでも同じように扱われるので、混ぜずに1つで書きます

もう一つ、Google はページの言語を hreflang や lang 属性ではなく、表示されている内容から判断します。英語版のページの本文が日本語のままなら、hreflang を書いても英語のページとしては扱われません。lang 属性は、読み上げや表示のために正しく付けたうえで、本文そのものを訳すことが前提です。

翻訳は、申込みに近いページから順に、人が読み直して出す

訳す範囲は、会場・アクセス・プランの考え方・見学の方法・問い合わせといった、申込みに直結するページから始めます。全ページを一度に訳そうとすると、更新が追いつかずに古い情報の外国語ページが残ります。

機械翻訳は下訳として便利ですが、出したまま公開するのは避けます。Google がスパムとして扱う行為の一覧にも、よそのコンテンツを集め、翻訳などで形を変えて、読み手にほぼ価値のないページを量産する行為が含まれています（参照：Google 検索のスパムポリシー）。また、ナビゲーションだけを訳して本文は日本語のまま、という作りも、検索結果に同じ内容が言語違いで並ぶ原因になるとして、多言語サイトの資料で注意されています。

婚礼のページには、そのまま訳すと伝わらない言葉が多くあります。訳す前に、式場の中で用語の対訳表を1枚作っておくと、ページごとに訳がぶれません。

日本語版を更新したら、訳も追いかける手順を決める

多言語のページは、作るより保つほうが難しいため、日本語版の更新が外国語版に伝わる仕組みを先に作ります。季節のフェアやプランの入れ替えが多い式場では、ここを決めずに公開すると、数か月後に外国語版だけ内容が古くなります。

1. ページごとに「訳の元になった日本語版の更新日」を持たせる。 CMS の項目として、外国語版のページに保存しておく
2. 日本語版を更新したら、対応する外国語版に「要更新」の印が付くようにする。 担当者が一覧で確かめられる形にする
3. 料金・日付・空き状況のように変わりやすい情報は、外国語版に直接書かない。 日本語版と同じデータから出すか、「最新の情報は問い合わせで案内する」と書く
4. 訳を直したら、hreflang の組み合わせが崩れていないかを確かめる。 ページを追加・削除したときは、すべての言語版の指定を同時に直す
5. 公開したら、英語版・中国語版などのそれぞれが Search Console 上で表示回数が出ているかを見る。 出ていない言語版があれば、本文が訳されているか、hreflang が相互になっているかを確認する

海外からの問い合わせは、フォームの入力欄から見直す

外国語のページを作っても、問い合わせフォームが日本の電話番号と「姓・名」の前提のままだと、最後の一歩で入力できなくなります。W3C の資料は、氏名の順番や構成が文化によって違うことを前提に、「名」「姓」を決めつけない欄の作り方を示しています（参照：W3C「Personal names around the world」）。

受け取る側の準備も欠かせません。どの言語のページから届いた問い合わせかが分かるように、ページの言語をフォームの隠し項目として一緒に送り、受信のメールや管理画面で見えるようにします。自動返信のメールも言語ごとに用意し、返信までの目安と、日本時間で対応することを書いておきます。

フォームまで作ったら、各言語のページからスマホで実際に送信し、自動返信と式場側の受信の両方が届くことを確かめてから公開します。

多言語ページが検索とAIに正しく読まれるために

多言語のページは、検索結果だけでなく、AI の回答で式場が紹介されるときの材料にもなります。外国語で質問した人に正しく案内されるかを左右するのは、その言語のページに書かれた会場の基本情報の量と正確さ。

株式会社bundlyzeでは言語ごとのページづくりの土台にもなる LLMO の取り組みを自社のサイトで続け、AIの答えで会社がどう紹介されるかを確かめる手順も記事にしています。言語ごとのページに、会場名・所在地・アクセス・受け付けている問い合わせの方法を本文で書き、構造化データや hreflang と内容をそろえておくことが、どの言語でも共通の土台になります。多言語ページも含めた整え方は、検索とAI向けの対策（SEO・LLMO）にまとめています。

※本文で引いた W3C と Google の各ページは、確認日を2026年10月3日としています。hreflang の仕様説明などは改訂されることがあるので、実装に入る直前にもう一度原文に目を通してください。