Google SEO 上級

多言語コンテンツ公開の流れ:翻訳完了後の5つの関門

多言語サイトのトラブルは90%が「翻訳が終わった後」に起きます。用語の不一致、メタデータの未書き換え、hreflangの設定ミス、単位や日付の未ローカライズ、公開後の検証なし——この5つの関門のどれか一つでも漏れると、その言語版にかけた初期投資が無駄になります。

多言語コンテンツの公開:翻訳完了後の5つの関門多言語サイトのトラブルは90%が「翻訳が終わった後」に起きる第一関門用語の一貫性用語集と1項目ずつ照合⚠ 出たら即アウト:ブランド名が翻訳されている第二関門SEOメタデータtitle / desc / slug を書き直す⚠ 中国語タイトルを直訳 → 誰も検索しない第三関門URLとhreflang双方向の相互参照 + x-default⚠ canonicalが全て英語版を指す → インデックスされない第四関門ローカライズ対応日付 / 単位 / 通貨 / 法規制⚠ 09/16は地域によって読み方が逆になる第五関門公開後の検証1日 / 7日 / 30日の3回チェック⚠ 公開したら忘れる → 半年後に気づくフローを定着させる鍵:言語ごとに「言語責任者」を1人決める責任者がいない言語は、半年以内にパラメータが古いままのページに劣化します ——しかも誤った情報は、その言語版がないことより悪い結果を招きます。AIの学習データに入り込み、ブランド情報を長期的に汚染するからです。
多言語コンテンツ公開の流れ:翻訳完了後の5つの関門

多言語コンテンツ公開の流れ:翻訳完了後の5つの関門

結論から言うと:多言語サイトのトラブル90%は「翻訳が終わった後」に起きる。用語の不一致、メタデータの未書き換え、hreflangの設定ミス、単位や日付の未ローカライズ、公開後の検証なし——この5つの関門のどれか一つでも漏れると、その言語版にかけた初期投資が無駄になります。

1. なぜ「翻訳完了」はまだ中間地点なのか

まず、実際の現場で繰り返し起きている事故を見てみましょう。

事故 表面的な現象 本当の原因
ドイツ語ページの製品パラメータが英語ページと違う 顧客が注文後に仕様の違いに気づく パラメータ更新時に英語ページしか直していない
フランス語ページがGoogleで全く順位が出ない ページは存在するのに検索で見つからない hreflangの設定ミスで重複コンテンツと判定される
日本語ページが顧客に伝わらない 用語の機械翻訳ミス 用語集がなく「精度」と「繰り返し位置決め精度」が混同されて訳される
スペイン語ページの直帰率が極端に高い 顧客が開いてすぐ閉じる 日付形式(09/16 vs 16/09)が混乱を招く
顧客から価格の誤解についてクレームが来る 通貨の表記が不明確 数字だけで通貨を書かない、または通貨記号が曖昧

この5種類の事故には共通点があります。すべて「翻訳が終わった後」に起きているのです。

翻訳作業そのもの(中国語を別の言語に変換すること)は「文字の問題」を解決するだけです。ある言語版を本当に使えるものにするには、さらに次のことを処理する必要があります。用語、メタデータ、URLとリンク、現地の慣習、公開後の検証この5つです。だから多くの企業の多言語サイトは「言語はたくさん作ったのに、英語しか役に立たない」状態になります。

2. 用語集:すべての土台

5つの関門の話に入る前に、まず用語集について触れなければなりません——後続のすべての工程を支える基盤です。

用語集を省けない理由

多言語コンテンツでは、同じ中国語の語が文脈によって異なる外国語に対応することがあり、その逆もあります。機械翻訳ではこの対応関係を扱えません。

日本語 英語での訳語候補 実際の意味 訳語を混ぜた場合の影響
精度 精度 / 正確さ accuracy は正確さ(真値への近さ)、precision は再現性を指します 顧客が precision の意味で受け取り、期待にずれが生じる
納期 リードタイム / 納期 lead time は注文から出荷までの期間です 商談や契約条件でのトラブル
カスタマイズ カスタマイズ / カスタム / OEM OEM には特定の商習慣上の意味があります 顧客が OEM 対応可能だと誤解する
保証 保証 / 保証期間 warranty は製品保証、guarantee は約束を指します アフターサービスの責任範囲が不明確になる
生産能力 生産能力 / 生産量 capacity は最大能力、output は実際の生産量を指すことが多いです 顧客が最大生産能力を前提に発注する

用語集の作り方

ステップ やり方 成果物
① 抽出 製品ページ、仕様表、FAQ から頻出の専門用語を抽出 中国語の用語 100~300 語
② 訳語の確定 各用語に標準訳を一つ決める(ターゲット言語のネイティブに確認するのも可) 中国語 → ターゲット言語の対照表
③ 禁止訳の明記 「使わない語」を明確にする ミスを減らす
④ 言語ごとに管理 言語ごとに一つ、現地の業界慣習も含める 各言語の用語集
⑤ 継続的に更新 製品や用語が増えるたびに追記 バージョン管理

実践的な提案:用語集に「顧客が実際に使う言い方」を加えましょう。たとえばドイツの顧客は特定の業界用語を好み、辞書の標準訳はあまり使わないことがあります。顧客がメールや展示会で使う語を記録しておけば、どんな辞書より正確です。

三、五つの関門を順に解説

第一関門:用語の一貫性チェック

チェック項目 確認方法 不合格のサイン
用語が用語集どおりに訳されているか 検索置換ツールで一つずつ確認 同じ用語がページによって訳が違う
同じ製品の名称が統一されているか 製品名を全文検索 同じ型番がページによって呼び方が違う
パラメータの単位が統一されているか すべての数値と単位を確認 一方は mm、もう一方は cm
会社名とブランド名 ブランド名を全文検索 ブランド名が翻訳されている(ブランド名は通常訳さない)
認証名称 CE / UL / ISO などを確認 認証名が意訳されたり略称が誤っていたりする

この関門でよくあるミス:ブランド名が翻訳されること。「环形山」のような中国語ブランド名が「Crater Mountain」などと機械翻訳されると、ブランド実体の一貫性が直接損なわれます——ブランド名はどの言語でも同じ文字列でなければなりません。検索エンジンや AI は文字列の一致で実体を識別するからです。

第二関門:SEO メタデータのリライト

これが最もよく飛ばされる関門です。多くの企業がページの title と description も一緒に機械翻訳してしまい、ターゲット市場の検索結果で極端に低い成果しか出せていません。

プロジェクト やり方 よくある誤り
タイトル リライト直訳ではなく、ターゲット市場の検索習慣に合わせてキーワードを組み立てる 中国語タイトルを直訳すると、語順も用語も現地の検索習慣に合わない
説明 リライト、現地語のキーワードと行動喚起を含める 直訳すると機械翻訳のように読める
H1 Title と連動させるが、完全には一致させない title と一字一句同じ(意味空間の無駄遣い)
URL スラッグ ターゲット言語を使い、ピンインは使わない 中国語のピンイン slug を使う(ドイツ語圏の顧客には全く通じない)
画像 alt ターゲット言語で説明する 中国語の alt や英語の alt をそのまま残す
内部リンクのアンカーテキスト ターゲット言語の説明的なアンカーテキストを使う 「ここをクリック」のような情報のないアンカーテキストを使う

なぜ Title は直訳せず書き直す必要があるのか?検索需要の表現方法は言語によって異なるからです。中国語では「工業級執行機構メーカーおすすめ」と言っても、ドイツ語圏の顧客は「elektrischer Stellantrieb Hersteller Industrie」と検索するかもしれません——語順、用語の習慣、修飾関係がすべて異なります。直訳した結果は文法的には正しいものの、誰も検索しません。

実用的な方法:ターゲット言語で主要キーワードを検索し、上位に表示されるページのタイトルがどう書かれているかを見て、その「表現方法」に沿って自分のタイトルを再構築する(内容をコピーするのではなく)。

第3関門:URL 構造と hreflang

この関門は最も技術的で、最も間違いやすいものです。

URL 構造の3つの方式:

プラン 形式 メリット 欠点 適している
サブディレクトリ site.com/de/ 評価が集中し、維持管理が簡単 サーバーが同一オリジンである必要があり、地域識別が弱い ほとんどの企業
サブドメイン de.site.com 独立して展開可能 評価が分散し、個別設定が必要 大規模サイト、地域差が大きい場合
国別トップレベルドメイン site.de 地域シグナルが最も強い コストが高く、複数のドメインと証明書が必要 ローカライズ度が極めて高い

サブディレクトリ方式を推奨(site.com/de/)、評価が集中し維持コストが最も低いため、ほとんどの海外展開企業に十分です。

hreflang のよくある6つの設定ミス:

# 誤り 結果 正しい方法
1 片方向参照(A が B を指し、B が A を指し返さない) 検索エンジンがこの関係を無視する 必ず双方向で相互参照する
2 x-default がない 言語が一致しないユーザーにフォールバックページがない デフォルトバージョンを指定する(通常は英語または言語選択ページ)
3 hreflang が指すページが存在しないか 404 関係が無効になる 公開前にリンクがアクセス可能か1つずつ検証する
4 hreflang と canonical が競合 シグナルが矛盾し、インデックスが異常になる canonical は自身の言語バージョンを指し、すべてを英語版に向けない
5 言語コードが不規範(de-ATと書くべきところをat) 認識されない ISO 639-1 言語コード + 任意の ISO 3166-1 地域コードを使う
6 ページネーション / フィルタページにも hreflang を付けるが設定が一致しない インデックスが混乱する ページネーションページは self-referencing または統一ポリシーを使う

第4条が最も見落とされやすく、最もよくあるものです。典型的なミスは、すべての言語バージョンの canonical が英語版を指していることです。これは検索エンジンに「これらの言語ページはすべて英語ページのコピーだ」と伝えることになり、結果として非英語版はほとんどインデックスされません——これが「多言語化したのにランキングされない」最大の原因です。

第4関門:ローカライズ適応(言語だけではない)

言語は正しくても習慣が合わなければ、顧客は「これは自分たち向けではない」と感じます。

プロジェクト ローカライズが必要な項目 よくある誤り
日付 形式(MM/DD か DD/MM か YYYY-MM-DD) 09/16 はスペイン語圏・ドイツ語圏では誤読されます
数字 桁区切りと小数点(1,234.56 vs 1.234,56) 小数点記号を間違えると、数値の解釈がずれます
単位 メートル法/ヤード・ポンド法(mm vs inch、kg vs lb、℃ vs ℉) 米国市場なのにメートル法しか記載しない
通貨 通貨の明確な表記 数字だけで通貨を書かない
氏名の順序 名が先か姓が先か 顧客の呼び方を間違える
住所の形式 国ごとに異なる住所の記載順 物流と信頼に影響
法規制の表現 現地のコンプライアンス要件(例:EU の製品安全規制、データ保護) 中国語のコンプライアンス表現をそのまま翻訳
連絡の習慣 現地で好まれる連絡手段(電話/メール/WhatsApp) 連絡手段を1つしか用意しない
計量の習慣 出力・面積・重量の現地での表し方 顧客が自分で換算する必要がある

なかでも「数値形式」と「単位」は最も見落とされやすく、影響は最も直接的です。米国の顧客は「1.234,56 mm」を見て戸惑い、ドイツの顧客は「1,234.56 mm」を見て同じく戸惑います——この2つの数字は読み方が両者で異なり、桁を1つ誤って判断する恐れがあります。

第5の関門:公開後の検証

公開はゴールではありません。公開後1日目・7日目・30日目にそれぞれ一度チェックすることをおすすめします。

チェックのタイミング チェック内容
公開当日 リンクが開けるか、hreflang が機能しているか、リダイレクトは正しいか、ページは正常に表示されるか
公開7日目 検索エンジンがクロールしたか、Search Console にエラーはないか、多言語タグが認識されているか
公開30日目 インデックスされているか、キーワードの表示はあるか、直帰率と滞在時間に異常はないか

検証ツールと方法のチェックリスト:

目的 方法
hreflang が正しいか確認する Search Console の「国際化」レポート + HTML head を手動で確認
インデックスされているか確認する site:site.com/de/クエリ
重複コンテンツの問題を確認する Search Console の「重複ページ、Google が選択した正規ページがユーザー指定と異なる」
リダイレクトチェーンを確認する クロールツールまたはブラウザ拡張機能
言語判定を確認する ブラウザの言語環境でアクセスし、正しいバージョンに自動転送されるか見る
パフォーマンスを確認する 各言語版の読み込み速度(CDN ノードが対象地域をカバーしているか)

よく見落とされるチェックが1つあります。すべての言語版で速度が揃っているかです。英語版がグローバル CDN を使い、ドイツ語版が米国ノードのみの場合、ドイツのユーザーがドイツ語ページを開くと明らかに遅くなり、直帰率と順位に直接影響します。

四、プロセスの固定化:どの関門を誰が担当するか

多言語コンテンツで問題が起きるのは、たいてい誰もやっていないからではなく、誰も責任を負っていないからです。5つの関門を明確に割り当てることをおすすめします:

関門 担当役割 成果物 検収基準
① 用語の一貫性 コンテンツ / プロダクト 用語集 + 校正記録 用語の反映率 100%
② SEO メタデータ SEO / コンテンツ 言語ごとの title / desc / slug 一覧 各ページを個別に執筆し、直訳はしない
③ URL と hreflang 技術 / SEO 設定チェックリスト + 検証スクリーンショット Search Console でエラーなし
④ ローカライズ適応 コンテンツ / 対象市場の担当者 適応チェックリスト(日付 / 単位 / 通貨 / 法規) 20 項目を抜き取り検査し、すべて合格
⑤ 公開後の検証 SEO / 運用 3 段階の検証レポート 30 日以内に正常にインデックス

組織づくりについて一つ提案があります。言語ごとに「言語責任者」を決めてください。その人が専任でなくても、どの言語を誰が担当するかを明確にしておく必要があります。実際、「担当者のいない言語」は半年で「パラメータが古いままのページ」に劣化します。そして古い誤った情報は、その言語版がないことよりも有害です。AI の学習データに取り込まれ、ブランドの情報を長期的に汚染するからです。

FAQ よくある質問

機械翻訳 + 人の推敲で対応できますか?
可能ですが、手順が重要です。推奨する順序は次のとおりです。用語集を先に作成 → 機械翻訳 → 重点段落を人が通読 → ローカライズ適応 → 公開後の検証。このうち最も省いてはいけないのが用語集です。用語集がなければ、機械翻訳は専門用語で必ず誤り、人の推敲も「表現が美しいか」に偏って「用語が正確か」を見落とします。パラメータの多い製品ページは、主要ページをネイティブスピーカーか業界の翻訳者に確認してもらうことをおすすめします。
一度に何言語を公開すべきですか?
「国際的に見えるか」ではなく、対象市場の売上比率で決めます。おすすめは次のとおりです。まず英語 + 主力市場の言語 1〜2 言語から始め、五つの関門をすべて通す完全なフローを確立してから拡張します。理由は、どの言語にも長期的な保守(パラメータ更新、コンテンツ更新、コンプライアンス更新)が必要だからです。保守できるかどうかが言語数の上限を決めます。8 言語を公開しても誰も保守しなければ、1 年後には 8 つの古いページになります。
自動翻訳プラグインは使えますか?
使えますが、位置づけに注意が必要です。自動翻訳プラグインは「顧客に内容を理解してもらう」レベルには向いています(製品ページの閲覧や会社概要の理解など)。ただし出力は通常クライアント側で動的に翻訳されるもので、独立したページとして検索エンジンにインデックスされません。つまり本格的な多言語 SEO の代わりにはなりません。「ドイツ語の検索結果で見つかる」ことが目標なら、必要なのは静的な独立 URL と hreflang を備えたドイツ語ページであり、プラグインのリアルタイム翻訳ではありません。
アクション やり方
変更を記録 英語版(主ソース)のコンテンツ更新時に、変更点と日付を記録する
必要性を判断 変更が他言語に影響するか判断する(パラメータ変更は必ず同期、文体の調整は後回しでよい)
同期を割り当て タスク管理システムで言語ごとの担当者にタスクを割り当てる
定期監査 四半期ごとに各言語版と主ソースの整合性を抜き取り検査する
多言語コンテンツの更新はどう同期しますか?
ここが長期運用で最も制御を失いやすい部分です。次のような仕組みづくりをおすすめします。言語バージョン同期チェックリスト」:重要なのは「変更が必ず同期タスクを起動する」仕組みであり、人が覚えていることに頼らないことです。一箇所でもパラメータ更新後の同期を忘れると、「英語ページはIP65、ドイツ語ページはIP54」といった事故が起きます。
多言語サイトでAI引用最適化(GEO)に取り組むべきですか?
はい、しかも多言語であること自体がGEOの強みの一つです。同じ事実を複数の言語で表現することは、複数言語のコーパスにブランドエンティティを築くことを意味します。具体的な提案:重要な事実(パラメータ、認証、会社情報)が各言語版で完全に一致していることを確認する。各言語版がAIクローラーに取得可能であること(robots.txtとCDNがブロックしていないか確認)。対象言語の文脈で、そのまま引用できる結論段落を用意する。注意:機械翻訳で生成したコンテンツは引用される際の価値が低くなります。表現が「直訳的」で、現地の自然な質問の仕方に合わないためです。
階層 指標 観察期間
技術 インデックス登録ページ数、hreflangエラー数、クロール状況 公開後30日
トラフィック 各言語の自然検索流入とキーワードカバレッジ 3〜6か月
ビジネス 各言語がもたらす問い合わせ数と成約 6~12ヶ月
投資対効果はどう評価しますか?
三つの層に分けて、かつ長めの時間軸で見ることをおすすめします:重要な注意点:英語市場の基準で他の言語を測らないこと。ドイツ語市場は通常規模が小さいが意向が強く、スペイン語市場は規模が大きいが客単価が低い可能性があり、日本語市場は細部への要求が極めて高い。同じKPIセットで異なる言語を測ると、「この言語は役に立たない」という誤った結論を導きやすくなります。

最後に

多言語で最も人手を食う部分は、実は翻訳ではありません。翻訳は外注もでき、スピードも上げられます。本当に難しいのは翻訳後の五つの関門です:用語を揃える、メタデータを書き直す、構造を対応させる、慣習に合わせる、公開後にデータを見る。

この五つには共通点があります:どれも「この市場を本当に理解している人」が必要であり、ツールだけでは無理だということです。だからこそ、多言語コンテンツのコストは決して「翻訳費」ではなく、継続的な保守にかかる人的コスト。

です。ですから実用的な提案はこうです:「何言語できるか」ではなく、「何言語を長期的に保守できるか」を問うてください。答えは通常、予想より少ないものです。しかしそれこそが、本当に問い合わせを生む言語なのです。

崔立姝
崔立姝 クレーター専門家

デリバリー・オペレーション責任者 · クレーター デリバリー&オペレーションチーム

クレーター(Crater)デリバリー&オペレーション責任者。SEOの実装実行、ソーシャルメディアチャネルの運営とコンテンツ配信を担当し、データを用いて成長施策を分解するのが得意。複数の海外展開プロジェクトのデリバリーを手がけ、Facebook、Twitter、TikTok、YouTubeとSEO/GEOの連携戦略に注力している。

SEO実装コンテンツ運営事例解説
1106件のシェア
84件のナレッジベース