Google ウェブマスター向け公式ブログ

スマートフォンの普及が現在急速に進んでおり、それに合わせてスマートフォンに最適化されたコンテンツも日々増えています。私たちは以前、Google 検索と相性の良い携帯電話 / スマートフォン向けウェブサイトを運営する方法 をご紹介しましたが、その後も Google は、スマートフォンに最適化されたコンテンツの対応の向上に努めてきました。その取り組みの一環として、スマートフォン専用コンテンツを識別する方法として、2011年12月に スマートフォン版 Googlebot-Mobile を導入 しました。

そして今回、Google がお勧めするスマートフォンに最適化されたウェブサイトの構築方法、そしてデスクトップとスマートフォンにそれぞれ最適化された両方のサイトが Google の検索結果で良い結果が得られるような方法を説明したいと思います。

スマートフォンに最適化されたサイト構築の推奨方法
私たちの推奨する方法の詳細については、こちらのサイト（英語）でご確認ください。

簡単に要約しますと、スマートフォンに最適化されたサイトを構築する際に、Googleは、次の 3 つの構成をサポートしています。

1. レスポンシブ・ウェブデザインを使用しているサイト、すなわち、すべてのデバイスに単一の URL で同じ HTML を提供し、CSSを使用してデバイスごとにデザインを変更するサイトです。こちらが Google の推奨する設定方法となります。
2. すべてのデバイスに対し単一の URL で、ユーザーエージェントに応じてデスクトップ用かモバイル用かなどを判断して動的に異なる HTML と CSS を提供するサイト。
3. モバイル用のサイトとデスクトップ用のサイトを別々に構築しているサイト。

レスポンシブ・ウェブデザイン
レスポンシブ・ウェブデザインは、CSS3のメディアクエリを使用して見た目を変更するWeb ページの構築手法です。つまり、デバイスに関わらず共通の 1 つの HTML を用意し、CSS メディアクエリを使用して、そのページを表示する画面サイズからデバイスを判断しCSSを選択し、そのデザインを変更します。レスポンシブ・ウェブデザインについてより詳しい情報は、Google のウェブマスターによる こちらの記事（英語）や 今回の推奨方法のセクション（英語）をご覧ください。

レスポンシブ・ウェブデザインを使用すると、次のような利点があります。

• PC 用のページとモバイル用のページを単一の（同一の） URL とすることができるため、ユーザーにとってはシェアやリンクが容易であり、Google のアルゴリズムにとってはコンテンツを適切にインデックスできるようになります。
• ユーザーエージェントの異なる Googlebot ごとにページをクロールする必要がないため Google がより効率的にコンテンツを発見することができます。

デバイスごとに最適化した HTML
しかし Google は、レスポンシブ・ウェブデザインを使用することが適切とはいえない状況があることを理解しています。そのため、私たちはサイトがデバイスごとに最適化した HTML を使って同等のコンテンツを提供することをサポートしています。デバイス固有の HTML の提供方法は、デスクトップ版とスマートフォン版で同じ URL（動的な配信と呼ばれています）で提供する方法と、異なる URL（たとえば、www.example.comとm.example.comなど）で提供する方法に分けることができます。

あなたのサイトが動的な配信をされている場合、ユーザーエージェントごとにコンテンツを変えている事をキャッシュサーバや Google のアルゴリズム伝えるために Vary HTTP ヘッダを使用することを強くお勧めします。また、Googlebot-Mobile でもクロールのシグナルとして利用します。詳細は こちら をご覧ください。

デスクトップ版とモバイル版で別のサイトを構築しているケースに関しては、その実装方法は様々な方法が考えられますが、重要なのは、デスクトップ版とモバイル版がそれぞれ存在しつつも同一の目的、内容のページであればそのことを我々のアルゴリズムにアノテーションで伝えることです。アノテーションを利用することで、デスクトップ用のページとモバイル用のページとして別々に作られたページが実はデバイスごとに最適化して作成された同一の内容であり、同一のものとして取り扱われるべきことを Google に伝えることができます。

これらのアノテーションは、Google があなたのスマートフォンに最適化されたコンテンツを発見し、アルゴリズムがコンテンツの構造を理解する助けになり、そして検索結果においても良い結果が得られる可能性が高まります。

結論
このブログ記事は、Google がお勧めするスマートフォンに最適化されたサイトの構築方法の要約です。より詳しい内容につきましては、完全版をぜひご覧いただき、みなさまのサイトに最適な実装方法を見つけて頂ければと思います。

また、ウェブマスター ヘルプフォーラムではこの記事に関するご質問を受け付けています。（質問締め切り：2012 年 6 月 22 日）この記事に関するコメントやご意見・ご感想は、ウェブマスター ヘルプフォーラムのこちらのスレッド までお寄せください。

Posted by Pierre Far, Webmaster Trends Analyst
Original version: Recommendations for building smartphone-optimized websites

「私たちのサイトが突然、検索でほとんど表示されなくなってしまいました。ところが私たちは何も心当たりがないのです。調べてみたところ、サイトの制作を依頼していた会社が勝手に行った施策が『ウェブマスター向けガイドライン』というものに違反していたことが原因だったとわかりました。」

このように、サイトオーナーの気づかぬうちに Google の ウェブマスター向けガイドラインの「品質に関するガイドライン」違反となるような施策が行われ、ガイドラインに違反してしまったケースが最近増えているようです。あまりウェブに詳しくないサイトオーナーの方や、まだ経験の浅いウェブマスターの方々にはウェブスパムの存在やウェブマスター向けガイドラインの存在を知らない方も多く、その結果、気づかぬうちに Google のウェブマスター向けガイドライン 違反となるような施策が行われ、ガイドラインに違反するという状況が数多く見られます。

こうしたケースは特定の業者のみによるものではありません。そこで今回は、みなさまがこのような事態に陥らないよう、そもそも Google がなぜ「品質に関するガイドライン」を作成したのかというところから、どうすれば冒頭のような事態を避けられるかまで、ご説明したいと思います。

ウェブマスター向けガイドライン（品質に関するガイドライン）とは
Google 検索が目指しているのは、Google の創業者で現 CEO のラリー ペイジが紹介している通り、「（完璧な検索エンジンとは、）ユーザーの意図を正確に把握し、ユーザーのニーズにぴったり一致するものを返すエンジン」です。Google はこうした検索エンジンを目指し、日々改善を重ねています。一方で、ウェブマスターや SEO 業者の中には、自身のサイトの掲載順位を上げるためにユーザー向けに内容を改善するのではなく、実際よりも良いサイトであると検索エンジンに対して偽装をしたりなどして、検索エンジンを騙すことでランキング操作をしようとする人達がいます。これらの手法は“ブラックハット SEO” や “ウェブスパム” と呼ばれています。このようなサイトを放置しておくと、ユーザーにとってほとんど価値のないページや本来上位に表示されるべきでないページを検索結果として表示することになり、検索エンジンの品質が低下してしまいます。そこで Google はユーザーの利便性を守るため、ウェブマスター向けガイドラインの品質に関するガイドラインでこのような検索エンジンを欺く不正行為を示し、このガイドラインに違反した場合は検索結果においてユーザーの目に触れにくくなるようアルゴリズムまたは手動によるスパム対策を実施させて頂く場合があることをあらかじめ公開し、それを遵守するようお願いしています。

※ブラックハット SEO と呼ばれる手法には様々な種類があり、例えば機械的に作成され、日本語として意味を成さないテキストで構成されたサイト や、アフィリエイトリンクだけで構成された、ほとんど 何のオリジナルな情報もないサイト、そして 誘導ページ や 有料リンク などがあります。

気づかぬうちにガイドライン違反とならないために気をつけたいポイント
それではこのような事態にならないためにはどうすればいいでしょうか。上のケースでは、サイト制作を依頼していた業者が何の説明もなく行なっていた悪質な施策により、ガイドライン違反となりました。この他にも、事前に SEO 施策について伝えられたものの、それがガイドラインに違反する手法かどうかについて説明がなされないようなケースなどもあるようです。そこで、このように外部の業者を利用する場合にガイドライン違反にならないよう気をつけたいポイントをご紹介します。

• ウェブマスター向けガイドラインの品質に関するガイドライン に目を通しておく
• SEO 業者は慎重に選ぶ
  ヘルプ記事「検索エンジン最適化（SEO) 」には、SEO を発注する際の注意事項がまとめられています。SEO 業者の中には高度な専門性を有し、ガイドラインを熟知した信頼出来る所もあれば、ガイドライン違反の手法を提案する所もあるようです。この件についてはウェブマスターヘルプフォーラムでも 関連スレッド がありますので、よく分からない点などありましたらぜひご質問いただければと思います。
• ウェブマスター ツールを常にチェックする
  外部の業者に発注している場合でも業者に全て任せてしまうのではなく、ご自身で常にサイトに何か問題は発生していないか目を光らせることは重要です。このような場合に役立つのが、ウェブマスター ツール です。例えば、
• ガイドライン違反の通知はウェブマスター ツールに届きます。外部の業者にすべて任せるのではなく、必ずアクセスできるようにすることを強くお勧めします。また、この通知は登録している メールアドレスへ転送する ことが可能ですので、ウェブマスターツールにアクセスしていないときでも、何か通知を受け取った場合にはそれを知ることができます。
• 「サイトへのリンク」で外部のサイトからのリンクをチェックできます。何かリンク操作が行われているかどうかなどはここで確認することが可能です。

ガイドライン違反の通知が届いた場合の対処方法
ウェブマスター向けガイドラインに違反した場合、多くの場合 Google からメッセージをお送りしています。ガイドラインに違反してしまった場合、SEO 施策にどんなにお金を払っても期待される効果は望めなくなってしまいますので、ガイドライン違反の通知が届いた場合には、違反箇所をすべて修正し、どのような対処をされたか、修正箇所を列挙するなど細かく記載した 再審査リクエスト をウェブ マスターツール経由で送ってください。SEO 施策などを外部に依頼していた場合は、依頼していた会社にどのような施策をしたのか、確認してみてください。ときおり途中経過をお送りいただくことがありますが、途中経過で違反が解除されることはありませんので、すべて修正した後にお送りください。

私たちは、Google 検索が少しでもみなさまのお役に立てるよう今後も改善を重ねていきます。
ご意見・ご感想は、ウェブマスター ヘルプフォーラム までお寄せください。

Posted by Takeaki Kanaya, Search Quality Team

サイトを管理していると、サイト全体またはサイトの一部を別の場所に移動しなければならない場合があります。たとえば、コンテンツをサブディレクトリからサブドメインに移動したり、まったく新しいドメインに移動したりするケースです。このようなコンテンツの場所の移動は多少努力が必要ですが、この作業を正しく行うことは重要です。

新しいサイトの構造を検索エンジンが認識できるようにし、サイトにユーザーが問題なくアクセスできるようにするには、次の項目を参考にしてください。

• 301 リダイレクト を使用して、移転前のコンテンツの URL にアクセスするすべてのユーザーやクローラーを移転先の URL にリダイレクトすることが重要です。2 つの場所の関係を明確にするために、元の URL がそれぞれ、同様のコンテンツをホストする新しい URL を指すようにします（全てのページを新しいサイトのトップページにリダイレクトするのではなく、ページごとにそれぞれ対応する新しいページにリダイレクトします）。301 リダイレクトを使用できない場合は、代わりに検索エンジン向けに クロス ドメイン対応の rel=”canonical” 属性 の使用をおすすめします。
• 同じ Google ウェブマスター ツール アカウントであなたが 新しいサイトと元のサイトの所有者であることの確認 をします。
• Fetch as Googlebot 機能を使用して、Googlebot が移転先のコンテンツをクロールできるかどうかを確認します。Google が移転先のコンテンツに実際にアクセスできることを確認することは重要です。また、元のサイトのリダイレクトや rel=canonical の設定を Googlebot がクロールする必要がありますので、Googlebot がその情報をクロールする前に元の URL を robots.txt でブロックしないようご注意ください。
• コンテンツを新しいドメインに移動する場合は、Google ウェブマスター ツールの [設定] の [アドレスの変更] オプションを使用して、Google にその変更についてお知らせください。

• サイトの URL 構造も変更した場合、404 エラーページ が表示されることのないよう、新しい移転先にきちんと誘導できていることを確認してください。リンク切れ などの調査にも、ウェブマスター ツールが役に立ちます。新しいサイトについて、[健全性] > [クロール エラー] を確認してください。
• サイトマップ が最新の状態であることを確認してください。
• 301 リダイレクト を設定したら、404 エラー ページ の表示状況を監視し、ユーザーが新しいページにきちんとリダイレクトされているか、想定外のリンク切れが発生していないか、などをチェックします。サイト上で 404 エラー ページがユーザーに表示された場合は、そのユーザーがアクセスしようとした URL を確認し、コンテンツの移転先にリダイレクトされなかった原因を特定して、301 リダイレクト ルールを適宜変更します。
• Google ウェブマスター ツールの [サイトへのリンク] を見て、あなたのコンテンツにリンクしている重要なサイトを確認し、新しい移転先のアドレスを連絡してください。
• サイトのコンテンツが特定の地域専用の場合は、Google ウェブマスター ツールで新しいサイトの 地域ターゲットの設定 をもう一度確認することをおすすめします。
• まったく同一、またはほとんど同一のクロール可能な 2 つのサイトを、301 リダイレクトや rel="canonical" を指定せずに運営することはできるだけ避けてください。
• 最後に、コンテンツを別の場所に移動する際に、コンテンツ、URL 構造、ナビゲーションの大幅な変更など、重要な変更を行うことはおすすめしません。一度に行う変更が多すぎると、ユーザーや検索エンジンが混乱するおそれがあります。

コンテンツを別の場所に移動する方法についてのコメントやご意見・ご感想は、ウェブマスター ヘルプフォーラム までお寄せください。

Written by Fili Wiese (Ad Traffic Quality) & Kaspar Szymanski (Search Quality)
Original version: How to move your content to a new location

日頃 ウェブマスター ツール を使っている方はお気づきかと思いますが、ウェブマスター ツールでは日々様々な改善や新機能が追加 されています。今回、ナビゲーション、ダッシュボード、そしてトップページが見た目にも機能的にも大きく改善されましたのでご紹介します。


ナビゲーションを再編成しました
まず、ナビゲーションの改善についてです。関連する機能ごとに項目をまとめ、ナビゲーション項目を再編成しました。新しい項目は、設定、健全性、トラフィック、最適化となります。

• 設定：設定可能な項目（通常頻繁には変更しません）
• 健全性：サイトに問題が発生していないかを確認するための項目。
• トラフィック：あなたのサイトが Google 検索上でどのように成果を上げているかを確認するための項目。
• 最適化：あなたのサイトを強化するためのヒントを確認するための項目。

また、機能に変更はないのですが、[HTML の提案]の項目名が[HTML の改善]と変更されたように、いくつかの名称変更が実施されました。ナビゲーション項目がどのように整理されたのか、ぜひ新しいウェブマスター ツールのナビゲーションをひと通り確認してみてください。

ダッシュボードも改善され、見やすくなりました
新しいナビゲーションと同様、新しいダッシュボードも気に入って頂ければと思っています。ダッシュボードの上部では、あなたのサイトについて重要なメッセージがある場合、その情報が表示されます。そしてその下に、あなたのサイトの現在の状態がチャートやグラフでひと目で確認できるようになりました。クロール エラーや検索クエリ、サイトマップといった重要項目の状態が一目で確認できるようになったことで、サイト管理も効率的になることを期待しています。

トップページをコンパクトに
最後に、サイトリストのプレビューサムネイルを非表示にしてリストをコンパクトに表示することが可能になりました。レイアウトはいつでも切り替え可能です。


この記事に関するコメントやご意見・ご感想は、ウェブマスター ヘルプフォーラム までお寄せください。

Written by Kamila Primke, Software Engineer, Webmaster Tools
Original version: Navigation, Dashboard and Home page

創造性は私たちの生活に大切なもので、日々の暮らしに豊かさを与えてくれます。たとえば、友人のために見た目も楽しいラテアートを作ってあげたいけど創造的で素敵な絵柄が思いつかない。そんなとき、私が利用するのが Google 画像検索 です。


検索結果に表示される画像は、ブロガーや情報サイト、写真素材サイトなど、大小さまざまな規模のサイトオーナーが、自分の HTML ページに埋め込んでいる画像です。Google は、BMP、GIF、JPEG、PNG、WebP、SVG といった形式の画像をインデックスに登録しています。

しかし、Google はどうやってこれらの画像が紅茶ではなくコーヒーであることを認識しているのでしょうか？Google のアルゴリズムは画像をインデックスに登録するとき、その画像が見つかったページのテキストを見て、画像に関する情報を得ています。それ以外にも、ページのタイトルや本文も見ています。画像のファイル名や、リンク先を示すアンカーテキストや「alt 属性のテキスト（英語）」から情報を得ることもあれば、コンピューター ビジョンを用いて画像情報を得たり、ページ上にキャプション テキストが存在するときは 画像のサイトマップ に含まれているキャプションの情報を用いることもあります。

画像をインデックスに登録しやすくするために、下記の点を守ってください。

• 画像が埋め込まれている HTML ページと画像そのもの、どちらも Google がクロールできるようにしておくこと
• Google が対応している形式の画像であること（BMP、GIF、JPEG、PNG、WebP、SVG）

さらに、下記のようにしておくこともおすすめします。

• 画像のファイル名が画像の内容に関連した名前になっている
• 画像の alt 属性が、人間が読んで分かるような画像説明になっている
• 加えて、HTML ページのテキスト コンテンツと画像近辺のテキストを、画像に関連した内容にしておくことも有効です。

ここからは、これまでに画像検索について寄せられた質問に対してお答えします。
Q: Googlebot-Image ではなく、Googlebot が画像をクロールしているのを見かけることがありますが、それはなぜですか？
A: URL のリンク先が画像なのかどうか不明なときによくある現象です。こういった場合、Google はまず Googlebot で URL をクロールします。URL のリンク先が画像だと分かれば、通常 Googlebot-Image で再び訪問します。したがって、通常は Googlebot と Googlebot-Image の両方に対して、画像とページのクロールを許可しておくとよいでしょう。

Q: 画像にファイル サイズに上限があるというのは本当ですか？
A: Google では、どんなサイズの画像でもインデックス登録します。ファイル サイズに制限はありません。

Q: 画像に含まれている EXIF や XMP などのメタデータはどうなりますか？
A: ユーザーがより簡単に検索対象にたどり着けるようにするため、Google は見つけたあらゆる情報を使用します。なお、EXIF データなどの情報は、画像をクリックしたときに表示されるページ（インタースティシャル ページ）の右側のサイドバーに表示されることがあります。


Q: 画像のサイトマップは送信すべきでしょうか。どんな利点があるのですか？
A: はい、送信してください。画像のサイトマップ は、Google に新しい画像の存在を知らせるのに役立つと共に、画像が何の画像なのかを知る助けにもなります。

Q: CDN を使って画像を提供しています。どうやったら画像のサイトマップを使用できますか？
A: クロスドメインの制約（英語）は、サイトマップのタグに対してのみ適用されます。画像のサイトマップでは、タグは別のドメイン上の URL を示すことが可能ですので、画像に CDN を用いていても大丈夫です。Google がクロール エラーを発見した場合にお知らせできるよう、ウェブマスター ツールにて CDN のドメイン名を検証することもおすすめします。

Q: 自分が所有する複数のドメインまたは複数のサブドメイン上（例えば CDN や関連サイトなど）に画像が重複して存在する場合は、問題となりますか？
A: 一般的に、どのタイプのコンテンツでも複製しないことが最善の方法です。複数のホスト名にまたがって画像を重複させている場合、Google のアルゴリズムはその中の 1 つをその画像の優先（canonical）コピーに選びますが、それが皆さんの選んでほしいバージョンであるとは限りません。またその場合、画像のクロールやインデックス登録が遅くなることもあります。

Q: 元々の画像が、それ以外のソースのものよりランキングが下位になっている場合がときどきありますが、それはなぜですか？
A: Google は画像の内容を判定する際に、ページのテキスト コンテンツを使用していることを覚えておいてください。例えば、オリジナル ソースが、テキストがほとんど存在しない画像ギャラリーのようなページである場合、テキストをより多く含むページが上位の検索結果として選ばれることがあります。ある特定の検索キーワードに対する検索結果があまりにもおかしいと思われる場合は、検索結果の下に表示されているフィードバック用リンクで報告するか、ウェブマスター ヘルプフォーラム にて事例を報告してください。

セーフサーチ

ユーザーがセーフサーチ フィルターをオンにしている場合、Google のアルゴリズムは様々なシグナルに基づき、ある画像（ウェブ検索の話であれば、ページ全体）を検索結果から除外すべきかを判定しています。画像の場合、そういったシグナルの一部はコンピューター ビジョンを使って生成されていますが、セーフサーチ アルゴリズムでは、もっとシンプルなこと、例えばその画像が以前どこで使用されたのかや、画像が使用されていたコンテキスト（文脈）なども見ています。
ただし、最も強力なシグナルの 1 つは、自発的にマークされたアダルト ページです。アダルト コンテンツを配信するウェブマスターの方は、下記のいずれか 1 つのメタタグでページをマークアップすることをお勧めします。

<meta name="rating" content="adult" />
<meta name="rating" content="RTA-5042-1996-1400-1577-RTA" />

ユーザーの多くは、検索結果にアダルト コンテンツが表示されることを好みません（子供が PC を使用する場合は特にそうです）。上記メタ タグのいずれかをウェブマスターが用いることで、ユーザーは見たくない検索結果や、想定外の検索結果を見ずに済むので、ユーザー エクスペリエンスの向上につながります。

どんなアルゴリズムにも当てはまりますが、セーフサーチ フィルターによってコンテンツが検索結果から意図せずして除外されてしまうことがあります。ご自分の画像やページがセーフサーチによって誤って除外されていると思われるときは、こちらのフォーム （英語）を使ってご連絡ください。

画像のインデックス登録について詳しくは、画像 に関するヘルプセンターの記事や、役立つ情報が満載の 検索エンジン最適化 (SEO) スターターガイド を参照してください。質問などがございましたら、ウェブマスター ヘルプフォーラム までお寄せください。

Written by Gary Illyes, Webmaster Trends Analyst
Original version: 1000 Words About Images

Google では ウェブマスター ツールに関して様々な改善を重ねてきました。今回、ウェブマスター ツールの 検索クエリ のデータが改善されましたのでご紹介します。


今回の改善で最も重要なのは、検索クエリのデータの履歴が過去 90 日までさかのぼって確認できるようになった点です。検索クエリのページ右上にある期間の設定をクリックすると、これまで 35 日分のデータしか表示できませんでしたが、90 日分のデータを表示することが可能になりました。

クリック後：

90 日間のデータを見る場合、変動率を表示するオプションは無効になります。以前の期間との変動を確認したい場合は、対象期間は 30 日となるよう調整してください。変動率は、デフォルトでは無効になっていますが、グラフとテーブルの間にあるボタンで切り替えることができます。


ウェブマスターツールのもう 1 つの大きな改善点は、サイトの所有権の確認をするとすぐに、基本的な検索クエリのデータを参照できるようになった点です。もうサイトの情報が表示されるまでお待ち頂く必要はありません。

最後に、Google では現在クリックが発生しているトップ 2000 クエリのデータを収集しています。クエリのデータの発生が複数の国や言語に及ぶ場合は、表示されるクエリ数は 2000 未満となる場合もあります。たとえば、カナダにおける [flowers] という検索は、google.com 上の [flowers] の検索とは区別してカウントされます。この機能により 98％ のサイトにおいてはクエリを完全にカバーしています。

今回の改善がみなさんのサイトの運営に役立つことを願っています。この記事に関するコメントやご意見・ご感想は、ウェブマスター ヘルプフォーラム までお寄せください。

Written by Javier Tordable, Tech Lead, Webmaster Tools
Original version: Even more Top Search Queries data

本日は、リッチ スニペット テスト ツールの新機能を紹介します。

リッチ スニペット テスト ツール が新しく HTML 入力による確認をサポートしました。これまで、多くの方から公開前の HTML ソースをテストできるようにして欲しいというリクエストを頂いてきました。今回、下図のように HTML ソースコードを利用して確認できるようになり、確認・修正のたびに何度もアップロードをする必要がなくなりました。リッチ スニペットを導入・設定する際にはぜひご活用ください。


リッチ スニペット テスト ツールについて詳しい情報はヘルプ記事「リッチ スニペット テスト ツール」をご覧ください。

この記事に関するコメントやご意見・ご感想は、ウェブマスター ヘルプフォーラム までお寄せください。

Posted by Anthony Chavez, Product Manager
Original version: Updates to rich snippets

この記事は日本時間の 2012 年 4 月 25 日に英語版の Google Webmaster Central Blog に投稿された記事「Another step to reward high-quality sites」の抄訳です。

Google はこれまで、検索エンジン最適化（SEO） は、有益で建設的なものと成りうる（英語）、と発言してきましたが、それは 私たちだけの意見ではありません（英語）。実際、効果的な検索エンジン最適化は、サイトをよりクロールしやすく、個々のページをよりアクセスしやすく、そして見つけやすくすることができます。たとえば、専門家以外の人が検索に使うキーワードを調査することにより、専門用語ばかりのページを避けるといった単純なことも、検索エンジン最適化のひとつです。

ホワイトハット SEO（ウェブマスター向けガイドラインに違反しない SEO）は多くの場合、サイトの使い勝手の改善や、素晴らしいコンテンツ作成の助長、サイト表示の高速化など、ユーザーと検索エンジンの両方に良い効果をもたらします。また、優れた検索エンジン最適化はマーケティング的視点でも見ても非常に有効であることが多いのではないでしょうか。サイトをより魅力的にするような方法、工夫を考えることは検索エンジンにも、ソーシャルメディアにも非常に有効です。良質なサイトを制作することは、しばしばウェブ上のサイトの評判を向上させ、その結果より多くのサイトからのリンクの獲得や、多くのユーザーのサイト訪問をもたらすでしょう。

“ホワイトハット” SEO の反対は “ブラックハット SEO” や “ウェブスパム” と呼ばれるものです。（メールのスパムと区別するために、”ウェブスパム” と呼んでいます）。掲載順位を上げることやトラフィックを増やすことを追求する中で、まったくユーザーのためにならない裏技や抜け道のような手法を使用してそのサイトに本来適切な掲載順位より高い掲載順位を得ようとしているようなサイトのことです。私たちは、サイトの掲載順位を少しでも高く操作するために行われる キーワードの詰め込み や リンクプログラムへの参加 など、様々なウェブスパムを毎日確認しています。

検索ユーザーが素晴らしいサイトを見つけて情報を得る、その手助けのために Google は多くの検索アルゴリズム変更を行っています。私たちはまた、検索アルゴリズムだけの為でなく、ユーザーの為に優れたサイトを作っている方々の努力が、きちんと報われてほしいと考えています。

そこで今回 Google は、ウェブスパムをターゲットにした重要な変更を検索アルゴリズムに施しました。これまでも良質なサイトを適切に評価するために様々なアルゴリズムの変更を実施してきましたが、今回の変更では、Google の 品質に関するガイドライン に違反しているサイトについて、その掲載順位を下げるような対策を実施します。このアルゴリズムの変更は、ウェブスパムを削減し、良質なコンテンツを促進するための私たちの新たな試みです。変更の詳細を明かすことは、抜け道をくぐり抜けたサイトが検索結果にあふれ検索ユーザーの利便性を損なう可能性があるためできませんが、ウェブマスターのみなさんにお伝えしたいことは、ユーザーにとって利便性の高い 良質なサイトを作ること（英語）に専念し、ウェブスパムを駆使することなく “ホワイトハット” SEO を心がけてください、ということです。

この変更によって影響を受けるサイトは、あからさまなスパムばかりではありませんが、共通して言えるのは、検索結果の掲載順位を人為的に操作するためにホワイトハット SEO を逸脱した SEO を行っているということです。

このアルゴリズムの変更は、すべての言語で同時に実施されます。この変更により、英語の検索では全体の 3.1％程度に、日常的に検索を利用するユーザーが気づくかもしれない程度の変化があります。また、ドイツ語、中国語そしてアラビア語ではおよそ 3 %となります。しかし、その割合はウェブスパム率の高い言語ほどより高くなり、たとえば、ポーランドでは 5 % 程度となります。

Google は、ホワイトハット SEO を行う人々（またはまったく検索エンジン最適化をしていない人々）が素晴らしい、魅力的なサイト制作に専念できるよう願っています。

このアルゴリズムの変更が多くのウェブマスターと、検索ユーザーにとって有益なものとなれば幸いです。

Posted by Matt Cutts, Distinguished Engineer
Original version: Another step to reward high-quality sites

クロール エラーは、ウェブマスター ツールで最も重要な機能の 1 つです。本日は、このクロール エラーが改善され、さらに便利になりましたので、お知らせします。

今回の改善により、数多くの新しいタイプのエラーを検出してレポートできるようになりました。それに伴い新しいエラーは、識別しやすいよう「サイト エラー」と「URL エラー」の 2 つに分けて表示しています。

サイト エラー
サイト エラーとは、特定の URL だけでなく、サイト全体に影響するエラーです。たとえば、DNS の解決エラー、ウェブ サーバーとの接続エラー、robots.txt ファイルの取得エラーなどです。これまではサイト エラーを URL 別にレポートしていましたが、URL 固有のエラーではないためあまり意味がありませんでした。実際これらのエラーでは、Googlebot が URL のリクエストをすることすらできません。そこでこれを変更し、サイト エラーはタイプ別にエラー発生率を記録することにしました。また、サイト エラーの頻度が上がり、注意を要するレベルに達した場合にはアラートを送信することも検討しています。


ほとんどのサイトは、これらのエラーが発生しないのが普通です。最近サイト エラーが発生していないのであれば、これらのセクションを逐一チェックする必要はありません。そこで、緑色のチェックマークを表示して、すべてが正常に稼動していることを一目で確認できるようにしました。


URL エラー
URL エラーは、特定のページにのみ関係するエラーです。つまり、Googlebot がその URL をクロールしようとして DNS を解決し、サーバーに接続し、robots.txt ファイルを取得して読み込んだ後に、この URL をリクエストしたら問題が発生した、というエラーです。ウェブマスター ツールでは、URL エラーをその原因に基づいていくつかのカテゴリに分類しています。サイトで Google ニュースやモバイルのデータ（CHTML/XHTML データ）を提供している場合、それらのエラーは別のカテゴリで表示されます。


少ない方が効果的
これまでのウェブマスター ツールでは、タイプごとに最大 10 万件のエラーを表示していました。これほどの量の情報をすべて消化しようとするのは、消防車のホースの水をすべて飲むのと同じくらい困難だったのではないでしょうか。どのエラーの重要性が高く（たとえばホームページがダウンしている）、どのエラーの重要性が低いか（たとえばある個人サイトからのリンクにタイプミスがある）を識別する方法も用意されていませんでした。10 万件のエラーを効率的に確認する手段、たとえば並べ替えや検索、「修正済み」のマークを付ける機能も用意されていませんでした。新バージョンのクロール エラー機能では、最も重要なエラーを強調することに重点を置きました。最も重要と思われるエラー、対処する必要のあるエラーが、カテゴリごとに 1,000 件ずつ表示されます。これら上位 1,000 件のエラーは並べ替えたり検索したりでき、修正済みのマークを付けたり、詳細を表示したりすることもできるようになっています。


サイトによっては、特定のタイプのエラーが 1,000 件を超えるかもしれません。その場合でも、そのタイプのエラーの総数を確認したり、過去 90 日間の履歴データをグラフで表示したりすることは可能です。1,000 件のエラーの詳細と累計エラー数だけでは不十分という場合に備え、API を使ってプログラム的にアクセスし、すべてのエラーをダウンロードできるようにすることも検討しています。

また、robots.txt によってブロックされたページのリストも削除しました。この情報が robots.txt ファイルによる問題を診断する際に役立つこともありますが、大抵の場合はサイト運営者が「意図的に」ブロックしたものです。[クロール エラー]は緊急性の高いエラーを重点的に確認するための項目に特化させるため、robots.txt でブロックされた URL の情報は近日中に [サイト設定] の [クローラのアクセス] に移設する予定です。

詳しい情報を手に入れる
エラー リストの個々の URL をクリックすると、詳しい情報が記載されたウィンドウが表示されます。このウィンドウでは、その URL を最後にクロールしようとした日時、最初に問題が通知された日時、そのエラーの簡単な説明などを確認できます。


このウィンドウでは、エラーの原因になった URL のリンクをクリックすることで、実際にアクセスするとどうなるかを試すことができます。他にも、エラーに「修正済み」のマークを付けたり（後ほど詳しく説明します）、エラー タイプのヘルプ コンテンツを見たり、その URL を含むサイトマップを生成したり、その URL にリンクしている他のページを確認したりできます。また、Googlebot に今すぐ URL を取得させて、詳しい情報を入手したり、正しく修正できているかどうかを確認したりすることもできます。


エラーに対処する
新バージョンのクロール エラー機能で最も注目してほしいのが、重要なエラーに重点を置いて先に修正できる点です。エラーをランク付けして、対処が可能なエラーほど優先順位リストの上位に表示されるようにしました。対処可能なエラーとは、たとえばサイト内のリンク切れの修正、サーバー ソフトウェアのバグの修正、リンク切れの URL を除去するサイトマップの更新、ユーザーを実在するページに移動させる 301 リダイレクトなどです。ランク付けは、その URL がサイトマップに含まれているか、その URL へのサイト内またはサイト外からのリンクがいくつあるか、その URL への検索トラフィックが最近発生したかなど、さまざまな要因に基づいて行われます。

エラーの修正が完了したら、Googlebot にその URL を取得させることで、正しく修正できているかどうかを確認できます。フル アクセス権のあるユーザーであれば、エラーに「修正済み」のマークを付けることもできます。マークを付けると、そのエラーがリストから削除されます。修正済みのマークを付けたエラーは、URL を再クロールして同じエラーが発生しない限り、再びエラー リストの上位に表示されることはありません。


新しいクロール エラー機能にはさまざまな工夫を凝らしてあります。皆様に「これは便利」と感じていただけることを願っております。この記事に関するコメントやご意見・ご感想は、ウェブマスター ヘルプフォーラム までお寄せください。

Written by Kurt Dresner, Webmaster Tools team
Original version: Crawl Errors: The Next Generation

この度、Google ウェブマスター ツールに新たな機能が追加され、サイトの所有者がサイトのデータや設定へのアクセス権を制限付きで他のユーザーに与えられるようになりました。他のユーザーにフルのアクセス権を与える機能（英語）は以前からありましたが、ウェブマスターのみなさんからは度々「設定の変更はできないが、ウェブマスター ツールのデータの閲覧はできるような、制限付きのアクセス権を他のユーザーに与えたい」というようリクエストをいただいていました。今回導入された新しいユーザー管理機能により、こういった設定が可能になります。

ウェブマスター ツールのホームページで「サイトを管理」というドロップダウンのメニューをクリックすると、メニューのオプションが表示されます。以前は「サイト所有者を追加/削除」と表示されていたメニューが、現在は「ユーザーを追加/削除」という名前に変更されています。


この「ユーザーを追加/削除」というメニューを選ぶと、新しいユーザー管理のページが表示されます。ここでは最大 100 人のユーザーを追加または削除したり、各ユーザーに対してアクセス レベルを「フル」または「制限付き」に指定したりすることが可能です。ユーザー管理のページから追加されたユーザーは、特定のサイトに関連づけられています。もしあなたがそのサイトの所有者であると確認できなくなった場合、あなたが追加したユーザーもウェブマスター ツールでのそのサイトに対するアクセス権を失います。確認済みのサイト所有者の追加や削除は、以前と変わらずウェブマスター ツール内の、ユーザー管理 ＞ サイト所有者の管理ページ から行います。


フルのアクセス権を与えられたユーザーは、すべてのデータの閲覧が可能になり、さらにサイトの設定の変更やサイトリンクの順位をを下げるなど、ほとんどの操作を実行することができるようになります。制限付きのアクセス権を持つユーザーは、ほとんどのデータの閲覧と、Fetch as Googlebot を使うことやアカウントにメッセージを転送する設定など、いくつかの限られた操作のみを行うことができます。制限付きのアクセス権しか持たないユーザーにはウェブマスター ツール内の多くの場所で「アクセスが制限されています」というメッセージが表示されます。



制限付きユーザーやフルの権限を持つユーザー、サイト所有者がどのような機能や操作を実行できるのかはヘルプ記事の「権限」のページをご覧ください。

今回の新しい機能では、アクセス権限を限定することでウェブマスター ツールに精通していない方にも権限を付与することが可能になり、サイト運営に関わる多くの方の間でウェブマスター ツールの情報を共有することができるようになりました。これによって皆様のウェブマスター ツールを通じてのサイト管理がよりスムーズになればと願っています。今回の新たなユーザー管理機能について、ご意見、ご質問などございましたら、ウェブマスター ヘルプフォーラム からお声をお寄せください。

Written by Jonathan Simon, Webmaster Trends Analyst
Original version: Safely share access to your site in Webmaster Tools

本日は、ウェブマスター ツールのメッセージ センターにお送りしている通知の中で、ソフトウェアのアップデートをおすすめする通知についてご紹介させて頂きます。

サイトで使用されているソフトウェアやプラグインのバージョンが古く、ハッキングされる可能性があるなど脆弱性が検知された場合や、より新しいバージョンが利用できることを Google が検知した場合、ウェブマスター ツールのメッセージ センターにメッセージをお送りしているケースがあります。たとえば、Drupal の モジュール や Joomla の 拡張機能 のアップデートが入手できる状態であるのに、一部のサイトではアップグレードが済んでいない、ということがあるかもしれません。ウェブマスターが新しいバージョンにアップグレードしない理由はいくつか考えられますが、理由の 1 つとして、単に新しいバージョンが存在することを知らないことも考えられます。そのようなケースについては Google がお役に立てるのではないかと考え、ウェブマスターの皆様に、ウェブマスター ツール を通じてメッセージを送信して、ソフトウェアの新しいバージョンについてお知らせしています。

お知らせが必要なサイトを特定するために、Google ではクロールしたウェブページのソース コードを解析するなどの方法を使用します。たとえば、WordPress や他の CMS アプリケーションには、バージョンを特定する タグが含まれています。この タグが、Google からウェブマスターの皆様に通知を行う上でバージョンの判別に非常に役立ちます。ソフトウェア デベロッパーの方が自分のソフトウェアの新しいバージョンについて Google からユーザーに通知してほしいとお考えの場合は、まずソフトウェアのバージョンを特定する タグがソース コードに含まれるよう開発することをおすすめします。プラグインやウィジェットを開発している場合も、ユーザーに提供するソース コードにバージョン番号を入れることをおすすめします。

ソース コードにバージョン番号を入れることがセキュリティ上好ましい方法なのかどうかについては、意見が分かれるかもしれません。バージョン番号を入れると、そのウェブサイトが特定の種類の攻撃に対する脆弱性を持っている可能性があることがハッカーやワーム作成者にわかってしまうからです。しかし Matt Mullenweg 氏 は、「昔のワーム作成者は脆弱性の確認にインストールされているソフトウェアのバージョン番号を確認していましたが、最近ではバージョン番号は見ずにサイトの機能や動作そのものを確認しています。」と指摘しています。また、バージョン番号があることで、サイトを更新する必要があるかどうかを判別できるという利点があります。Google は、バージョン番号をソース コードに入れることは、害よりも利益の方が大きいケースが多いと考え、メッセージの送信に活用しています。

最後に、このお知らせは強制的なものではありませんので、アップグレードするかどうかについてはウェブマスターの皆様ご自身でご判断ください。

※対象ソフトウェアにつきましては、現在では WordPress や Typo3 なども追加されています。

Posted by Patrick Chapman, Search Quality Team
Original version: 'New software version' notifications for your site

サイトマップは、皆さんのサイトのページに関する情報を Google に提供する手段の 1 つです。ウェブマスター ツールのサイトマップ機能では、皆さんから提供されたサイトマップに対して、サイトマップ内の URL のインデックス登録数や、サイトマップにエラーがないかといったフィードバックを提供しています。この度、ウェブマスター ツールにおいてさらに多くの情報を提供するようになりました。1 つずつご紹介していきましょう。


サイトマップ ページでは、コンテンツのタイプ別に詳細情報を表示しています。今回、ウェブページや動画、画像、ニュースそれぞれについて、サイトマップの統計情報がひと目でわかるようになりました。これによって、各コンテンツ タイプの項目の送信数（送信されたものがある場合）のほか、一部のコンテンツ タイプについては、インデックス登録されている項目数もわかるようになっています。今回の機能強化に伴い、この新しいサイトマップ ページが [Labs] の動画サイトマップ機能に代わるものとなり、動画サイトマップ機能は廃止される予定です。

次の改善点は、サイトマップをテストする機能です。実際に送信する場合とは異なり、テスト機能ではエラーがあるかどうかのチェックだけが行われ、サイトマップは Google へ送信されません。テストでは Googlebot によってすぐにサイトマップの確認が行われ、通常は数秒で完了します。なお、このテストはあくまで初期的な診断で、細部に渡る詳しいものではなく、問題点をすべて検知できるわけではないことにご注意ください。例えば、サイトマップ内の URL がダウンロードされたときにしか確認できないようなエラーはこのテストでは発見できません。

テスト機能に加え、エラーの表示方法を改善し、サイトマップの問題点をこれまでよりも見つけやすくしました。1 つのサイトマップに対して、同じ種類のエラーを何度も繰り返し表示するのではなく、エラーや警告をグループ分けし、具体例をいくつか表示するようになりました。同様に、サイトマップのインデックス ファイルについても、サイトマップ インデックス配下のサイトマップのエラーや警告をまとめて表示するようにしました。これによって、配下のサイトマップを 1 つずつクリックして調べる必要がなくなります。

最後に、「削除」ボタンの挙動も変更しました。ウェブマスター ツールからサイトマップを削除する際、皆さんのアカウントとサイトの他のオーナーのアカウントの両方から削除されるようになります。ただし、サイトマップはウェブマスター ツールから削除しても、Google によってまだ読み込まれたり処理されたりする可能性があることにご注意ください。例えば、robots.txt ファイル内でサイトマップを参照している場合は、検索エンジンは引き続きそのサイトマップを処理しようとする場合があります。このようにサイトマップが参照されることを完全に防ぐためには、ファイルをご自分のサーバーから削除するか、robots.txt でブロックしてください。

ウェブマスター ツールのサイトマップ、およびサイトマップの機能について詳しくは、ヘルプ センター の記事をご覧ください。ご質問がありましたら ウェブマスター ヘルプフォーラム までお寄せください。

Written by Kamila Primke, Software Engineer, Webmaster Tools
Original version: What’s new with Sitemaps

「データは宝である」という話をショップオーナーの皆様からよく聞きます。そのデータで、商品の販売実績や顧客の購買傾向がわかる場合はなおさらです。Google ではそういった皆様からの声をもとに、Google Merchant Center の改善を図っています。第一弾として、ショップオーナーの皆様のお手元により多くのデータをお届けできる機能を追加しました。
Google ショッピング に商品フィードを送信していただくと、Google Merchant Center アカウントの [掲載結果] タブ ( 以前の [パフォーマンス レポート] タブ ) で、より詳しい商品実績データがご覧いただけるようになりました。

すべての商品についてのクリック数が表示できるだけでなく、データを掘り下げて特定の商品カテゴリ、ブランド、状態、国別のクリック数も表示できるようになりました。期間を限定して表示することもできます。さまざまなタイプの商品、ブランドなどの実績を簡単に比較できるため、現状を評価し、さらに最適化の必要がある箇所を特定することができます。


この新しい機能を使用して商品の実績をより詳しく分析できるようになったため、情報に基づいた判断が可能となり、投資収益率の向上を図ることができます。

Google では、今後も Google ショッピング および Google Merchant Center の機能を改善していきます。頻繁にチェックしてみてください。

Posted by 鈴木宏輔 / プロダクトマネージャー

ユーザーをコンバージョンに導くプロセスで大きなボトルネックのひとつとなるのが、オンライン フォームへの入力です。ショッピングや登録のプロセスが完了するかどうかは、フォームの出来により大きく異なります。フォームへの入力は、サイトの目標を達成する上で最も重要かつ要求の厳しいステップです。多くのユーザーにとってオンライン フォームは、ウェブ上のさまざまなサイトで自分の名前や住所などの情報を繰り返し入力しなければならないものもあるため、多くのユーザーが、この面倒な作業のために入力を途中でやめてしまいます。

Chrome の自動入力やその他のフォーム入力機能は、一般的なプロフィール情報を記憶し、フォームにその情報を事前に入力することで、こうした障壁を取り除きます。ただし現在のところ、ウェブマスターには、Chrome やその他のフォーム入力機能がサイトのフォームを正しく解析してくれるかどうかがわかりません。いくつかの 規格があります（英文）が、ウェブサイトの実装に負担がかかるため、あまり利用されていないのが現状です。

そこで、Chrome ではフォームのフィールドに新しい「オートコンプリート タイプ」属性を試験的に導入いたしました。ウェブ デベロッパーのみなさまはこの属性を使って、text フィールドと select フィールドに標準的なデータ タイプ（「full-name」、「street-address」など）で明確にラベルを付けることができます。この属性を使用してフォームを自動入力用にマーク アップすることで、ユーザー インターフェースやバックエンドに変更を加えずにサイトでのコンバージョン率を高めることができます。


実際には、input 要素に属性を追加するだけです。たとえば、メール アドレスのフィールドは、次のようになります:

<input type=”text” name=”field1” x-autocompletetype=”email” />

Google は、他の複数の自動入力対応ベンダーと共同で今回の設計を行ってきました。あらゆる初期段階の提案と同様に、ウェブ標準化コミュニティからのフィードバックに基づいてこの機能を変更、改善していく予定ですが、Google ではこの機能が、HTML5 の仕様で自動入力フォームの対応について議論するよいきっかけになると考えています。現在のところ、この新しい属性は x-autocompletetype として Chrome に実装されています。これは、webkitspeech 属性（昨年の夏に リリース（英文））と同様に、まだ実験運用属性であり、標準属性ではありません。

詳しくは、仕様案の全文（英文）をご覧ください。この記事に関するコメントやご意見・ご感想は、ウェブマスター ヘルプフォーラム までお寄せください。また、標準化の議論（英文）へのご意見もお待ちしています。

Posted by Ilya Sherman, Software Engineer
Original version: Making form-filling faster, easier and smarter

ウェブマスター向け公式ヘルプ フォーラム は、 3 月 6 日で開設から 3 周年を迎えました。

これもひとえに、日頃活発にディスカッションに参加してくださっているウェブマスターの皆さまのおかげです。ありがとうございます！

今年もウェブマスター向け公式ヘルプ フォーラムをご利用の皆さまを対象としたアンケートを実施し、皆さまからのお声をお聞かせいただきたいと思います。

アンケートでお寄せいただいくご意見はウェブマスター ヘルプフォーラムチームにとって何よりの貴重なご意見となっており、フォーラム運営の改善に活用させていただいています。例えば 2011 年のアンケートからは以下のような企画が誕生しました。

• スマートフォン版 Googlebot-Mobile 導入に伴う Q&A スレッドの設置
• 再審査リクエストについてのまとめ情報の提供
• ウェブサイトのユーザーテストについてウェブマスターの皆さまからのコツ、経験談の募集スレッドの設置

今年のアンケートでも、皆さまからのアイディア、ご提案をどんどん取り入れ、皆さまと共に、さらに役立ち、多くのウェブマスターの方々が集まるウェブマスター向け公式ヘルプ フォーラムをつくっていきたいと思います。また、アンケートを回答してくださった方の中から抽選で 40 名様に Google オリジナルグッズ（写真）をプレゼントさせていただきます。


アンケートのご回答はこちらからよろしくお願いいたします。
*回答受付期間: 2012 年 3 月 7 日（水）～3 月 25 日（日）

それではご回答、お待ちしております！

Posted by サーチクオリティチーム

Google では、数カ月前に google.com 上でログインした状態で検索をすると、デフォルトでSSL暗号化される変更を加えました が、今回、co.jp ドメインにおいても、同様にデフォルトで暗号化されるようになりました。

詳しい情報は こちら でご確認ください。

Posted by サーチクオリティチーム

ウェブマスター ツールの検索クエリの機能が新しくなりましたのでお知らせします。以前はあるクエリについて表示されたすべての URL の平均順位を表示していました。今後はその代わりに、最上位に表示された URL の平均順位を表示します。

例えば Nick が「ベーコン」と検索し、あなたのサイトが検索結果の 3, 6, 12 番目に表示されたとします。また、Jane も「ベーコン」と検索し、同様に検索結果の 5 番目と 9 番目に表示されたとします。以前はこれらのすべての順位を平均して 7 位と表示していました。今後はそれぞれの検索結果に表示される最も高い順位の平均（Nick の検索結果では 3 位、Jane の検索結果では 5 位になります）をとって 4 位と表示されます。

この新しい計算方法によって、表示される順位はよりウェブマスターのみなさまの実感に近いものとなるでしょう。

上位のクエリ データへの影響
この変更は今後の上位の検索クエリのデータに影響します。過去のデータは変更されません。この変更に伴い掲載順位の低い URL の平均はとらなくなるので、平均掲載順位は通常同じか高くなります。

ウェブマスター ツールの「ウェブ上のサイト」セクションで 新しくなった上位のクエリのデータをご確認ください。また、上位のクエリデータは プログラムを使用してダウンロードを行うこともできます（英語）。ぜひご活用ください。

今後もウェブマスター ツールがあなたのサイト運営に役立てるよう改善に努めます。お気づきのことなどありましたら ウェブマスター フォーラム でお知らせください。

Posted by Chris Anderson, Google Analytics team, and Susan Moskwa, Webmaster Trends Analyst
Original version: Update to Top Search Queries data

海外向けのビジネスを展開されているサイトでは、事業の展開に応じて、ウェブサイトの情報を様々な地域のユーザーに届けるために、サイトをローカライズ（現地化）することを考えている方は多いのではないでしょうか。そこでこの記事では、多地域向けのウェブサイトの構築に必要なことを、検索エンジンの視点から考えていきます。ではまず多地域向けのウェブサイト作成に関する大まかな準備について説明した後、サイトの構築方法について見ていきましょう。
※本記事で扱う多地域向けのウェブサイトとは、明確に複数の地域（多くの場合、国も異なります）のユーザーをターゲットにしたサイトを指し、多言語向けのウェブサイト（ 関連ブログ記事 （英語））とは複数の言語で提供されているサイトを指します。

グローバル ウェブサイトの準備

ウェブサイトを複数の地域や言語に対応させることは簡単な作業ではありません。ウェブサイトを複数のバージョンを作成するということは、バージョンの数だけその修正に手間がかかる可能性もあるということなのです。そのため、サイトの多地域・多言語化を始める前に、最初のバージョンですべてがきちんと動作することを確認してください。また、管理する URL の数が一気に増えるわけですから、ウェブサイトを支える設備もそれなりに必要になることを忘れないでください。

多地域向けウェブサイトの計画

複数の地域（通常は国）向けのサイトを計画するときは、まずそれぞれの国や地域の法的条件や行政上の規制について調べ、自分のウェブサイトに関係するものがないかどうか確認します。これらの条件によっては、たとえばその国固有のドメイン名を使えない、などその後の作業に影響が出ることがあります。

多くのウェブサイトにとって、ドメイン名は非常に重要です。Google ではドメイン名に関して、次の 2 種類を区別しています。

• ccTLD（国別コード トップレベル ドメイン）: このドメインは、それぞれ特定の 1 つの国に関連付けられています（たとえば、.jp は日本、.de はドイツ、.cn は中国など）。これは、ユーザーにとっても検索エンジンにとっても、そのウェブサイトがどの国向けに作られているかを示す明確なシグナルとなります。
• gTLD（ジェネリック トップレベル ドメイン）: このドメインは特定の国には関連付けられていません（たとえば、.com、.net、.org、.museum など）。Google では、.eu や .asia などの地域トップレベル ドメイン名も gTLD とみなしています（これらのドメインは、特定の国には関連付けられないためです）。また、Google はいくつかの vanity ccTLD（.tv、.me など）も、gTLD として扱っています。というのも、これらのドメインを利用したサイトは、特定の国ではなく、より一般的な広い地域をターゲットとしていると考えるユーザーやウェブマスターが多いからです（Google が gTLD として扱う ccTLD を完全に網羅した一覧表はありません。こうした内容は、時と共に変化するからです）。gTLD を持つウェブサイトの地域ターゲティングは、 [ウェブマスター ツール] の [地域ターゲット設定] を使用して設定することができます。

地域ターゲティングの判断要素

Google では通常、以下の要素を使ってウェブサイト（またはウェブサイトの各部分）の地域ターゲティングを判断します。

1. ccTLD の使用
   これは一般に、特定の 1 つの国を指定しているため、ユーザーにとってわかりやすい指標となるでしょう。
2. ウェブマスター ツールを使った gTLD の手動による地域ターゲティング（これはドメイン、サブドメイン、またはサブディレクトリのレベルで設定可能です）
   設定方法の詳細については、 ブログ記事 （英語）と ヘルプ記事：地域ターゲットの設定 を参照してください。この方法を使用すると、 地域ターゲティングからの地域タグが検索結果に表示される （英語）ため、ユーザーにとっても非常にわかりやすくなります。ただし、1 つのページが複数の国をターゲットとしている場合（ドイツ語圏のすべての国を対象としているなど）は地域ターゲティングを設定するのは適切ではないかもしれません。その場合は単にその言語を使ってページを作成し、地域ターゲティングは設定しないでください（多言語でのページ作成については こちらの記事をご参照ください ）。
3. サーバーの位置（サーバーの IP アドレスにより判断）
   サーバーの物理的な位置は、対象とするユーザーの近くであるはずです。しかし、ウェブサイトによっては分散 CDN（コンテンツ デリバリー ネットワーク）を使用している場合や、ウェブ サーバーのインフラストラクチャが整備されている国でホスティングされている場合もあるため、Google ではサーバーの場所だけで判断することは避けています。
4. その他の要素
   上記以外の要素がヒントになることもあります。たとえば、ページに記載された住所や電話番号、使われている言語や通貨、別のローカル サイトからのリンク、Google のローカル ビジネス センターの利用状況などから判断する場合もあります。

Google ではターゲット地域の特定に際し、場所を表すメタ タグ（geo.position や distribution）や HTML 属性を使用していないことに気をつけてください。これらの要素は、他の点では便利なこともありますが、地域ターゲティングに使用するには信頼性に欠けることがあるからです。

URL 構造

ターゲット地域の特定に使われる上述の 3 つの要素は、使用されているサーバーや URL と密接に関係しています。地域ターゲティングをページごとに設定するのは難しいため、URL 構造を使ってウェブサイトをいくつかのセグメントに分けて地域ターゲティングを設定するほうが理解しやすいでしょう。以下に、地域ターゲティングに利用できる URL 構造の例と、それぞれの長所と短所を挙げます。

ccTLD 例: example.de, example.fr	gTLD を使用したサブドメイン 例: de.site.com, fr.site.com, etc.	gTLD を使用したサブディレクトリ 例: site.com/de/, site.com/fr/, etc.	URL パラメータ 例: site.com?loc=de, ?country=france, etc.
長所（+） - 地域ターゲティングが明確 - サーバーの場所に依存しない - サイトの分割が簡単 - 法的要件に対応しやすい（場合による）	長所（+） - 設定が簡単 - ウェブマスター ツールの地域ターゲティングを使用できる - 複数の場所にあるサーバーを使用できる - サイトの分割が簡単	長所（+） - 設定が簡単 - ウェブマスター ツールの地域ターゲティングを使用できる - ホストが同じであるため管理がしやすい	長所（+） （おすすめしません）
短所（-） - 入手にコストがかかる - より多くのインフラが必要 - ccTLD 要件を満たす必要がある（場合による）	短所（-） - ユーザーが URL だけでは地域ターゲティングを認識できない場合がある（例: 「de」は言語か国か）	短所（-） - ユーザーは URL だけでは地域ターゲティングを認識できない場合がある - サーバーの場所が特定の箇所に集中する可能性がある - サイトの分割が難しい	短所（-） - URL に基づくセグメント化は難しい - ユーザーは URL だけでは地域ターゲティングを認識できない場合がある - ウェブマスター ツールの地域ターゲティングを使用できない

おわかりのように、地域ターゲティングの設定は、どのサイトでも常に同じになるとは限りません。たとえ国別コード トップレベル ドメイン（ccTDL）を使っているサイトであっても、内容はグローバルなものかもしれません。ですから想定とは異なる場所からサイトを訪れるユーザーのことを考えておくべきです。そのためにできることの 1 つとしては、ユーザーが地域や言語を選択するためのリンクをすべてのページに表示することが考えられます。

グローバル ウェブサイトでの重複コンテンツの管理

複数の地域や言語のコンテンツを提供するウェブサイトでは、同じコンテンツや類似したコンテンツを別々の URL で提供している場合があります。違う国にいる別のユーザーがそのコンテンツを使用する限り、通常は問題ありません。もちろん各地域のユーザー グループごとに別々のコンテンツを提供することをおすすめしますが、実際には最初からすべてのページとバージョンについてユーザー グループごとに別々のコンテンツを提供するということは容易ではないでしょう。ですから、たいていの場合は、重複するコンテンツを「隠す」ために robots.txt ファイル でクロールをブロックしたり、 noindex ロボット メタ タグ を使用したりする必要はありません。ただし、同じコンテンツを同じユーザー グループ向けに複数の URL で提供している場合（たとえば、example.de/ と example.com/de/ の両方でドイツ語のコンテンツをドイツのユーザー向けに表示している場合）は、お好みのバージョンを 1 つ選択してそこへ適切に リダイレクトさせる か、 rel=canonical リンク要素を使用するとよいでしょう。

この記事に関するコメントやご意見・ご感想は、 ウェブマスター ヘルプフォーラム までお寄せください。

Written by John Mueller, Webmaster Trends Analyst, Google Switzerland
Original version: Working with multi-regional websites

ウェブマスター チームは、数万件もの Google のウェブページを日々取り扱っています。今回は、ウェブマスターチームのこのような実地の経験に基づいたヒントやアドバイスをご紹介いたします。

もしご自身のウェブサイトにおけるユーザーの利用状況のテストや解析をまだ行ったことがないのであれば、サイトがターゲットのユーザーにとって有用なものになっているかを確認してみることをお勧めします。たとえば一例として、平均的なユーザーが下にスクロールする回数は上にスクロールする回数の 5.9 倍、つまり一度スクロールして通り過ぎたコンテンツは多くの場合「もう見られることがないも同然」であると言われています。まずはあなたのサイトの中に必要以上にスクロールさせるページがないかどうか、そしてそのページのアクセスログを解析し、直帰率の高さや滞在時間の長さなどを確認してみてはいかがでしょうか？（スクロールに関する Jakob Nielsen 氏の研究結果 （英語）では、ユーザーはスクロールすることを嫌がらないけれどもそれにも限界がある、と述べられています）

まず、あなたのユーザーについて考えてみましょう

新たなウェブサイトの制作をするときは、まったく新しいサイトを構築する場合でも、既存サイトをリニューアルする場合でも、次のことについて考えてみると良いでしょう。

• ユーザーはどこからサイトにアクセスするのか（自宅から、職場から、それとも外出先から）。
• 訪問者はどの程度技術に精通しているのか。
• ウェブサイトで取り上げる内容にユーザーはどの程度馴染みがあるのか。

このような項目についての答えが、初回のサイト デザインを決めるにあたって大いに役立つことがあります。

たとえば、外出先でアクセスすることが多いユーザーは、サイトで必要な情報を見つけるための時間があまりなかったり、じっくり集中しにくい環境にあり、またデータ接続も低速であったりすることが考えられます。その場合、目的を 1 つに絞ったシンプルなレイアウトが最適でしょう。また、技術にさほど詳しくないユーザー向けにコンテンツを提供する場合、目的のコンテンツにアクセスするのが難しくなり過ぎないようにしましょう。アニメーションを使えば華やかになるかもしれませんが、それがユーザーにとって価値があり、また目的のコンテンツにアクセスするのが難しくなり過ぎない場合だけ利用するようにしましょう。

テストをしなくても、基本となるユーザー プロフィール（いわゆる「ペルソナ」）を作成してみると、ユーザーにとって使いやすいデザインを作る上で役立つことがあります。プロフィールといっても、ユーザーの生い立ちや背景などを事細かに網羅する必要はなく、ユーザーの行動パターンを考えてみるだけでも足りるでしょう。

シンプルなテスト

テストは多額の費用をかけて大がかりに実施する必要はありません。友だちや家族に聞いてみるだけでも大きなヒントを得られるでしょう。ポイントとなるのは次のようなことです。

• テスト対象者の人数: サイトのレイアウトやナビゲーションの問題点を見つけるには 5 人くらいに聞いてみるだけでも十分でしょう（サンプル サイズが小さくても十分である理由を述べた Jakob Nielsen 氏の記事（英語） をご覧ください）。
• テスト対象者を選ぶ: さまざまな技術レベルの人を揃えた方が有用な結果につながりやすいでしょう。ただし、発生した個々の問題よりも全体の傾向を重視するようにします。たとえば、テスト対象者の半数以上に同じユーザビリティの問題が発生した場合は、本当に対処が必要な問題であると判断できるでしょう。
• テストの場所: 可能であればユーザーの自宅を訪問して、サイトを利用する様子を観察してみましょう。ユーザーにとって自然な環境でリラックスした状態で普段どのようにウェブを見るのかを観察します。実際にユーザーを訪問できないときはリモート テストを行うのもよいでしょう。このような場合に Google+ ハングアウトを活用できるという報告も届いています（Google+ ハングアウトの使い方について詳しくはこちらをご覧ください）。
• テスト方法: サイトの目的に応じてウェブサイトで行う簡単な操作を 4 つか 5 つ考え、ユーザーに実行してもらいましょう。テスト対象者の体験や思考をよく理解できるように、思ったことを声に出して言ってもらうとよいでしょう。
• テストするべき項目: テスト用のサイトをまるごと 1 つ構築しなくても、クリックできる画像や文書のフォーマット（PDF など）または HTML などの基本的なプロトタイプを使って、基本的なインタラクションをテストすることができます。さまざまなナビゲーションやレイアウトをテストすることで、実際に実装する前にどのようにユーザーに利用されるかを確認することができます。
• テストするべきではない項目: グラフィック デザイン要素よりも機能性に重点を置きましょう。デザインについては感じ方が主観的であることが多いからです。デザインについての有用なフィードバックが得られるのは、大人数（200 人以上）のユーザーを対象とした定量的なテストを行った場合に限られると言われています（ただし、たとえばサイトに使用する色によってコンテンツが判読できなくなるという場合などは、そのようなテストをしなくても有用なフィードバックが得られるでしょう）。デザインについてある程度の有用なフィードバックを得る方法としては、記述的なキーワードを 5～6 個用意して、その中からサイトに最もあてはまるものをユーザーに選んでもらうという方法などがあります。

全体として、基本的なテストはウェブサイトの機能がどのように動作しているか、つまり情報がどの程度簡単に見つけられるか、またサイトとのインタラクションがどのようなものになるかを確認する上で非常に有用です。

ユーザー テストから分かったこと

もし本当に調査とテストを行う価値があるかどうかまだ確信が持てないなら、実際に私達がユーザーに接して得ることができた事例が参考になるでしょう。いくつかの例を以下に紹介します。これらは、実際のユーザーと直接対面して Google のウェブページを利用する様子を観察しなければ、あるいは Google のウェブ トラフィックを解析しなければ知り得なかったことです。

• コンテンツを表示/非表示にするレイアウトを使用する場合は注意する: スクリプトを使用して長いテキストを展開したり折りたたんだりするようにしている場合、ユーザーが折りたたまれたコンテンツの存在に気づかないケースが多いことがわかりました。たとえば JavaScript で折りたたまれて非表示になるコンテンツは、ユーザーがページ内を検索（たとえば Ctrl+F キーを使うケース）しても見つかりません。

• 言葉の使い方を確認する: 見出し、リンク、ボタンは、ユーザーがページをざっと見たときに最も目を引く要素です。たとえばリンク テキストには「詳細を読む...」という言葉を使わないようにしましょう。ユーザーはさらに何かを読まなければならないと感じさせるリンクをクリックすることを避けるようです。その代わりに、ユーザーがリンクをたどった後にどのようなコンテンツが表示されるのかをそのまま説明する言葉を使うように心がけましょう。リンク テキストは周りの文脈と切り離されたとしても意味が通り、簡単に理解できるようなものにしましょう（実際にユーザーがざっと見るときにはそのようにして読まれるからです）。またボタン テキストの場合には言葉の使い方を工夫して、内容がわかりやすく、ユーザーの興味を引き、クリックしてみたくなるようなものになるよう心がけましょう。
• 低速接続の環境でページをテストする: さまざまなネットワーク環境を使用してページをテストしてみましょう（たとえば、近所のカフェや友だちの家の Wi-Fi などを使ってブラウジングしてみましょう）。ご自分のサイトのターゲット ユーザーが、たとえば職場のネットワークほど高速でない家庭用のインターネット接続でページを表示する可能性が高い場合には特にこのテストは有用です。私達のケースでは、スクリプトを使用したアニメーションをシンプルかつ高速にし、CTR （クリック スルー レート）とサイト滞在時間の数値が大幅に改善されました（低速のインターネット接続でテストできない場合は Google の Page Speed Online でパフォーマンスを確認することができます）。

終わりがないかのように思える開発のやり直しのサイクルにはまり込んでしまったときは、まず少しだけ立ち止まってユーザー プロフィールの作成と基本的なテストを行うことで、サイトのレイアウトやアーキテクチャに対する適切なアプローチを選択できるようになるでしょう。

この記事に関するコメントやご質問は、ウェブマスターヘルプフォーラム までお寄せください。
* ウェブマスター ヘルプフォーラムでは あなたの「簡単にできるウェブサイトのユーザー テストやユーザー リサーチの方法、コツ」を教えてください！ というスレッドを開設しました。ウェブサイトのユーザ テストの実践例、どのようにしたらうまく行ったか、またテストを最大限に活用するためにどのような工夫をしたか、などなど皆さまの経験から得られたコツやポイントを募集しています。ご投稿お待ちしています！

Posted by サーチクオリティチーム

ビジネスを世界展開しようとしているなら、ウェブサイトもそれにあわせる必要があるでしょう。テキストを翻訳するだけの簡単なことだと思う方もいるかもしれませんが、実は気をつけることは他にもあります。Google ウェブマスター チームが作成するサイトは、40 を超える言語にローカライズ（現地語化）されることも頻繁にあります。今回はその経験を基に、ページを多言語そして多地域向けに公開するにあたっての注意点を紹介します。

（外国語のコンテンツは発信しないから関係ないと思うかもしれませんが、もしかしたら他の国の人が、Google 翻訳のようなツールを使ってあなたのページを自分の母国語で見ている かも知れません。サイトを本来の表示言語以外の言語で見ているユーザーの割合は、アナリティクスのマイレポートに表示されるトラフィックを参照することでわかります）

「言語が増える=HTML テンプレートが増える」ではない
これについてはいくら強調しても足りないくらいですが、同じテンプレートをすべての言語バージョンで再利用すること、そしてテンプレートの HTML はシンプルにしておくことを強くおすすめします。

HTML コードがどの言語でも同じであることは、メンテナンスの観点から非常に重要です。言語ごとに HTML コードに手を加えてバグを修正するのでは、拡張性に欠けます。ページのコードはできるだけシンプルなままにしておいて、スタイルについては CSS を使うのがよいでしょう。（コードをシンプルしておくもう 1 つの利点は、翻訳のしやすさです。ほとんどの翻訳ツールは HTML ドキュメントを解析して翻訳可能な文字列を抽出しますので、この作業は、HTML の構造が正しければ、非常に容易です）

文字列の長さに注意
要素のサイズを固定したときにテキストがきれいに見えるようなデザインの場合は、テキストを翻訳すると大変なことになるおそれがあります。たとえば、ページの左側に置いたナビゲーション用のテキストが、翻訳するとかなり長くなってしまうことがあります。ナビゲーション用のタイトルが 2 行にまたがってしまう可能性も考えて、全体が収まるように行の高さを決定する必要があります（ナビゲーション テキストを最初に母国語で作るときもこのことは考慮する価値があります）。

テキストの長さが変動することが特に問題となるのは、フォームのラベルやレイアウトです。たとえば、フォームのラベルを左側に、入力フィールドを右側に配置したデザインの場合は、テキストが長いと 2 行になってしまい、短いと入力フィールドとの間が空きすぎて関連がないように見えてしまいます。どちらの場合もデザインが台無しになり、フォームの可読性が損なわれます。さらに、右から左（RTL）にテキストを記述する言語のレイアウトについてもスタイルを考慮する必要があります（詳しくは後ほど）。このような理由から、Google では、ラベルをフィールドの上に置くようにフォームをデザインしています。フォームが読み取りやすくなり、さまざまな言語に翻訳したときもスタイルの維持が容易だからです。


また、テキストを表示する領域の高さを固定するのも避けたほうがよいでしょう。高さを揃えたいくつかのボックスを背景としてレイアウトすると、母国語のテキストはぴったり収まっても、テキストが翻訳されたときにあふれ出てしまうことがあります。デザインの中で使う UI 要素が、テキストの長さの増減によって影響を受けるかどうかも考える必要があります。たとえば、タブを横に並べる か、 縦に並べる かといったことです。

右から左へ記述する言語への対応
右から左へ記述する言語のページに表示するためのコンテンツは、ほとんどの場合、純粋な RTL ではなく双方向となります。テキストによっては、左から右という方向を維持する必要があるからです（会社名の英語表記や電話番号など）。双方向 HTML のソース編集には問題が起こりがちですが、その理由は、エディタの多くが Unicode の双方向アルゴリズムをサポートしていないことです（問題と解決策に関する詳しい情報（英語））。例えば下の例のように " と > の順序を間違えてしまうということが起きえます:

<p>ابةتث <img src="foo.jpg" alt=" جحخد"< ذرزسش!</p>

双方向のテキストを適切に編集できるエディタは Coda のほか、Dreamweaver、IntelliJ IDEA、JEditX などがあります。

RTL 言語用にページをデザインするときは、必要なサポートのほとんどをコア CSS に組み込み、html 要素の dir 属性（下位互換性のため）とともに body 要素にも CSS のクラスを用意するのがよいでしょう。他の場合と同様に、すべてのスタイルを 1 つのコア スタイルシートに集めておくと、メンテナンスがしやすくなります。

スタイルに関しては、右側にフロートする要素は左側にもフロートする必要があり、その逆も同じであることに注意してください。要素の一方の側に設定されているパディングやマージン幅は反対側に置かれ、テキストの整列属性は反対向きに設定されます。

Google が通常採用しているアプローチの 1 つに、html[dir=rtl] CSS セレクタではなく body タグのクラスを使用するというものがありますが、これは古いブラウザとの互換性のためです。例えば以下のように HTML, CSS を記述します。

要素:

<body class="rtl">
<h1><a href="http://www.blogger.com/"><img alt="Google" src="http://www.google.com/images/logos/google_logo.png" /></a> 見出し</h1>

左から右への（デフォルトの）スタイル:
h1 {
height: 55px;
line-height: 2.05;
margin: 0 0 25px;
overflow: hidden;
}
h1 img {
float: left;
margin: 0 43px 0 0;
position: relative;
}

右から左へのスタイル:
body.rtl {
direction: rtl;
}
body.rtl h1 img {
float: right;
margin: 0 0 0 43px;
}

（実際の例を 英語版 と アラビア語版 で比較できます。）

また、RTL を主とするドキュメントの中に会社名の英語表記や電話番号のような左から右のテキストがある場合に、ブラウザで正しく処理されるようにするには、インライン要素で埋め込まれたテキスト文字列を、方向を設定する属性を使って折り返します。

<h2>‫עוד ב- <span dir="ltr">Google</span>‬</h2>

dir 属性を入れる HTML コンテナがない場合（title 要素や、メッセージ プロンプト用に JavaScript によって生成されたソース コードなど）は、次のようにすると同じことを実現できます。‫ と ‬‬ は、Unicode 制御文字です:

<title>&#x202B;‫הפוך את Google לדף הבית שלך‬&#x202C;</title>

JavaScript コードでの使用例:
var ffError = '\u202B' +'כדי להגדיר את Google כדף הבית שלך ב\x2DFirefox, לחץ על הקישור \x22הפוך את Google לדף הבית שלי\x22, וגרור אותו אל סמל ה\x22בית\x22 בדפדפן שלך.'+ '\u202C';

（詳細については、 アラビア語やヘブライ語などの右から左へ記述する言語の HTML ページの作成と RTL 言語でのスクリプトの作成 （英語）に関する W3C の記事を参照してください）

文字化け
（既に日本語文字を使用しているウェブマスターの方はあまり意識する必要はないと思いますが、）ラテン文字以外の外国語の文字セット（キリル文字、ギリシャ文字、アジアやインドのさまざまな言語の文字）をこれまでに一度も使用したことがない場合は、エディタとブラウザのどちらも、コンテンツが意図したとおりに表示されない場合があります。

エディタとブラウザのエンコードが UTF-8（推奨）に設定されていることを確認するとともに、HTML テンプレートに html 要素の lang 属性を追加することを検討してください。これによって、ブラウザがページを正しくレンダリングできるようになります。このことには、すべての Unicode 文字が正しく表示されるという利点もあります。つまり、é（é）のような HTML 実体参照を使う必要がなくなるので、貴重なバイト数を節約できます。エンコードをうまく解決できないときは、W3C の文字エンコードに関するチュートリアル （英語）を参照してください。この問題の詳しい説明があります。

標準規格に従った命名
最後に、複数の言語バージョンを作るときの命名規則に関する実務的なヒントを紹介します。ISO 639-1 言語コード などの標準規格に従って名前を付けておくと、同じドキュメントのさまざまな言語バージョンを扱うときに便利です。

標準の命名規則が使用されていれば、ユーザーがサイトの構造を理解しやすくなることに加えて、サイトを構築するウェブマスターにとってもメンテナンスしやすくなります。また、サイトのその他の要素（ロゴ画像や PDF ドキュメントなど）に言語コードを使うと、ファイルの識別がしやすくなります。

また、ウェブマスター セントラルの記事で、URL 構造に関するヒントと、 多地域向けウェブサイト （英語）や 多言語ウェブサイト に関する問題について紹介していますので、参考にしてください。

ここで紹介したことについては、Google 自身も日々苦戦していますが、確かに言えることは、十分な計画を立てて適切な構造の HTML としっかりとした CSS を作成すれば、ローカライズが格段に楽になるということです。

Posted by Kathryn Cullen, Google Webmaster Team
Original version: Îñţérñåţîöñåļîžåţîöñ