76%の人が、説明が母国語であれば商品を購入する可能性が高いというデータがあります。 によるとしたがって、翻訳は単なる「礼儀」ではなく、コンバージョンに直接影響します。
クライアントがサイトの英語バージョンを要求しています。Tildaを開くと、多言語サイトを作成する組み込みの方法がないことに気づきます。いくつかの回避策しかなく、そのほとんどは最初から、または後で問題を引き起こします。
オプション1：Tildaの別のプロジェクト
最も明白な解決策：プロジェクトを複製し、すべてを手動で翻訳し、別のドメインまたはサブドメインで公開します。
クライアントがメインサイトで何かを変更すると、コピーに移動して同じことを行います。クライアントがブログを積極的に運営したり、カタログを更新したりする場合、これは無限の手動同期になります。さらに、要素がずれる可能性があるため、コンテンツはTildaエディターで翻訳して再レイアウトする必要があります。
もう1つの問題はSEOです。Tildaには、2つの別々のプロジェクト間でhreflangを設定する組み込みメカニズムがありません。hreflangがないと、Googleは2つのサイトが関連していることを理解せず、英語バージョンを重複コンテンツとして認識する可能性があります。
対象：更新頻度が低く、検索でのプロモーションを計画していない単一ページのランディングページ。
オプション2：言語スイッチャー付きゼロブロック
これは、Tildaの単一プロジェクト内で全てを完結させたい代理店でよく見られます。ロジック：CSSを介してロシア語のブロックが非表示になり、別のブロックが表示されます。言語はボタンで切り替わります。
解決策のように見えますが、検索エンジンはこのページを理解しません。Googleは両方の言語の混在したコンテンツを一度に見ており、ロシア語のテキストが一部のユーザー向けで、英語が他のユーザー向けであることを知りません。hreflangも言語による分離もありません。SEOにとっては、2つの別々のサイトよりも悪い結果になる可能性があります。
さらに、このアプローチではフォームや動的コンテンツは翻訳されません。カタログのボタン、フォームフィールド、エラーメッセージなど、すべてが元の言語のままになります。
オプション3：JSスクリプトによる翻訳サービス
Weglot、Linguise、および同様のソリューションは、ページ上のJSスクリプトを介してTildaと連携します。ブラウザは元のコンテンツをロードし、スクリプトがそれを翻訳されたバージョンに置き換えます。
視覚的には、このアプローチは機能します。ユーザーは翻訳されたテキストを見ますが、ページの読み込み直後ではなく、しばらくしてからです。ただし、SEOにはメリットがありません。検索エンジンは、JSスクリプトがコンテンツを置き換える前にコンテンツを見るため、サイトの元のバージョンのみをインデックスに登録します。
検索エンジンは、最初のレンダリング時に表示されるものをインデックスに登録します。JSコンテンツは表示されないか、遅れて表示される可能性があります。これは、あなたの英語バージョンが検索で期待よりも悪くインデックスされるか、まったくインデックスされないことを意味します。
オプション4：サーバーサイド翻訳付きプロキシ
動作原理：ユーザーとあなたのサイトの間にプロキシサーバーが立ち、サーバー側でコンテンツ全体を翻訳します。ブラウザにはすでに翻訳されたHTMLが届きます。
これにより得られるもの：
- 検索エンジンは、JSの準備ではなく、完全に翻訳されたコンテンツを見ます
- hreflangは自動的に生成されます（各ページのメタタグとサイトマップ内）
- すべての動的コンテンツが翻訳されます：カタログ、フォーム、ボタン、エラーテキスト
- コンテンツ管理は元のサイト上でのみ行われ、言語の数が増えても労力は増えません
これがMultifyの仕組みです。サブドメイン（例：en.yourwebsite.ru）または別のドメインを介して英語版を接続すると、残りのすべてはサーバーレベルで処理されます。
英語版を作成する際に考慮すべきこと
ドメイン構造
2つのオプション：サブドメイン（en.site.ru）または別のドメイン（site.com）。ほとんどのプロジェクトでは、サブドメインの方が設定が簡単で、SEOの観点からも問題なく機能します。別のドメインは、西側市場向けに別のブランドを構築する予定がある場合に意味があります。
Tildaはフォルダ（site.ru/en/）をネイティブにサポートしていません。プロキシなしではこれを実装することはできませんが、このオプションの方が有利です。1つのドメインの評判が高まり、複数のサイトのプロモーションに分散する必要がありません。
適応させる必要のあるコンテンツ
テキストの機械翻訳は作業の半分です。英語圏の視聴者には、多くの場合、次のものが必要です。
- 例とケースを西洋の読者にとって理解しやすいものに置き換える
- 支払い方法を変更する：ロシアで機能する一部の決済システムは、海外では機能しない場合があります
- 行動喚起を調整する：ロシア語の視聴者に効果的なものが、英語では奇妙に聞こえる場合があります
- 画像をチェックする：翻訳する必要があるテキストが画像に含まれているか
hreflangとサイトマップ
正しく設定されたhreflangがないと、Googleはロシア語ユーザーに英語版を表示したり、その逆を行ったりする可能性があります。Tildaでhreflangを手動で設定するのは簡単ではありません。 プラットフォームは、各ページのHEADにコードを手動で挿入することを提案しています — 自動インターフェースはありません。
プロキシソリューションを使用する場合、hreflangは通常、各ページに対して自動的に生成されます。サイトマップも自動的に更新されます。
英語版のフォーム
これは別の話です。Tildaのフォームは、機械的に翻訳されても、別途設定しない限り、ロシア語の通知システムにデータを送信します。フィールド、フィールド内のヒント、送信後のメッセージ、検証エラーメッセージなど、これらすべてを個別に翻訳する必要があります。
Tildaで英語版を立ち上げる際の典型的な間違い
hreflangなしで公開する。 検索エンジンは、互いにリンクされていない2つのサイトを認識します。トラフィックが意図した場所に流れない可能性があります。
テキストのみを翻訳し、動的な要素を無視する。 英語のカタログとロシア語の「カートに追加」ボタン。コンバージョン率はそれに応じて低くなります。
別のプロジェクトを作成し、同期について考えない。 最初の数ヶ月はすべて順調です。しかし、その後クライアントが修正を加え始めると、どちらかのサイトが遅れをとります。
決済システムを無視する。 ユカッサとロボカッサは海外のカードを受け付けません。英語バージョンが西洋のオーディエンス向けであれば、StripeまたはPayPalが必要です。
決定を下す方法
サイトがシンプル（ランディングページ、名刺サイト）で、英語バージョンが一度きりで更新が不要な場合は、Tildaで別のプロジェクトを作成するのが最も簡単です。サイトが活発で、定期的な更新、カタログ、またはフォームがある場合は、プロキシソリューションが必要です。それ以外のすべては、後で返済しなければならない負債を生み出します。
