REEID EDITORIAL

多言語WordPressがSEOプラグインとどのように連携するか

多言語WordPressサイトでは、主な技術的な問いはSEOプラグインが役立つかどうかではなく、どのシステムが各検索シグナルを管理するかです。タイトル、説明文、カノニカル、スキーマ、XMLサイトマップ、robotsディレクティブ、言語関係のすべてに明確な正本が必要であり、そうすることで翻訳ページ同士が競合したり、検索エンジンに矛盾したシグナルを送ったりしないようにできます。

12 Sep 20261 min read

要点

多言語アーキテクチャとSEOプラグインは別々の層として扱ってください。多言語層は言語バージョンとその関係を定義し、SEO層はそれらの関係を上書きしたりシグナルを重複させたりせずに、ページ単位のメタデータを出力するべきです。

多言語アーキテクチャの役割が終わり、SEOプラグインの役割が始まる場所

多言語WordPressの構成では、通常、同時に2つの異なる問題を解決する必要があります。第一に、1つのページが複数の言語で存在することを表現しなければなりません。第二に、その各バージョンについて検索エンジン向けのメタデータを公開しなければなりません。これらは関連していますが、同じ責任ではありません。

多言語層は、言語バージョン同士を結び付ける場所です。SEOプラグイン層は、タイトル、説明文、カノニカル、スキーマ、XMLサイトマップ、robotsディレクティブのようなページ単位のシグナルを出力する場所です。両方の層が同じシグナルを管理しようとすると、重複、不一致、または誤った方向を指すシグナルが生じがちです。

タイトルと説明文には共有の既定値ではなく、言語ごとの制御が必要

ページタイトルとメタ説明文は、通常、言語バージョンごとに翻訳されるべきです。これらは検索結果のスニペットの一部であり、コンテンツの言語と一致している必要があるからです。技術的な問題は翻訳そのものではなく、管理の所在です。多言語システムが翻訳済みコンテンツを保存し、SEOプラグインがスニペット欄を保存する場合、両方のシステムが正しい値を予測可能な方法で読み書きできる必要があります。

よくある失敗は、SEOフィールドが一度コピーされたまま更新されず、翻訳ページが元の言語のタイトルや説明文を継承してしまうことです。逆の失敗もあります。SEOプラグインが翻訳コンテンツから代替タイトルを生成する一方で、多言語層はそのページを別の言語バージョンと結び付いたものとして扱い続けるケースです。どちらの場合も、ページは技術的には到達可能でも、検索とユーザーにとって意味的に不整合になります。

カノニカルは各言語バージョンの優先URLを反映すべき

カノニカルタグは、管理の衝突がすぐに表面化する箇所です。多言語サイトでは通常、各言語バージョンをそれぞれのURLでインデックス可能にしつつ、他のバージョンとの関係も示す必要があります。つまり、翻訳ページのカノニカルは、アーキテクチャが意図的に統合していない限り、元の言語ページではなく、そのページ自身の優先URLを指すべきです。

SEOプラグインと多言語システムの両方がカノニカルを設定しようとすると、問題はHTML内の重複だけではありません。より深刻なのは、その言語における正規のURLがどれかについて意見が食い違うことです。すると検索エンジンには混在したシグナルが送られます。あるシステムは翻訳ページがカノニカルだと言い、別のシステムは元ページを優先すべきだと示唆します。その実際の結果として、インデックスの不安定化や、特定の言語で誤ったページが表示されることがあります。

スキーマはページを説明し、言語関係はサイト構造を説明する

構造化データと言語関係は、異なる問題を解決します。スキーマはページの内容と文脈を説明します。言語関係は、言語をまたいだ同等または関連ページがどのようにつながっているかを説明します。これらを混同すると、技術的には正しいが誤った言語バージョンに付与されたスキーマや、構造化データで表されるページの同一性と一致しない言語リンクが生じる可能性があります。

実装者にとって有用な問いは、どの層がスキーマを生成し、どの層が言語グラフを把握しているかです。多言語システムがどのページ同士が翻訳関係にあるかを知っているなら、その関係の正本はそのシステムであるべきです。SEOプラグインがページ内容からスキーマを生成するなら、翻訳ページが互換可能な複製であると仮定せず、言語バージョンごとに生成するべきです。

XMLサイトマップとrobotsディレクティブはインデックス判断を重複させるべきではない

XMLサイトマップとrobotsディレクティブはどちらもインデックス制御ですが、役割は異なります。サイトマップは、検索エンジンに何が存在し、発見対象として意図されているかを伝えます。robotsディレクティブは、ページをどのように扱うべきかを伝えます。多言語構成では、翻訳ページが必要なときに発見可能で、不要なときに除外されるよう、両方が言語アーキテクチャと整合していなければなりません。

主な実装上のトレードオフは、多言語層とSEOプラグインのどちらが言語バリアントのサイトマップ項目を生成するかです。両方が行うと、重複URLや一貫しない含有ルールが発生する可能性があります。一方のシステムがページを除外し、もう一方が含める場合、その言語バージョンをインデックス対象にする意図があるのかについて、サイトは矛盾したシグナルを送ります。

最も安全なパターンは、各SEOシグナルに単一の管理者を割り当てること

最も明快な実装は、各シグナルの管理者を1つのシステムに割り当て、もう一方のシステムにはその決定を認識させることです。多言語層は言語の識別と関係を管理すべきです。SEOプラグインは各ページバージョンのメタデータ表示を管理すべきですが、それは多言語アーキテクチャが定めた境界内に限られます。

この分担により、翻訳ページが誤ったメタデータを継承したり、矛盾するカノニカルを出力したり、誤ったサイトマップ状態で表示されたりする可能性が減ります。また、デバッグも容易になります。シグナルが誤っているとき、どちらの層を最初に確認すべきかが明確になり、同じ出力に責任があると両者が考えている2つのシステムを追いかけ回す必要がなくなります。

SEOシグナル推奨される管理者理由
タイトルSEO層、言語バージョンごと翻訳コンテンツに一致するページ単位の出力が必要
説明文SEO層、言語バージョンごと各バージョンの言語と意図を反映すべき
カノニカルSEO出力を伴うアーキテクチャ認識層各言語バージョンの優先URLと一致していなければならない
スキーマ言語コンテキストを考慮したSEO層ページを説明し、バージョンごとに出力されるべき
XMLサイトマップ1つのシステムのみサイトマップ管理の重複は不整合な含有を生む可能性がある
robotsディレクティブ1つのシステムのみ矛盾するディレクティブはインデックス判断を損なう可能性がある
言語関係多言語アーキテクチャ層翻訳ページ同士がどのようにつながるかを定義する

重要

よくある質問

翻訳された各ページには、それぞれ独自のタイトルと説明文が必要ですか?

はい、そのページがその言語で個別に順位付けされ、表示されることを意図しているなら必要です。元の言語のスニペット欄を再利用すると、ページは技術的には翻訳されていても、検索結果では意味的にずれたままになる可能性があります。

SEOプラグインだけで多言語カノニカルを管理できますか?

多言語アーキテクチャがすでに正しい言語関係とURL構造を定義している場合に限ります。カノニカルは単なる書式設定ではありません。各言語の優先バージョンがどのURLかを把握していることに依存します。

多言語サイトでサイトマップの問題が頻繁に起こるのはなぜですか?

サイトマップ生成は重複しやすいからです。多言語層とSEO層の両方が言語バリアントを列挙しようとすると、どのURLがインデックス対象セットに属するかで意見が食い違う可能性があります。

衝突を避けるための主なルールは何ですか?

各シグナルに1つの管理者を与えてください。言語関係は多言語アーキテクチャに属し、ページ単位のSEO出力はSEO層に属します。その間には明確な境界が必要です。

アーキテクチャを実運用に移す

WordPressの統合が多言語システムでどのように動作するかを見る

REEID Integration Directoryで、プラグイン固有の互換性、翻訳対象領域、実装メモを確認してください。

Shopping Cart
Scroll to Top