ヒンディー・英語ストアフロントのSEO：URL、hreflang、ワークフロー

なぜヒンディー＋英語ストアで SEO の重複が起きやすいのか

ヒンディー＋英語ストアの SEO 重複は、たいてい言語以外ほとんど同じに見える二つのページとして現れます。製品、見出し、メタタグが同じで、Google がどちらをどのユーザー向けに表示すべきか判断しにくくなります。

これは、翻訳済みURLを明確なシグナルなしに公開したときや、英語ページを複製して一部だけ言葉を変えたときに起こりがちです。その結果、「違う」ように見えるだけで価値を追加していないページ群が生まれ、薄いコンテンツや重複コンテンツとして扱われることがあります。

次にカニバリゼーションの問題があります。これは自サイト内の二つのページが同じ検索クエリで競合することを意味し、どちらも本来のパフォーマンスを出せなくなります。例えば、英語のカテゴリページとヒンディーのカテゴリページがともに「men shoes」を狙っている（ヒンディー版がほとんど英語の文面やタイトルのままになっている）と、Google はどちらを表示するかを切り替えたり、弱い方を評価したりします。

ヒンディー＋英語のストアSEOにおける目標は単純です：言語と検索意図ごとに一つの明確なページ。英語ページは英語のクエリをしっかり狙い、ヒンディーページはヒンディーのクエリをしっかり狙い、両者は明確に分離され相互関係が分かるようにします。

インドでは人々が一つのきれいな言語で検索するわけではないため、これが難しくなります。多くのユーザーが英語、ヒンディー、混合クエリ（ヒングリッシュ）で検索します。例えば「best pressure cooker 5 litre」や「saree under 1000」のような例です。もしヒンディーページが軽く編集した英語ページに過ぎないと、混合検索で英語ページと競合してしまうことがあります。

重複リスクを素早く見つける方法は次の点をチェックすることです：

• 言語を跨いで同じタイトルとディスクリプションが使われている
• 見出しや本文が非常に似ていて単語を入れ替えただけに見える
• ヒンディーページが読んでもほとんど英語のままに感じられる
• 同じ「購入」意図に答える複数のページが存在して言語フォーカスが不明瞭である

拡張可能な URL 構造の選び方

URL構造は、重複を防ぐか静かに生んでしまうかの最初の判断です。検索エンジンのクロール、パフォーマンス計測、英語とヒンディーのページを長期的に整合させる難易度に影響します。

一般的な構成は三つあります：

• サブフォルダ: example.com/en/ と example.com/hi/
• サブドメイン: en.example.com と hi.example.com
• 別ドメイン: example.in と example.com（またはヒンディー専用ドメイン）

大半のチームにとって、サブフォルダがデフォルトで最も良い選択です。すべてが一つのドメインの下にあるため、オーソリティ、クロール、レポーティングが一箇所にまとまります。canonical タグ、内部リンク、テンプレートの一貫性を保つのも簡単です。規模の小さいチームでは、この構成により翻訳ページの薄さや重複につながるミスが減ります。

サブドメインも機能しますが、実務では別サイトのように扱われがちです。解析が分割されたり、トラッキング設定が複製されたり、技術的なSEOチェックが二重になりやすく、メンテナンスの差が出て英語側が先に改善されヒンディー側が遅れることで品質ギャップが生まれます。

別ドメインは、ビジネスが本当に別である場合（履行ルール、価格、法的要件が異なる等）に意味があります。それ以外では手間が倍増します：サイトマップも別、オーソリティ構築も別、ミスマッチしたページが競合する機会が増えます。

選択より重要なルールが一つあります：パターンを決めたら全体に適用すること。 カテゴリが /hi/ にあるなら、製品、フィルタ、ブログ、サポートページも同じ構造に従うべきです。不整合なパターンは、同じ意図の複数URLが誤って公開される一般的な原因です。

英語・ヒンディーのためのクリーンな URL パターン

明確な URL パターンは、ページが言語の違いであって重複ではないことを分かりやすくします。ヒンディーと英語のストアSEOにおける最も単純なルールは：一言語＝一URL、常に、です。

一般的で明確なパターンは言語フォルダを使うことです：

• 英語: /en/
• ヒンディー: /hi/

こうすればページは分かりやすくなります：

• カテゴリ: /en/mens-shoes/ と /hi/purush-joote/
• 製品: /en/puma-running-shoe-12345/ と /hi/puma-daudne-joota-12345/
• ブログ: /en/blog/how-to-measure-feet/ と /hi/blog/pair-kaise-mapen/
• ヘルプ: /en/help/returns/ と /hi/help/returns/

ローカライズする部分と固定すべき部分

ユーザーが読む部分はローカライズし、システムが依存する部分は安定させます。

ローカライズするもの：

• カテゴリ、製品、記事、ヘルプの人間向けスラッグ
• サイト内に共通する語（"returns"、"shipping"、"size-guide" 等）

固定しておくもの（翻訳しない）：

• SKU、製品ID、バリアントID、そして 12345 のような安定した数値識別子
• 分析や在庫管理を支えるトラッキングパラメータや内部コード

URL の末尾に ID を残すと、後でヒンディースラッグが変わっても同じ製品にマッピングしやすくなります。

ホームページの言語選択と重複回避

“メイン”のホームページに見える複数の URL を持たないようにしてください。デフォルトを一つ選び、他は明示的にします。

シンプルな設定例：

• デフォルトホーム: /（英語か中立の選択画面どちらかを選ぶ）
• 言語別ホーム: /en/ と /hi/

/ に言語セレクタを置く場合、/?lang=hi や /?lang=en のようなインデックスされうるコピーを増やさないよう気をつけてください。これらは増えやすく管理が難しいです。言語切替はフォルダURLに紐づけ、各言語に一つのクリーンなアドレスを持たせるようにします。

ヒンフラング（hreflang）基本

hreflang は「これらのページは同じ製品やカテゴリで、書かれている言語や地域が違うだけです」と Google に伝えるための小さなマークアップです。単独でランキングを押し上げるものではありません。主に正しい言語のバージョンを正しい利用者に表示させ、ヒンディー版が英語版と競合しないようにするのが目的です。

インド向けの普通のセットアップは言語＋国の形式です：

• インド向けヒンディー: hi-IN
• インド向け英語: en-IN

もし他国向けの英語も提供するならグローバル英語に en を使い、インド特有の英語（INR 表示や配送ルールなど）には en-IN を残すこともあります。ページが実際にどれだけ違うかに応じて最小限のセットを選びましょう。

hreflang がページを "グループ化" する仕組み

hreflang はクラスターとして機能します。各言語版は他のバージョンを参照し、自分自身も参照する必要があります。例えば英語の製品ページはヒンディー版を指し、ヒンディー版は英語版を指し返すべきです。片方が他方の参照を忘れるとシグナルが弱まり、Google がそれらを別ページと見なすことがあります。

ここで多くのヒンディー＋英語のセットアップが失敗します：英語ページだけに hreflang を追加したり、一部のテンプレートだけに入れたりするため、Google は不完全なセットしか見えません。

x-default とはいつ使うか

x-default はユーザーを確実にどの言語・地域に割り当てるか判断できない場合のフォールバックページ用です。言語選択ページや言語を選ばせる中立的なゲートウェイページがある場合に有用です。

x-default を主要な言語ページの一つに向けないでください。すべてのユーザー向けの真のデフォルトでない限り、混乱を招きどのバージョンをランクさせるべきかのシグナルが混ざってしまいます。

重複を防ぐ canonical とインデックスルール

canonical タグと hreflang は役割が異なり、ほとんどの二言語ストアでは両方が必要です。hreflang はどの言語版をどのユーザーに見せるかを伝え、canonical は非常によく似た複数のページのうちどれが主要かを伝えます。

ヒンディー＋英語ストアの安全なデフォルトは：各実際の言語ページが自分自身に canonical を張ることです。英語製品ページは英語 URL を canonical にし、ヒンディー製品ページはヒンディー URL を canonical にします。そして相互に hreflang を参照させます。これにより両方のページがランキング対象になり得て、重複と見なされにくくなります。

もしヒンディーページをインデックスされたくない場合は、英語に canonical を張ることもできますが、その場合はヒンディー URL をランキング対象から実質的に外す意図があると検索エンジンに伝えることになります。テンポラリなプレースホルダや自動翻訳で内容が不十分な場合にのみ短期的に使うべきです。

インデックスルールは短時間で増殖するページに最も重要です：

• 内部検索結果ページには noindex を付ける。
• 近似した価値しかないフィルタ組み合わせは noindex を検討する。
• ファセットナビゲーションはユーザーにとって有用に保ちつつ、すべてのフィルタURLがインデックスされないようにする。

パラメータやソートの URL はインデックスの膨張源になりがちです。?sort=price や ?utm_source= のような URL があるなら、クリーンな「主要」バージョン（通常はフィルタ無しのカテゴリ）を決め、パラメータ版はすべてそこに canonical するとよいです。特定のフィルタが専用のランディングページに値するなら（例：「メンズ ランニングシューズ」）、そのフィルタ専用の固定 URL を作り、固有の文章を与えて本物のカテゴリとして扱ってください。

実用的な翻訳ワークフロー（ステップ・バイ・ステップ）

良いワークフローが、ヒンディーと英語のページがお互いに競合しないように保ちます。目的はすべてを翻訳することではありません。各言語でランクに値するページを公開し、正しい意図にマッピングすることが目的です。

実行可能なステップ・バイ・ステップ

1. ページの在庫を作り「両方に必要か片方で良いか」のルールを決める。 高い意図を持つページ（ホーム、上位カテゴリ、ベストセラー、配送、返品、問い合わせ）は両言語に置きます。ロングテールのフィルタ、ほぼ重複するサブカテゴリ、低トラフィックのランディングページは、検索獲得の証拠が出るまで一言語にしておきます。

2. 誰かがテキストに手を付ける前に翻訳ブリーフを書く。 語調（フォーマルなヒンディーか会話調か）、製品名や素材の用語集、サイズや単位の表示方法、配送・代金引換・返品・保証・オファーで使う正確な語句を含めます。これによりテンプレート全体で同じ語がばらばらに使われるのを防げます。

3. まずは商用ページをローカライズし、カタログ全体を最初に翻訳しない。 カテゴリイントロ、購入ガイド、FAQ、信頼情報などを優先して翻訳・適応します。製品ページは意思決定に影響する部分に注力：タイトル、主なベネフィット、仕様、ケア指示、配送/返品情報など。製品に元の英語が一行しかないような場合は、ヒンディーに翻訳しても薄いページになりがちなので、その製品は一言語のままにし、カテゴリやサポートページを翻訳する方が得策です。

4. SEO 要素を含む構造化された QA を実施する。 タイトルタグやメタディスクリプションは字面通りでなく意味でチェックします。H1 は一つだけか、見出しがきれいか、パンくずが適切な言語かを確認します。内部リンクとアンカーテキストが行き先の言語に合っているか（ヒンディーナビが英語ページを指し続けないか）も検証してください。

5. 小さなバッチで公開し、言語別にパフォーマンスを監視する。 20～50 URLs をリリースして、言語ごとのインプレッション、クリック、クエリを確認します。もしヒンディーページが英語クエリでランクし始める（または逆）なら、各ページが正しい言語意図に答えるようにコピーや内部リンクを調整します。ここで勝敗が決まります。

簡単な例：英語のカテゴリが “running shoes” と言い、ヒンディー版がページ間で複数の異なる表現を使っているなら、ブリーフで一つの主要なヒンディー表現を決めて一貫して使ってください。一貫性はユーザーに優しく、二つのページが取り替え可能と見なされる可能性を下げます。

もし Koder.ai のようなビルドプラットフォームを使うなら、ブリーフと用語集を共有リファレンスにしておき、同じテンプレートパーツ（配送、返品、サイズ説明）を再利用することで翻訳ページが半端で空っぽにならないようにできます。

製品・カテゴリテンプレートで薄いページを避ける方法

最も速く SEO の重複を生むのは、製品ごとにヒンディー版を全て公開することですがページに実際の情報がほとんどない場合です。ヒンディーページがタイトルの翻訳と短い一行だけだと、Google は価値が低いと見なす可能性があり、同じセクション全体の評価を下げたり、どの言語がランクすべきかを混乱させたりします。

テキストが少ない製品には単なる直訳以上が必要です。買い手の判断を助ける詳細を追加してください。短くしても構いませんが、箱の中身、サイズとフィットの注意、素材、手入れ方法、保証条件、地域別の配送予定、実際によくあるFAQをいくつか入れるなどページを「完結」させる必要があります。目標はヒンディーを英語より長くすることではなく、完結した内容にすることです。

良いテンプレートは“ほとんど空”のページを避けます。SKU ごと、カテゴリごとに埋められる一貫したブロックを用意してください：

• ページタイトル＋明確なページ内見出し（キーワードを詰め込まない）
• ページ内容と一致するメタディスクリプション
• 3～5 の FAQ（在庫、サイズ、支払い、返品など）
• 短く平易な配送・返品のスニペット
• 保証、COD ルール、交換期間のような信頼情報

インデックスを許可する前に最低限のコンテンツルールを設定してください。多くのプロジェクトがここで失敗します：すべてを翻訳してすべてをインデックス許可してしまうのです。

実用的なルール例：

• ページに完全なヒンディー説明文がない場合はインデックスしない（短い一文だけでは不可）
• 少なくとも FAQ 2 件がヒンディーで答えられていること
• 主要属性（サイズ、素材、互換性など）が翻訳されていること
• 条件を満たさないページは公開はしても noindex にする

例：ファッションカタログ 2,000 SKU のヒンディー提供を始めるとします。最初は上位200製品と上位カテゴリのみをインデックス許可し、残りはテンプレートを満たすまでインデックスを保留にします。Koder.ai のようなプラットフォームなら、これらのチェックをテンプレートに組み込み、バッチ公開で問題が出たらスナップショットとロールバックを使って安全に戻せます。

ヒングリッシュ（Hinglish）と混合意図検索の扱い

インドではヒングリッシュ検索が一般的です。人々はクエリの中でスクリプトや言語を混ぜます（例："wireless earbuds price" や "मिक्सर grinder 750w"）。SEO 的には検索者は同じ製品を探していることが多く、書き方の混合があるだけです。

有用なルール：ヒングリッシュを第三の言語バージョンとして扱わないこと。混合クエリだけを狙って別ページを作ると、主な英語またはヒンディーのページと競合するほぼ重複ページが出来やすくなります。

ブランド名、モデル番号、技術的識別子は言語間で一貫しておきましょう。これらの語句はヒンディーのクエリ内でも英語で入力されることが多く、統一することでユーザーと検索エンジンの両方が正しいページに辿り着きやすくなります。例えば “Philips HL7756/00” は英語・ヒンディー双方のページでそのままにしてください。

バイリンガル要素はページを混乱させずに助けになる場合があります。仕様、寸法、SKU、互換性の注記など、ユーザーが期待する箇所にだけ入れるとよいでしょう。単純なパターンとしては：ヒンディーのラベル＋英語の単位、またはモデル名を変えずにヒンディーの説明文を使う、などです。

ヒンディー＋英語のストアSEOで混合意図検索を取り込みながらカニバリゼーションを避ける際に通常うまくいくことは：

• 各ページはそのURL言語を主に使う（言語をベースにページを決める）
• モデル語句は同じにして説明部分だけ翻訳する
• バイリンガルのパンくずや仕様表は、明確さが向上する場合にだけ追加する
• カテゴリページは広い用語を、製品ページはモデル固有の用語をターゲットにする

期待値を設定してください：すべての言語ミックスで一つのページを完璧にランクさせるのは目標にしないこと。代わりにクリーンな英語ページ、クリーンなヒンディーページ、そして“中間”検索が正しいバージョンに着地するのを助ける小さなバイリンガル手がかりを目指します。

例：英語の順位を損なわずにヒンディーを導入する

D2C のパーソナルケア店が 500 製品を持っており、英語サイトはすでに製品・カテゴリ用語でランクしています。彼らはヒンディー版を導入したいが、重複や英語ページの順位低下は避けたい。これはよくある課題です：リーチを増やしたいが、二つのバージョンが互いに争うのは避けたい。

彼らは明確なフォルダ構造を選びます：

• 英語: /en/（例: /en/category/face-wash/）
• ヒンディー: /hi/（例: /hi/category/face-wash/）

一度にすべてを翻訳するのではなく段階的にローンチします。まず上位20カテゴリと上位100製品を翻訳・公開します。残りの400製品には薄いヒンディーページを作らず、準備が整うまで英語のみのままにしておきます。

重複を避けるために三つの単純なルールを守ります。各言語ページは自己参照 canonical を持ち、英語ページは以前と同様に動作します。翻訳ページには en ⇄ hi の hreflang 注釈が付きます。そしてヒンディーページはタイトルや数語を入れ替えただけで作られず、カテゴリイントロ、製品の利点、使用法、FAQ を書き直してヒンディーで本当に役立つページにします。

ローンチ後は Search Console と解析で週次監視を行います。2 週目にカニバリゼーションが見られ、ヒンディーカテゴリが英語クエリに出始め英語ページがわずかに落ちる現象が起きました。対処はシンプルです：ヒンディーページを自然なヒンディー見出しとヒンディーのキーワードに調整し、内部リンクが英語メニューから英語ページを指すように直し、hreflang が正しいか確認します。2 週間以内に結果は分離し、英語ページは英語クエリで、ヒンディーページはヒンディークエリでそれぞれ成長しました。

カニバリゼーションを引き起こす一般的なミス

カニバリゼーションは Google が複数のページを同じクエリへの競合する回答と見なすときに起きます。ヒンディー＋英語のストアでは、意図は良くてもヒンディーを急いで導入するとランキングが不安定になることが多いです。

よくある発端は自動翻訳をそのまま公開し、すべてをインデックスさせてしまうことです。ヒンディー版がぎこちないか英語の構造をなぞっただけだと薄く見え、Google は同じキーワードでそれをテストしてバージョンを切り替えます。

hreflang のミスも頻繁な原因です。ヒンディーページが英語を指すが英語ページが戻りリンクを持たない（返しの参照がない）場合、シグナルは弱くなります。言語や地域コードの誤り、hreflang が非カノニカル URL を指していることも混乱を招きます。

canonical タグは誤って状況を悪化させることがあります。英語とヒンディーの両方を同じ英語 URL に canonical してしまうと、検索エンジンに「これらは重複だから英語だけ残して」と伝えることになり、ヒンディーが結果から除外されたり、両方がインデックス競争する原因になります。

同じ意図に対して多数のページがある場合にも注意が必要です。例えばナビゲーションとサイト内検索で別々に使われる二つの異なる翻訳があると、同じクエリを別URLが別々に狙うことになります。

ファセットフィルタは問題を静かに増やします。サイズ、色、ブランド、価格のフィルタがインデックス可能な URL を生むと、価値の少ないカテゴリのように見える大量のページが生成されます。

まず監査すべきパターンは次のとおりです：

• 機械翻訳されたページを品質チェックなしで全部インデックス化している
• hreflang に返しのリンクがない、または間違った URL を指している
• canonical がヒンディーと英語を同じ URL にまとめている
• 命名の不整合で重複するヒンディーカテゴリが作られている
• フィルタやソート URL がスケールでインデックスされている

簡単な現実チェック：自サイトで上位カテゴリの語句を両言語で検索し、人が見て「同じページ」と呼ぶような複数の URL が見つかれば、Google も同じ問題を認識している可能性が高いです。

公開前のクイックチェックリスト

ヒンディーページを公開する前に、基本を落ち着いて確認してください。ほとんどの順位低下は小さなシグナル（URL、canonical、hreflang、内部リンク）が互いに矛盾することで起きます。

公開準備チェックリスト

公開リリースの最終ゲートとしてこれを使ってください：

• 一つの URL パターンを全体で適用する。 ホーム、カテゴリ、製品、ブログ/ヘルプ、ランディングページすべてに同じルールを適用し、フォルダとパラメータを混在させない。

• 各言語ページは自己 canonical。 英語ページは英語に、ヒンディーページはヒンディーに canonical を張る。クロスカノニカルは、片方を唯一のインデックス対象にしたいときだけ使う。

• 完全で正しい hreflang セット。 各英語ページはそのヒンディー版を指し、ヒンディー版も英語版を指す。真のデフォルトページ（言語選択ページなど）がある場合のみ x-default を含める。

• 価値の低い重複はインデックスしない。 フィルタ、内部検索結果、近似したソート順の変種は通常 noindex にする。一方でコアページはクロール許可する。

• 翻訳 QA はテキストだけでない。 ページタイトル、H1/H2、メタディスクリプション、必要に応じた画像 alt テキスト、内部リンク（同言語への遷移になっているか）、およびローカライズ可能な構造化データ（製品名など）を確認する。通貨、配送文言、返品ポリシーの断片も対象に含める。

ローンチ後は /en/ と /hi/ を別々に追跡することが安全策になります（ランキング、クリック数、インデックス数、上位クエリ）。ヒンディーページが伸びているが英語ページが落ちるようなら、ロールアウトを遅らせテンプレートを修正してから翻訳を進めてください。

次のステップ：シンプルなローンチ計画とツール

まずデフォルト言語を決めます。インド向けでは多くのストアが新規訪問者には英語をデフォルトにし、URL を変える明確な言語切替を提供します（単にページ内の文言を切り替えるだけにしない）。ヘッダー、フッター、チェックアウトで切替を一貫させ、ユーザーが途中でバウンスしないようにします。

ローンチを波に分けて行い、影響を測って問題を直してから次へ進む計画を立てます。実用的な順序は：上位収益カテゴリ→そのカテゴリ内のベストセリング製品→ロングテール、です。これによりヒンディーページを検索効果の高いクエリに集中させ、薄いページのリスクを減らせます。

翻訳ページがインデックスされる前にシンプルな品質ゲートを設定します。各ヒンディーページが単独で有用であることが目標であり、英語のコピーをそのまま競合させるのは避けます。

• ローカル向けの情報を少なくとも2～3点追加する（配送、サイズ、使用上の注意、FAQなど）
• タイトルとメタディスクリプションは機械翻訳ではなくヒンディーの検索意図に合わせて作成する
• 内部リンクが正しい言語版を指していることを確認する
• hreflang の対は完全であること（hi-IN と en-IN、または選んだセット）
• 価値の低いページは基準を満たすまで noindex にする

ツールとしては、Google Search Console でインデックスとカニバリゼーションを早期に検出し、クロールツールで hreflang と canonical を大規模に検証することをお勧めします。再構築を行うなら、チャットで構造を説明して React ページを素早く生成できる Koder.ai のようなプラットフォームで /en/ と /hi/ のルートをプロトタイプし、スナップショットとロールバックで本番前に安全に反復するのが有効です。これにより作業は管理可能、計測可能、そして取り消し可能になります。