技術・仕様　／　更新：2026年8月19日

WordPressの多言語化｜4つの方法と規模別の選び方

定番プラグインが使えなくなり、選択肢が変わりました。規模ごとの現実的な方法を整理します。

WordPress を多言語対応にする方法は複数あります。 以前は定番のプラグインを入れれば済みましたが、 開発終了や有料化で選択肢が減り、状況が変わりました。

ここでは現実的な4つの方法を比較し、規模と更新頻度からどれを選ぶべきかを整理します。

4つの方法

小規模なら「別インストール」が最も確実

5〜10ページ程度で、更新もほとんどないサイトなら、 言語ごとに WordPress を別々にインストールするのが最善です。

一見すると手間が増えるように見えますが、更新頻度が低ければ、その手間はほとんど発生しません。 年に数回しか触らないサイトのために、複雑な仕組みを入れて保守性を下げるほうが損になります。

設置は example.com と example.com/en/ のように サブディレクトリで分けるのが扱いやすく、ドメインの評価も分散しません。

中規模なら「マルチサイト」

WordPress には、1つのインストールで複数のサイトを管理するマルチサイトという標準機能があります。

「日本語版と英語版で載せる内容が違う」場合に向いています。 海外向けには製品情報を厚くし、国内向けには採用情報を載せる、といった作り分けが自然にできます。

逆に、全ページを1対1で対訳させたい場合は、 マルチサイトだと対応関係を人が管理することになり、抜け漏れが起きやすくなります。

大規模なら「カスタムフィールド」

ページ数が多く、日本語と外国語が1対1で対応しているサイトでは、 1つの記事の中に言語ごとの入力欄を持たせる方法が有効です。

翻訳漏れが起きないことが最大の利点です。 別インストールやマルチサイトでは「日本語版だけ更新して英語版が古いまま」という状態が起きますが、 同じ編集画面に両方の入力欄があれば、更新時に気づけます。

ページ数が多いサイトほど、この差が効いてきます。 50ページを超えるあたりから、他の方法では管理しきれなくなります。

プラグインを使う場合の注意

手軽ですが、依存先が1つ増えることを理解したうえで選んでください。

• 提供が止まるリスク：開発終了・有料化は実際に起きています
• 移行が難しい：独自のデータ構造で保存するため、他の方法へ移しにくい
• 本体更新への追従：WordPress の更新にプラグインが対応するまで待つことがある
• 費用が継続する：有料プラグインは年額が発生します

短期間で公開したい、予算が限られている、といった事情があれば選択肢に入りますが、 10年運用する前提のコーポレートサイトには向きません。

選び方のまとめ

判断の軸は「ページ数」と「更新頻度」の2つです。 多言語化というと難しく考えがちですが、 小規模で更新が少ないなら、素直に別々に作るのが最も確実で安く済みます。

どの方法でも決めておくこと

• 誰が翻訳するか：社内か、翻訳会社か。機械翻訳を下訳に使うか
• 更新時の運用：日本語を更新したとき、外国語版をいつ直すか
• 問い合わせ対応：外国語で問い合わせが来たとき、誰が返すか
• URL構成：サブディレクトリか、サブドメインか、別ドメインか

意外に見落とされるのが3つ目です。 英語サイトを作れば英語で問い合わせが来ます。 返信できる体制がないまま公開すると、対応できない問い合わせが溜まることになります。

よくある質問

多言語化プラグインを入れれば済みませんか？

以前は定番のプラグインがありましたが、開発終了や有料化で選択肢が減っています。プラグインに依存すると、提供が止まったときにサイト全体が動かなくなります。長く運用する前提なら、依存しない方法を検討してください。

小規模なサイトはどうすればいいですか？

5〜10ページ程度で更新も少ないなら、言語ごとに WordPress を別々にインストールして独立したサイトとして運用するのが最も確実です。仕組みが単純で、片方が壊れてももう片方に影響しません。

自動翻訳で対応できませんか？

機械翻訳をそのまま出すのは避けてください。BtoBでは訳の不自然さが信用に直結します。下訳として使い、人が確認する運用にしてください。

URLはどう分ければいいですか？

サブディレクトリ（example.com/en/）が扱いやすく、ドメインの評価も分散しません。サブドメインや別ドメインでも可能ですが、それぞれSEO上は別サイトとして扱われます。