ブログ

Multifyの仕組み：リバースプロキシとサーバーサイド翻訳

この記事の内容： クライアントスクリプトがTildaで機能しない理由、DNSを介したリバースプロキシスキームの仕組み、それがSEOと動的コンテンツに与える影響、フォームの翻訳方法、サーバー側での通貨換算方法。
クライアントは3つの言語でウェブサイトを作成するよう依頼します。Tildaのドキュメントを開き、多言語ソリューションを見ると、Weglotも組み込みツールもカタログとフォームに対応できないことがわかります。Multifyは異なります。ページ上のスクリプトではなく、DNSを介して動作します。その仕組みを分析してみましょう。

クライアント側の翻訳の問題

ほとんどの翻訳サービスは同じ原則で動作します。JavaScriptスクリプトをページの<head>に挿入します。スクリプトはブラウザで読み込まれ、ページ上のテキストを傍受し、翻訳に置き換えます。
これにより、いくつかの問題が発生します。
検索エンジンはオリジナルを見ます。 Googlebotはページをリクエストし、スクリプトなし（またはスクリプトが実行されていない）HTMLを受け取り、元の言語をインデックスします。言語バージョンはまったくインデックスされないか、重複としてインデックスされます。 Googleは公式に確認しています、JavaScriptのレンダリングは遅延し、保証されていないことを。
動的コンテンツは翻訳されません。 Tildaは別のAPIリクエストを通じて商品カタログをロードします。翻訳スクリプトがページを「処理」した時点では、商品はまだ到着していません。結果：インターフェースは翻訳されていますが、商品名と価格は元の言語のままです。
フォームが壊れます。 Tildaフォームは、独自のドメインを介してデータを送信します。翻訳スクリプトはあなたのドメインで動作し、Tildaのリクエストにアクセスできません。フィールドのラベル、エラーメッセージ、送信後のテキストは翻訳されません。

リバースプロキシの仕組み

MultifyはDNSレベルで接続します。言語バージョンへのトラフィックがTildaに直接ではなく、Multifyサーバーを介して行われるようにレコードを変更します。
スキームは次のとおりです。
  1. ユーザーがde.yoursite.com（またはyoursite.com/de）を開く
  2. DNSがMultifyサーバーにリクエストを送信する
  3. MultifyがTildaから元のページをリクエストする
  4. HTMLを受け取り、サーバー上のすべてのコンテンツを翻訳する
  5. すでに翻訳されたページをユーザーに提供する
ユーザーはあなたのドメインを見ます。Tildaは、自分とユーザーの間にプロキシレイヤーがあることさえ知りません。Tildaの観点からは、単なるサイトへの別のリクエストです。

サーバーサイド翻訳がSEOにとって重要な理由

HTMLが提供される前にサーバーで翻訳が行われると、検索エンジンはすでに準備された翻訳済みページを受け取ります。これは次のことを意味します。
  • Googlebotはドイツ語版をドイツ語コンテンツを含む個別のURLとしてインデックスします
  • <head>内のhreflang属性は正しい言語バージョンを指します
  • サイトマップには各言語の個別のURLがあります
  • 重複コンテンツがない — 各バージョンに独自のセマンティクスがある
これらのタグはすべてMultifyによって自動的に生成されます。各ページにhreflangを手動で記述したり、個別のサイトマップを維持したりする必要はありません。実装要件は、 ローカライズされたバージョンのGoogleドキュメント。

動的コンテンツにもたらすもの

プロキシアーキテクチャは、最初のHTMLだけでなく、コンテンツに対するその後のすべてのリクエストもインターセプトします。TildaがAPIを介して製品カタログをロードすると、Multifyはサーバーの応答をインターセプトし、ブラウザに渡す前に翻訳します。
実質的に、これは次のことを意味します。
  • 商品名と説明が完全に翻訳される
  • 価格は必要な通貨に換算されます（これについては後述します）
  • 動的に読み込まれるブログ記事は、必要な言語に切り替わります
  • ウィジェットやサードパーティのブロックのコンテンツは、技術的に可能な場所で処理されます
代理店にとって、これはカタログを持つクライアントからの最も一般的な質問、「商品も翻訳されますか？」を解消します。
あなたのサイトが他の言語でどのように見えるか見てみましょう
リンクを残してください — あなたのサイトで直接デモをお見せします。
リクエストを送信 →

サーバーサイドでの通貨換算

同じロジックで動作する別の機能です。通貨換算のためのクライアントスクリプトは、ページがすでに読み込まれた後にブラウザで価格を変更します。
問題は同じです。検索エンジンは元の通貨で元の価格を認識します。その結果、ドイツのストアではGoogleがルーブル建ての価格をインデックスします。これはローカルSEOにとって壊滅的です。
MultifyはHTMLが配信される前に価格を変換します。ドイツのユーザーはユーロ建ての価格のページを受け取り、Googlebotはドイツ語版をインデックスする際にこれらの価格を認識します。

接続に必要なこと

Tilda側で何も変更する必要はありません。サイトはそのままです。すべての接続は以下に集約されます。
  1. Multifyへの登録とサイトの追加
  2. 言語の選択と言語バージョンの設定
  3. レジストラでのDNSレコードの変更
その後、言語バージョンは自動的に機能し始めます。翻訳はキャッシュされ、メインサイトに変更があった場合、Multifyは次のページリクエスト時にキャッシュを更新します。

フォームはどうなるか

TildaフォームはTildaの別のサブドメインを介して動作します。通常のクライアントスクリプトは、他のドメインへのリクエストを傍受できません。Multifyはネットワーク層で動作し、Tilda APIとのやり取りを含むリクエストをプロキシします。
フォームのすべての要素が翻訳されます。フィールド名、ヒント、エラーメッセージ、送信後のテキストなどです。
関連トピックを読む
Tildaでのフォーム翻訳：なぜ思っているよりも難しいのか
Tildaフォームで具体的に何が翻訳され、どこで問題が発生し、Multifyが動的フィールドの問題をどのように解決するか。
記事を読む →

主なポイント

リバースプロキシアーキテクチャは、クライアントスクリプトでは解決できない問題を解決します。
  • 検索エンジンは翻訳されたHTMLを受け取り、言語バージョンを正しくインデックスします
  • 動的コンテンツ（カタログ、ブログ）は、静的なマークアップだけでなく、完全に翻訳されます
  • フォームは完全に機能します：フィールド、エラー、確認
  • 価格はページが配信される前に変換され、ブラウザでは変換されません
  • hreflang、sitemap、およびメタタグは自動的に生成されます

よくある質問

Tildaのウェブサイトで何か変更する必要がありますか？

いいえ。メインサイトはそのままです。DNSレコードのみが変更され、言語バージョンへのトラフィックはMultifyを介して行われます。

Tilda Personalでも機能しますか、それともBusinessのみですか？

接続にはドメイン名が必要です。Tildaに独自のドメインが接続されている場合、プランは関係ありません。

サイトの変更があった場合、翻訳はどのくらいの速さで更新されますか？

翻訳はキャッシュされます。メインサイトのコンテンツが変更されると、変更されたページへの次回の要求時にキャッシュが更新されます。緊急の更新のために、Multifyパネルでキャッシュを手動でリセットできます。

プロキシ層は読み込み速度に影響しますか？

Multifyサーバーは複数の地域に配置されており、キャッシュは積極的です。実際には、遅延は最小限であり、ユーザーには見えません。
サイトを編集せずに多言語対応を接続
リンクを残してください — あなたのサイトで直接デモをお見せします。
私のサイトのデモを見る →
2026-03-25 22:38