Tildaでウェブサイトを作成し、カタログを追加し、チェックアウトを設定しました。次に、英語とドイツ語のバージョンを立ち上げる必要があります。テキストを翻訳するだけで十分だと思われるかもしれません。
CSA Research によると、購入者の76%は母国語での購入を好み、40%は他の言語では購入しません。しかし、言語バージョンを追加して機能させることは、異なるタスクです。
実際には、多言語ストアは通常の多言語サイトよりも複雑です。動的なカタログ、カート、チェックアウト、支払い通知、エラーメッセージがあります。これらの各要素には個別の注意が必要です。何かを見落とすと、ドイツの顧客はドイツ語のストアフロントを見ても、カートはロシア語のままになります。
ストアで翻訳する必要があるもの
Tildaのオンラインストアには、動作が異なるいくつかのコンテンツカテゴリがあります。静的なページテキストは問題の一部にすぎません。
静的コンテンツ
ストアの説明、会社概要、配送条件、ホームページの静的ブロック。これらは標準的に翻訳され、どのプロキシ翻訳者でも対応できます。
商品カタログ
Tildaは、JavaScriptを介して商品カードを動的にロードします。名前、説明、特性、価格はページがロードされた後に生成されます。ほとんどの翻訳者はHTML構造しか見えず、後からロードされるものは見えません。
結果：ストアフロントでは商品が「Leather wallet」と表示されていても、カードに移動すると再びロシア語になります。または、ストアフロントがすでに英語になっていても、カタログ全体が翻訳されないままになります。
カートとチェックアウト
Tilda Storeは独自のロジックを持つ独立したモジュールです。カート、チェックアウトページ、配送先住所フィールド、支払い方法の選択、「支払う」ボタン—これらはすべて個別のコンポーネントです。ほとんどのサービスはこれらを翻訳しません。
システムメッセージ
「商品がカートに追加されました」、「在庫が不足しています」、エラー通知—これらはすべて動的に生成されます。他のすべてが翻訳されていても、元のサイトの言語のまま残ることがよくあります。
メールと通知
メールでの注文確認は別の話です。Tildaは独自のメカニズムを介してメールを送信するため、Multifyはこのプロセスに影響を与えません。これはバグでも特定のサービスの制限でもありません。メールはプロキシの責任範囲外に存在します。
技術的には、これは外部の自動化によって解決できます。Multifyは、フォームデータに言語、国、およびリクエストが送信されたドメインのフィールドを渡します。n8n、Make、または類似のツールを接続すると、ロジックを設定できます。たとえば、ドイツ語版からリクエストが来た場合、ドイツ語のテンプレートでメールを送信するなどです。ただし、これは個別の統合であり、自分で設定する必要があります。
なぜ標準的なソリューションでは対応できないのか
WeglotとLinguiseは静的なHTMLを翻訳します。動的なコンテンツ（カタログ、カート、メッセージ）は、表示されないか、不安定に翻訳されます。
具体的な問題：ユーザーが商品をカートに追加すると、Tildaはサーバーにアクセスし、リアルタイムでデータを受信します。この時点で、クライアント側の翻訳ツールはすでにページの処理を完了しています。新しいデータは表示されません。
解決策はサーバーサイド翻訳です。Tildaへのすべてのリクエストがプロキシを通過すると、各応答（カタログデータやカートの状態を含む）はサーバーで翻訳され、ブラウザにはすでに準備された結果が届きます。ユーザーは、ページにどのようにアクセスしたかに関わらず、常に翻訳されたコンテンツを見ることができます。
通貨：3つのアプローチとその影響
多言語ストアには、ほとんどの場合、多通貨が必要です。ドイツの購入者にはユーロで、英国の購入者にはポンドで価格を表示する必要があります。3つのアプローチがあり、それぞれSEOに異なる影響を与えます。
JavaScriptでの変換
最も一般的な方法：ページ上のスクリプトがルーブル価格を取得し、ブラウザで直接必要な通貨に再計算します。ユーザーはユーロを見ますが、HTMLでは依然としてルーブルです。
これはSEOにとって良くありません。Googlebotはページをクロールし、ルーブルでの価格を見ます。もしあなたのサイトがドイツ市場向けであれば、インデックス化されたものとユーザーが見るものの間に不一致を記録します。これはドイツ語のクエリでのランキングに影響します。
複数のカタログの手動管理
ドイツ語版のユーロ価格の別カタログ。機能しますが、価格が変更されるたびに手動で更新する必要があります。小規模なカタログには許容されますが、200以上の商品には適していません。
サーバーでの変換
価格はサーバーで再計算され、ユーザーは必要な通貨で準備されたページを受け取ります。Googlebotはドイツの購入者が見るものとまったく同じもの、つまりユーロ建ての価格を見ます。SEOは正しく、データは最新です。
為替レートのソースを選択できます。ルーブル市場の場合は中央銀行、ヨーロッパ市場の場合はECB、または価格が毎日為替レートとともに変動するのを望まない場合は、手動で指定されたレートを選択できます。
SEO: 各言語バージョンで設定する必要があるもの
適切なSEO基盤のない多言語ストアは、ターゲット市場の検索エンジンでは見えません。
hreflang
hreflangタグは、Googleに同じページの複数の言語バージョンがあることを伝えます。これがないと、検索エンジンは各国からのユーザーにどのバージョンを表示すべきかを理解せず、言語バージョンを重複コンテンツと見なす可能性があります。
ストアにとってこれは特に重要です。各商品、各カテゴリ、各チェックアウトページには、正しいhreflangが必要です。 Googleの公式ドキュメント には、実装ルールが詳細に記載されています。
各言語のサイトマップ
サイトマップには、すべてのページのすべての言語バージョンが含まれている必要があります。300の商品と3つの言語の場合、サイトマップには900ページが含まれ、それぞれにその言語が指定されます。
各バージョンのメタタグ
検索結果のタイトルとディスクリプションは、ユーザーの言語である必要があります。ドイツの購入者はドイツ語の商品説明を、フランスの購入者はフランス語の商品説明を見ます。
URL構造
主なモデルは2つあります。サブドメイン (de.yourshop.com) とフォルダ (yourshop.com/de/) です。Tildaのほとんどのオンラインストアでは、フォルダの方が実装が簡単で、追加のDNS設定は必要ありません。
ローカリゼーション: 翻訳のその先
技術的には、翻訳は1日で設定できます。しかし、特定の国の購入者向けにストアを機能させるには、いくつかの追加事項を考慮する必要があります。
日付と数字の形式。 ドイツでは価格は「19,99 €」と書かれ、米国では「$19.99」と書かれます。桁区切り、通貨記号の位置、日付形式。これらは現地の購入者がすぐに気づく細かな点です。
支払い方法。 ロシアの購入者はYooKassaまたはSBPに慣れています。ヨーロッパの購入者はStripe、PayPal、またはSEPA送金を期待しています。すべてのユーザーにすべての支払い方法を表示しても意味がなく、混乱を招きます。特定の地域で機能するものだけを表示する方が良いでしょう。
配送条件。 各市場には独自の納期、運送業者、配送料があります。これは自動的に翻訳されるものではなく、各市場に合わせて内容を調整する必要があります。
法的要件。 欧州市場では、 GDPRに準拠したクッキーバナー、ユーザーの言語でのプライバシーポリシー、場合によっては必須の販売者情報（ドイツのImpressum）が必要です。
Tildaで多言語ストアを立ち上げるためのチェックリスト
言語バージョンを立ち上げ、トラフィックに公開する前に、このリストを使用してください。
コンテンツの翻訳
- ウェブサイトのすべてのページが翻訳されています。これには、ホームページ、会社概要、連絡先が含まれます。
- 商品カタログ：ターゲット言語での名前、説明、特徴
- 商品カード：詳細な説明とタブを含む
- カート：すべてのインターフェース要素が翻訳されています
- チェックアウトページ：フィールド、ボタン、ヒント
- フォーム入力時のエラーメッセージ
- 画面上の注文確認
- 注文確認メール（ローカライズにはn8n / Makeを介した個別の統合が必要です）
価格と通貨
- 価格はターゲット市場の通貨で表示されます
- 変換はサーバー側で行われます（JS経由ではありません）
- 為替レートのソースが選択されています：ライブ為替レート / ECB / 手動で指定されたレート
- 価格形式は国の標準に準拠しています（区切り文字、通貨記号）
- 検索（Googleショッピングを使用している場合）の価格はサイトの価格と一致しています
SEO
- hreflangタグが商品カードを含むすべてのページに設定されている
- サイトマップにはすべてのページのすべての言語バージョンが含まれている
- 各言語バージョンのページのタイトルと説明
- 言語バージョンのURL構造は一貫している（サブドメインまたはフォルダ）
- Canonicalタグが正しく設定されており、重複がない
機能性
- 言語スイッチャーは、チェックアウトページを含むすべてのページで機能する
- 商品をカートに追加してもインターフェースの言語は変わらない
- サイトに戻ったときに言語が保持される
- 地理位置情報による言語の自動検出が設定されている（必要に応じて）
- カタログ検索がターゲット言語で機能する
支払い方法
- 利用可能な支払い方法が市場に対応している
- 各言語バージョンでテスト注文が正常に完了しました
- 確認メールは購入者の言語で届きます
法的要件
- プライバシーポリシーが翻訳されている
- 利用規約が翻訳されました
- Cookieバナーが設定されている（ヨーロッパ市場では必須）
- 特定の市場の年齢制限またはその他の制限が考慮されました
最終確認
- ストアフロントから注文確認までの完全な購入経路がテストされました
- 言語バージョンのモバイル表示が確認されました
- 言語バージョンの読み込み速度は許容範囲内です
- 言語バージョンへのトラフィックは分析で個別に追跡されます
一般的な起動エラー
カートを確認せずに翻訳を開始しました。 最もよくある状況は、ストアフロントは翻訳されているが、カタログは問題なく表示されるものの、カートとチェックアウトがロシア語のままであることです。購入者は注文手続きに進み、未翻訳のインターフェースを目にしました。起動する前に、必ず完全な購入経路をたどってください。
価格はJSを介して翻訳されます。 外見上はすべて正しく見えますが、Googlebotはドイツ語のページでルーブルの価格を見ています。これはドイツの検索でのランキングや、Googleショッピングでの商品カードの表示方法に影響します。
商品ページにhreflangがありません。 ホームページでは設定しましたが、カテゴリページでも設定しましたが、商品カードでは忘れていました。Googleは/de/product/leather-walletが/product/leather-walletのドイツ語版であることを理解せず、ドイツのユーザーにロシア語版を表示する可能性があります。
メールを忘れていました。 顧客がドイツ語で注文しましたが、確認メールはロシア語で届きました。Tildaは独自のメカニズムでメールを送信するため、これは自動的に解決されません。翻訳されたメールが必要な場合は、n8nまたはMakeを介した個別の統合が必要です。Multifyは、注文が来たフォームの言語とドメインをデータで渡し、これに基づいてテンプレート選択ロジックを構築できます。
よくある質問
ストアの各言語バージョンに個別のドメインが必要ですか？
いいえ。フォルダ付きの単一ドメイン（yourshop.com/de/）は、ほとんどのストアの標準的なソリューションです。個別のドメインまたはサブドメインは、特定の国向けに完全にローカライズされた製品を個別のブランディングで作成する場合にのみ意味があります。大幅な再設計なしに複数の言語を起動するには、フォルダの方が簡単です。
商品が動的に読み込まれる場合、Multifyはカタログをどのように処理しますか？
Multifyはサーバーレベルのプロキシとして機能します。カタログデータのリクエストを含むTildaへのすべてのリクエストは、Multifyを介して行われます。商品の応答はサーバーで翻訳され、翻訳されたコンテンツがブラウザに届きます。これは、標準のTilda StoreブロックとZero Blockの両方で機能します。
異なる通貨だけでなく、国ごとに異なる価格を表示できますか？
はい。為替レートによる換算に加えて、特定の言語バージョンに固定価格を設定できます。たとえば、ドイツ語版にルーブルの為替レートに縛られない29ユーロの価格を設定できます。これは、市場ごとに異なる価格設定ポリシーがある場合に便利です。
店舗のコンテンツが変更された場合、翻訳はどのように更新されますか？
新しい商品が追加されたり、説明が変更されたりすると、次回の要求時に翻訳が自動的に更新されます。インターフェースで毎回手動で翻訳を更新する必要はありません。プロキシレイヤーは、元のコンテンツと同様に新しいコンテンツを処理します。
多言語ストアのためにTilda自体で何か設定する必要がありますか？
Tilda側からの追加設定は通常必要ありません。通常どおりエディターで作業します。商品を追加し、説明を変更し、価格を更新します。残りのすべては、プロキシレベルでMultifyが処理します。
Tildaで多言語ストアを立ち上げることは、単に翻訳を追加するだけではありません。商品カードから確認メールまで、購入プロセスの各ステップが顧客の言語で機能することを確認する必要があります。上記のチェックリストは、起動前に何も見落とさないようにするのに役立ちます。
