ウェブサイトを翻訳したいと考えているが、常に同じ結論に達する：プロキシか翻訳APIか。
問題は、これらのどれもがデフォルトでうまく機能しないことです。フォームは翻訳されません。動的コンテンツは元の言語のままです。Googleはサイトの1つのバージョンしか見ないため、SEOは改善されません。そして、これを解決しようとすると、新たな問題が発生します。
この記事では、各アプローチがどのように機能するか、それぞれがどこで破綻するか、そして選択する前に考慮すべき点について説明します。
翻訳APIの仕組み
翻訳APIはテキストを受け取り、それを別の言語で返します。DeepL、Google Cloud Translation、Amazon Translateなどがあります。リクエストを送信すると、翻訳が返されます。
これをウェブサイトで使用するには、誰かがAPIをコードに組み込む必要があります。
- 初期統合のための開発者
- 独自のキャッシュロジックと翻訳の更新
- 呼び出しごとに支払い（文字数またはトークン数による）
- サイトの変更があるたびにサポート
自動的に行われないこと： APIは、あなたのサイトにどのようなテキストがあるか、いつ変更されるか、どのように表示するかを知りません。これらは自分で構築する必要があります。APIは翻訳エンジンに過ぎず、それ以外のすべては統合作業です。
独自の技術チームと非常に具体的な要件を持つプロジェクトにとっては意味があるかもしれません。しかし、数日で多言語サイトを立ち上げる必要がある代理店にとっては、これはあまりにも大きな負担です。
翻訳プロキシの仕組み
翻訳プロキシは、ウェブサイトのサーバーとユーザーのブラウザの間に位置します。誰かがmycompany.com/ru/にアクセスすると、リクエストはプロキシを通過し、プロキシはサーバー上のコンテンツを翻訳し、すでに翻訳されたページを返します。
サイトのコードに触れる必要はありません。設定は開発ではなくDNSの問題です。
実際には:
- 静的および動的コンテンツは、ブラウザに到達する前に翻訳されます
- 各言語のURLは実際のものです: /ru/, /fr/, /de/
- 元のコンテンツが更新されると、翻訳も自動的に更新されます
- SEOは初日から機能します
実際の制限事項: すべての翻訳プロキシが動的コンテンツを翻訳するわけではありません。JavaScriptベースのものはブラウザで翻訳を挿入するため、SEOに悪影響を及ぼし、フォームは未翻訳のままになります。サーバー側で動作する翻訳プロキシのみがこれらの問題を回避します。
ウェブサイト翻訳における実際の問題
プロキシとAPIのどちらを選択する前に、それぞれの方法が特定の状況でどのように機能しなくなるかを理解する価値があります。
フォーム
フォームは最も問題のある点の1つです。フィールドのテキスト、エラーメッセージ、確認は通常、動的に生成されます。クライアントAPIでは、このテキストは遅れて表示されるか、まったく表示されません。JavaScriptプロキシでも同じです。サーバー側で動作するプロキシのみがフォームを一貫して翻訳します。
動的コンテンツ (JavaScript)
商品カタログ、リアルタイム価格、JavaScriptによって生成されるテキストはすべて、ページが読み込まれた後にブラウザに表示されます。クライアントAPIとJavaScriptプロキシは、まだHTMLに存在しないものを翻訳できません。結果：部分的に翻訳されたページ。
SEO
Google Search Centralの 公式ドキュメント, content rendered via JavaScript may be indexed with a significant delay or not indexed consistently. If translations depend on JavaScript, Google may not see them — or may see them weeks later.
With a server-side proxy, Google receives an already translated page. Each language version has a real URL, hreflang, and a place in the index.
E-commerce
オンラインストアでは、カタログ、価格、購入ボタン、確認ページが翻訳されている必要があります。購入プロセスが半分別の言語である場合、コンバージョンにはつながりません。また、Googleがインデックスしないカタログは、オーガニックトラフィックを引き付けません。
直接比較
では、どれを選ぶべきでしょうか？
直接API は、技術チームがあり、統合に時間があり、複雑なウェブアプリケーション、ユーザーコンテンツの翻訳、ドキュメント翻訳パイプラインなどの特定の要件がある場合に意味があります。
JavaScriptプロキシ は簡単にインストールできますが、クライアントAPIと同じSEOと動的コンテンツの問題を抱えています。非常にシンプルな静的サイトにのみ適しています。
サーバーサイドプロキシ は、コードを変更せずに言語を追加する必要がある既存のサイトにとって自然な選択肢であり、初日から機能するSEOと動的コンテンツのサポートを提供します。
問題は、市場に出回っているほとんどのプロキシがサーバーではなくブラウザで動作することです。
代替案はありますか？
一部のソリューションは、両方のアプローチの最良の部分を組み合わせています。サイトのコードを変更せずにサーバーサイドプロキシとして機能しますが、テキストだけでなくコンテキストを考慮した高度な翻訳モデルを使用します。
これは実際には何を意味するのでしょうか？
- CMSでページが重複しない
- 動的コンテンツは静的コンテンツと同様に翻訳されます
- SEOは最初から機能します：実際のURL、自動hreflang、各言語のサイトマップ
Multifyはまさにこのように機能します。DNSレベルで接続し、すべてをサーバーで翻訳し、各言語バージョンにSEO構造を自動的に生成します。
よくある質問
翻訳プロキシは直接APIよりも遅いですか？
必ずしもそうではありません。適切に実装されたプロキシは翻訳をキャッシュし、すでに処理されたコンテンツを提供します。追加される遅延は最小限であり、通常、エンドユーザーには気づかれません。
プロキシはどのウェブプラットフォームでも使用できますか？
ほとんどの翻訳プロキシは、DNS経由でルーティングできるあらゆるサイト（Tilda、WordPress、Webflow、または自社開発）で機能します。具体的な統合は、使用するサービスによって異なります。
コンテンツの変更時にプロキシ翻訳は自動的に更新されますか？
はい。元のサイトのコンテンツが変更されると、プロキシは変更を検出し、更新された翻訳を適用します。手動での介入、ファイルのエクスポートやインポートは不要です。
翻訳する必要のないコンテンツはどうなりますか？
翻訳プロキシでは通常、特定のURL、要素のCSSセレクター、または元の言語のままにする必要のあるテキストパターンなど、除外ルールを設定できます。Multifyにはこのオプションがあります。
