WordPress 7.0 ブロックエディターで多言語プラグイン Bogo 有効時に REST API 500 エラーが出る原因と対処
WordPress の多言語プラグイン Bogo を有効化した状態でブロックエディターを開くと、カテゴリーなどのタクソノミーパネルが空になり、REST API が 500 Internal Server Error を返す症状は、Bogo が REST API に付与する lang パラメータと WordPress 7.0 のブロックエディター側のリクエスト処理が競合していることが主な原因だ。
なぜ Bogo とブロックエディターの組み合わせで REST API が 500 エラーを返すのか
この問題の核心は、ブロックエディターが内部で使用する REST API エンドポイントに対するリクエストにある。ブロックエディターは編集画面を表示する際、/wp-json/wp/v2/taxonomies や /wp-json/wp/v2/users/〜 といった複数のエンドポイントに同時にリクエストを送信し、カテゴリー一覧や投稿者情報を取得している。
Bogo は多言語対応のために、これらの REST API リクエストに対して自動的に lang クエリパラメータを付与する。たとえば ?lang=en や ?lang=ja といった具合だ。このパラメータ追加の処理が、ブロックエディターの特定の内部リクエストと組み合わさった際に、サーバー側で PHP の致命的エラーを引き起こしている。
データベースから要求された言語のデータを取得しようとするが、ブロックエディターのコンテキストでは想定外の引数が渡され、結果として WP_Query やタクソノミー取得関数が WP_Error オブジェクトを返す。これが REST API のレスポンス生成時に適切にハンドリングされず、500 エラーとして表面化する。
エラーの切り分けと原因特定の手順
まずは問題が本当に Bogo とブロックエディターの組み合わせに限定されているのかを確認する。以下のフローに沿ってテストを進めると、原因の特定がスムーズになる。
上記の最小構成でもエラーが再現する場合、Bogo とブロックエディターの直接的な競合と判断できる。なお、クラシックエディタープラグインをインストールして同じ操作を行った際に問題が発生しないことも、ブロックエディター固有の問題であることの強い証拠になる。
実用的な回避策と当面の対応
根本的な修正は Bogo プラグイン側のアップデートを待つ必要があるが、運用を止めずにしのぐ方法はいくつか存在する。状況に応じて以下を使い分ける。
クラシックエディターへの一時的な切り替え
最も確実で即効性のある回避策は、クラシックエディタープラグインをインストールして旧来の編集画面を使うことだ。クラシックエディターは REST API に依存したデータ取得を行わないため、Bogo の lang パラメータ付与が問題を引き起こす余地がない。
→ ブロックエディターの内部リクエストが lang パラメータと競合
→ REST API 非依存のため競合が発生しない
クラシックエディターは WordPress の公式プラグインディレクトリから無料でインストールできる。インストール後は「設定」→「投稿設定」からデフォルトのエディターを切り替えられる。
REST API への lang パラメータ付与をフィルターフックで制限する
Bogo は REST API リクエストに言語パラメータを付与する際、rest_dispatch_request や rest_pre_dispatch といったフィルターフックを経由している。子テーマの functions.php に以下のようなコードを追加することで、管理画面からのリクエストに対して言語パラメータの付与を抑制できる。
add_filter( 'rest_dispatch_request', function( $dispatch_result, $request, $route, $handler ) {
// 管理画面からの REST API リクエストの場合、Bogo の言語処理をスキップ
if ( is_admin() || ( defined( 'REST_REQUEST' ) && REST_REQUEST && strpos( $route, '/wp/v2/' ) === 0 ) ) {
remove_filter( 'rest_dispatch_request', 'bogo_rest_dispatch_request', 10 );
}
return $dispatch_result;
}, 5, 4 );このコードは、/wp/v2/ から始まる REST API ルート（ブロックエディターが使用する主要なエンドポイント）に対して、Bogo が持つ bogo_rest_dispatch_request フィルターを一時的に除去する。ただし、この方法は Bogo の内部実装に依存しているため、プラグインのバージョンアップによって動作が変わる可能性がある点に注意が必要だ。
プラグインのダウングレードまたはフォーク版の利用を検討する
Bogo 3.9.2 で問題が顕在化したのであれば、1つ前のバージョンである 3.9.1 にダウングレードすることで問題が回避できる可能性がある。ただし、ダウングレードはセキュリティ上のリスクを伴うため、あくまで開発者側の対応を待つ間の暫定策と位置づける。
代替の多言語プラグインへの移行を検討する
Bogo はシンプルな多言語化プラグインとして長く使われているが、ブロックエディターとの相性問題が続くようであれば、Polylang や WPML、TranslatePress といった代替プラグインへの移行も選択肢に入る。これらのプラグインはブロックエディターとの互換性テストがより積極的に行われており、多言語サイトの構築で実績も豊富だ。
デバッグモードで詳細なエラー情報を取得する
REST API の 500 エラーは、通常の PHP エラーとは異なり debug.log に記録されない場合がある。そのため、wp-config.php に以下の定数を追加して、より詳細なエラー情報を取得する。
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'SAVEQUERIES', true );さらに、ブラウザの開発者ツールで「ネットワーク」タブを開き、500 エラーを返している REST API リクエストを特定する。該当するリクエストの「レスポンス」タブを確認すると、サーバーから返された HTML のエラーページや JSON エラーオブジェクトが表示される。WordPress 7.0 では「このサイトで重大なエラーが発生しました」というメッセージが返ってくることが多い。
どうしてもエラーの詳細が取得できない場合は、wp-config.php に以下のコードを追加し、REST API エラー専用のログファイルを作成する方法もある。
add_action( 'rest_api_init', function() {
set_error_handler( function( $errno, $errstr, $errfile, $errline ) {
$log = sprintf( '[%s] %s:%d %s', date( 'Y-m-d H:i:s' ), $errfile, $errline, $errstr );
file_put_contents( WP_CONTENT_DIR . '/rest-api-errors.log', $log . PHP_EOL, FILE_APPEND );
});
}, 1 );このコードは REST API の初期化時にカスタムエラーハンドラを登録し、発生したエラーをすべて wp-content/rest-api-errors.log に記録する。問題が解決したら必ず削除すること。
よくある質問
Bogo の代わりに Polylang を使っても同様のエラーは出るか
Polylang は REST API との統合が設計段階から考慮されており、ブロックエディターとの組み合わせでも同様の 500 エラーが発生する可能性は極めて低い。実際に多くの多言語サイトで Polylang とブロックエディターの組み合わせが問題なく運用されている。移行を検討する価値は十分にある。
この問題は WordPress 7.0 以前のバージョンでも発生するのか
WordPress 6.x 系では報告が少なく、7.0 へのアップデート後に顕在化したケースが多い。ブロックエディターの内部実装が 7.0 で変更され、特定の REST API エンドポイントに対するリクエストのタイミングやパラメータの扱いが変わったことが影響していると考えられる。
クラシックエディターに切り替えた後、再びブロックエディターに戻せるのか
問題なく戻せる。クラシックエディターで作成した投稿は、ブロックエディターに戻した際に自動的にクラシックブロックとして読み込まれる。Bogo プラグイン側のアップデートで問題が修正されたら、クラシックエディタープラグインを無効化してブロックエディターに戻せばよい。
REST API のエラーはフロントエンドの表示にも影響するのか
今回の問題は管理画面のブロックエディター内に限定されており、公開済みサイトのフロントエンド表示には影響しない。カテゴリー一覧や投稿一覧の表示、多言語切り替え機能は通常どおり動作する。ただし、ブロックエディターでカテゴリーを選択・編集できないため、投稿の作成や編集作業に支障が出る。
functions.php にフィルターフックを追加する方法がわからない場合はどうすればよいか
最も安全な方法は、FTP クライアントまたはレンタルサーバーのファイルマネージャーを使い、子テーマの functions.php ファイルを編集することだ。操作に不安がある場合は、Code Snippets プラグインを利用して管理画面からコードを追加する方法もある。誤ったコードの追加はサイト全体に影響するため、必ず事前にバックアップを取得してから作業すること。
この記事のポイント
- Bogo 有効時にブロックエディターのカテゴリーパネルが空になるのは、REST API への lang パラメータ付与が競合を起こすため
- クラシックエディターに一時的に切り替えることで、即座に問題を回避できる
- functions.php にフィルターフックを追加し、管理画面からの REST API リクエストに対して Bogo の言語処理を抑制する方法もある
- 根本解決には Bogo プラグイン側のアップデートが必要で、状況によっては代替プラグインへの移行も検討する
- REST API の 500 エラーは debug.log に記録されないことがあるため、専用のエラーログ取得を設定すると原因特定が早まる
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WordPress多言語プラグインを徹底比較〜TranslatePress・WPML・Universallyの最適解
WordPressサイトを多言語化することは、リーチの拡大やSEOトラフィックの増加、売上向上に直結する施策だ。だが、数ある翻訳プラグインの中からどれを選ぶべきか判断するのは容易ではない。TranslatePressとWPMLは長年の実績を持つ定番であり、Universallyはよりモダンな手法で翻訳を自動化する新興の選択肢だ。
この記事では、WP Beginnerのテストと分析に基づき、セットアップの容易さ、翻訳品質、多言語SEO、パフォーマンス、WooCommerce対応、サポート、価格の7つの観点から3つのプラグインを比較する。自社サイトに最適な翻訳プラグインを選ぶための判断材料を提供する。
結論から言えば、Universallyは最も簡単なセットアップとクラウドによる高速パフォーマンス、圧倒的な導入コストの低さが魅力だ。TranslatePressは直感的なビジュアル編集を求めるユーザーに適しており、WPMLは特に複雑なWooCommerceストア運用で真価を発揮する。
セットアップの容易さ
サイトを多言語化するプロセスは、可能な限り手間がかからないのが理想だ。TranslatePressとUniversallyは、10分以内に別言語版を公開できる。一方、WPMLは相応の設定作業が必要で、作業に入る前にその工数を理解しておく価値がある。
TranslatePressのセットアップ
TranslatePressの導入はWPMLよりシンプルだ。WordPress.orgからプラグインをインストールし、設定画面で言語を選択すると、APIキーなしで即座にフロントエンドの翻訳エディターが利用可能になる。管理バーの「サイトを翻訳」をクリックし、ライブページ上のテキスト要素を直接クリックして翻訳するだけだ。バックエンドのスプレッドシートや別ダッシュボードは一切存在しない。
注意点として、訪問者のブラウザ言語を自動検出して切り替えを促す機能は、Businessプラン（年間199ユーロ）のみの提供だ。Personalプランでは言語スイッチャーを設置できるが、訪問者自身が手動で言語を選択する必要がある。
WPMLのセットアップ
WPMLは、3つのプラグインの中で最も多くの初期設定を要求する。Multilingual CMSプランでは、最低でも2つのプラグインコンポーネント（WPML本体とString Translation）のインストールが必要だ。各コンポーネントに独自のセットアップウィザードがあり、翻訳は自動では開始されない。ページごとに手動でトリガーするか、「すべてを翻訳」モードを有効にして自動翻訳のクレジット消費を設定する。
WP Beginnerのテストによれば、シンプルなサイトの翻訳設定だけでも1時間近くかかったという。複雑なテーマやカスタム投稿タイプを使用する大規模サイトでは、さらに多くの時間を見込む必要がある。この複雑さには理由があり、WPMLはTranslatePressやUniversallyでは提供されないきめ細かな制御を可能にする。ただし、そのレベルの制御が不要であれば、オーバーヘッドに見合わない。
Universallyのセットアップ
Universallyは、その手軽さが際立つ。プラグインをインストールし、専用ダッシュボードからAPIキーを貼り付け、対象言語を選ぶだけだ。この3ステップで作業は完了する。言語スイッチャーが自動でサイトに表示され、ショートコードの設置やテンプレート編集、ページごとの翻訳トリガーは一切不要だ。
言語検出、SEO設定、スイッチャーの配置まですべてが自動化されており、大半のサイトは10分足らずで多言語化が完了する。WP Beginnerの著者も、その要求の少なさに驚いたと述べている。
セットアップの容易さでは、Universallyが最速であり、TranslatePressがそれに次ぐ。WPMLの複雑さは、提供する詳細な制御が本当に必要な場合にのみ正当化される。
翻訳品質
機械翻訳の品質は近年大幅に向上しており、3つのツールはいずれも多くの言語ペアで読みやすい翻訳を生成する。差が出るのは、誤りの修正方法と、最終結果に対する編集権限の大きさだ。
TranslatePressの翻訳品質
TranslatePressは、大規模言語モデルとニューラル機械翻訳エンジンを組み合わせ、言語ペアとコンテンツタイプごとに最適な手法を自動選択する。有料プランではTranslatePress AIが利用でき、プランごとに単語数の上限が設定されている。高精度のDeepL連携はBusinessプラン以上で利用可能だ。
TranslatePressの最大の強みは、全プランで利用できるフロントエンドのビジュアルエディターだ。ライブページ上のテキストをクリックするとサイドバーに翻訳が表示され、その場で修正できる。変更はリアルタイムでページに反映される。翻訳メモリ機能も全プランに含まれており、95%以上一致する既存の翻訳を新しい文字列に自動適用する。
WPMLの翻訳品質
WPMLは根本的に異なるアプローチを取る。デフォルトは手動翻訳であり、すべての文字列をユーザーが制御する。機械翻訳は有料アドオンで、DeepLやGoogle Translate、Microsoft Azure Translatorを利用できる。クレジットはCMSプランとAgencyプランに含まれており、ワークフローはAIによる翻訳結果をそのまま公開するのではなく、人間によるレビューを前提に設計されている。
高度な翻訳エディターは、プロの翻訳者向けにサイドバイサイドの編集画面を提供し、翻訳メモリと公開前の品質チェック用レビュアー権限も備える。法律文書や医療情報など、誤訳が重大な結果を招くコンテンツでは、この手動優先の設計が力を発揮する。
Universallyの翻訳品質
Universallyは、汎用の言語モデルではなくWebコンテンツ向けに特化してトレーニングされたカスタムAIモデルを使用する。この専門化により、単語単位の置き換えではなくブランドの声や文脈を維持した翻訳を実現する。同社の報告では、ほとんどの言語ペアで90〜95%の精度を達成している。
用語集機能（全有料プランで利用可能）では、ブランド名や製品名、特定のフレーズの訳し方を固定でき、そのルールがサイト全体に自動適用される。現時点では専用の編集ツール（ダッシュボードテキストエディターやライブビジュアルエディター）はロードマップ上の計画段階であり、まだ提供されていない。
翻訳品質では、UniversallyとTranslatePressがそれぞれ異なる理由で優れている。AI翻訳をそのまま公開し、ほとんど手を加えたくないならUniversallyが適している。一方、手動で細かく編集したい場合は、クリックして修正できるTranslatePressのビジュアルエディターが実務上の大きなアドバンテージとなる。WPMLはプロの翻訳パイプラインとミッションクリティカルなコンテンツ向けという別の領域にある。
多言語SEO
多言語での公開は、検索エンジンがそれらのページを正しく検出し、インデックスして初めて効果を発揮する。3つのツールはいずれも技術的なSEOの基本をカバーするが、何が自動で含まれ、何が上位プランに制限されているかには意味のある違いがある。
TranslatePressの多言語SEO
SEO Packアドオンはすべての有料プランに含まれ、hreflangタグや多言語XMLサイトマップ、翻訳されたメタタイトルとディスクリプション、画像のaltテキスト、Open Graphメタデータ、翻訳URLスラッグを処理する。URLスラッグの翻訳は全有料プランで利用可能であり、同じ機能に別途課金する競合ツールと比較してコストパフォーマンスに優れる。また、Yoast SEOやRank Math、AIOSEO、SEOPress、Slim SEOとの連携により多言語サイトマップを生成できる。
WPMLの多言語SEO
WPMLの専用SEOアドオンはCMSプランとAgencyプランに含まれる。hreflangタグ、x-default hreflangタグ、翻訳URLスラッグ、言語別のメタ情報をすべてカバーする。AIOSEOやYoast SEOとの深い互換性により、SEOプラグインの全フィールドが翻訳ワークフローに自動で組み込まれる。ただし、Yoast SEO Premiumのリダイレクト機能はWPMLと互換性がない点に注意が必要だ。
Universallyの多言語SEO
Universallyは、多言語SEOの全スタックを自動で処理する。hreflangタグ、翻訳メタ情報、多言語XMLサイトマップ、schema.org構造化データ、RTL言語サポートが、言語を追加した瞬間に有効化され、手動設定は一切不要だ。これはUniversallyの本物の強みであり、SEO設定ページを一度も開くことなく堅実な多言語SEOを実現できる。
多言語SEOではWPMLとTranslatePressが同点だ。いずれも有料プランでx-default hreflangと翻訳URLスラッグを含む完全なSEOスタックをカバーする。Universallyは国際SEOの基本を自動化するが、x-defaultタグやネイティブなURLスラッグ翻訳に関するきめ細かな制御は現時点では欠けている。
パフォーマンスと表示速度
サイト速度はSEOとコンバージョンの両方に影響する。複数言語の追加は、翻訳プラグインの実装が非効率だとサイトを遅くする要因になる。これら3つのツールは、翻訳コンテンツの保存と配信において根本的に異なるアーキテクチャを採用している。
TranslatePressのパフォーマンス
TranslatePressはWPMLと同様に、翻訳をWordPressデータベースに直接保存する。コンテンツが増えるにつれて同じデータベース肥大化の問題が発生する。実用的な利点として、翻訳メモリにより各文字列のAPI呼び出しは1回限りだ。新しい言語での初回訪問後、以降の訪問者はキャッシュされたデータベース版を受け取り、追加の処理は発生しない。翻訳が自社データベースに保存されるため、TranslatePressのサービスがオフラインになったりサブスクリプションを解約したりしてもサイトは機能し続ける。
WPMLのパフォーマンス
WPMLは翻訳を言語ごとの重複エントリとしてデータベースに保存する。WP Beginnerのテストでは、キャッシュなしのサイトで0.3〜0.5秒の追加遅延が確認された。質の高いキャッシュプラグインでほとんどを取り戻せるが、データベースの負荷は時間とともに増大する。数百の投稿を複数言語に翻訳したサイトでは、優れたキャッシュを導入していてもオーバーヘッドが無視できなくなる。多言語化の前にキャッシュプラグインを導入し、言語別に異なるキャッシュファイルを配信する設定を行うことが推奨される。
Universallyのパフォーマンス
Universallyは、200以上のエッジ拠点を持つグローバルCDNから翻訳コンテンツを配信し、WordPressデータベースには一切書き込まない。追加する言語数に関係なく、サイトのデータベースサイズは変わらない。キャッシュプラグインで言語別キャッシュを有効にする初期設定は推奨されるが、大半の人気キャッシュプラグインなら簡単なトグル操作で完了する。クラウドで動作するため翻訳はUniversallyのサーバーで保存・同期され、自社データベースを圧迫するものは何もない。
パフォーマンスではUniversallyが明らかにリードしている。グローバルCDN配信とデータベース書き込みゼロの組み合わせは、データベース肥大化が避けられないTranslatePressやWPMLに対して明確な優位性を持つ。
WooCommerce対応
WooCommerceストアの多言語化は、標準サイトの翻訳より複雑だ。動的なカートメッセージやチェックアウト時のエラー通知、自動送信される注文確認メールなど、すべてが顧客の言語で正しく表示されなければならない。顧客がスペイン語でストアを閲覧したのに自動配信レシートが英語だと、混乱を招きブランドの信頼を損なう。
TranslatePressのWooCommerce対応
TranslatePressは追加アドオン不要で、フロントエンドのビジュアルエディターを通じてWooCommerceを翻訳する。商品ページ、説明、カート、チェックアウトフローが自動でカバーされる。注文確認メールは顧客の閲覧言語で送信され、ログインユーザーには最後に使用した言語が記憶される。WPMLと比較した場合のギャップは多通貨対応で、TranslatePressには通貨切り替え機能が組み込まれていない。現地通貨で価格を表示したい場合は、専用のマルチカレンシープラグインが別途必要になる。
WPMLのWooCommerce対応
WPMLのWooCommerce Multilingualアドオン（Multilingual CMSプランに含まれる）は、WP Beginnerの著者が「これまで見た翻訳プラグインの中で最も徹底したWooCommerce統合」と評する出来だ。商品、カテゴリ、属性、バリエーション、カスタムフィールド、カートとチェックアウト、配送方法名、注文確認メールを自動でカバーする。
さらに、200以上の通貨に対応したネイティブのマルチカレンシー機能を内蔵する。為替レートベースの価格設定と、商品・通貨ごとの手動上書きが可能で、所在地に基づく通貨表示により訪問者は自動で現地通貨の価格を目にすることができる。
UniversallyのWooCommerce対応
UniversallyはWooCommerceの翻訳も他のコンテンツと同様に自動処理する。アドオン不要、商品ごとの設定も不要で、商品説明や画像altテキスト、カートとチェックアウトフローがカバーされる。ただしTranslatePressと同様に、ネイティブのマルチカレンシー機能は持たない。現地通貨表示が必要な場合は別途プラグインを用意する必要がある。
WooCommerce対応ではWPMLが圧勝だ。ネイティブのマルチカレンシー、翻訳された商品属性やバリエーションの細かい制御、言語別の注文メールは、他の2つとは明確に異なる次元にある。TranslatePressはほとんどのWooCommerce翻訳ニーズに十分応え、シンプルなストアに適している。Universallyは基本をカバーするが、複雑な多言語WooCommerceセットアップ向けには設計されていない。
カスタマーサポート
多言語サイトで何か問題が発生したとき、サポートの品質と可用性は実際の運用に差をもたらす。3つのツールはいずれもサポートを提供するが、対応時間、実績、応答の一貫性には大きな違いがある。
TranslatePressのサポート
TranslatePressは、大規模なユーザーベースに支えられた強力なサポート評価を得ている。WordPress.orgでは1,600件以上のレビューで4.7/5、Trustpilotでは4.6/5を獲得している。レビューではサポート担当者の名前が頻繁に挙げられ、明確で実践的な回答が迅速に得られたという声が多い。ただしサポートは平日のみで24時間対応ではない点に留意が必要だ。
WPMLのサポート
WPMLのサポート評価は際立っている。9言語で1日22時間対応し、G2とCapterraの両方で4.7/5を獲得している。多数の5つ星レビューにおいて、サポートこそがWPMLを使い続ける理由として挙げられている。「信じられないほど速く正確」「積極的」といった言葉が繰り返し登場する。全プランに直接チケットアクセスが含まれ、過去の解決済みチケットを検索できるフォーラムでは、返信を待たずに一般的な問題を自力解決できる。
Universallyのサポート
Universallyは新しいプラグインだが、WPFormsやAIOSEO、OptinMonsterなどの人気プラグインを手がけるAwesome Motive（WPBeginnerの運営元でもある）によって開発されている。数百万のWordPressサイトで動作する実績あるエンジニアリングとサポート体制を背景に持つ。日常的なサポートはチケット送信で対応し、Proプランユーザーには優先対応が提供される。
ドキュメントも新プラグインとしては充実しており、インストールや言語管理、トラブルシューティング、SEO、開発者API情報をカバーする。しかも開発者ではなくサイト運営者向けに書かれているため、返信を待たずに多くのセットアップ上の疑問を自力で解決できる。
サポートではWPMLが最も評価が高い。ほぼ24時間の多言語対応と、数多くのレビューで「乗り換えない理由」として真っ先に挙げられる強固な評価は、他を凌駕する。TranslatePressはそれに次ぐ位置にあり、平日限定という制約はあるが、評価スコアは高くユーザーベースも最大だ。Universallyは充実したドキュメントとAwesome Motiveのサポートチームを持つが、WPMLに迫るだけのライブサポートの実績はまだ構築途上である。
価格
3つのツールの価格差はこの比較の中で最も大きい。TranslatePressとWPMLは年間定額制を採用し、Universallyは月額の単語従量課金制（米ドル建て）を取る。どれが最もコスト効率が良いかは、コンテンツ量と公開頻度によって変わる。
TranslatePressの価格
TranslatePressにはWordPress.orgで無料のコアプラグインが用意されており、手動翻訳と追加1言語に対応する。有料プランではAI翻訳とSEO Pack、対応言語数が拡張される。Personalプランが年間99ユーロ（約115ドル）、Businessプランが年間199ユーロ（約230ドル）、Developerプランが年間349ユーロ（約405ドル）だ。サブスクリプションを解約しても、既存の翻訳はデータベースに残り、サイトの全言語が機能し続ける点が実務上のメリットとして見逃せない。
WPMLの価格
WPMLには無料版が存在しない。Blogプランが年間39ユーロ（約45ドル）だがWooCommerce非対応、Multilingual CMSプランが年間99ユーロ（約115ドル）で3サイトとWooCommerce対応、Agencyプランが年間199ユーロ（約230ドル）で無制限サイトだ。WPMLの定額制が真価を発揮するのは大規模サイトで、翻訳量に関係なく同じ価格で済む点にある。
Universallyの価格
Universallyは米ドル建てで、月額の単語従量課金制だ。無料プランでは1言語2,000単語まで利用できる。Starterプランが月額7.50ドル（1サイト、1言語、10,000単語）、Businessプランが月額15.80ドル（1サイト、3言語、50,000単語）、Proプランが月額40.80ドル（3サイト、5言語、200,000単語）だ。年間一括払いで約17%割引となり、全プランに14日間の返金保証が付く。
多くの単一サイト運営者にとって、Universallyが価格面で最も有利だ。月額15.80ドルのBusinessプランで50,000単語×3言語の余裕があり、導入障壁が低い。一方、複数サイトを管理する制作会社や、毎日数百ページを翻訳するような大規模運用では、単語数無制限のWPML定額制（年間99ユーロ）が最も高いコストパフォーマンスを発揮する。
この記事のポイント
- セットアップの速さと手軽さを最重視するならUniversallyが最適だ。
- ビジュアル編集と自社サーバー内での翻訳データ保持を求めるならTranslatePressを選ぶとよい。
- 本格的なWooCommerceストアやプロ翻訳ワークフローが必要な場合はWPMLが突出して強力だ。
- いずれのプラグインも多言語SEOの基本はカバーするが、WPMLとTranslatePressが細部まで制御可能だ。
- パフォーマンスへの影響を最小化したいなら、CDN配信でデータベース負荷ゼロのUniversallyが明確に有利だ。
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験