ホームページの多言語対応はどこまで必要か｜翻訳ツールで足りる場合と、URLを分けるべき場合

「ホームページを多言語対応したい」という相談は、実際には二つの異なる要望が同じ言葉で語られています。一つは、すでにサイトへ来ている外国語話者に内容を読ませたいという要望。もう一つは、海外や多言語の検索から、新しく引き合いを取りたいという要望です。

この二つは、必要な作りがまったく違います。前者は翻訳ツールやブラウザの翻訳機能で足りますが、後者は言語ごとに別のURLを用意しないと、そもそも検索結果に出てきません。翻訳ウィジェットを設置したのに海外からの問い合わせが増えない、という相談が絶えないのは、この違いが説明されないまま導入されているからです。

制作会社の記事の多くは、費用相場と翻訳ツールの比較から始まります。しかし先に決めるべきは金額でも道具でもなく、どちらの目的なのかです。目的が決まれば、訳す範囲も、URLの構造も、運用に必要な体制も自動的に決まります。逆にここを飛ばすと、費用をかけた側が成果の出ない構成になることがあります。

この記事では、Googleが公開している一次情報を確認しながら、多言語対応の判断を順に整理します。Web制作全体の進め方はサイト制作の進め方｜発注から公開までの工程と発注者側の作業で扱っています。

多言語対応には、目的が2つある

最初に、自社がどちらを求めているのかを決めます。この判断だけで、必要な作業量が数倍変わります。

上の行は、相手が自社を知っている状態です。展示会で名刺を渡した相手、取引先から紹介された相手、店頭でQRコードを読んだ相手が、日本語のページを前にして読めずに困っている。この場合に必要なのは「読める状態にすること」だけで、検索に出る必要はありません。

下の行は、相手が自社をまだ知らない状態です。相手は現地の言語で検索し、その結果から選びます。検索結果に出るには、検索エンジンが読み取って登録できるページが存在しなければなりません。ここが技術的な要件を生みます。

実務では、上の目的で足りるケースが相当あります。特に、海外取引はあるが商談の入口が展示会と紹介で完結している企業、インバウンドの来店客はいるが予約は現地の旅行サイト経由という店舗は、検索対策まで進める必要がありません。製造業のように引き合いの入口が限られる業種では、どこで相手と出会っているかを先に洗い出してください。業種ごとの引き合いの作り方は製造業のWebマーケティングは何を増やすべきか｜問い合わせ数より先に決める、取りたい引き合いの条件と卸売業のWeb集客は誰に向けて設計するか｜買い手は小売店だけではなく、取引条件の開示が問い合わせの質を決めるで扱っています。

翻訳ウィジェットを入れても、海外の検索には出てこない

サイトに設置する翻訳ウィジェットや、ブラウザに内蔵された翻訳機能は、手軽で費用も抑えられます。ただしこれらが行っているのは、表示している人の画面上で文字を置き換えることであって、新しいページを作ることではありません。

検索エンジンが検索結果に載せられるのは、URLを持ち、取得して内容を読み取れるページだけです。ブラウザの翻訳機能は閲覧者の手元で動くため、検索エンジンが取得する対象になりません。翻訳された英語の文章は、どのURLにも存在していないからです。

したがって、次の状態が起こります。

• 日本語で検索した人には出る。元のページは通常どおり登録されている
• 英語で検索した人には出ない。英語のページというものが存在しない
• サイトに来た人は読める。表示の段階で置き換わるため目的は果たす

つまり翻訳ウィジェットは、目的が「来た人に読ませる」であれば正解の選択肢です。安く、早く、更新の手間も増えません。問題なのは、これを「多言語SEO対策」として導入し、海外からの流入を期待してしまう場合です。期待している成果と、導入したものの機能が噛み合っていません。

検索に出ない状態の切り分け方そのものはページがインデックスされない原因と確認の順序｜検索に出ない状態を切り分けるで整理しています。この場合は「登録されない」のではなく「登録される対象が無い」ため、Search Consoleを見ても原因は見つかりません。

URLの分け方は3つ。パラメータは使わない

検索から取りに行くと決めた場合、言語ごとにURLを分けます。Googleは「多地域、多言語のサイトを管理する」というドキュメントで、使えるURL構造を挙げています。選択肢は実質3つで、もう1つは推奨されていません。

国別ドメインは、その国を対象としていることが最も明確に伝わります。一方で、ドメインを国ごとに取得・維持する費用がかかり、ドメインの評価も別々に育てることになります。1つの国に腰を据えて展開するのでなければ、負担が先に来ます。

中小企業が最初に選ぶなら、サブディレクトリが現実的です。既存のドメインの中に階層として持てるため、サーバーもCMSも1つで済み、日本語サイトで積み上げた評価と切り離されません。運用の担当者を分けなくてよい点も大きい要素です。

URLパラメータで言語を切り替える方式は、Googleのドキュメントで推奨されていないと明記されています。URLから対象が読み取りにくく、分割して扱うことも難しいためです。既存サイトがこの方式になっている場合は、URL構造の変更を伴います。手順と注意点はURLを変えるときのリダイレクト｜評価を落とさない手順と、やってはいけない転送を参照してください。

どの構造を選んでも、ナビゲーションの設計は言語ごとに必要になります。項目の決め方はグローバルナビの設計｜項目の決め方と並べ方で扱っています。

hreflangは、相互に参照し合っていないと無視される

言語ごとにページを用意したら、それらが同じ内容の別言語版であることを検索エンジンに伝えます。伝えないと、内容の重複したページとして扱われる可能性があります。この指定に使うのがhreflangです。

Googleは指定の方法を3つ挙げています。どれか1つを選べばよく、併用する必要はありません。

実装で最も多い失敗は、片方向にしか書かないことです。Googleのドキュメントには、2つのページが互いに参照し合っていない場合、参照するタグは無視されるという趣旨が明記されています。ページXがページYを指しているなら、ページYもページXを指し返す必要があります。

日本語ページから英語ページへのリンクだけを書き、英語ページ側に何も書かない。この状態では指定が効きません。「設定したのに反映されない」という相談の多くは、この往復が欠けています。

書式にも決まりがあります。言語はISO 639-1、地域はISO 3166-1 alpha-2の形式で指定し、地域だけを単独で指定してはいけません。「日本向け」を表そうとして地域コードだけを書いても、言語の指定として解釈されません。

加えて、どの言語版にも当てはまらない利用者に向けた指定として x-default があります。閲覧者のブラウザ設定が、指定したどの言語や地域とも一致しない場合に使われる値です。言語選択のページや、既定の言語版を指しておきます。

なお、Googleはページの言語をコンテンツそのものから判断します。hreflangやHTMLのlang属性は、言語を宣言するためのものではありません。hreflangが果たす役割は、複数ある版の中からどれを表示するかを選ぶための情報を渡すことです。ここを取り違えると、タグを書いたのに日本語のページが英語圏で表示される、といった状況の原因を見誤ります。

同じ内容のページが複数ある状態をどう整理するかは似た内容のページが複数あるときの整理｜正規URLの指定と、統合の判断、構造化データをどこまで入れるべきかは構造化データはどこまで必要か｜効果が出る種類と、もう表示されなくなったもので扱っています。

Googleが「避けてください」と書いている2つの実装

多言語サイトの解説記事で推奨されている方法の中に、Googleが明確に避けるよう書いているものが含まれています。該当するのは2つです。

1. 原文と訳文を1つのページに併記する

日本語の文章の下に英語の文章を並べる、あるいは左右に並べて置く構成です。制作の手間が少なく、1ページで済むため管理も楽に見えます。

しかしGoogleのドキュメントには、Googleが言語を正しく判断できるように、各ページのコンテンツとナビゲーションには1つの言語を使用し、原文と訳文を一緒に表示することは避けてくださいという趣旨が明記されています。1つのページに複数の言語が混在すると、そのページが何語のページなのかを判断しにくくなるためです。

「多言語対応の方法」として併記型を挙げている解説は少なくありませんが、検索からの流入を目的にするなら選べません。来た人に読ませるだけが目的で、検索に出ることを求めないのであれば、実害は限定的です。ここでも目的による分岐が効いてきます。

2. 閲覧者の言語設定で自動的に切り替える

ブラウザの言語設定やアクセス元の地域を見て、日本語版から英語版へ自動的に飛ばす実装です。親切な機能に見えますが、Googleのドキュメントには、サイトのある言語バージョンから別の言語バージョンへユーザーを自動的にリダイレクトすることは避けてください、と明記されています。

理由は、利用者と検索エンジンの双方が、すべての言語版へたどり着けなくなるためです。日本在住で英語を使う人が日本語版に飛ばされて戻れない、あるいは検索エンジンが一部の版を取得できない、といった状態が起こります。

代わりに置くのは、利用者が自分で切り替えられるリンクです。ヘッダーに言語の切り替えを置き、選んだ結果を保持する。判断を利用者に残す形にします。自動で飛ばす実装は、実際に不具合の相談として持ち込まれることが多い部類です。

費用は初期の翻訳ではなく、運用で決まる

多言語サイトの費用は、翻訳の見積りだけで判断できません。初期費用は1回で終わりますが、運用の負荷は公開した後ずっと続くからです。

構造を式で表すと、次のようになります。

• 初期費用 ＝ 翻訳する文字量 ＋ 言語版の実装 ＋ デザインの調整
• 運用の負荷 ＝ 更新するページ数 × 言語数

問題になるのは2つ目です。日本語のページを1つ直すたびに、言語の数だけ同じ作業が発生します。3言語に対応していれば、1回の更新が4回分の作業になります。お知らせ、価格、サービス内容、担当者名。どれも更新の対象です。

ここで起きるのが、言語版だけが更新されずに取り残される状態です。日本語サイトは最新なのに、英語版には終了したサービスと古い電話番号が残っている。これは単に古いだけでなく、読んだ相手に誤った情報を伝えることになります。

さらに厄介なのは、放置した言語版を簡単には消せない点です。すでに検索結果に出ていて、外部からリンクされている可能性があるページを削除すると、そこへ来た人が行き先を失います。始めるときに、やめるときの手順まで決めておいてください。保守運用に何を含めるかはホームページの保守運用とは？何を、どの頻度でやるのかで扱っています。

見積りを受け取ったときに確認すべき項目は、次のとおりです。金額の大小より、何が含まれていないかを先に見てください。見積書の読み方そのものはWeb制作の見積書の読み方｜同じ金額が別の買い物になる理由で整理しています。

最下行は特に見落とされます。CMSの構造が単一言語を前提にしていると、後から言語を足すときに作り直しになります。将来的に増やす可能性があるなら、最初の1言語を実装する段階で伝えてください。CMSの選び方と更新体制は更新しやすい企業サイトの作り方｜CMS選定と運用設計のポイント、日本語と言語版で構成を分けたい場合の判断はヘッドレスCMSは導入すべきか｜WordPressで足りる条件と、分けたときに失うものを参照してください。

全ページを訳す必要はない

「多言語対応」と聞くと、サイト全体を丸ごと訳す前提で考えがちです。しかし訳すべきページは、相手が判断に使うページだけです。更新の負荷が言語数に比例する以上、訳す範囲を絞ることが運用を続けられるかどうかを決めます。

優先順位は、相手が意思決定に必要とする順です。

最下行は、意識して外してよい部分です。お知らせやブログは本数が最も多く、しかも増え続けます。ここを対象に含めると運用が破綻し、結果として全体の更新が止まります。訳さないと決めて、その言語版のナビゲーションから外すほうが健全です。

逆に、問い合わせフォームは必ず含めてください。会社概要を訳したのにフォームが日本語のままで、項目の意味が分からず送信されない、という状態は実際に起こります。自動返信メールの言語、必須項目の説明、電話番号の国番号まで含めて確認します。

企業サイトに必要な表記の整理は企業サイトに必要な表記の整理｜プライバシーポリシーと、特商法表記が要る条件、サイト全体の構成の考え方は情報設計（IA）とは？わかりやすいサイト構成の作り方で扱っています。

機械翻訳をどこまで使ってよいか

翻訳の費用を抑える方法として、機械翻訳の利用は現実的な選択肢です。精度は以前とは比較にならないほど上がっています。ただし、そのまま公開するかどうかは、ページの性質によって分けてください。

分岐の基準は、誤ったときに何が起きるかです。読みにくいだけで済むページと、金銭や責任の範囲に関わるページを、同じ基準で扱わないでください。

特に注意が必要なのは、日本語の商習慣に根ざした表現です。「応相談」「要問い合わせ」「別途お見積り」といった言い回しは、直訳しても相手に条件が伝わりません。何が決まっていて何が決まっていないのかを、書き直す必要があります。これは翻訳ではなく、原稿の作成にあたる作業です。

見積りの段階で「翻訳」とだけ書かれている場合、この書き直しが含まれているかを確認してください。含まれていなければ、日本語の原稿をそのまま渡すことになり、相手にとって判断できない文章が出来上がります。

向いている場合と、向いていない場合

ここまでを踏まえて、着手の判断を整理します。技術的にできるかどうかではなく、公開した後に運用が続くかどうかで決めてください。

4行目は、着手前に必ず確認してください。日本語サイトの更新が止まっている状態で言語版を足すと、止まる対象が増えるだけです。更新の負荷は言語数に比例するため、いま回っていない体制で複数言語を回すことはできません。

最下行は、実際によくある動機です。それ自体を否定する必要はありませんが、目的が「体裁」のままだと、訳す範囲も更新の頻度も決められません。「海外の取引先に会社概要を見せたときに、実在と規模が伝わる状態にする」まで具体化すれば、訳すべきページは数ページに絞れます。この形なら運用も続きます。

3行目も重要です。問い合わせが来ること自体が目的ではありません。英語で来た問い合わせに数日返答できなければ、機会を失うだけでなく印象も損ないます。受け皿を先に決めてください。

よくある失敗

翻訳ウィジェットを入れて「多言語SEO対策」と考える

最も多い失敗です。ウィジェットもブラウザの翻訳機能も、表示の段階で文字を置き換えるだけで、検索エンジンが取得できる別のURLを作りません。そのため海外の検索結果には出てきません。来た人に読ませる目的なら十分に機能しますが、流入を増やす手段として導入すると成果が出ないまま費用だけが残ります。導入前に、どちらの目的なのかを言葉にしてください。

日本語と英語を同じページに並べる

1ページで済み、管理も楽に見えるため選ばれがちです。しかしGoogleは、各ページのコンテンツとナビゲーションには1つの言語を使用し、原文と訳文を一緒に表示することは避けるよう明記しています。検索からの流入を目的にする場合は選べません。ページを分けたうえで、相互に切り替えられるリンクを置いてください。

ブラウザの言語設定で自動的に飛ばす

親切な実装に見えますが、Googleは言語バージョン間の自動リダイレクトを避けるよう明記しています。利用者も検索エンジンも、すべての言語版へたどり着けなくなるためです。日本在住の英語話者が日本語版に固定される、といった状況も起こります。切り替えは利用者が選べる形にしてください。

hreflangを片方向にだけ書く

日本語ページから英語ページへの指定だけを書き、英語ページ側に書き返さないケースです。相互に参照し合っていない指定は無視されるため、設定したのに反映されないという状態になります。ページを追加するたびに、往復が揃っているかを確認してください。地域コードを単独で指定することもできません。

お知らせやブログまで訳す範囲に含める

本数が最も多く、しかも増え続ける部分です。ここを含めると更新が追いつかず、結果として言語版全体が放置されます。訳さないと決めて、その言語版のナビゲーションから外すほうが健全です。訳す対象は、相手が意思決定に使うページに絞ってください。

問い合わせフォームを日本語のまま残す

会社概要と製品ページだけを訳し、フォームを訳し忘れる例です。読んで興味を持った相手が、最後の段階で連絡できません。項目名、必須の表示、送信後の画面、自動返信メール、電話番号の国番号まで含めて確認してください。ここが通らなければ、訳した他のページはすべて成果につながりません。

よくある質問

英語版を作れば、海外からの問い合わせは増えますか

ページを用意することは条件の一つであって、それだけで増えるとは限りません。検索から来てもらうには、相手が実際に使う言葉で検索したときに見つかる必要があります。日本語のキーワードを直訳しても、現地で使われている用語と一致しないことがあります。対象の国で使われる呼び方を確認したうえで構成を決めてください。キーワードの選び方の考え方はSEOキーワードの選び方｜検索数で選ぶと問い合わせにつながらない理由で扱っています。

サブディレクトリとサブドメイン、どちらがSEOに有利ですか

Googleのドキュメントでは、どちらも使える構造として並べられており、優劣は示されていません。判断材料になるのは運用側です。1つのサイトとしてまとめて管理したい、サーバーもCMSも増やしたくないのであればサブディレクトリ、拠点や運用主体が国ごとに分かれるのであればサブドメインが向きます。中小規模で1〜2言語から始める場合は、サブディレクトリが扱いやすい選択です。

機械翻訳で作ったページは、検索で評価されませんか

機械翻訳を使ったこと自体を理由に評価が下がるという記述は、Googleのポリシーにありません。問われるのは出来上がったページが読者にとって有用かどうかです。ただし、確認を経ていない翻訳は、単位や条件の誤り、意味の通らない訴求文といった問題を含みます。事実の記述が中心のページと、責任や金額に関わるページを分けて、後者は人が確認してください。

既存のサイトに後から言語を追加できますか

CMSの構造次第です。多言語を前提にした作りであれば追加できますが、単一言語を前提にしていると実装からやり直しになることがあります。現在のサイトで確認すべきは、言語ごとにページを持てるか、URLの階層を分けられるか、hreflangを自動で出力できるかの3点です。将来的に増やす可能性があるなら、最初の1言語を実装する段階で制作会社に伝えてください。

翻訳した後、日本語サイトを更新したらどうすればよいですか

更新のたびに、対応する言語版も更新します。この作業が言語数だけ発生することが、多言語サイトの実質的なコストです。運用を続けるために、更新頻度の高いページを訳す範囲から外す、更新の担当と翻訳の依頼先をあらかじめ決めておく、といった設計をしてください。更新が止まった言語版は、古い情報を伝え続けることになります。

言語版のページが検索結果に出てきません。何を確認すればよいですか

順番に切り分けます。まず、そのURLが単独で開けるか。開けなければページとして存在していません。次にSearch Consoleで登録状況を確認し、登録されていなければ内部リンクとサイトマップを見ます。登録されているのに表示されない場合は、狙っている言語での検索語句と、ページに書かれている語が一致していない可能性があります。日本語のキーワードを直訳しただけになっていないかを確認してください。

サイトのリニューアルと同時に多言語化すべきですか

同時に行うほうが、実装の重複が少なく効率的です。CMSの選定段階から多言語を前提にできるため、後から追加するより費用も抑えられます。ただし、確認する項目が一度に増えるため、日本語側の構成が固まらないまま言語版を進めると手戻りが大きくなります。日本語の原稿を確定させてから翻訳に入る順序を守ってください。進め方はコーポレートサイトのリニューアルで扱っています。

まとめ

多言語対応で最初に決めるのは、費用でも翻訳ツールでもありません。「すでに来ている人に読ませる」のか、「検索から新しく引き合いを取る」のか、という目的です。前者なら翻訳ウィジェットやブラウザの翻訳機能で足り、更新の負荷も増えません。後者は、言語ごとに別のURLを用意しなければ検索結果に出てきません。

この違いを飛ばすと、翻訳ウィジェットを導入して海外からの流入を期待する、という噛み合わない状態が生まれます。ウィジェットは表示の段階で文字を置き換えるだけで、検索エンジンが取得できるページを作っていないからです。

URLを分けると決めた場合、構造の選択肢は国別ドメイン、サブドメイン、サブディレクトリの3つで、URLパラメータは推奨されていません。中小規模で1〜2言語から始めるなら、サブディレクトリが扱いやすい選択です。そのうえで、言語版どうしをhreflangで結びます。相互に参照し合っていない指定は無視されるため、往復が揃っているかを必ず確認してください。

Googleが避けるよう明記している実装が2つあります。原文と訳文を1つのページに併記すること、そして言語バージョン間で自動的にリダイレクトすることです。どちらも解説記事で推奨されていることがありますが、検索からの流入を目的にするなら選べません。

そして費用は、初期の翻訳ではなく運用で決まります。更新の負荷はページ数×言語数で増え、日本語サイトを1つ直すたびに言語の数だけ同じ作業が発生します。だからこそ、訳す範囲を絞ってください。会社概要、製品の仕様、問い合わせフォーム。相手が判断に使うページだけで足ります。お知らせやブログを含めると運用が破綻します。

着手前の確認は一つです。日本語サイトの更新が止まっているなら、言語版を足しても止まる対象が増えるだけです。いま回っていない体制で、複数言語を回すことはできません。

多言語サイトの設計や既存サイトの構成のご相談はお問い合わせからご連絡ください。ホームページ制作の考え方はWEB制作・ホームページ制作、これまでの制作事例は制作実績、会社の概要をまとめた資料は資料ダウンロードでご覧いただけます。