独立型サイトの多言語プラグイン:WPML/Polylang/TranslatePressを比較
一、まず考えを整理する:本当に必要な言語はいくつか
選定の前に一つの問いに答えてください。今、本当にそんなに多くの言語が必要ですか?多くのチームはいきなり英語、ドイツ語、フランス語、スペイン語、アラビア語、ロシア語の6バージョンを作ろうとしますが、結果として各バージョンのコンテンツは数十記事しかなく、翻訳品質もばらつきます。正しい順序は、まず英語サイトを徹底的に作り込んで問い合わせを生み出し、実際の問い合わせ元に応じて2つ目の言語を決めることです。この点は海外市場の優先順位でより詳しい市場の優先順位を説明しています。
ここでの直感に反する判断はこうです。言語は多ければ多いほど良いわけではありません。言語が1つ増えるたびに、継続的に更新が必要なコンテンツ保守のラインが1本増えます。3言語なら、ブログを1本書けば3本翻訳し、製品パラメータを1つ変えれば3か所を同期する必要があり、1か所でも漏れるとリンク切れや誤訳になります。コンテンツの生産能力が限られているなら、2〜3言語のほうが6言語より成果が出ることがよくあります。
| 言語数 | コンテンツ保守の負荷 | 推奨プラグインの方向性 | 年間コストの目安 |
|---|---|---|---|
| 英語のみ | なし | 多言語プラグインは不要 | 0 |
| 2〜3言語 | 低い。1人で保守可能 | Polylang無料版から | 0〜100ドル |
| 4〜5言語 | 中程度。翻訳フローが必要 | Polylang ProまたはWPML | 100〜200ドル |
| 6言語以上 | 高い。翻訳チームが必要 | WPMLエンタープライズ版 | 300ドル以上 |
2. 3プラグインの項目別比較
3つのプラグインは設計思想がまったく異なります。WPMLは「全機能の商用プラグイン」路線で、WooCommerceや各種ページビルダー、SEOプラグインとの互換性が最大の売りです。代わりに毎年のサブスクリプションが必要で、システムはやや重くなります。Polylangは「軽量だが自分でつなぐ必要がある」路線で、コアは無料、Pro版でURLのカスタマイズと翻訳管理が提供され、テーマ側で互換性を自分で整える必要があります。TranslatePressは「見たまま編集」路線で、フロントエンドのページ上で文をクリックしてその場で翻訳でき、機械翻訳の連携が最もスムーズですが、コンテンツ量が増えるとパフォーマンスが低下します。
SEO の面では3つとも hreflang を自動出力できますが、どれも一度は自分で確認が必要です。hreflang の書き間違いは多言語サイトで最もよくある事故です。詳しくはHreflang多言語対応の自己参照、戻りリンク、x-default の3つの必須チェック項目をご覧ください。
| 比較の軸 | WPML | Polylang | TranslatePress |
|---|---|---|---|
| ライセンス方式 | 年額サブスク、サイト数ごと | 無料版 + Pro 買い切り | 無料版 + Pro 買い切り |
| 翻訳インターフェース | 管理画面の一覧形式で文字列翻訳 | 管理画面で記事ごとに翻訳 | フロントエンドで視覚的にクリック選択 |
| 機械翻訳 | 有料連携 | 別途プラグインが必要 | 標準搭載、ワンクリックでインポート |
| プラグイン互換性 | 最も充実、公式の後押しも多い | テーマが対応しているか次第 | 普通、特殊なプラグインは競合しやすい |
| パフォーマンス負荷 | 普通よりやや重い | 最も軽い | コンテンツが多いと遅くなる |
| 向いている規模 | 5言語以上の大規模サイト | 2〜4言語の小規模サイト | コンテンツ量が少ない素早い立ち上げサイト |
三、選び方：3ステップの判断フレームワーク
「どれが有名か」で選ばないでください。以下の3つの問いに順番に答えると、答えは自然に見えてきます。第一の問い：現在と1年以内に予定している言語数はいくつですか？第二の問い：使っているテーマとプラグイン（特にページビルダー、WooCommerce）は多いですか、雑多ですか？第三の問い：毎年サブスク費用を払って手間を減らすことに納得できますか？
ケース1：2人の小規模チーム、英語サイトが軌道に乗り、ドイツ語を追加したい。コンテンツは100件未満、テーマはシンプルな Astra か GeneratePress。Polylang 無料版をそのまま導入し、ドイツ語を2つ目の言語にして、URL は /de/ サブディレクトリを使います。この段階はコストゼロで、1年は十分持ちます。ケース2：貿易会社のサイト、6言語、Elementor と WooCommerce に加えて十数個のマーケティングプラグインを使用。このように互換性の負担が大きい組み合わせでは、WPML のサブスク費用をケチらないでください。Polylang でテーマを自力対応すると、終わりのない互換性の沼に引きずり込まれます。
| あなたの状況 | おすすめの選択 | 理由 |
|---|---|---|
| 2言語、テーマはシンプル、予算が厳しい | Polylang 無料版 | コストゼロ、性能は最も軽い |
| 3〜4言語、翻訳管理が必要 | Polylang Pro | 買い切り、URL カスタマイズ込み |
| 6言語、プラグインの山 | WPML | 互換性のトラブル対応時間を大幅に削減 |
| コンテンツが少なく、すぐ2言語目を出したい | TranslatePress | 機械翻訳のワンクリックインポートが最速 |
| すでにどれかを使っていて正常に動作している | 乗り換えない | 移行コストは差額よりはるかに大きい |
四、落とし穴回避：多言語公開でよくある5つの事故
最初の落とし穴は、多言語プラグインを2つ同時にインストールすることです。WPML と Polylang はデータモデルが互換性がなく、同時に有効化すると互いのテーブルを書き換えてしまい、問題が起きてもきれいに消せません。どちらを使うと決めたら、それだけをインストールしてください。2つ目の落とし穴は、機械翻訳をそのまま公開して審査しないことです。TranslatePress のワンクリックインポートは便利ですが、技術パラメータ、製品型番、約束事の表現は必ず人が一度目を通す必要があります。翻訳後の編集方法はこちらをご覧ください翻訳後編集（MTPE）。
3つ目の落とし穴は、URL構造を決め切らないまま公開してしまうことです。多言語化にはサブディレクトリ（/de/）、サブドメイン（de.example.com）、独自ドメインの3方式があり、選んだ後に変更するとURL構造の変更になるため301リダイレクトをやり直す必要があります。4つ目の落とし穴はhreflangの相互リンク漏れで、Googleがこれらのページを同一内容の別言語版だと認識できません。5つ目の落とし穴はグラフやSVG内のテキストが未翻訳のままで、読み上げても英語のままになることです。こうした埋め込みコンテンツの扱いは多言語サイトのグラフ処理をご覧ください。公開前の5つのチェックポイントは多言語コンテンツ公開フロー。
| よくある事故 | 結果 | 予防アクション |
|---|---|---|
| 多言語プラグインを2つ同時に導入 | データテーブルが壊れて復旧が困難 | 1つだけ残し、バックアップしてから切り替える |
| 機械翻訳をそのまま公開して未確認 | 用語ミスで顧客からクレーム | 技術系の内容は必ず人が確認する |
| 公開後にURL構造を変更 | 全URLが無効になり301をやり直し | 公開前にサブディレクトリかサブドメインを確定 |
| hreflangの相互リンク漏れ | Googleが多言語グループを無視 | 各言語ページを相互にリンクする |
| グラフ内のテキストが未翻訳 | ドイツ語ページに英語のグラフが混在 | 翻訳可能なSVGを使うか画像を別途作成 |
FAQ よくある質問
WPMLはPolylangよりずっと高いですが、価値はありますか？
TranslatePressの機械翻訳をそのまま使っても大丈夫ですか？
サブディレクトリ、サブドメイン、独自ドメインのうち、URL構造はどれを選ぶべきですか？
今使っているプラグインが良くないのですが、途中で別のものに乗り換えられますか？
多言語プラグインはサイトを遅くしますか？
3言語で足りますか？フランス語やスペイン語も追加すべきですか？
最後に
多言語プラグイン選びの本質は「機能が多いか」ではなく「あなたのチームが長く保守できるか」です。WPMLは手間の少なさと互換性を買うもの、Polylangは購読費を抑える代わりにテーマへの組み込みが自分持ち、TranslatePressは公開の速さを取るものです。正解はなく、合うかどうかだけです。言語が少なくプラグイン構成がシンプルなら軽いもの、言語が多く技術スタックが複雑なら安定したものを選びましょう。
実行は3ステップ。第一に、言語数とプラグインの複雑さを判断表に照らして1つだけ選び、それだけを導入する。第二に、公開前にURL構造を確定し、hreflangの相互リンクを設定し、機械翻訳は下書きとして人がレビューする。第三に、半年ごとに問い合わせ元を見て言語を追加するか決める。多言語化をきちんとやってこそ、ドイツ語・スペイン語・アラビア語の市場でAIに見つけてもらえます。詳しくは多言語 GEO。
覚えておきたい一言。多言語プラグインは機能が最も多いものを選ぶのではなく、半年後も保守を続けたいものを選ぶのです。選び間違えの代償は価格差ではなく、やり直しです。