クライアントは3つの言語でウェブサイトを作成するよう依頼します。Tildaのドキュメントを開き、多言語ソリューションを見ると、Weglotも組み込みツールもカタログとフォームに対応できないことがわかります。Multifyは異なります。ページ上のスクリプトではなく、DNSを介して動作します。その仕組みを分析してみましょう。
クライアント側の翻訳の問題
ほとんどの翻訳サービスは同じ原則で動作します。JavaScriptスクリプトをページの<head>に挿入します。スクリプトはブラウザで読み込まれ、ページ上のテキストを傍受し、翻訳に置き換えます。
これにより、いくつかの問題が発生します。
検索エンジンはオリジナルを見ます。 Googlebotはページをリクエストし、スクリプトなし（またはスクリプトが実行されていない）HTMLを受け取り、元の言語をインデックスします。言語バージョンはまったくインデックスされないか、重複としてインデックスされます。 Googleは公式に確認しています、JavaScriptのレンダリングは遅延し、保証されていないことを。
動的コンテンツは翻訳されません。 Tildaは別のAPIリクエストを通じて商品カタログをロードします。翻訳スクリプトがページを「処理」した時点では、商品はまだ到着していません。結果：インターフェースは翻訳されていますが、商品名と価格は元の言語のままです。
フォームが壊れます。 Tildaフォームは、独自のドメインを介してデータを送信します。翻訳スクリプトはあなたのドメインで動作し、Tildaのリクエストにアクセスできません。フィールドのラベル、エラーメッセージ、送信後のテキストは翻訳されません。
リバースプロキシの仕組み
MultifyはDNSレベルで接続します。言語バージョンへのトラフィックがTildaに直接ではなく、Multifyサーバーを介して行われるようにレコードを変更します。
スキームは次のとおりです。
- ユーザーがde.yoursite.com（またはyoursite.com/de）を開く
- DNSがMultifyサーバーにリクエストを送信する
- MultifyがTildaから元のページをリクエストする
- HTMLを受け取り、サーバー上のすべてのコンテンツを翻訳する
- すでに翻訳されたページをユーザーに提供する
ユーザーはあなたのドメインを見ます。Tildaは、自分とユーザーの間にプロキシレイヤーがあることさえ知りません。Tildaの観点からは、単なるサイトへの別のリクエストです。
サーバーサイド翻訳がSEOにとって重要な理由
HTMLが提供される前にサーバーで翻訳が行われると、検索エンジンはすでに準備された翻訳済みページを受け取ります。これは次のことを意味します。
- Googlebotはドイツ語版をドイツ語コンテンツを含む個別のURLとしてインデックスします
- <head>内のhreflang属性は正しい言語バージョンを指します
- サイトマップには各言語の個別のURLがあります
- 重複コンテンツがない — 各バージョンに独自のセマンティクスがある
これらのタグはすべてMultifyによって自動的に生成されます。各ページにhreflangを手動で記述したり、個別のサイトマップを維持したりする必要はありません。実装要件は、 ローカライズされたバージョンのGoogleドキュメント。
動的コンテンツにもたらすもの
プロキシアーキテクチャは、最初のHTMLだけでなく、コンテンツに対するその後のすべてのリクエストもインターセプトします。TildaがAPIを介して製品カタログをロードすると、Multifyはサーバーの応答をインターセプトし、ブラウザに渡す前に翻訳します。
実質的に、これは次のことを意味します。
- 商品名と説明が完全に翻訳される
- 価格は必要な通貨に換算されます（これについては後述します）
- 動的に読み込まれるブログ記事は、必要な言語に切り替わります
- ウィジェットやサードパーティのブロックのコンテンツは、技術的に可能な場所で処理されます
代理店にとって、これはカタログを持つクライアントからの最も一般的な質問、「商品も翻訳されますか？」を解消します。
サーバーサイドでの通貨換算
同じロジックで動作する別の機能です。通貨換算のためのクライアントスクリプトは、ページがすでに読み込まれた後にブラウザで価格を変更します。
問題は同じです。検索エンジンは元の通貨で元の価格を認識します。その結果、ドイツのストアではGoogleがルーブル建ての価格をインデックスします。これはローカルSEOにとって壊滅的です。
MultifyはHTMLが配信される前に価格を変換します。ドイツのユーザーはユーロ建ての価格のページを受け取り、Googlebotはドイツ語版をインデックスする際にこれらの価格を認識します。
接続に必要なこと
Tilda側で何も変更する必要はありません。サイトはそのままです。すべての接続は以下に集約されます。
- Multifyへの登録とサイトの追加
- 言語の選択と言語バージョンの設定
- レジストラでのDNSレコードの変更
その後、言語バージョンは自動的に機能し始めます。翻訳はキャッシュされ、メインサイトに変更があった場合、Multifyは次のページリクエスト時にキャッシュを更新します。
フォームはどうなるか
TildaフォームはTildaの別のサブドメインを介して動作します。通常のクライアントスクリプトは、他のドメインへのリクエストを傍受できません。Multifyはネットワーク層で動作し、Tilda APIとのやり取りを含むリクエストをプロキシします。
フォームのすべての要素が翻訳されます。フィールド名、ヒント、エラーメッセージ、送信後のテキストなどです。
主なポイント
リバースプロキシアーキテクチャは、クライアントスクリプトでは解決できない問題を解決します。
- 検索エンジンは翻訳されたHTMLを受け取り、言語バージョンを正しくインデックスします
- 動的コンテンツ（カタログ、ブログ）は、静的なマークアップだけでなく、完全に翻訳されます
- フォームは完全に機能します：フィールド、エラー、確認
- 価格はページが配信される前に変換され、ブラウザでは変換されません
- hreflang、sitemap、およびメタタグは自動的に生成されます
よくある質問
Tildaのウェブサイトで何か変更する必要がありますか？
いいえ。メインサイトはそのままです。DNSレコードのみが変更され、言語バージョンへのトラフィックはMultifyを介して行われます。
Tilda Personalでも機能しますか、それともBusinessのみですか？
接続にはドメイン名が必要です。Tildaに独自のドメインが接続されている場合、プランは関係ありません。
サイトの変更があった場合、翻訳はどのくらいの速さで更新されますか？
翻訳はキャッシュされます。メインサイトのコンテンツが変更されると、変更されたページへの次回の要求時にキャッシュが更新されます。緊急の更新のために、Multifyパネルでキャッシュを手動でリセットできます。
プロキシ層は読み込み速度に影響しますか？
Multifyサーバーは複数の地域に配置されており、キャッシュは積極的です。実際には、遅延は最小限であり、ユーザーには見えません。
