[WP]BOGO vs Polylang：無料版の機能とパフォーマンスを徹底比較【2025年最新早見表】

WEBデザイナーの皆さん、こんにちは！

クライアントからの「サイトを多言語化したい」という要望、WordPressで対応する際、頭に浮かぶのは「BOGO」と「Polylang」の二大巨頭ではないでしょうか。

「どちらも無料だけど、今回の案件に最適なのはどっちだ？」
「翻訳プラグインって重くないの？」
「Polylangの無料版で、ACF（Advanced Custom Fields）みたいなカスタムフィールドって、どこまで翻訳対応できるんだっけ…？」

もし、このプラグイン選定を「なんとなく」で進めてしまうと、どうなるでしょう。
開発終盤になって「あ！ご要望のカスタム投稿タイプ、無料版では翻訳機能に対応していませんでした！」「スラッグの仕様が要件と違います！」なんてことになれば…想像するだけで恐ろしい手戻りと、クライアントの信頼を失うコストが発生します。

この記事では、そんな悪夢を回避するため、特にWEBデザイナーが実務で直面する「無料版の機能（カスタム投稿・フィールド）」と「パフォーマンス（サイトの重さ）」という観点から、BOGOとPolylangを徹底的に解剖します。

BOGO vs Polylang：無料版の機能とパフォーマンスを徹底比較【2025年最新早見表】

まずは結論から。2025年現在の仕様で、両者をデザイナー目線で比較した早見表をご覧ください。

比較項目	BOGO	Polylang (無料版)
パフォーマンス	◎ 超軽量・シンプル	○ 軽量
基本設定	◎ 非常に簡単	○ 簡単（ウィザード形式）
投稿・ページの翻訳	○（投稿ごとに紐付け）	○（投稿ごとに紐付け）
カスタム投稿	△（要PHPカスタマイズ）	◎（無料版で標準対応）
カスタムフィールド	△（要PHPカスタマイズ）	○（言語ごとに個別設定可）
スラッグ	○（言語ごと同じスラッグを設定可能）	◎（言語ごと異なるスラッグ設定が基本）
URL構造	△（/en/ 階層化は工夫が必要）	◎（/en/ 等に標準対応）
PHP条件分岐	○（get_locale() を使用）	◎（get_locale() / pll_current_language()）
おすすめ案件	・PHPカスタマイズ前提・パフォーマンス最優先	・カスタム投稿/CFを使いたい・SEOも考慮

BBOGOのメリット・デメリット：軽量だが「カスタム投稿」等の翻訳はPHP必須

BOGOは、あの「Contact Form 7」の作者が開発した、信頼性抜群の日本製プラグインです。

最大のメリットは、その圧倒的な「軽量さ」

BOGOはWordPressが本来持つ「ロケール」という仕組みを使い、余計なデータベーステーブルをほとんど作りません。そのため、サイトパフォーマンスへの影響は最小限。まるで羽毛のような軽さです。パフォーマンスを何よりも重視するクライアントには、これ以上ない選択でしょう。

そのシンプルさはデメリットと表裏一体

カスタムフィールドの翻訳にはデフォルトでは非対応です。ただ、functions.phpなどでゴリゴリとコードを書けば、翻訳（というか言語別の出し分け）はいけなくもないです。

これはカスタム投稿タイプも同様で、管理画面に翻訳機能を追加するにはPHPでのカスタマイズが必須となります。

Polylang無料版の強み：カスタム投稿・フィールド翻訳に標準対応、機能豊富で失敗しない選択

変わってPolylangは、無料版の段階で「かゆいところに手が届く」機能が満載の優等生プラグインです。

Polylangは、カスタム投稿タイプとカスタムタクソノミーに対応

最大の強みは、なんといっても「カスタム投稿タイプ」と「カスタムタクソノミー」に無料版で標準対応している点。

例えば「制作実績（カスタム投稿）」や「実績カテゴリー（タクソノミー）」を多言語化したい場合、BOGOならPHPとにらめっこですが、Polylangなら管理画面でチェックを入れるだけ。この差は、実案件において天と地ほどの工数差を生みます。

ACFなどで作成したフィールドも、言語ごとに個別の値を入力することが無料版で可能です。（※フィールド設定自体を言語ごとに変えるといった高度なことはPro版の領域ですが、実用上は無料版で十分なケースがほとんど）

また、Polylangは「/en/about/」のように言語ごとにディレクトリを分けるのが基本設計であり、SEOの観点からも推奨されます。BOGOのように「/about/」という同じスラッグを全言語で使い回す設計とは思想が異なりますね。

【コピペOK】BOGO・Polylang共通で使えるPHPコード（2025年版）

言語別条件分岐

Polylang専用の便利コード

もしPolylangを採用したなら、より直感的な専用関数が使えます。

pll_current_language() を使うと、en_USのようなロケールではなく、自分で設定した短いスラッグで分岐できるため、コードがスッキリしますね。

BOGOとPolylang、無料版の機能で見る「案件別」使い分けガイド【2025年】

2025年現在、BOGOとPolylangの判断基準は非常にシンプルです。