多言語SEO｜hreflangの実装ミスと機械翻訳の品質基準

自社サイトを英語圏・中国語圏など複数の言語で展開するとき、「hreflangタグさえ入れれば多言語対応は完了」「翻訳リソースがないので自動翻訳ツールで全ページを機械翻訳すれば十分」と考えてしまうことがあります。しかし、hreflangは実装を1か所でも間違えるとタグ自体が無視されますし、機械翻訳もGoogleのスパムポリシーとの兼ね合いで注意が必要な条件があります。

Google検索セントラルのローカライズ版に関するガイドや多地域・多言語サイトの管理ガイド、スパムに関するポリシーの一次情報をもとに、hreflangの正しい設定、URL構造の選び方、機械翻訳を使う際の品質基準を整理します。

01.多言語対応SEOとは何を指すか

多言語対応SEOとは、同じサイト・同じコンテンツを複数の言語で提供する際に、各言語版を検索エンジンとユーザーの双方に正しく認識させるための一連の技術的な対応を指します。具体的には次の3つが柱になります。

• hreflangによる言語・地域の対応関係の明示
• URL構造（サブディレクトリ・サブドメイン・ccTLD）の設計
• 翻訳コンテンツの品質担保

なお、「gTLDと.io・.aiのようなccTLDのどちらを取得すべきか」というドメイン選び自体の論点は、以下の記事でGoogleの一次情報をもとに整理しています。本記事はドメインを既に決めた前提で、多言語展開時のhreflang実装・URL構造・翻訳品質に絞って扱います。

02.hreflangの役割と基本の書き方

hreflangは、同じ内容を異なる言語・地域向けに用意しているページ同士の対応関係をGoogleに伝えるためのアノテーションです。Google検索セントラルはローカライズ版に関するガイドで、こうした対応関係を伝えることで「Googleがユーザーを言語・地域に応じて最も適切なページへ案内できるようになる」と説明しています。

実装方法は3種類あり、Googleはどれを使っても評価上の差はないとしています。ローカライズ版に関するガイドでは「3つの方法はGoogleから見て同等であり、サイトにとって最も都合の良い方法を選んでよい。3つを同時に使うこともできるが、Search上のメリットはなく、むしろ1つに絞るより管理が難しくなりかねない」としています。

• HTMLのlinkタグ：サイトマップやHTTPヘッダーを使えない場合に有効
• HTTPヘッダー：PDFなどHTML以外のファイルに有効
• サイトマップ：対応関係を1か所にまとめて管理できる

必ず守るべき原則が2つあります。1つは自己参照で、各言語版は自分自身を含めた全言語版を列挙する必要があります。もう1つは相互参照（return link）で、2ページが互いを指し合っていない場合、そのタグ自体が無視されます。第三者が勝手に自サイトの言語版を名乗ることを防ぐための仕組みです。

03.hreflangの実装でよくある間違い

Google検索セントラルは、hreflangが正しく機能しない典型的な原因として次の3つを挙げています。いずれも「タグを書いたのに反映されない」という相談の大半を占める間違いです。

特に相互参照の漏れは、CMSでページを追加・削除した際に他言語版側の更新を忘れることで起きがちです。多言語ページが増えるほど手作業での管理は破綻しやすいため、サイトマップでの一元管理か、CMS側でhreflangを自動生成する仕組みを早い段階で用意しておくと事故を防げます。

04.URL構造の選び方：サブディレクトリ・サブドメイン・ccTLD

多言語版のURLをどう構成するかについて、Googleの多地域・多言語サイトの管理ガイドは4つの方式を挙げ、それぞれの強み・弱みを整理しています。

多地域・多言語サイトの管理ガイドによれば、URLパラメータ方式（example.com?loc=deのような形）はGoogleが明確に非推奨としています。それ以外の3方式に優劣はなく、取得・運用コストと、どこまで強い地域ターゲティングが必要かで選ぶのが実務的です。単一言語圏の会社サイトを国別に明確に分けたいならccTLD、複数言語をコストを抑えて運用したいならサブディレクトリ、というのが典型的な判断軸になります。

もう1つの判断軸がクロールバジェットです。Google検索セントラルのクロールバジェットの管理ガイドは「サイトはホスト名によって定義されます。たとえば、https://www.example.com/とhttps://code.example.com/は別々のホスト名であるため、クロールバジェットも別々になります」と説明しています。つまりクロールバジェットが分かれるかどうかは「ホスト名が違うかどうか」で決まり、サブドメインとccTLDはどちらも別ホスト名なので、この観点では同じ扱いになります。サブディレクトリだけが1つのホスト名の中でクロールバジェットを分け合う形です。

3言語（日本語・英語・ドイツ語）で運用する場合の実例で並べると、次のようになります（クロールバジェットの根拠は同じクロールバジェットの管理ガイドの「ホスト名が別なら別予算」という説明です）。

つまりexample.de／example.jpのようにccTLDで分ける構成も、サブドメインと同じ理由（別ホスト名になる）でクロールバジェットの分離という点では有効です。ccTLDとサブドメインの違いは、クロールバジェットではなく地域ターゲティングの強さと取得・運用コストの方にあります（前掲の比較表を参照）。

クロールバジェットが実際に問題になるのは、以下の記事で整理している「100万URL級の大規模サイト」や「毎日大量更新するサイト」など一部の大規模サイトに限られます。そうした規模で、かつ既に自サイトのクロールバジェットが不足気味だと分かっている場合は、サブドメインまたはccTLDでホスト名を分けて言語版ごとにクロールバジェットを分離するのが理にかなった選択です。逆に、それ以外の大多数のサイトにとってはクロールバジェットは決め手にならず、判断軸は運用コストと地域ターゲティングの強さのままで問題ありません。

05.機械翻訳・自動翻訳とSEOへの影響

翻訳リソースが限られる中で、機械翻訳・自動翻訳ツールを使って多言語ページを量産したくなる場面は多いはずです。ここで押さえておくべきは、「機械翻訳を使うこと自体」はGoogleのポリシー違反ではないという点です。問題になるのは、翻訳の手段ではなく出来上がったページがユーザーに価値を提供しているかどうかです。

つまり実務上の線引きは、翻訳結果を人がレビューし、必要に応じて文化的な文脈や表現を調整した上で公開しているか、それとも未レビューのまま自動生成しただけのページを大量に公開しているか、という点にあります。多言語展開の初期段階で全ページを機械翻訳する場合でも、主要な流入ページ・コンバージョンに直結するページから優先的に人的レビューを入れる運用が現実的な落とし所です。

表現の「不自然さ」はSEOにどう影響するか

「機械翻訳を人がレビューすれば量産ページの問題はクリアできる」としても、レビューの中身が誤訳の修正だけで、訳文の不自然さ（語順の直訳調、慣用表現の逐語訳、文脈に合わない訳語選択など）まで手を入れていないケースは少なくありません。ここで押さえておきたいのは、Googleが「翻訳の自然さ」という専用の評価基準を公表しているわけではないという点です。ただし、既存の2つの品質評価の枠組みが、結果的に不自然な訳文を拾う設計になっています。

• 役立つコンテンツの自己評価質問：Google検索セントラルの役立つコンテンツ作成ガイドは、自己評価すべき質問として「スペルや文体上の問題はないか」「コンテンツは丁寧に作られているか、それとも雑に急いで作られたように見えるか」を挙げています。不自然な訳文はまさにこの「文体上の問題」「雑に作られた印象」に直結します。
• キーワードの乱用（keyword stuffing）：Googleのスパムに関するポリシーは、同じ語句を繰り返しすぎて「不自然に聞こえる」文章をキーワードの乱用の例として明示しています。逐語訳で同じ用語・言い回しを機械的に繰り返す訳文は、この基準に抵触しうる書き方です。

具体的にどの程度の繰り返しが問題になるのか、英語の紹介文を機械翻訳した想定例で比較します。

いずれも「翻訳だから」ではなく、人が読んで不自然だと感じる文章全般を対象にした基準です。実務上は、誤訳の有無だけを確認する校正ではなく、その言語を母語とするレビュアーが「自然な文章として読めるか」まで見る工程を入れることが、翻訳品質を担保する上での実質的な基準になります。流入・コンバージョンに直結するページほど、この母語レビューを優先する価値があります。

06.多言語ページのcanonical・サイトマップ運用

多言語ページのcanonical（正規URL）は、各言語版が自分自身を正規URLとして指定するのが基本です。デフォルト言語版のURLに他言語版のcanonicalをまとめてしまうと、他言語版が正規URLとして扱われなくなり、検索結果にも出にくくなります。canonicalの基本的な考え方は以下の記事で整理しています。

hreflangをサイトマップで管理する場合、言語版ごとのURLを1つのサイトマップにまとめてxhtml:linkで相互参照を記述できるため、ページ数が多いサイトほどHTMLのlinkタグを1件ずつ管理するより事故が起きにくくなります。例えば英語版・日本語版の2言語を運用する場合、サイトマップの各<url>ブロックに次のように書きます。

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:xhtml="http://www.w3.org/1999/xhtml">
  <url>
    <loc>https://example.com/en/</loc>
    <xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/" />
    <xhtml:link rel="alternate" hreflang="ja" href="https://example.com/ja/" />
    <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/en/" />
  </url>
  <url>
    <loc>https://example.com/ja/</loc>
    <xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/" />
    <xhtml:link rel="alternate" hreflang="ja" href="https://example.com/ja/" />
    <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/en/" />
  </url>
</urlset>

ポイントは、どちらの<url>ブロックにも、自分自身を含めた全言語版（en・ja・x-default）を同じ内容で列挙することです。2章の自己参照・相互参照の原則を、サイトマップという1ファイルの中で満たす形になります。ページが増えたら、この<url>ブロックをURLの数だけ追加していきます。サイトマップ自体の基本的な役割・送信方法は以下の記事で整理しているため、ここでは多言語運用に特有の注意点だけに絞ります。

07.新規に多言語展開するときの進め方

既存の日本語サイトを多言語化する場合、次の順番で進めると手戻りが少なくなります。

• URL構造を先に決める：サブディレクトリ・サブドメイン・ccTLDのどれにするかは後から変更するとリダイレクト設計が必要になるため、翻訳作業に入る前に確定させる。
• 優先ページから人的レビュー付きで翻訳する：トップページ・主要な商品/サービスページ・問い合わせ導線など、流入とコンバージョンに直結するページを先に人手でレビューする。
• hreflangを自己参照・相互参照で実装する：ページ数が多い場合はサイトマップでの一元管理を検討する。
• canonicalを言語版ごとの自己参照にする：デフォルト言語への集約はしない。

08.よくある質問（FAQ）

09.まとめ

多言語対応SEOの土台は、hreflangの自己参照・相互参照を正しく実装すること、URL構造をサブディレクトリ・サブドメイン・ccTLDのトレードオフを踏まえて決めること、そして機械翻訳を使う場合でも人的レビューを伴わない量産ページを避けることの3点です。いずれもGoogleが一次情報で条件を明示しているため、実装前にガイドの原文を確認しながら進めると手戻りを防げます。