多言語サイトのURL構造はサブディレクトリとサブドメインのどちらがいいですか？

多くの場合、サブディレクトリ方式（example.com/en/）がおすすめです。ドメインの評価が一つに集約されるため、新しい言語を追加しても既存のSEO資産を活かせます。海外に現地法人がある場合はccTLD（example.co.uk）も選択肢になります。サブドメイン方式は技術的にはシンプルですが、ドメイン評価が分散しやすい点に注意が必要です。

hreflangタグの設定で最も多いミスは何ですか？

最も多いミスは「片方向リンク」です。日本語ページに英語版へのhreflangを設定したら、英語ページにも日本語版へのhreflangが必要です。双方向リンクがないとGoogleはページの言語関係を正しく認識できず、インデックスが遅延したり重複コンテンツと判定される原因になります。言語コードの誤り（jpではなくjaが正しい）も頻出ミスです。

Webサイトの多言語化でコストを抑えるにはどうすればいいですか？

すべてのページを同じ品質で翻訳するのではなく、翻訳の深さをL1（機械翻訳そのまま）からL5（現地制作）の5段階で使い分けることが有効です。コンテンツの重要度と市場の重要度を掛け合わせて最適な深さを選ぶことで、翻訳コストを最大6割以上削減できます。

機械翻訳（AI翻訳）だけで多言語サイトを運用できますか？

ヘルプセンターや社内資料などはAI翻訳で十分機能しますが、LPや広告コピー、法務コンテンツにはプロの翻訳者や創作翻訳が必要です。AI翻訳が適切な領域を見極め、売上に直結するページやブランド訴求ページには上位の翻訳段階を適用する使い分けが重要です。

多言語SEOで見落としやすい設定は何ですか？

hreflangの双方向リンク設定、BCP 47準拠の言語タグ（jpではなくjaが正しい）、ロケール対応（日付・通貨・数値の表記形式）、canonical設定の自己参照の4つが見落としやすい項目です。これらの技術設定が不備だと翻訳品質が高くても検索エンジンに正しく評価されません。

hreflangの設定方法とcanonicalの正しい使い分け｜多言語SEO実践ガイド

「3言語に展開したのに、海外からの問い合わせがゼロ」。 多言語サイトを構築した企業からよく聞く声です。翻訳の品質が悪いのでしょうか？実はそうとも限りません。多くの場合、原因は翻訳の品質ではなく、サイト構造の設計、hreflangの設定ミス、そして翻訳にかけるコストの配分にあります。

多言語サイトの構築には、大きく分けて3つの失敗パターンがあります。

URL構造の選択を誤る — サブディレクトリ、サブドメイン、ccTLDの選び方でSEO効果が大きく変わるのに、深く考えずに決めてしまう
hreflangの設定が不完全 — 片方向リンクや言語コードの間違いで、Googleが言語版の関係を認識できない
すべてのページを同じ品質で翻訳する — 全ページをプロ翻訳にするとコストが膨れ上がり、かといって全部AI翻訳だとブランドが損なわれる

本稿では、この3つの失敗を避けるための実践ガイドを提供します。URL構造の選び方から、hreflangタグの具体的な設定方法、翻訳コストを63%削減するための5段階フレームワーク、そして多言語SEOの完全チェックリストまで、多言語サイト構築に必要な知識を一本にまとめました。

翻訳の手のかけ方を5段階で示した階段図 図1: 翻訳の「深さ」は5段階 — 軽い順にL1〜L5

多言語サイトのURL構造を選ぶ

多言語サイトを構築するとき、最初に決めるべきなのがURL構造です。この選択はあとから変更しにくく、SEOの効果に直結します。主な選択肢は3つあります。

サブディレクトリ方式（推奨）。 example.com/en/、example.com/zh/ のように、既存ドメインの下に言語ごとのディレクトリを作る方式です。ドメインのSEO評価が一つに集約されるため、新しい言語を追加しても既存の被リンク資産を活かせます。サーバーも1台で管理できるため、運用コストが低く抑えられます。多くのBtoB企業にとって、最もバランスの取れた選択肢です。

ccTLD方式。 example.co.uk、example.de のように、国別コードトップレベルドメインを使う方式です。Googleに対して「このサイトはこの国向け」という強力なシグナルを送れます。ただし、ドメインごとにSEO評価がゼロからのスタートになり、取得・維持のコストもかかります。海外に現地法人がある企業や、特定の国で強いブランド認知を築きたい場合に向いています。

サブドメイン方式。 en.example.com、zh.example.com のように、サブドメインで言語を分ける方式です。技術的にはメインサイトと独立して管理できるメリットがありますが、Googleはサブドメインを別サイトとして扱う傾向があり、ドメイン評価が分散しやすくなります。

方式	URL例	SEO評価	運用コスト	適するケース
サブディレクトリ	example.com/en/	集約	低	多くのBtoB企業（推奨）
ccTLD	example.co.uk	国別に独立	高	現地法人あり・特定国に注力
サブドメイン	en.example.com	分散しやすい	中	技術的に独立管理が必要な場合

表1: URL構造の比較 — 迷ったらサブディレクトリ方式を選ぶ

パラメータ方式（example.com?lang=en）は避けてください。Googleのジョン・ミューラー氏も公式に非推奨としています。パラメータ方式ではGoogleがページの言語バージョンを正しくクロール・インデックスできず、多言語SEOの効果がほぼ失われます。

hreflangタグの正しい設定方法

URL構造が決まったら、次に設定するのがhreflangタグです。hreflangは「このページには別の言語バージョンがある」とGoogleに伝えるためのHTMLタグで、多言語SEOの根幹をなす設定です。

hreflangの基本構文

hreflangタグは、HTMLの<head>セクションに <link> 要素として記述します。

<!-- 日本語ページのheadに記述 -->
<link rel="alternate" hreflang="ja" href="https://example.com/ja/about/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/about/" />
<link rel="alternate" hreflang="zh-Hans" href="https://example.com/zh/about/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/about/" />

x-default は、どの言語にもマッチしないユーザーに表示するデフォルトページを指定します。通常は英語ページか、言語選択ページを指定します。

設定の3大ルール

ルール1：双方向リンクを必ず設定する。 日本語ページから英語ページへhreflangを設定したら、英語ページから日本語ページへもhreflangを設定します。これが片方向だけだとGoogleはhreflangの指示を無視します。3言語あるなら、各ページに3つのhreflangタグ（自分自身への参照を含む）が必要です。

ルール2：言語コードはBCP 47に準拠する。 よくある間違いが、日本語を jp と書くことです。正しくは ja です。jp は国コード（ISO 3166-1）であり、言語コード（ISO 639-1）ではありません。主要な言語コードを以下にまとめます。

言語	正しいコード	よくある間違い
日本語	`ja`	`jp`
英語（米国）	`en-US`	`en-us`（小文字は可だが一貫性に注意）
英語（英国）	`en-GB`	`en` のみ（地域を省略）
簡体字中国語	`zh-Hans`	`zh-CN`（古い形式）
繁体字中国語	`zh-Hant`	`zh-TW`（古い形式）
韓国語	`ko`	`kr`

ルール3：自己参照を含める。 各ページのhreflangタグに、そのページ自身を指すエントリーも含めます。日本語ページのheadに hreflang="ja" で自分自身のURLを指定するということです。これがないと、Googleがページの言語を正しく判定できない場合があります。

設定方法は3つある

hreflangの設定方法は3つあり、サイトの規模や技術スタックに応じて選べます。

HTMLの<head>内（小〜中規模サイト向け）。 上記の基本構文のとおり、各ページのheadセクションに <link> タグを記述します。言語数×ページ数分のタグが必要になるため、数百ページを超えるとメンテナンスが大変になります。

XMLサイトマップ（大規模サイト向け）。 サイトマップファイルに <xhtml:link> 要素でhreflang情報を記述する方法です。HTMLを変更する必要がなく、一括管理できるため、大規模サイトで特に有効です。

<url>
  <loc>https://example.com/ja/about/</loc>
  <xhtml:link rel="alternate" hreflang="ja" href="https://example.com/ja/about/" />
  <xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/about/" />
  <xhtml:link rel="alternate" hreflang="zh-Hans" href="https://example.com/zh/about/" />
</url>

HTTPヘッダー（PDF等の非HTMLファイル向け）。 PDFやドキュメントファイルなど、<head> セクションを持たないファイルに対して、HTTPレスポンスヘッダーで指定する方法です。

Link: <https://example.com/en/doc.pdf>; rel="alternate"; hreflang="en",
      <https://example.com/ja/doc.pdf>; rel="alternate"; hreflang="ja"

3つの方法を混在させることもできますが、同じページに対して複数の方法を併用するのは避けてください。情報が矛盾するリスクが生まれます。サイト全体で1つの方法に統一するのが安全です。

A社のhreflang設定ミスから学ぶ

BtoB SaaS企業のA社（従業員200名）は、英語・中国語サイトの公開直後にインデックスが3週間遅延するトラブルを経験しました。原因は以下の2つでした。

片方向リンク: 日本語→英語のhreflangは設定したが、英語→日本語の設定を忘れていた
言語コードの誤り: 日本語の言語コードに jp を使用していた

修正後は1週間でインデックスが正常化し、英語版ページが検索結果に表示され始めました。hreflangのミスは気づきにくいため、Google Search Consoleの「インターナショナルターゲティング」レポートでエラーがないか定期的に確認してください。

翻訳の「深さ」を5段階で使い分ける

URL構造とhreflangが整ったら、次は翻訳そのものの設計です。ここで多くの企業がぶつかるのが「翻訳費用の壁」です。

A社が日本語サイトを英語と中国語に展開しようとしたとき、翻訳会社の見積もりは2,400万円でした。対象はWebサイト全ページ、ヘルプセンター500記事、ブログ50本、LP10枚、利用規約とプライバシーポリシー。合計約80万語です。

「全部機械翻訳にしよう」というCTOの提案もうまくいきませんでした。LPを機械翻訳で英語にしたところ、ネイティブのレビュアーから「意味は通るけど、このページを見て契約したいとは思わない」というフィードバックがあったのです。

A社に本当に必要だったのは「全部高品質に翻訳する」でも「全部機械翻訳にする」でもありません。ページごとに翻訳の手のかけ方を変える判断基準でした。

5段階のフレームワーク

翻訳の手のかけ方を、L1（最も軽い）からL5（最も重い）の5段階で整理します。

L1：機械翻訳そのまま。 AI翻訳の出力をそのまま、または最小限の修正で使います。社内向けの資料や、ほとんど閲覧されない補助ページに向いています。1語あたり0.5〜2円程度です。

L2：機械翻訳＋人が修正（ポストエディット）。 AI翻訳の出力を、人間のエディターが修正します。国際規格ISO 18587で品質要件が定められた手法です。ヘルプページやFAQ、技術文書に最適で、品質とコストのバランスが良い段階です。1語あたり3〜6円程度です。

L3：翻訳者が翻訳。 プロの翻訳者が原文から翻訳し、別のレビュアーがチェックします。ブログ記事や事例紹介など、読者が内容をじっくり読むページに適しています。1語あたり8〜15円です。

L4：創作翻訳（トランスクリエーション）。 原文のメッセージを保ちつつ、対象の文化に合わせて表現を創り直します。広告コピーやLPのキャッチコピーなど、「読んで心が動く」品質が必要な場面で使います。1語あたり15〜30円です。

L5：現地でゼロから制作。 その市場向けにゼロからコンテンツを作ります。原文は参考程度にしか使いません。主力市場のLPやブランドストーリーに限定して使います。1語あたり30〜60円です。

5つの段階の違いをひとことで言えば、「誰が、どこまで手をかけるか」の差です。L1〜L2はAIが主役で人間が補助、L3は人間が主役、L4〜L5はクリエイターや現地のマーケターが主役になります。

A社のLPキャッチコピー「データで、未来を動かす」を各段階で翻訳するとどうなるか見てみましょう。

L1: "Move the future with data." — 意味は通りますが、コピーとしては平板です
L2: "Drive the future with data." — 動詞を力強い表現に修正しています
L3: "Powering tomorrow through data." — 翻訳者がニュアンスを汲み取った自然な英語です
L4: "Your data. Your future. Unleashed." — コピーライターが英語圏で刺さる表現を創作しています
L5: 英語圏の市場調査を踏まえ、競合分析のうえでゼロからコピーを開発します

この差を見れば、「ヘルプセンターの500ページにL4を適用する」ことの非効率さがわかります。同時に、「主力市場のLPにL1を使う」リスクも明らかです。

どのページにどの深さを当てるか

5段階を定義したら、次は自社のどのページにどの段階を使うかの判定です。ここで使うのが、コンテンツの種類と市場の重要度の2つの軸で深さを決めるマトリクスです。

	重要度：低い市場	重要度：中程度の市場	重要度：高い市場
社内資料・補助ページ	L1	L1〜L2	L2
ヘルプ・FAQ・技術文書	L2	L2〜L3	L3
ブログ・事例・レポート	L2	L3	L3〜L4
LP・広告コピー	L3	L4	L4〜L5
ブランドストーリー・動画	L3〜L4	L4〜L5	L5

表2: コンテンツ種別×市場重要度による翻訳の深さの目安

A社がこのマトリクスを使った結果

A社は英語市場を「中程度（売上構成比15%）」、中国語市場を「低い（まだ売上なし、テスト段階）」と判断しました。

英語市場（中程度の重要度）:

ヘルプセンター500ページ → L2〜L3
ブログ50本 → L3
LP10枚 → L4
利用規約・プライバシーポリシー → L3以上

中国語市場（低い重要度）:

ヘルプセンター500ページ → L2
ブログ50本 → L2
LP10枚 → L3
利用規約・プライバシーポリシー → L3以上

この使い分けで、当初の見積もり2,400万円が約900万円に圧縮されました。削減率は63%です。主力LPの品質はL4で担保されているため、コンバージョン率への影響は最小限に抑えられています。

法務関連のコンテンツ（利用規約、プライバシーポリシー、契約書など）は市場の重要度に関係なくL3以上を使ってください。翻訳ミスが法的責任に直結するためです。とくにGDPR（EU一般データ保護規則）対応が必要な言語圏では、対象国の法務に詳しい翻訳者の関与が欠かせません。

コンテンツ種別と市場重要度のマトリクスで翻訳の深さを判定する図 図2: 判定マトリクス — コンテンツの重要度が上がるほど、翻訳に手をかける

コスト・品質・納期のバランスを理解する

5段階の各段階には、コスト・品質・納期のトレードオフがあります。

Loading chart...

図3: 深さ別のコスト・品質・納期の比較 — 深さを上げるほど品質は向上するが、コストと納期も増大する

このグラフから読み取れる重要なポイントがあります。L2からL3への品質向上幅が最も大きいということです。コストは2.5倍になりますが、品質は65%から80%へ15ポイント改善します。一方、L4からL5は品質が90%から98%へ8ポイント向上するだけで、コストは1.33倍です。

限られた予算で最大の品質改善を狙うなら、重要なページだけをL4〜L5に引き上げて、残りはL2で効率化するほうが全体の成果は大きくなります。

上記の数値は概念モデルです。実際のコスト・品質・納期は、言語ペア（日英と日中ではコスト構造が異なります）、翻訳者の専門性、ツール環境によって変動します。自社の実績データで調整してください。

翻訳ワークフローを設計する

深さが決まったら、運用フローを設計します。ポイントは、翻訳を始める前に深さを決めることです。

図4: 多言語コンテンツの翻訳フロー — 重要度を判定してから、深さに応じた翻訳を実行し、品質チェックを経て公開する

このフローには3つのゲートがあります。

第1ゲート：重要度の判定。 新しいコンテンツができたら、まず表2に照らして深さを決めます。迷ったときの目安は「このページの翻訳ミスがSNSで拡散されたら、どのくらいダメージがあるか」です。ダメージが大きいなら、深さを1段階上げてください。

第2ゲート：品質チェック。 深さごとにチェック基準が異なります。L1なら「致命的な誤訳がないか」のスポットチェックで十分です。L3なら用語の一貫性と文体の自然さまで確認します。L4以上は、対象市場のネイティブスピーカーによるレビューが必須です。

第3ゲート：SEO設定の確認。 翻訳品質がどれほど高くても、hreflangの設定が間違っていれば検索エンジンに正しく認識されません。前述のhreflang設定の3大ルールと、次のセクションのチェックリストで確認します。

運用で気をつけたい3つのこと

翻訳しやすい原文を書く。 多言語展開を前提にするなら、原文の段階で「翻訳のしやすさ」を意識します。「石の上にも三年」のような日本特有の表現は避け、文化に依存しない言い回しを使います。用語集を先に整備しておけば、翻訳者ごとに表記がブレる問題も防げます。

公開後のデータで深さを見直す。 言語別のページビュー、直帰率、コンバージョン率を追跡し、深さの判定が適切だったか検証します。A社では中国語のブログをL2で公開した3か月後に直帰率が日本語版の2倍になり、L3に引き上げました。逆にヘルプセンターのL3対応ページはL2でも十分だったため、次回更新時にL2に切り替えてコストを30%削減しています。

AI翻訳の適用範囲を見極める。 2025〜2026年にかけてLLMベースの翻訳品質は大幅に向上しました。ヘルプセンター、社内ナレッジベース、更新頻度の高い技術文書はL1〜L2で十分に機能します。A社ではヘルプセンターの80%をL2で運用していますが、ユーザー満足度はL3の時期と大きな差がありません。ただし、法務コンテンツ、LP・広告コピー、売上に直結する料金ページなどは、AI翻訳だけでは品質が足りません。A社がLPをL1で公開したときのコンバージョン率は日本語版の18%でしたが、L4でリライトした後は72%まで回復しました。

一律翻訳と深さ別翻訳のコスト比較を示すビフォー・アフター図 図5: 一律翻訳（左）と深さ別の使い分け（右）のコスト構造の違い

多言語SEO完全チェックリスト

翻訳の品質がどれほど高くても、技術的な設定が不備だとGoogleに正しく評価されません。多言語サイトを公開する前に、以下のチェックリストで確認してください。

hreflang関連

すべての言語ページに、すべての言語バージョンへのhreflangタグを設定した（双方向リンク）
各ページのhreflangに自己参照を含めた
x-default を設定した（デフォルトの言語ページ or 言語選択ページ）
言語コードがBCP 47に準拠している（jaであってjpではない）
hreflangのURLが正規URL（canonicalと一致するURL）を指している
Google Search Consoleの「インターナショナルターゲティング」でエラーがないか確認した

URL構造

言語ごとに固有のURLを持っている（パラメータ方式を使っていない）
URL構造がサイト全体で統一されている（サブディレクトリならすべてサブディレクトリ）
各言語ページにcanonicalタグの自己参照を設定した
XMLサイトマップに全言語のURLを含めた

コンテンツのローカライゼーション

日付形式が対象地域に合っている（2026年3月20日 vs March 20, 2026）
通貨記号が対象市場に合っている（¥ vs $ vs €）
数値表記が対象地域の慣習に合っている（1,000 vs 1.000）
電話番号に国番号を含めた
画像内のテキストも翻訳した（OGP画像を含む）
HTMLのlang属性を各言語ページに設定した

技術的なSEO

各言語ページの表示速度を確認した（CDNの地域設定含む）
モバイル対応が全言語で機能している
構造化データ（JSON-LD）の言語・地域情報が正しい
言語切り替えのUIが全ページに表示されている
自動リダイレクト（IPベース）を避け、ユーザーに言語を選ばせている

チェック項目	よくあるミス	影響
hreflang双方向	片方向リンクだけ設定	インデックスの遅延・重複コンテンツ
言語タグ	`jp` を使う（正しくは `ja`）	Googleが言語を認識できない
x-default	設定し忘れる	言語マッチしないユーザーの導線が不明確
ロケール	日付や通貨が日本形式のまま	ユーザー体験の低下・信頼性の毀損
canonical	言語間で重複指定	一部のページが検索結果から消える
自動リダイレクト	IPベースで言語を強制	ユーザーが言語を切り替えられない

表3: 多言語SEO設定のよくあるミスと影響

まとめ

URL構造はサブディレクトリ方式を基本に。 ドメインのSEO評価を集約でき、新しい言語の追加も容易です。ccTLDは現地法人がある場合、パラメータ方式は避けてください
hreflangは「双方向・自己参照・BCP 47準拠」の3つを守る。 片方向リンクや言語コードの誤りは、検索エンジンがページの言語関係を認識できなくなる最も多い原因です。Google Search Consoleで定期的にエラーチェックをしてください
翻訳の深さを5段階で使い分ける。 L1（機械翻訳そのまま）からL5（現地制作）まで、コンテンツの種類と市場の重要度で適切な段階を選びます。A社はこの使い分けで翻訳コストを63%削減しました
翻訳品質だけでなくSEO設定も確認する。 hreflang、canonical、ロケール対応の設定が揃って初めて、翻訳への投資が検索結果に反映されます

最初の一歩としておすすめなのは、自社サイトのURL構造の確認とhreflangの設定状況のチェックです。Google Search Consoleの「インターナショナルターゲティング」レポートを開けば、現状の問題点がすぐに見えてきます。

Agenticベースでは、多言語サイトのURL設計から、hreflang設定の実装、翻訳の深さ判定、多言語SEOの技術実装まで一貫して支援しています。お問い合わせはこちら →

この記事の著者

Agentic Base 編集部

AIエージェントとWebメディア運用の知見を活かし、実践的なナレッジを発信しています。