Lingvit
  • WooCommerce
  • WordPress
  • Eコマース

WooCommerce多言語化:WPMLなしでストアを翻訳する(2026年版)

読了時間 9分

WooCommerceストアを本当に多言語化するには、商品タイトルを翻訳するだけでは足りません。 カートの文字列、決済フロー、カテゴリーページ、顧客アカウントページ、注文メールが すべて各言語で機能する必要があります。このガイドでは、それが実際に何を要求するのか、 主なアプローチがどう比較されるか、そして何を省略できるかを解説します。

WooCommerce多言語化が実際に意味すること

完全に多言語化されたWooCommerceストアは、いくつかの明確なコンテンツ領域をカバーします。

商品ページ

商品タイトル、短い説明、完全な説明、レビューテキスト。最もコンテンツ量の多い翻訳対象です。

カテゴリーとタグのページ

カテゴリー名、説明、パンくずリスト。これらは翻訳されたコンテンツが順位に直接影響する、SEO上重要なページでもあります。

ナビゲーション

メニュー項目、ヘッダーリンク、フッターナビゲーション — 通常はWordPressテーマの他の部分と同じ文字列です。

カートと決済

WooCommerceには「Add to cart」「Proceed to checkout」、フィールドラベル、バリデーションメッセージ、配送オプションのテキストなど、数十のUI文字列があります。これらは投稿コンテンツではなく、WooCommerceコア内のPHP文字列です。

注文確認・アカウントページ

注文ステータスメッセージ、「ありがとうございました」ページのコピー、顧客アカウントエリア(注文、住所、アカウント詳細)。

商品バリエーションと属性

「サイズ」「カラー」のようなバリエーションラベルと、その選択肢の値(「小」「中」「赤」)は商品ページやカートに表示されます。

3つのアプローチ

WooCommerceを多言語化する主な方法は3つあり、それぞれ異なるモデルを持っています。

WPML + WooCommerce Multilingualプラグイン

コンテンツ複製モデル:各商品は言語ごとに別々のWordPress投稿として存在します。 WPMLがそれらをリンクします。翻訳はWordPress管理画面で手動で入力します。WPML、 そのWooCommerce多言語ワークフロー、そして商品ごとの大きな手作業が必要です。

Polylang + Polylang for WooCommerce

WPMLと同じコンテンツ複製モデルですが、ライセンス費用は低めです。翻訳ワークフローも 同様に手動で、すべての商品、カテゴリー、属性ごとに管理画面で翻訳済みコピーを 作成する必要があります。より手頃ですが、作業量が減るわけではありません。

自動翻訳(スクリプトタグ)

WordPressテーマまたはプラグイン経由で追加されるスクリプトです。コンテンツの 複製はなく、元の商品投稿は変更されません。訪問者が言語を切り替えると、対応する ブラウザレンダリングの商品・カテゴリー・カートのテキストがその場で翻訳されます。 決済拡張機能とホスト型決済ページは事前の確認が必要です。

WooCommerceにおけるWPML/Polylangの問題

コンテンツ複製モデルは、カタログの規模とともに大きくなる構造的な問題を生みます。 各商品投稿は言語ごとに一度ずつ存在する必要があり — 別々のWordPress投稿、別々の メタフィールドのセット、そしてWooCommerceの用語で言えば必要に応じて別々の在庫と 価格情報が必要です。

200商品、3対象言語のストアの場合:商品だけで600のデータベースエントリが必要で、 カテゴリー、タグ、属性タクソノミーはそれ以前の話です。商品の説明を更新するときは 3回更新することになります。新商品を追加するときは3回作成することになります。

同期の失敗はよくあります — 英語版を更新してフランス語版のコピーを更新し忘れると、 誰かが気づくまでフランス語の顧客は古い価格や説明を見続けることになります。WPMLは 同期ツールを提供していますが、コンテンツ更新のたびにワークフローの手間が増えます。

Polylangにも同じ構造的な問題があります。コストは低くても、保守の負担は同じです。

WooCommerceにLingvitを追加する方法

3ステップです。

  1. WordPressプラグインディレクトリからLingvit WordPressプラグインをインストールするか、 プラグイン → 新規追加でプラグインZIPをアップロードします。
  2. Lingvitダッシュボードで、ストア用のプロジェクトを作成します。セットアップ画面に 表示されるプロジェクトIDをコピーします。
  3. WordPress管理画面の設定 → Lingvitで、プロジェクトIDを貼り付けて 対象言語を選択します。保存すると、プラグインがすべてのフロントエンドページに 自動的にスクリプトタグを挿入します。

商品投稿は複製されません。対応する商品・カテゴリー・カートのテキストはランタイムで 翻訳され、再利用のために保存されます。決済拡張機能、決済プロバイダーのページ、 確認フローは公開前に確認してください。

自動的に翻訳される内容

フロントエンドにレンダリングされるすべてのテキストノードが翻訳されます。WooCommerce ストアの場合、それは以下をカバーします。

WooCommerce多言語化:WPMLなしでストアを翻訳する(2026年版)の補足データ
コンテンツ領域自動的に翻訳される
商品タイトルと説明はい
バリエーションラベル(サイズ、カラー)と選択肢の値はい
カテゴリーとタグのページはい
WooCommerceのカート文字列(「カートに追加」「小計」)はい
決済フローの文字列とフィールドラベルはい
注文ステータスメッセージはい
顧客アカウントページはい
ブログとコンテンツページはい

横にスクロールしてすべての列を表示できます。

引き続き別途対応が必要な部分

DOMベースの翻訳がカバーするのはブラウザにレンダリングされるコンテンツのみです。 2つの領域はこの範囲外です。

トランザクションメール

WooCommerceは、注文確認、配送通知、アカウントメールをPHPのサーバーサイドコードから 送信します。これらはブラウザのDOMには一切レンダリングされません。翻訳するには、 WooCommerce → 設定 → メールで言語ごとのメールテンプレートを 設定するか、WooCommerce Multilingual Emailのような、顧客のロケールでメールを 送信する多言語メールプラグインを使用してください。

決済ゲートウェイとホスト型ページ

Stripe Checkout、PayPalのホスト型ページ、その他のオフサイト決済フローは決済 プロバイダーのドメインから提供されます。そのローカライゼーションは決済 プロバイダー側が管理しており、多くはブラウザのロケールを自動検出します。決済 ステップの前にあるWooCommerceの決済フィールドはLingvitによって通常通り 翻訳されます。

多言語WooCommerceにおけるSEO

Lingvitは、ストアの各言語版に言語固有のURLを作成します: /fr/shop/、 /de/product/blue-chair/など。 各URLは検索エンジンから独立してインデックス可能です。

hreflangタグはすべてのページに自動的に追加され、どのURLが各言語・地域の正規版かを 検索エンジンに知らせます。これにより、元のURLと翻訳されたURLが検索結果で競合することを 防ぎます。

メタタイトルと説明文はページコンテンツと一緒に翻訳されるため、翻訳された言語版にも 現地化されたメタデータが検索結果に表示されます。各言語URLの商品スキーマ(JSON-LD 構造化データ)には翻訳された商品名と説明が含まれ、現地の検索でリッチリザルトを 可能にします。

多くの場合、最もトラフィックの多いSEOターゲットであるWooCommerceのカテゴリーページに ついては、翻訳されたカテゴリー名と説明が言語固有のURLに表示され、各バージョンが 対象言語での独自のキーワード関連性を持つことになります。

よくある質問

LingvitはElementorの商品ページで動作しますか?

はい。Elementorは他のページビルダーと同様にフロントエンドにHTMLをレンダリングします。LingvitのMutationObserverはElementorがレンダリングしたコンテンツを通常通り処理し、ElementorのWooCommerceウィジェットで構築された商品ページテンプレートも含まれます。

Advanced Custom Fields(ACF)の商品フィールドはどうですか?

ACFのフィールド値がフロントエンドのDOMにレンダリングされる場合は、はい対応します。商品説明、タブ、カスタムテンプレートエリアに表示されるフィールドは自動的に翻訳されます。WordPress管理画面内でのみ使われるフィールドや、サーバーサイドのロジック(カスタムメール、APIレスポンス)で使われるフィールドはLingvitでは翻訳されません。

LingvitはWooCommerceの速度やパフォーマンスに影響しますか?

スクリプトは非同期で読み込まれ、保存済みの翻訳は再利用できますが、総合的なパフォーマンスはページ、ブラウザ、ネットワーク、ウィジェットの配信状況によって左右されます。公開前に代表的な商品、カート、決済フローでテストしてください。