SEOとローカリゼーションの両方のURLをどのように構成する必要がありますか?


111

複数の言語でサイトを設定する場合、検索エンジンと使いやすさのためにURLをどのように設定すればよいですか?

私のサイトがwww.example.comであり、フランス語とスペイン語に翻訳しているとしましょう。ユーザビリティとSEOに最適なものは何ですか?

ディレクトリオプション:

http://www.example.com/sample.html
http://www.example.com/fr/sample.html
http://www.example.com/es/sample.html

サブドメインオプション:

http://www.example.com/sample.html
http://fr.example.com/sample.html
http://es.example.com/sample.html

ファイル名オプション:

http://www.example.com/sample.html
http://www.example.com/sample.fr.html
http://www.example.com/sample.es.html

Accept-Languageヘッダー:

または、単にAccept-Languageヘッダーを解析し、そのヘッダーに合わせてコンテンツサーバー側を生成する必要がありますか?

これを行う別の方法はありますか?異なる言語バージョンに異なるURLがない場合、検索エンジンについてはどうすればよいですか?


更新2011-12-06

Googleにはmeta、他の言語コンテンツを明示的にポイントするためのタグに関する新しい推奨事項があります。多言語コンテンツの新しいマークアップです

更新2012-05-25

関連するが正確ではない:サイトマップの多言語および多国籍のサイトアノテーション

更新2013-06-12 サイトコンテンツを特定の国ターゲティングするには、質問に直接関連するいくつかのURLスキームの議論が含まれます。


この質問は、いくつかの良い、関連する情報があります。 webmasters.stackexchange.com/questions/961/...
JasonBirch

また、翻訳するだけでなくローカライズする場合は、「en-us」、「de-de」などのコードの使用を検討する必要があります。
webjunkie

サイモン・ヘイター。質問に対する変更はロールバックされました。追加したものは、既存の質問のいずれにも対応していません。より複雑なオプションセットを使用して新しい質問を作成する場合は、お気軽にご質問ください。ただし、私の質問を変更すると、ユーザーが混乱するような方法で質問と回答が歪められます。ありがとう。
-artlung

回答:


92

SEOと国際化の両方のためにサイトを構成するには、多くの受け入れられる方法があります。それぞれに長所と短所があります。

トップレベルドメイン

以下のような複数のトップレベルの国のドメインで同じドメイン名を購入するexample.comexample.esexample.de

長所

  • Googleにより完全にサポートされています。Googleウェブマスターツールにサイトを追加すると、ターゲットをどのように設定するかをGoogleに伝えることができます。
  • 自国のTLDで公開されているコンテンツを好む傾向があるユーザーによく好まれます
  • ドメイン名自体はローカライズできます。多くの国際ユーザーは、英語の単語や英語の発音のドメイン名に対してひどく反応するかもしれません。これは、ラテンアルファベットを使用しない言語では特に重要です。
  • 国ごとのローカライズをサポートします。さまざまな国の視聴者example.co.ukexample.com.au対象にした別々のサイトを作成できます。これらのサイトには、スペルがわずかに異なる重複したコンテンツが含まれている可能性がありますが、それでもランクは高くなります。実際、同じ言語の複数のローカライズされたサイトは、その言語の単一のサイトよりもランクが高い場合があります。
  • ホスティングは、ターゲットにされている国のWebサーバーにDNSを向けることでローカライズできます。

欠点

  • 多くのドメインを購入するには費用がかかり、時間がかかります。特に不法占拠者に対処する必要がある場合。
  • Cookieは複数のロケール間で共有できません。つまり、ユーザーは各サイトに個別にログインする必要があります。
  • 多くの言語には複数の国があり、言語コードに国TLDがない場合があるため、言語のみでローカライズするための適切なオプションはありません。TLDがなどの言語コードと一致する場合でもes、検索エンジンは、サイトがスペイン語を話す人すべてではなく、スペインのユーザーにのみ適していると想定する場合があります。

サブドメイン

単一のドメインを購入し、などのサブドメインを使用しen.example.comes.example.com

長所

  • Googleにより完全にサポートされています。
  • または言語によるローカライズをサポートします。
  • DNSをユーザーの近くにあるWebサーバーにポイントすることにより、ホスティングをローカライズできます。
  • 複数のドメインを購入するのに比べて、実装が簡単で安価です。
  • Cookieはすべてのロケールで共有できるため、シングルサインオンを使用してよりシームレスなユーザーエクスペリエンスを実現できます。

欠点

  • ドメイン名自体をローカライズする機会はありません
  • トップレベルのドメインに比べて、ユーザーにとってローカルに見えないことがあります。

サブディレクトリ

単一のドメインを購入し、などのサブディレクトリを使用しexample.com/en/example.com/es/

長所と短所

  • サブドメインと同じですが、異なるロケールの複数の国でサイトをホストできないDNSエントリが1つあります。

推奨されない手法

  • ファイル名index_en.htmlやなどの異なるファイル名を使用しますindex_de.html。この手法は、Googleでは完全にサポートされていません。たとえば、ウェブマスターツールでターゲティングを設定する方法はありません。
  • URLパラメータ:などのURLパラメータを使用しますlang=en。同じ理由で、異なるファイル名が推奨されないことは推奨されません。
  • 言語ヘッダーを受け入れるヘッダーに基づいて言語を自動的に切り替えAccept-Languageます。
    • 多くのユーザーは、このヘッダーを正しく設定していません。これは、友人のコンピューターまたはインターネットカフェを使用している可能性のある海外旅行ユーザーに特に当てはまります。また、英語のWebブラウザーをインストールし、十分な英語を知っているが、別の言語のコンテンツを好む国際的なユーザーにも当てはまります。
    • Googleは、GooglebotがAccept-Languageさまざまな地理的場所からヘッダーとクロールを送信することを発表しました。ただし、異なる言語のコンテンツには個別のURLを使用することをお勧めします。
    • Accept-Languageヘッダーを使用して、訪問しているサイトがAccept-Languageヘッダーと一致しない場合にメッセージを表示することにより、ユーザーが別のバージョンのサイトを好む可能性があることを示唆できます。
  • 地理的IPアドレス:IPアドレスが地理的に配置されている場所に基づいて言語を自動的に切り替えます。

オンページマークアップ

複数の言語をサポートする場合、言語メタデータで明確にマークアップする必要があります。

htmlタグでlang属性を使用します。

<html lang="en">

Googleが提案する他の言語の同じページへのrel代替リンクを使用します

<link rel="alternate" hreflang="es" href="http://www.example.com/" />
<link rel="alternate" hreflang="es-ES" href="http://es-es.example.com/" />
<link rel="alternate" hreflang="es-MX" href="http://es-mx.example.com/" /> 
<link rel="alternate" hreflang="en" href="http://en.example.com/" />

または、この情報をサイトマップファイルに入れることができます

サイトについてGoogleに伝える

サイトの各言語(またはロケール)をGoogle Webmaster Toolsに追加する必要があります。これは、トップレベルドメイン、サブドメイン、またはサブディレクトリに対して実行できます。

サイトが国によってターゲティングされている場合、ウェブマスターツールを使用してサイトターゲティングを設定する必要があります。[構成]-> [設定]-> [地理的ターゲット]に移動し、ドロップダウンリストから正しい国をターゲットに選択します。


「サブドメインと同じ。ただし、異なるロケールの複数の国でサイトをホストすることを妨げる1つのDNSエントリが存在する。」-それは、多くの異なる国で1つのWebサイトをホストできない単一のドメインがあるためではないことに注意してください。私たちが持っているすべての技術で、それは「簡単」です。また、Cassandraなどのシステムを使用する場合、データは問題ありません。
アレクシスウィルク

「特に不法占拠者に対処する必要がある場合」 -不法占拠者とは何ですか?
デイブ

ドメイン名不法占拠者はドメイン名のバリエーションを購入します。この場合、example.comを所有している可能性がありますが、不法占拠者はexample.co.ukとexample.itを奪い取った
Stephen Ostermiller

サイトマップ多言語および多国籍のサイトアノテーションを追加することを検討してください。回答
Pmpr

Googleよると、ディレクトリまたはサブドメインオプションのいずれかであることに注意してください。
ジョアンピメンテルフェレイラ

22

彼のブログであなたと似た質問に答えると、Matt Cuttsは提案します:

たとえば、ビジネス向けにフランス語版とドイツ語版のサイトがある場合、私の好みは次のとおりです。

  1. example.frやexample.deなどのccTLDS
  2. その後、fr.example.comやde.example.comなどのサブドメイン。
  3. それが不可能な場合は、example.com / fr /やexample.com/de/などのサブディレクトリを使用します

1
オプション2が3よりも優れている理由を教えてください。ありがとう
ジョアンピメンテルフェレイラ

Googleの専門家よると、オプション2と3はランキングの目的で同じです。
ジョアンピメンテルフェレイラ

20

ドイツ語のユーザーとして、ウェブサイトが英語のページを表示させないのは嫌いです。なぜなら、私が望むものをよく知っていると思うからです。アメリカ人が理解するのは難しいかもしれませんが、実際には複数の言語を話す人々がいます。

ドイツのウェブサイトを見たい場合もあれば、英語のウェブサイトを見たい場合もあります。

Accept-Languageヘッダーを単純に解析するだけでは気が狂うかもしれません。

ドイツ語のページが英語のページの安価な翻訳である場合は特にそうです。

ユーザーが簡単に使用できるようにするには、英語版にもまたはなどのローカライズがdomain.com/en/必要en.domain.comです。

入力するとdomain.comAccept-Languageヘッダーに基づいて英語またはドイツ語のページが表示されます。ただし、あなたの選択が気に入らない場合は、ドメイン名の言語を簡単に交換できるはずです。

エクストラヒント:あなたは、ドメイン名の両方タイピングの前に言語を持っている場合ger.domain.comde.domain.comドイツ語のウェブサイトに私を持参してください。


7
+1It might be hard for Americans to understand but there are actually people who speak more than one language.
TheBlackBenzKid

15

私の意見では、フォルダまたはサブドメインのアプローチを使用する必要があります。これらはユーザーにとってより直感的だからです。どちらが個人的な好みの問題であるか、私は個人的にフォルダーのアプローチが明確であると思います。ファイル名オプションは、はるかに直感的ではありません。

Accept-Language最初の訪問でユーザーを正しいコンテンツに誘導するためにヘッダーを解析することは良い考えですが、フォルダーまたはサブドメインのURLにリダイレクトする場合にのみ行う必要があります。そうしないと、特定の言語のコンテンツにリンクすることができなくなり、Webサイトのインデックス作成が面倒になります。


7
また、ヘッダーの内容に関係なく、常にユーザーに選択肢を提供します-ドイツ語版が提供されると、翻訳がひどいため、または英語(MSDN、例-すべてのコードは英語であるため、ドイツ語のテキストを使用するとコンテキストの切り替えが増えます)
balpha

+1 balpha-これは、モバイルフレンドリーサイトは常にデスクトップのフルバージョンのページへのリンクを提供する必要があるというヤコブニールセンの主張に似ています。ページの複数のバージョンが存在する場合、ユーザーが希望するページを情報に基づいて推測しますが、ユーザーに最終的な選択をさせます。
ブラズモンガー

5

ローカライズされたバージョン(つまり、フランス!=フランス語)を使用する場合は、サブドメインオプションを使用します。サブドメインを使用しますが、この国が異なる言語を使用している場合は、ディレクトリを使用した方が良いと思います。例えば:

us.domain.com (USA)
us.domain.com/en/sample.html (USA - english)
us.domain.com/es/ejemplo.html (USA - spanish)
es.domain.com (Spain)
es.domain.com/es/ejemplo.html (Spain - spanish)
es.domain.com/ca/exemple.html (Spain - catalan)

Bingはジオメタタグに依存していますが、Googleの場合はGoogleウェブマスターツールを使用する必要があります。

グローバル市場をターゲットにしたい場合www.domain.comは、優先ユーザー言語(ブラウザーでAccept-Languageヘッダーに言語の優先順位を与える)を使用するか、主要市場言語を使用します(使用しない場合)。


5

これは、Stack Overflowで尋ねたのと同じ質問です。そして、そのためのリソースを入手しました。回答としてここに投稿します。

あなたができる選択について、Googleから素晴らしいリソースを見つけました。使用できる各方法の長所と短所のセクションがあります。

私は今、多言語のウェブサイトでしばらく苦労しています。言及された回答に記載されていない記事には間違いなくいくつかのポイントがあります。これが答えとしてこれを投稿する必要性を感じた理由です。これが誰かの助けになることを願っています。


3

サブドメインは使用しません。SEOの観点からはあまり役に立ちません:http : //www.hobo-web.co.uk/seo-blog/index.php/blog-subdomain-or-subfolder-which-is-best/

ここで同様の話: サブドメイン対サブディレクトリ

大きなサイトを見ると、ほとんどの場合サブドメインを使用しています。

また、ビジネスがグローバルなものかローカルなものかによって異なります。私たちは著作権保護機関ですので、よりローカルなビジネスを利用するために。したがって、トップレベルドメインは、すべてを実行するよりも優れています.com

ファイル名は、私がまだ見たことがない概念です。


1

SAASベースの製品のシングルページアプリケーション(SPA)など、この方向への最新の採用-

  1. 国ごとに異なるウェブサイトを使用すると、メインブランディングドメインへのリンクジュースが失われます。例えば: - https://www.example.in/https://www.example.fr/など(アマゾン、ビッグEコマースの巨人は彼の過去にこのミスを犯しました。)

  2. SPAで同じドメインを使用し、すべての訪問者をそれにリダイレクトすることは問題ありませんが、この場合は1つの言語のみをターゲットにできます。国によって言語が異なるため、ユーザーエクスペリエンスが低下します。

  3. この事例には多くの最良の例があります(例:Microsoft&Uber)私は彼らがやっていることを個人的に気に入っており、彼らが最高のSEOプラクティスを使用していると信じています。

    When Lang-さまざまな国の英語。

    • https://www.example.com/en-in (インド向け)
    • https://www.example.com/en-au/ (オーストラリア向け)

    または

    • https://www.uber.com/en/in/ (インド向け)、
    • https://www.uber.com/en/au/ (オーストラリア向け)
    • https://www.uber.com/fr/ (フランス向け)

    ラングとカントリーが同じ場合-

    • https://www.example.com/fr-fr/またはhttps://www.example.com/fr/fr/(フランスの場合)
    • https://www.example.com/ru-ru/またはhttps://www.example[dot]com/ru/ru/(ロシアの場合)

詳細については、Google Search Consoleヘルプ:多地域および多言語サイトの管理 をご覧ください。


SEOが重要な場合、シングルページテクノロジーの使用はお勧めしません。
スティーブンオステルミラー

わーい!しかし、私はアプリケーションがUIとUXの目的のためにそれを必要とした場合に備えています。
Premnath321
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.