英語の/enプレフィックスは有効であり得る
多言語サイトでは、英語に /en、ヘブライ語に /he を使用できます。英語をルートに置く設計も有効です。問題は、管理されていない重複と矛盾するシグナルです。例えば、 /services と /en/services が同じ英語ページを配信しているのに、リンク、canonical、サイトマップの指定が一致していない場合です。
このプロジェクトは英語をルートに置き、ベンガル語、ヘブライ語、アラビア語を含むその他のサポート言語にプレフィックスを付けます。これはプロジェクトの規約であり、普遍的なSEOのルールではありません。冗長な英語プレフィックス付きパスは、対応するルートパスにリダイレクトします。既に /en を中心に一貫して整理されているサイトは、その規約に従うためだけに移行する必要はありません。 多言語URL構造に関するGoogleのガイダンス.
同等のページを明示的にマッピングする
本物の翻訳はそれぞれ、通常は自身の推奨URLにcanonical化すべきです。現在のページへの参照を含め、相互の hreflangで同等のバージョンをリンクします。絶対URLと有効な言語コードを使用します。 x-default は、特定の一致がない言語のフォールバックを識別します。すべてのページが英語であることを意味するものではありません。
例えば、英語のサービスページはそのベンガル語、ヘブライ語、アラビア語の同等ページを指すことができ、各同等ページが同じクラスターを返します。別の言語のホームページへのリンクは、欠落しているサービス翻訳の代わりにはなりません。
変更されていない英語の記事の周りに翻訳されたナビゲーションがあっても、翻訳された記事が作成されるわけではありません。このサイトでは、記事の翻訳は、翻訳された本文コンテンツが利用可能な場合にのみ、自身のcanonical URLと相互の言語リンクを受け取ります。英語のソースをまだ表示している言語URLは英語のcanonicalを指し、翻訳クラスターから除外されます。Googleの ローカライズ版リファレンス は、相互の注釈と未翻訳の本文コンテンツについて説明しています。
HTMLと読み方向を確認する
サーバーが返すHTMLには、適切な lang 属性を含めます。ヘブライ語とアラビア語には dir="rtl" が必要です。レイアウトには論理的なstart/endプロパティを使用します。メールアドレス、URL、製品名など、左から右に読む値が意図しない順序で表示される場合は、読み方向を分離します。言語メタデータは、読みやすく正確に翻訳されたコンテンツの代わりにはなりません。
実践的なリリースレビュー
- ブラウザのJavaScriptなしで各言語の代表的なURLを1つリクエストし、タイトル、canonical、言語、見出しを検査します。
- 代替言語リンクを両方向にたどり、同等のコンテンツに正常に解決されることを確認します。
- サイトマップには推奨され公開されたURLのみを保持します。トラッキングのバリアント、空のコレクション、下書きは除外します。
- プレビューホストがHTTPヘッダーまたはHTMLのmetaタグで
noindexを返し、本番環境はインデックス可能な状態であることを確認します。クローラーがその指示を読み取れるよう、プレビューページの取得は許可してください。 - サービス、記事、問い合わせフォームで、直接読み込みと記憶された設定を含め、言語切り替えを試します。
noindexの動作は Googleのインデックス制御ガイダンスに従います。これらのチェックは一貫した発見を支援しますが、ランキングを約束するものではありません。実装の支援については、 ウェブ開発 と、補助的な テクニカルSEOサービス.
