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

検索結果によりよいタイトルを

2012-01-27T10:00:00.000+09:00

Google の検索結果において、タイトルは重要な位置を占めています。タイトルは一行目に表示され、検索をした人はそのタイトルをクリックしてそれぞれのページにたどり着きます。そのため、そのページが何を表しているか一目でわかるように、具体的でわかりやすいタイトル（およびスニペット用にメタディスクリプション）を付けることをウェブマスターの皆様には常々お勧めしてきました。

ユーザーにどのようなタイトルを見せるかを決めるために、Google では多くのシグナルを利用しています。もしウェブマスターの方が <title> タグを使っているならば、基本的にはそれをタイトルに用います。しかしどのような検索キーワードに対しても常に <title> タグに書かれているものをそのまま表示してしまうと、ユーザーにとってはそのタイトルは検索キーワードと関連性が低いように見えることもあるかもしれません。そのような場合にそのページが検索キーワードと関連性が高いものであると気づいてもらうため、Google では代わりのタイトルを生成するアルゴリズムを利用することがあります。Google のテストでは、ほとんどの場合においてこれらの代わりのタイトルの方が元のタイトルよりも検索キーワードに対して高い関連性を示しました。また、これらの代わりのタイトルを使用することによりタイトルのクリック率は大幅に向上しており、検索をするユーザーとウェブマスターの皆さんの双方に役立っていました。これが Google が代わりのタイトルを表示する理由の半分です。

もう一方で、HTML 内に何もタイトルがなかったり、そのページを表すようなタイトルがウェブマスターによってつけられていない場合にも代わりのタイトルは表示されます。例えば、タイトルが単純に「ホーム」と名づけられている場合、タイトルはそのページの内容を表してはいません。また、1 つのサイトのページ内でまったく同じ（またはほぼ同じ）タイトルが使われているという問題もよく見られます。最近では、不必要に長かったり読みにくかったりするようなタイトルを簡潔でわかりやすいものに置き換える、という試みも行われています。

よりよいタイトルやメタディスクリプションの書き方、代わりのタイトルを生成する時に使われるシグナルに関しての詳しい情報は、「サイトのタイトルと説明の変更」というヘルプ記事をご覧ください。また、Google ではウェブサイトのタイトルが改善できそうなことを発見した場合はウェブマスターツールの「HTML の候補」という項目でウェブマスターの方にお知らせする取り組みも行っています。こちらはウェブマスターツールの左側のメニューの「診断」からご覧ください。

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

Posted by Pierre Far, Webmaster Trends Analyst
Original version: Better page titles in search results

誘導ページ（Doorway Page）はガイドライン違反です

2012-01-16T10:37:00.000+09:00

多くの方が、普段運営されているサイトへの集客に様々な工夫をされていることと思います。しかし、ユーザーのためではなく、過度に検索エンジンを意識した集客方法は、Google のウェブマスター向けガイドラインに違反してしまうことがあります。検索結果を人為的に操作してユーザーの利便性を下げてしまうようないくつかの行為を、Google は明確にガイドライン違反としています。その中で今回は日本でも多く見られるケースとして、誘導ページ（ドアウェイ、Doorway）についてご説明したいと思います。

誘導ページとは、ユーザーを特定のサイトに誘導したり、資料請求などをさせたりすることだけを目的に作られた、ユーザーに独自の価値を提供していないページ群のことをいいます。（いわゆる「サテライトサイト」の中にも、誘導ページにあたるものが多くあります。）具体的な例をご紹介しましょう。

例１：品質の低いコンテンツに、ある特定のサイトへのリンクを追加しただけのブログを複数作り、ユーザーを誘導しているケースです。

例２：地名以外ほぼ同一の誘導ページを大量に生成しているケースです。どの地域のページを見ても、資料請求フォームなどは同じものが用意されていることなどが特徴です。こうしたページでは、その地域ごとに特化した有用な情報はほとんど提供していないため、誘導ページと判断される可能性は高いと言えるでしょう。

Google は、ユーザーの検索キーワードに最も関連性が高く、かつ有用な検索結果を提供するよう心がけています。そのため、ここで例にあげたような、検索エンジンからユーザーを誘導するだけのために作られた固有の価値を持たないページは、ガイドライン違反として対応させていただく場合があります。

ウェブマスターの方々の中には、ここまでの説明を読んで、実際ご自身の管理しているページに誘導ページに該当するものがあるかどうか、気になる方もいらっしゃることでしょう。その場合、検索エンジンがなかったとしても、そのようなページを作ったかどうか、考えてみてください。Google ではあくまでユーザーにとってそのページを訪れる価値があるかという観点から判断をおこなっています。本当にユーザーのために作られたページと、検索エンジンからの誘導のみを目的としたページとでは、手のかけ方に大きな違いがあることを Google は認識していますのでご安心ください。

ご意見・ご感想は、ウェブマスターヘルプフォーラムまでお寄せください。

Posted by Takeaki Kanaya, Search Quality Team

ホスティングプロバイダとウェブマスターの皆様へ

2012-01-12T10:50:00.000+09:00

Google ウェブマスター向け公式ヘルプフォーラムに寄せられる質問の中には、ホスティングプロバイダの設定に起因するものがときおり見られます。そこで今回は、これまでにあった一般的な問題と修正方法をご紹介します。ホスティングプロバイダとウェブマスターの皆さまがこのような問題を認識、診断、修正するのに役立てば幸いです。

Googlebot のクロールがブロックされている: これはよく発生する問題で、通常はファイアウォールや DoS 攻撃防御システムの設定ミスで発生することが多く、また一部のサイトが採用している CMS（コンテンツマネージメントシステム）が原因で発生することもあります。防御システムはホスティングの要ともいえる要素で、サーバーリクエストの頻度が高い場合には自動的にブロックするよう設定されています。Googlebot はその性質上、人間のユーザーよりも多くのリクエストを実行するため、防御システムが Googlebot をブロックの対象と判断してしまい、その結果ウェブサイトがクロールできなくなることがあります。このような問題が発生していないか確認するには、ウェブマスターツールの Fetch as Googlebot 機能を使用して実際に Googlebot がクロールできているかを確認したり、ウェブマスターツールのクロールエラーにおいて何かアラートが表示されていないかを確認したりしてください。

Google では Googlebot によるクロールをより高度に制御したいウェブマスターの皆さまとホスティングプロバイダ向けに、いくつかのツールや情報を提供しています。これらの対策を実装することにより、クロールの効率も向上します。
- robots.txt ファイルや URL パラメータの設定を活用して Googlebot のクロールを制御する方法について、詳細なヘルプ記事を用意しています。
- Googlebot のユーザーエージェントを偽装した不正なロボット対策方法については、ヘルプ記事「Googlebot の確認」をご利用ください。
- Googlebot のリクエストの速度を変更するには、ウェブマスターツールであなたのサイトを確認し、クロール速度の変更を行ってください。ホスティングプロバイダが IP アドレスの所有権を確認することもできます。
クロールとインデックスに関する FAQ でも様々な情報を提供していますのでぜひご覧ください。
サイトへ接続できない: 上記と似たような問題で、Googlebot（およびユーザー）がウェブサイトにアクセスしようとしても繋がらない場合があります。これには DNS の問題、サーバーの過負荷によるタイムアウトや接続拒否、コンテンツデリバリネットワーク（CDN）の設定ミス、その他多くのエラーが含まれます。Googlebot がこのような問題に遭遇した場合は、ウェブマスターツールで URL にアクセスできないエラーまたはクロールエラーとして報告されます。
無効な SSL 証明書: ウェブサイトの SSL 証明書が有効であるためにはサイト名と一致している必要があります。よく発生する問題としては、有効期限の過ぎた SSL 証明書を使っていたり、サーバー上のすべてのウェブサイトで同じ証明書を使用する設定にしていたりといったサーバー側の設定ミスがあります。このような状況ではほとんどのウェブブラウザーがユーザーに警告を行います。Google もウェブマスターツール経由でメッセージを送信し、ウェブマスターに通知します。この問題を解決するには、ユーザーが目にするウェブサイトのすべてのドメインおよびサブドメインに対して SSL 証明書が有効であることを確認する必要があります。
ワイルドカード DNS: ウェブサイトがすべてのサブドメインリクエストに応答するように設定できることがあります。たとえばウェブサイト example.com を、foo.example.com、made-up-name.example.com、その他すべてのサブドメインに対するリクエストに応答させることができます。

特定の場合ではこれが望ましいこともあります。たとえば、ユーザーが作成したコンテンツを提供するウェブサイトでは、各アカウントにサブドメインを付与することがあります。しかし、別のホスト名で不必要にコンテンツが複製され、Googlebot のクロールに影響を与える可能性もあるため一部のウェブマスターにとっては望ましい状況ではありません。

ワイルドカード DNS の設定に関する問題を最小化するには、ウェブサイトでこの技術を使用しないか、存在しないホスト名に対して成功の応答をしないようにサーバーを設定します。この場合、接続を拒否するか、404 の HTTP ステータスコードを返すようにします。
バーチャルホスティングの設定ミス: この問題では、同じサーバーにホスティングされている複数のホストやドメイン名が、常に 1 つのサイトのコンテンツを返す症状が発生します。つまり、サーバーが複数のサイトをホスティングしていても、リクエスト内容にかかわらず 1 つのサイトのみを返すということです。この問題を調べるには、サーバーが HTTP リクエストの Host ヘッダフィールドに正しく応答しているかを確認する必要があります。
ホスト専用 URL での重複コンテンツ: 多くのホスティングサービスでは、テストや開発用の URL を提供しています。たとえばホスティングプロバイダが http://a.com/ というウェブサイトをホストしている場合、http://a.example.com/ や http://example.com/~a/ などの URL を介してサイトにアクセスできる場合があります。このようなホスト専用 URL は、パスワードで保護するなどして一般ユーザーにアクセスできないようにすることをお勧めします。一方でこういった URL がアクセス可能な場合でも、Google のアルゴリズムはお客様の意図したとおりに URL を取得する場合が多いです。アルゴリズムがホスト専用 URL を選択した場合でも、正しく正規化を行うことでアルゴリズムが取得する URL を指定することができます。
ソフトエラーページ: ホスティングプロバイダの中には、エラーページの表示にエラーのステータスコードの代わりに 200（成功）のステータスコードを使用している場合があります。たとえば「ページが見つかりません」というエラーページが 404 ではなく 200 を返すソフト 404 エラーであったり、「サイトが一時的に使用できません」というメッセージが通常のステータスコード HTTP 503 ではなく 200 を返したりします。Google ではソフトエラーページの検出に努力していますが、アルゴリズムがソフトエラーページの検出に失敗した場合、これらのページがそのままインデックスされてしまいます。これはランキングやクロスドメイン URL の選択で問題が発生する原因となる可能性があります。ステータスコードを確認する方法は簡単です。Fetch as Googlebot などのツールを使用して、サーバーが返す HTTP ヘッダーを確認するだけです。エラーページが HTTP 200 を返した場合、正しい HTTP エラーステータスコードを返すように設定を変更します。また、ウェブマスターツールの診断セクションにあるクロールエラーページで、ソフト 404 の報告がないか確認してください。
コンテンツの変更とフレーム: ホスティングプロバイダによってコンテンツが変更され（一般的には、ページにスクリプトや画像が挿入されます）、驚いたことがあるウェブマスターの方もいるでしょう。また、<frames>や <iframe> を使用してサイトのコンテンツが他のページに埋め込まれて表示されることもあります。ウェブホストによってコンテンツに意図しない変更が行われたかどうかを確認するには、ホストが提供するページのソースコードを確認し、ご自身でアップロードしたコードと比較します。サーバーによるコードの変更は、とても便利な場合もあります。たとえば、サーバーで Google の mod_pagespeed Apache モジュール（英語）などのツールを使用している場合、ページの表示速度を最適化するために縮小コードを返すことがあります。
スパムやマルウェア: 一部のウェブホストやサブドメインサービスが、マルウェアやスパムを広める要因になっている場合があります。Google ではユーザーの保護と検索品質を維持するための措置は、なるべく細やかに対応するようにしていますが、ホスティングされているサイトの大部分がスパムサイトであったり、マルウェアを配布したりしている場合、ウェブホスト全体に対して措置を取る必要が出てくることがあります。マルウェアを制御する助けとして、Google は以下のツールを提供しています。

Safe Browsing Alerts for Network Administrators （英語）: ホスティングプロバイダ向けの情報です。
マルウェアの通知: ウェブマスターツール内にある個別のウェブサイト向けの情報です。
Safe Browsing API について: 開発者向けです。

以上のヒントが、ホスティングプロバイダとウェブマスターの皆さまが問題を見つけ出し修正するのに役立てば幸いです。ここに挙げた以外に、サービスの品質やサポートの充実度など、ホスティングの品質面についても気を配るようにしてください。

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

Written by Pierre Far, Webmaster Trends Analyst
Original version: Tips for hosting providers and webmasters

2011 年もありがとうございました！ウェブマスターヘルプフォーラムから感謝をこめて

2011-12-27T10:58:00.001+09:00

2011 年も残すところあと数日となりました。

Google ウェブマスター向け公式ヘルプフォーラムは、ウェブマスターの方々の問題解決や、ディスカッションの場として開設されてから 3 年。今年も、さらに多くの方にご参加いただきました。本当にありがとうございました。

ここで、2011 年ウェブマスター向けヘルプフォーラムのハイライトをご紹介します。

より使いやすく新しい UI へ
つい先日ですが、ウェブマスター向けヘルプフォーラムは新しいプラットフォーム「Google プロダクトフォーラム」に移行しました。Google グループをベースに開発された Google プロダクトフォーラムは利便性がより一層高くなり、関心をお持ちのトピックについて他のユーザーと簡単に意見交換したり、質問を投稿して回答を受けたりすることができるようになりました。

トップレベルユーザーの方々とアメリカへ
9 月にはアメリカのカリフォルニア州サンタクララ、およびマウンテンビューの Google オフィスにて、Google のヘルプフォーラムで活躍されている全世界のトップレベルユーザー（ヘルプフォーラムに貢献してくださっているアクティブなユーザーの呼称）をご招待して「グローバルトップレベルユーザーサミット 2011」が開催されました。日本のウェブマスターヘルプフォーラムからもあうらゆうまさんとマサさんの 2 人がこのイベントに参加され、他の参加者や Google 社員とよりよいヘルプフォーラムのあり方やプロダクトについてディスカッションしました。私達日本のサーチクオリティチームのメンバーもディスカッションに参加し、普段はフォーラム上でしかやり取りできないトップレベルユーザーのみなさまから直接ご意見をお聞きすることができ、非常に貴重な機会となりました。

みなさまからたくさんのアイディア・ご意見を頂きました
また、今年はユーザーの方々からの貴重なご意見・アイディアも、フォーラムを通してたくさん頂くことができました。3 月に実施したウェブマスターヘルプフォーラムユーザーアンケートではフォーラム運営についてご意見・アイディアを聞かせていただいたり、10 月には「ウェブマスターツールにどんな機能があるといいですか？」といったトピックを設定して、ご意見、ご提案を聞かせていただくことができました。また、3 月に起きた東日本大震災の際には、ウェブマスターとして震災に対してできることはないか、多くの方々がディスカッションに参加してくださいました。

これらすべては、多くのウェブマスターのみなさまに日頃から積極的に参加していただいているからこそ生まれたエピソードです。改めまして、今年フォーラムに参加してくださった全てのみなさんに感謝申し上げます。ありがとうございました！

ここで、特に活発にディスカッションに参加し、いつもフォーラムを盛り上げてくださっているみなさまのお名前をご紹介させていただきます。

あうらゆうまさん、マサさん、たむらはんさん、癋見no さん、suzukik さん、dronpa さん、VAIO さん、den さん、netya さん、emi さん、SEM-ADVISER さん、hnxyy654 さん

来年も多くのみなさまと共に、ウェブマスター向けヘルプフォーラムをますます活気あるコミュニティとして大きく成長させていけたらと思っています。
2012 年もどうぞよろしくお願いします！

それではみなさま、良いお年をお迎えください。

p.s.
フォーラムで 2011 年のブログ人気記事をご紹介してます。ちなみに、今年最も多くの方に読んで頂いた記事は「アフィリエイトを導入されているウェブマスターの皆さまへ」でした。2 位以下の記事は、ぜひ以下のスレッドからご覧下さい。
2011 年にウェブマスターのみなさまの関心を集めたブログ記事は!? 年末年始のお休み中にぜひお読みください。

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

多言語コンテンツのマークアップのヒント

2011-12-19T11:50:00.000+09:00

世界中のユーザーからのアクセスがあるようなサイトにおいて、ユーザーの言語や地域に適したコンテンツを提供する方法はいくつかあります。Google では昨年、コンテンツは単一の言語で提供し、メニューやナビゲーション、フッターなどを複数の言語で提供しているウェブページ向けに、rel="alternate" hreflang="x" （英語）のサポートを開始いたしました。

今回は、多言語コンテンツに対する以下の 2 つのケースのサポートをさらに充実させます。

多地域向けのサイトで、ほぼ同じ内容のコンテンツを使用している場合。例: オーストラリア、カナダ、米国向けの英語版サイトで、価格のみが異なっているもの
多地域向けのサイトで、内容をすべて翻訳したコンテンツを提供しているもの、あるいは、全く異なる各国言語のコンテンツを地域別に提供しているもの。例: 日本語、英語、韓国語で書かれた製品情報ページを持つサイト

言語と地域を指定する
Google では、rel="alternate" hreflang="x" のサポートをさらに拡張し、翻訳されたコンテンツ、または複数の異なる地域向けに提供されたコンテンツに対応しました（英語）。hreflang 属性では言語が指定でき、また任意で国の指定、同等コンテンツのある代替 URL の指定もできます。このような代替 URL を指定することによって、Google ではこのようなページをグループとして認識し、検索ユーザーの言語地域に最適な URL を提供することを目指しています。代替 URL は、同じサイトのものでも、別のドメインのものでも、どちらでも構いません。

ほぼ同一のコンテンツとしてページにアノテーションを付ける
同一言語を使用し、異なる地域を対象にする、ほぼ同じコンテンツを持つページが複数ある場合は必要に応じて、rel="canonical" 属性を使用して、優先するバージョンを指定することができます。Google はその指定に基づき、検索結果を表示する際はそのバージョンを優先しつつ、適宜ユーザーの地域に対応する URL を表示するようにします。この方法は、例えば、同一の製品ページのドイツ語版を用意しているが、ドイツ、オーストリア、スイスぞれぞれの Google で検索するユーザーに見せるページを分けたい場合などに活用できます。

使用例
具体的な手順を、URL の例を示しながら説明します。

http://www.example.com/ - ウェブサイトの通常のホームページ (スペイン語)
http://es-es.example.com/ - スペインのユーザー向けバージョン (スペイン語)
http://es-mx.example.com/ - メキシコのユーザー向けバージョン (スペイン語)
http://en.example.com/ - 汎用的な英語バージョン

これらのページすべてに対し、マークアップを次のように使用して、言語と地域 (任意) を指定します。


<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/" />

hreflang=”es-ES” や hreflang=”es-MX” のように地域が指定されている場合、Google はその地域をターゲットにしているものと判断します。これらのアノテーションはすべて、URL 単位で使用してください。上記のリンク要素のどちらについても、サイトのトップページではなく、特定のページの URL を使用するようにしてください。

困ったときは
多地域、多言語対応のウェブサイトの正しい実装方法に関してご不明な点がありましたら、ヘルプセンター（英語）の該当トピックをご覧になるか、ウェブマスターヘルプフォーラムまでご質問をお寄せください。

Written by Christopher Semturs, Software Engineer, Search Infrastructure, Google Switzerland
Original version: New markup for multilingual content

スマートフォン版 Googlebot-Mobile の導入について

2011-12-16T01:22:00.000+09:00

スマートフォンユーザの増加に伴い、最近ではスマートフォン用に最適化されたコンテンツを提供するサイトも増えてきました。そこでGoogleでは、従来の携帯電話（フィーチャーフォン）のユーザーエージェントを使用した Googlebot-Mobile に加えて、スマートフォンのユーザーエージェントを使用した Googlebot-Mobile によるクロールを開始しましたのでお知らせいたします。スマートフォン版 Googlebot-Mobile の導入により、より幅広くスマートフォン用コンテンツを収集して、スマートフォンユーザーのための検索サービスの改善に利用していきます。

現時点で Googlebot-Mobile が使用する主なユーザーエージェントは次の通りです。

従来型携帯電話版 Googlebot-Mobile

SAMSUNG-SGH-E250/1.0 Profile/MIDP-2.0 Configuration/CLDC-1.1 UP.Browser/6.2.3.3.c.1.101 (GUI) MMP/2.0 (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)
DoCoMo/2.0 N905i(c100;TB;W24H16) (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)

スマートフォン版 Googlebot-Mobile

Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_1 like Mac OS X; en-us) AppleWebKit/532.9 (KHTML, like Gecko) Version/4.0.5 Mobile/8B117 Safari/6531.22.7 (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)

スマートフォン版 Googlebot-Mobile により収集されたコンテンツは、主にはスマートフォン向け検索の品質向上に利用されますが、デスクトップ検索や他の検索モードの品質向上にも利用されることもあります。新しいクローラが収集する情報の例としては、スマートフォン用のコンテンツであるかどうかや、リダイレクトの情報などが挙げられます。

これらの情報を用いる新たな機能として「スマートフォン用ページのリダイレクトスキップ」があります。この機能は、スマートフォンをスマートフォン用コンテンツにリダイレクトするページについて、検索結果から直接スマートフォン用ページへリンクするというものです。この機能により、検索結果ページをロードする際、リダイレクトに起因して発生する平均0.5〜1秒の遅延を短縮することが可能となります。

Googlebot-Mobile が使用するすべてのユーザーエージェントは特定の機種を指すものとなっていますので、Googlebot-Mobile を特別扱いせず、フィーチャーフォンの Googlebot-Mobile はフィーチャーフォンとして、スマートフォンの Googlebot-Mobile はスマートフォンとして扱ってください。過去のブログポストで述べたガイドラインは、スマートフォンに関する記述を除いては有効です。Googlebot-Mobile が従来型の携帯電話のユーザーエージェントしか使用しないという前提に基づいて、Googlebot-Mobile を特別に扱っているサイトがあるかもしれませんが、この機会に Googlebot-Mobile に対する方針の見直しをおすすめいたします。

この記事に関するコメントやご質問は、ウェブマスターヘルプフォーラムまでお寄せください。
* ウェブマスターヘルプフォーラムでは 2011 年 12 月 16 日～ 2011 年 12 月 22 日の間、スマートフォン版 Googlebot-Mobile に関する質問専用のスレッドを開設していますので、ぜひご利用ください。

Posted by 加藤義清 / ソフトウェア・エンジニア

Google カスタム検索エンジンがウェブマスターツール内で作成・管理できるようになりました

2011-12-09T18:14:00.003+09:00

Google カスタム検索エンジン（CSE）は、サイト内に Google 検索を用いたオーダーメイドの検索環境を作成するサービスです。複数のサイトをまたいで検索したり、自分のサイトデザインに合わせて検索結果のデザインを変更したり、検索向け AdSense で収益を得ることもできます。この度、この Google カスタム検索エンジンがウェブマスターツールから簡単に作成できるようになりました。

初めて CSE を作成する場合、ウェブマスターツールの「Labs」＞「カスタム検索」をクリックすると、自動でサイト内のみを検索するデフォルト設定の CSE が作成されます。そこから、設定を変更してカスタマイズするか、そのままサイトに CSE を追加するためのコードを入手できます。設定を変更したい場合はいつでも CSE の設定ページに移動することができます。

CSE を作成後（または、既に作成している場合）、ウェブマスターツールの「Labs」＞「カスタム検索」をクリックすればウェブマスターツールのページを離れることなく CSE を管理できます。

今回のアップデートで、ユーザーが皆さんのサイト内で情報を探しやすくなれば幸いです。ウェブマスターツールと CSE の連携に関するコメントやご質問は、ウェブマスターヘルプフォーラムまでお寄せください。

Posted by Sharon Xiao, Software Engineering Intern, and Ying Huang, Software Engineer
Original version: Create and manage Custom Search Engines from within Webmaster Tools

複数ページにまたがる記事やコンテンツをお持ちの方へ。rel=”next” と rel=”prev” を使用したページネーションのご紹介

2011-12-02T17:20:00.003+09:00

rel=”canonical” の設定が重複コンテンツを Google に知らせる手がかりになっているのと同様に、複数ページにまたがった一つのコンテンツがある場合、HTML のタグの rel=”next” と rel=”prev” （英語）を使ってそのページ間の関係を Google に示すことができるようになりました。

ウェブを見渡してみると、続きものになっているコンテンツには様々な形態があります。例えば 1 つの記事を複数のページに分けているものや、同一の製品カテゴリに属する製品を複数ページにまたがって掲載しているもの、フォーラムの 1 つのスレッドを一連の複数 URL に分割しているものなどがあります。この度、続きものを構成する個々のページ上で rel=”next” と rel=”prev” マークアップの指定を行うことによって、Google に対し、次のような指定ができるようになりました。

個々のページ / URL にあるリンクの効果などのインデックス対象の属性を、一連のページ全体のものとしてまとめること（つまり、page-1.html、page-2.html といった個々のページにあるリンクをばらばらの状態ではなく、一連のグループとして取り扱うこと）
最も関連性が高いページ / URL （通常は一連のコンテンツの最初のページ）にユーザーを誘導すること

rel=”next” と rel=”prev” を使うことによって、続きものになっているコンテンツの個々の URL 間の関係性を Google に示すことができます

ただし、この rel=”prev” と rel=”next” を実装すべきかどうかについて判断するにあたって、1 つ例外があります。連続するページで構成されるコンテンツとは別に、「すべて表示」ページ（ 1 ページに情報のすべてが表示されたページ）をお持ちの場合、あるいはそれを作ろうとしている場合はブログ記事「検索結果に『すべて表示』ページを優先的に表示する方法」を参照してください。ユーザーは検索をするときに「すべて表示」ページを好む傾向にあるため、Google では、適正と判断される場合は、個々のページではなく「すべて表示」ページの方を検索結果に表示するようにしています（rel=”next” および rel=”prev” を使用すれば、個々のページが表示される可能性が高くなります）。

サイトに「すべて表示」ページがない場合や、Google 検索による「すべて表示」ページの表示を無効にしたい場合は、この記事で説明する rel="next" と rel="prev" を使用してください。

「すべて表示」ページが含まれるページ構成については、ブログ記事の検索結果に「すべて表示」ページを優先的に表示する方法をご参照ください

ウェブマスターの選択肢

このような続きもののコンテンツに対するウェブマスターの対応については、次の 3 つの選択肢があります。

特に何も対策はしない。複数ページに分割されたコンテンツがウェブ上に存在し、ページ内の HTML マークアップ rel=”next”、rel=”prev” の有無に関係なく、Google は最も関連性の高い検索結果を表示するよう努めます。
サイトに「すべて表示」ページがある場合、または「すべて表示」ページを設けようとしている場合は、検索結果に「すべて表示」ページを優先的に表示する方法を参照してください。
ひと続きになっているコンテンツを構成する個々の URL に rel=”next” と rel=”prev” を指定し、URL 間の関係性を Google に示す（このブログ記事で紹介している例です）。これによって Google はコンテンツのインデックス登録がより正確にできるようになり、最も関連性の高いページ（通常は最初のページ）をユーザーに表示するようになります。実装に関しては以下で詳しく説明します。

rel=”next” と rel=”prev” の実装方法

上記の 3 番を選んだ方は、実装方法の説明をご覧下さい。次のようにいくつかの URL にページ分けされているコンテンツを例にとります。

http://www.example.com/article?story=abc&page=1
http://www.example.com/article?story=abc&page=2
http://www.example.com/article?story=abc&page=3
http://www.example.com/article?story=abc&page=4

最初のページ http://www.example.com/article?story=abc&page=1 では、<head> のセクションに次のように記述します。
<link rel="next" href="http://www.example.com/article?story=abc&page=2" />

2 番目のページ http://www.example.com/article?story=abc&page=2:
<link rel="prev" href="http://www.example.com/article?story=abc&page=1" />
<link rel="next" href="http://www.example.com/article?story=abc&page=3" />

3 番目のページ http://www.example.com/article?story=abc&page=3:
<link rel="prev" href="http://www.example.com/article?story=abc&page=2" />
<link rel="next" href="http://www.example.com/article?story=abc&page=4" />

そして最後のページ http://www.example.com/article?story=abc&page=4:
<link rel="prev" href="http://www.example.com/article?story=abc&page=3" />

いくつか注意すべき点があります:

最初のページには rel=”next” マークアップのみ記述し、rel=”prev” マークアップは記述しない。
2 ページから、最後から 1 つ前のページまでは、rel=”next” と rel=”prev” のマークアップを両方とも記述する。
最後のページには rel=”prev” のみ記述し、rel=”next” は記述しない。
rel=”next” と rel=”prev” の値は、相対 URL または絶対 URL のどちらでもよい（ <link> タグに準じる）。また、ドキュメントにリンクを指定している場合は、そのベース URL に基づいて相対パスを指定する。
rel=”next” と rel=”prev” は、 <head> セクション内で宣言するだけでよく、ドキュメントの <body> 内で記述する必要はない。
rel=”previous” は、rel=”prev” リンクの構文上のバリエーションとして許容される。
rel="next" と rel="prev" を指定することと、rel="canonical" を指定することは、別々の概念である。よって、同一ページ内に両方の宣言を記述することが可能。たとえば、http://www.example.com/article?story=abc&page=2&sessionid=123 の中で、次のように記述してよい。

<link rel="canonical" href="http://www.example.com/article?story=abc&page=2”/>
<link rel="prev" href="http://www.example.com/article?story=abc&page=1&sessionid=123" />
<link rel="next" href="http://www.example.com/article?story=abc&page=3&sessionid=123" />
rel=”prev” と rel=”next” は Google に対するヒントであり、絶対的な指示ではない。
rel="prev" や rel="next" を指定すべき箇所で指定していないなど、正しく実装されていない場合は、Google はこれまでと同様にページのインデックス登録を行い、コンテンツを把握する。

わからないことがある場合は？

詳しい情報は、ヘルプセンターを参照してください。この記事に関するコメントやご質問は、ウェブマスターヘルプフォーラムまでお寄せください。

Written by Benjia Li & Joachim Kupke, Software Engineers, Indexing Team
Original version: Pagination with rel=“next” and rel=“prev”

検索結果に「すべて表示」ページを優先的に表示する方法

2011-12-02T17:14:00.003+09:00

複数ページにまたがる記事やコンテンツをお持ちのウェブマスターの方向けに、「すべて表示」ページ（View-all ページ）を使用して検索結果に優先的に表示する方法をご紹介します。

ユーザーは、情報の一部だけが表示されているページを適宜めくっていく（「次へ」をクリックして次のページを閲覧する）コンテンツよりも、1 ページに情報のすべてが表示されたコンテンツの方を好むということが、我々が実施した調査の結果、判明しました。

ユーザーは、ページをめくることでロードの待ち時間が長くなる複数ページ構成より、1ページにすべてが表示されているコンテンツの方を好むことが多い

これを踏まえて Google はユーザーエクスペリエンス向上のため、続きもののコンテンツ（たとえば page-1.html、page-2.html... が存在するコンテンツ）に「すべて表示」のバージョン（たとえば page-all.html）も存在していることを検出したときは、検索結果には「すべて表示」のバージョンを優先して表示する取り組みをおこなっています。サイトに「すべて表示」のバージョンが存在している場合は、ウェブマスター側では特に何もする必要はありません。また、インデックス対象となるリンクなどの属性は、分割されている個々のページから、「すべて表示」バージョンのページに統合されます。

ただし、ロード時間が長いと「すべて表示」ページが敬遠される場合も

興味深いことに、ユーザーが「すべて表示」ページを好まなかったケースは、ロード時間の遅さに関連がありました（たとえば「すべて表示」ページに画像が数多く含まれていて、ロードに時間がかかる場合など）。ユーザーは検索結果表示の遅さにも不満（英語）を感じることを思えば当然のことです。したがって、一般的には「すべて表示」ページの方が好まれてはいるものの、ウェブマスターとしては、このようなパフォーマンスの問題と、全体的なユーザーエクスペリエンスとのバランスを取ることが重要です。

続きもののコンテンツに関する最善策

サイトに「すべて表示」ページがある場合

Google では、コンテンツの「すべて表示」ページがある場合、そのページを検出しようとします。（それを構成する個々のページがある場合はそれらのページも同時に検出しようとします）ウェブマスターの皆さまには特に何もしていただく必要はありません。ただし、Google に対してより明確なシグナルを送りたい場合は、個々の構成ページにて rel=”canonical” に「すべて表示」ページを指定することで、一連のページを適切に検出する可能性を高めることができます。

rel=”canonical” にて、一連の URL に含まれるコンテンツをまとめた「すべて表示」ページ（例: page-all.html）を指定することができます

なぜこれでうまくいくのでしょうか？

図に示されているように、一連のコンテンツの 1 つである page-2.html は、canonical のターゲットに page-all.html を指定することができます。ユーザーがあるキーワードで検索をおこない、検索結果から page-all.html が選択された場合、仮にキーワードに最も関連しているのが page-2.html であったとしても、ユーザーは page-all.html の中で、page-2.html に含まれる目的の情報を得ることができます。

一方、page-2.html にて page-1.html を canonical に指定することは避けてください。page-1.htm には page-2.html のコンテンツが含まれていないためです。ユーザーの検索キーワードは page-2.html 上のコンテンツに関連性が高いことはあり得ますが、page-2.html の canonical に page-1.html が設定されていると、ユーザーは検索結果の中から page-1.html を選択することも考えられます。この場合、目的の情報に到達するために別のページに移動しなければならないという操作が発生します。それはユーザーにとって不便であると同時に、Google にとっても最適といえる結果ではなく、また、ターゲットのはっきりしないトラフィックをサイトに呼ぶことになりかねません。

ただし、「すべて表示」ページを検索結果に表示しないことを強く希望する場合は、1）一連のコンテンツの個々のページに「すべて表示」ページへの rel=”canonical” が設定されていないことを確認した上で、2）「すべて表示」ページに “noindex” を設定してください。（設定方法は一般的なもので問題ありません）

個々の構成ページを優先表示したい場合（または「すべて表示」ページがない場合）

サイトが下記の状況のいずれか（または両方）に当てはまるケースとなるでしょう。
- 「すべて表示」ページが検索結果に適さない（たとえばロード時間が長すぎる、ユーザーにとって操作が難しくなるためなど）
- サイトのユーザーが複数ページ構成の方を好み、また検索結果に「すべて表示」ページではなく、個々のページの表示を望んでいる
このような場合は、標準的な HTML の rel=”next” と rel=”prev” 要素を指定して、一連のコンテンツの個々の構成ページ間の関係性を指定することができます。正しく指定されていれば、Google は通常、下記のような挙動をとります。
- 個々のページ/URL にあるリンクなどのインデックス属性を統合します。
- 個々のページのうち、最も関連性が高いページ/URL をユーザーに提供します。通常、コンテンツの最初のページですが、アルゴリズムによって、一連のコンテンツのいずれかのページを検索結果に表示する場合もあります。
個々のページにて、コンテンツの最初のページに対して rel=”canonical” を使用しているケース（たとえば page-2.html にて、rel=”canonical” に page-1.html を指定するなど）が見られますが、これらの個々のページには実際に重複コンテンツがあるわけではないため、このような指定はお勧めできません。rel=”next” と rel=”prev” を使用するのがより適切です。

まとめ

一般に、検索結果には「すべて表示」バージョンを好むユーザーが多いことから、Google では、適切な検出を行ったうえで「すべて表示」バージョンを優先的に表示する取り組みをおこなっています。サイトに続きもののコンテンツがある場合、ウェブマスターの皆さまに特に実施していただく作業はありません。ただし、サイト情報をどのように表示するのが最適なのかをより明確に Google に示したい場合は、下記の作業を行ってください。

「すべて表示」ページを最適化する場合は、個々の構成ページにて rel=”canonical” を使用し、ターゲットに「すべて表示」ページを指定します。
あるいは、
サイトの「すべて表示」ページを使わない場合は、 rel=”next” と rel=”prev” 属性を使用し、Google が一連のページを識別した際に構成ページの方を検索結果に表示するよう明示します。

わからないことがある場合

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

2011/12/3 追記
画像内の URL を修正いたしました。ご指摘いただきましたみなさま、ありがとうございました。

Written by Benjia Li & Joachim Kupke, Software Engineers, Indexing Team
Original version: View-all in search results

著作者情報のマークアップに対応しました

2011-11-25T11:08:00.003+09:00

この度、Google ではウェブ上のコンテンツとその著作者を関連付ける、著作者情報のマークアップに対応いたしました。素晴らしい著作者によるコンテンツを検索結果の中で見つけやすくするために、このデータを使用していこうと考えています。

現在 Google では、ウェブサイト内のコンテンツから著作者情報ページへリンクするマークアップに対応しています。たとえば、多くの記事を書いている The New York Times の記者がいたとします。ウェブマスターは著作者情報をマークアップすることによって、これらの記事を The New York Times の記者ページに関連付けることができます。著作者情報ページは、著作者がどういった人物か説明するものであり、著作者の略歴、写真、書いた記事、その他のリンクなどを含めることができます。

もしあなたがこうした記事等の著作物を掲載したサイトを運営しているなら、ぜひ著作者情報のマークアップについてヘルプ記事「著者情報」をご一読ください。このマークアップは、各検索エンジンやその他のウェブサービスが、ウェブのいたるところに存在する同一の著作者による著作物を識別できるよう、HTML5 （rel=”author”）や XFN （rel=”me”）などの既存の標準技術を利用しています。schema.org のマイクロデータ（英語）を使用した構造化データのマークアップを既に行っている場合でも、Google は著作者情報として認識します。

Google では、このマークアップを可能な限り簡単に取り入れられるようにしたいと考えています。そのために、The New York Times、The Washington Post、CNET、Entertainment Weekly、The New Yorker などの複数のサイトと協力してページのマークアップに取り組みました。さらに、YouTube や Blogger がホスティングするすべてのコンテンツにもマークアップを追加しました。将来的には、どちらのプラットフォームでもコンテンツの公開時に自動でマークアップが追加されるようになります。

良質なコンテンツは素晴らしい著作者によって生み出されます。Google ではこのマークアップによって、コンテンツの著作者を強調したり、検索結果のランク付けを改良したりできないか、その可能性を模索してまいります。

Posted by Othar Hansson, Software Engineer
Original version: Authorship markup and web search

クロスドメイン URL の選択 - 複数のドメイン間の重複コンテンツの正規化について

2011-11-16T10:48:00.001+09:00

このブログでも何度か重複コンテンツに関して取り上げてきました。重複コンテンツとは、同じコンテンツが複数の URL（同一のドメインにある/なしを問わず）に存在することを指しています。Google では、コンテンツが重複するページグループを発見した場合、アルゴリズムに従ってコンテンツを代表する URL を 1 つ選択します。ページグループには、同じサイトからの URL も、別のサイトからの URL も含まれます。複数のドメインが含まれるグループから代表 URL が選択された場合、この選択は「クロスドメイン URL の選択」と呼ばれます。簡単な例を挙げると、a.com からの URL と b.com からの URL が含まれる同じコンテンツのグループで、b.com から代表 URL が選択された場合、a.com の URL はそれ以降 Google の検索結果に反映されず、検索からのトラフィックが減ることがあります。

ウェブマスターは、rel="canonical" 属性や 301 リダイレクトなどを適切に設定することで、アルゴリズムに選択すべき URL を伝えることができます。アルゴリズムによる選択は、ほんとんどの場合こういったウェブマスターの意図が正しく反映されています。しかし時折クロスドメイン URL の選択を不適切と感じたり、不適切な場合の対処法が分からない、といった声を耳にすることがあります。

そこで Google は、クロスドメイン URL の選択の透明性を高めるために、ウェブマスターツールに登録された URL ではなく外部 URL がアルゴリズムによって選択された場合、それをウェブマスターツールにメッセージとして表示し始めました。このメッセージの詳細については、クロスドメイン URL の選択を参照してください。今回のブログ記事では、クロスドメイン URL のよく見られるいくつかのケースについて取り上げ、不適切な選択を修正する方法についてお話しします。

不適切なクロスドメイン URL の選択がされる主な原因
クロスドメイン URL の選択が適切になされるようアルゴリズムに伝える方法は数多くあります。

実際ほとんどの場合、Google のアルゴリズムはウェブマスターが代表 URL を示すために設定したシグナルに基づいて選択を行います。たとえば、ウェブマスターがサイト移転時のガイドラインやベストプラクティス (英語) に従っていた場合は、新しいウェブサイトの URL が代表 URL であることを Google のアルゴリズムに正しく伝えていると言えるでしょう。ウェブサイトの移転中にウェブマスターツールで今回実装された新しい通知メッセージを受信した場合、Google のアルゴリズムがサイト移転に気付いたと見なすことができます。

その一方で、アルゴリズムが代表にしたくない URL を選択した場合はどうすればいいのでしょうか。クロスドメイン URL の選択が不適切 (ウェブマスター側の希望と異なる) であった場合、いくつかの方法で状況を改善することができます。以下に、意図と異なるクロスドメイン URL の選択が行われる一般的な原因と、その修正方法をご紹介します。

複数リージョン向けウェブサイトを含む重複コンテンツ：多くのウェブマスターの方が、ときには不注意で、そしてときにはユーザーの所在地によってコンテンツを提供するために、同じ言語でほぼ同一のコンテンツを複数ドメイン上で公開しています。たとえば、ウェブマスターが example.com と example.net の両方で英語の同一コンテンツを用意したり、example.de、example.at、example.ch で 1 つのドイツ語のウェブサイトをホストしたりすることは珍しくありません。

ウェブサイトの性質やユーザーに応じて、現在サポートされている正規化の方法のうちいずれかを用いて、代表 URL をアルゴリズムに通知することができます。詳細については以下の記事を参照してください。

設定ミス：一部の設定ミスによって、アルゴリズムが誤った選択を行うことがあります。例として以下のようなものがあります：

正規化の間違い：正規化の設定の際に誤って外部ウェブサイトを指定してしまうと、アルゴリズムがその外部サイトの URL を検索結果への表示用に選択してしまうことがあります。これは、ウェブマスターが導入したコンテンツ管理システム (CMS) や CMS プラグインの設定に間違いがある場合に発生します。

こういった状況が発生している場合は、ウェブサイトで使用する URL を誤って正規化している部分 (rel="canonical" 属性や 301 リダイレクトの不適切な使用) を見つけて、修正します。
サーバーの設定ミス：時折、サイト a.com のコンテンツが b.com の URL に返されるという、ホスティングの設定ミスが見受けられることがあります。また、2 つの無関係なウェブサーバーが同一のソフト 404 エラーを返すと、Google がエラーページと判断しないことがあります。いずれの場合も、同じコンテンツが異なる 2 つのサイトから返されたと見なされ、アルゴリズムが a.com の URL を b.com の正規化と判断して選択してしまうことがあります。

こういった場合は、ウェブサーバーのどこに誤りがあるのか調査する必要があります。たとえば、サーバーがエラーページに対して HTTP 200 (成功) ステータスコードを返したり、同一サーバー上でホスティングされている別のドメインへのリクエストを取り違えたりすることがあります。問題の原因が分かり次第、サーバー管理者と協力して設定を修正してください。

悪意のあるウェブサイトへの攻撃：ウェブサイトに対する攻撃の中には、勝手に正規化を行うコードを生成するものがあります。たとえば、サイトに HTTP 301 リダイレクトを返させるものや、HTML や HTTP ヘッダーにドメインをまたがった rel="canonical" リンク属性を挿入するものがあります。この場合は悪意のあるコンテンツをホスティングしている外部 URL を指すことが一般的です。このような例では、攻撃を受けたウェブサイトの URL ではなく、悪意のある URL やスパム URL がアルゴリズムに選択されてしまうことがあります。

このような場合、サイトがハッキングされた、またはマルウェアに感染した場合のガイドラインに従い、再審査リクエストを送信します。ウェブマスターツールの Fetch as Googlebot 機能を使用すると、Googlebot に見えているようにコンテンツを表示し、クローキングされた攻撃を検出できます。

また、まれにではありますが、あなたのコンテンツをあなたから許諾を得ることなく使用している外部サイトの URL が選択されることがあります。著作権に違反して、他のサイトにコンテンツを複製された場合、そのサイトのホストに連絡を取って削除を依頼してください。また、DMCA (デジタルミレニアム著作権法) に基づく要求を提出することで、権利を侵害しているページを検索結果から除外するよう Google にリクエストすることもできます。

この記事について詳しい情報は、ヘルプ記事「クロスドメイン URL の選択」をご覧ください。コメントやご質問は、ウェブマスターヘルプフォーラムまでお寄せください。

Posted by Pierre Far, Webmaster Trends Analyst
Original version: Raising awareness of cross-domain URL selections

多言語ウェブサイトの作成について

2011-11-10T11:35:00.003+09:00

多言語のウェブサイトとは、複数の言語に向けてコンテンツを提供するウェブサイトです。多言語のウェブサイトの例には、日本語に加えて中国語と韓国語で公開されているアジアをターゲットとした企業のサイトや、ヨーロッパのサッカーチームのファンサイトを日本語とそのチームの母国語で公開している場合など様々なサイトがあります。

通常、多言語のウェブサイトを作成する意味があるのは、ターゲットユーザーの使用する言語が複数にわたっている場合です。ヨーロッパのサッカーチームのブログが日本にいるそのチームのファンに向けたものであれば、日本語のみで公開しても問題ないでしょう。しかし、世界中のそのチームファンにも読んでもらいたいと考えるなら、英語やそのチームの母国語のコンテンツも用意すると役に立つことでしょう。

Google の言語認識

Google はページごとにその主となる言語を判断しています。言語を認識しやすくするために、ページごとに使用する言語を統一すること、そして原文と訳文を一緒に表示しないことをおすすめします。1 ページについて複数の言語を認識することも可能ではありますが、ページ内のすべての要素（ヘッダー、サイドバー、メニューなど）の言語は統一して使用することをおすすめします。

Google では「lang」属性から文書型定義（DTD）まで、コードレベルの言語情報はすべて無視します。一部のサイト制作ソフトでは、これらの属性が自動的に作成されるため、ウェブページの言語を判断する際にこうした情報はあまり信頼できないためです。

一般的に Google である言語で検索を行う場合、ユーザーは検索した言語に最適化された検索結果が表示されることを期待しています。そこで、サイトの多言語化を図る際には、検索結果に表示されるスニペットや URL などにも気を配る事が重要となります。以下にそのためのヒントをいくつか紹介します。

多言語のサイトの分析: URL 構造

多言語のウェブサイトを作成するときに、特別な URL を用意する必要はありません。とはいえ、URL を見て自分がウェブサイトのどのセクションにいるのかを把握できればユーザーにとって便利です。たとえば、次のような URL が使われていると、ユーザーは自分がこのサイトの中の英語用コンテンツにいることが把握できます。

http://example.ca/en/mountain-bikes.html
http://en.example.ca/mountain-bikes.html

一方、次のような URL であれば、同じページをフランス語で表示していることがわかります。

http://example.ca/fr/mountain-bikes.html
http://fr.example.ca/mountain-bikes.html

また、このような URL 構造を使うと、多言語コンテンツのインデックス状況が分析しやすくなります。

非英語文字が含まれる URL を作成する場合は、必ず UTF-8 エンコードを使うようにしてください。UTF-8 でエンコードされた URL であれば、コンテンツ内からリンクされた場合も適切にエスケープされます。手動で URL をエスケープする必要がある場合は、オンラインの URL エンコーダを利用するのが簡単です。たとえば、次の URL を英語からフランス語に翻訳するとします。

http://example.ca/fr/mountain-bikes.html

翻訳後の URL は次のようになります。

http://example.ca/fr/vélo-de-montagne.html

この URL には非英語文字が 1 文字（é）含まれているので、ページ内のリンクで使用するために適切にエスケープすると次のようになります。

http://example.ca/fr/v%C3%A9lo-de-montagne

多言語のウェブサイトのクロールとインデックス

まずはじめに、自動翻訳したページをインデックスの対象としないようにしてください。自動翻訳は意味が通じない場合があるため、スパムとみなされる可能性があります。また、自動翻訳されたコンテンツは、しばしばユーザーにとって理解できなかったり、不自然に感じることがあります。そのようなコンテンツを多言語のウェブサイトとして作成するのは、ユーザーにとって有益ではありません。

多言語化を行う場合は、Googlebot がサイトのすべての言語バージョンをクロールできるようにしてください。また、ページ間で相互にリンクすることをおすすめします。つまり、同一コンテンツを異なる言語で掲載したページ間をリンクします。ユーザーにとってもこのリンクは非常に便利です。先ほどの例を使って説明すると、たとえばフランス語を使うユーザーが http://example.ca/en/mountain-bikes.html にアクセスしてしまった場合、ワンクリックで http://example.ca/fr/vélo-de-montagne.html に移動して同じコンテンツをフランス語で表示することができます。

サイトをよりクロールされやすくするために、ブラウザの言語設定による自動的なリダイレクトを行わないようにしてください。このようなリダイレクトを行うと、ユーザー（と検索エンジン）がサイトのすべての言語バージョンを見られなくなる場合があります。

最後に大切なこととして、各言語のコンテンツには別々の URL を使用してください。つまり、多言語間で同一の URL を使って Cookie でコンテンツを切り替えるような構造は避け、それぞれの言語ごとに URL を設定しましょう。

文字コードの使用

Google は、HTTP ヘッダー、HTML ページヘッダー、コンテンツから文字コードを直接判定します。文字コードに関して注意していただきたいのは、コンテンツとヘッダーの間などで情報が矛盾していないか注意することです。Google ではさまざまな文字コードを認識できますが、可能であればウェブサイトでは UTF-8 を使用することをおすすめします。

多言語のウェブサイトの作成についての説明は以上です。この記事に関するコメントやご質問は、ウェブマスターヘルプフォーラムまでお寄せください。

Written by Xavier deMorales, Google Search Quality
Original version: Working with multilingual websites

SSL 検索における検索クエリデータの取得方法について

2011-11-01T10:15:00.004+09:00

インターネットの世界において SSL 暗号化は急速に広まって（英語）きています。Google は、ユーザーの皆さまにより安全にサービスをご利用頂くため、Google アカウントにログインしたユーザーの google.com における検索については、https://www.google.com での SSL 検索がデフォルト（英語）となるよう変更することにいたしました。この変更は数週間ほどかけて実施される予定です。なお、google.co.jp に関しましては、現在のところ、変更時期は未定です。

この変更がウェブマスターに与える影響はどのようなものでしょうか。http://www.google.com （SSL 不使用）でのオーガニック検索結果では、ユーザーが google.com から来たことと、その検索クエリがわかります（ユーザーのブラウザーが HTTP リファラーフィールドを通してこの情報を取得し渡します）。しかし、SSL 検索でのオーガニック検索結果では、ウェブサイト側はユーザーが google.com から来たことしかわかりません。ただし、ウェブマスターツールから豊富な検索クエリデータへアクセスすることは可能です。ウェブマスターツールに追加した確認済みのサイトに対して、ウェブマスターは以下の操作を行えます。

過去 30 日間のデイリー検索クエリトップ 1,000 と、デイリーランディングページトップ 1,000 の表示。
表示回数、クリック数、クリックスルー率（CTR）の表示。また、各クエリの検索結果における平均掲載順位を直近 30 日間で比較。
CSV 形式でのデータのダウンロード。

また、Google アナリティクスの検索エンジン最適化レポートをご利用いただいているユーザーは、ウェブマスターツールと同様の検索クエリデータにアクセスでき、豊富なレポート機能を活用していただけます。

ウェブマスターツールで検索クエリデータを表示する方法について、Google はさらに改善を重ねていきます。ご質問、フィードバック、ご提案があれば、ウェブマスターヘルプフォーラムまでお寄せください。

Posted by Anthony Chavez, Product Manager
Original version: Accessing search query data for your sites

ウェブマスターツールの検索クエリのデータが Google アナリティクスから利用可能になりました

2011-11-01T09:59:00.004+09:00

これまでウェブマスターツールからのみご利用頂けた検索クエリのデータですが、この度 Google アナリティクスの [トラフィック] セクションで正式にご利用いただけるようになりました。

なお、本機能につきましては以前 Google アナリティクス公式ブログにてパイロットベータの募集をアナウンスをさせて頂きました。みなさまからのフィードバックにより、多くの改善を重ね、このたび正式に公開させて頂きました。ご協力ありがとうございました。

ご利用頂けるデータは次のとおりです。

検索クエリ: 1 日あたり上位 1,000 件のクエリに対するインプレッション数、クリック数、掲載順位、クリックスルー率（CTR）の情報
ランディングページ: 1 日あたり上位 1,000 件のランディングページに対するインプレッション数、クリック数、掲載順位、CTR の情報
地域別サマリー: 国ごとのインプレッション数、クリック数、CTR

これらの検索エンジン最適化レポートはいずれも、Google アナリティクスの持つ高度なフィルタリング機能とビジュアル化機能を活用して、データをより深く分析することができます。セカンダリディメンションを指定することにより、ウェブマスターツールでは利用できない方法でサイトのデータを表示できます。

これらの検索エンジン最適化レポートを有効にするには、ウェブマスターツールで確認済みのサイト所有者であること、そのプロパティの Google アナリティクス管理者であることが必要です。有効にすると、これらのレポートを表示するプロファイルを管理者が選択できます。

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

Posted by Christina Chen, Product Manager
Original version: Webmaster Tools Search Queries data is now available in Google Analytics

パラメータ付き URL 処理の新機能

2011-10-29T15:46:00.006+09:00

ウェブマスターツールの [サイト設定] > [設定] セクションから「パラメータ処理」機能がなくなっていることに、お気付きの方もいらっしゃるかもしれません。実は、この機能は「URL パラメータ」という新しいセクションとして独立することになりました。また、名前だけでなく機能そのものも一新されたので、より便利に使っていただけるかと思います。なお、以前の「パラメータ処理」機能による URL パラメータの設定は、自動的にこの新しいバージョンに反映されます。では、この新しい「URL パラメータ」には、どのような便利な機能があるのでしょうか。まずはこの機能の目的と役立つケースについてご紹介しましょう。

機能の概要
「URL パラメータ」機能を利用すると、サイト内のどの URL を Googlebot にクロールさせるか、URL 内のパラメータに基づいて指定することができます。それによってたとえば、この機能を使うことで簡単に重複コンテンツがクロールされるのを防ぐことができます。このため、あなたのサイトへのクロール負荷を軽減でき、また重複していないコンテンツがよりたくさんインデックスされやすくなるので、サイトのクロールが効率的に行われるようになるでしょう。また、Googlebot のクロールする範囲がまだ拡大できると思われる場合にも、この機能は有用です。ただし、ご利用にあたっては注意が必要です。というのも、URL パラメータの動作について十分に理解していなければ、クロールされるべき URL が誤ってクロールされない設定になり、そのコンテンツが Googlebot からはアクセスできくなってしまう恐れがあるからです。

新機能の詳細
では次に、新たに追加された機能についてご紹介しましょう。まず、個々のパラメータにクロールアクションを割り当てる際に、パラメータの動作が細かく指定できるようになりました。最初の手順としては、各パラメータがページのコンテンツを変更するかどうかを指定します。もしそのパラメータによってページのコンテンツが変化しないのであれば、設定作業はここで終了です。Googlebot はこのパラメータの代表的な値を持つ URL を選択し、クロールするでしょう。パラメータによってコンテンツが変わることはないので、どの値が選択されても同じ結果になります。一方で、もしパラメータによってページのコンテンツが変わる場合は、そのクロール方法を次の 4 つの中から選択することができます。

Googlebot が決定
すべての URL
値が指定されている URL のみ
クロールしない

なお、「値が指定されている URL のみ」を選択することで、パラメータに使用する値を自分で指定することができます。もう Google が用意する値のリストに制限されることはなくなりました。また、必須ではありませんが、たとえば並べ替えやページ指定、コンテンツ選択など、パラメータの具体的な動作を指定することもできます。さらに、すべてのパラメータに対して、それを含むクロール済み URL の例がそれぞれ表示されるようになりました。

上記の 4 つのクロールオプションのうち、「クロールしない」は今回追加されたもので、特に注意が必要です。このオプションはもっとも優先度が高く、当該の URL に含まれる他のパラメータのどの設定よりも優先されます。つまり、ある URL のパラメータが 1 つでも「クロールしない」に設定されていると、他のパラメータがたとえ「すべての URL」に設定されていたとしても、その URL がクロールされることはありません。なので、このオプションを使用するときには十分にご注意ください。ちなみに、2 番目に適用が優先されるオプションは「値が指定されている URL のみ」です。

事例
では、実際の例を通して、少し頭の体操をしてみましょう。
- - -
fairyclothes.example.com という名前のオンラインストアがありました。このお店のウェブサイトでは、URL の中でパラメータを使用しており、さまざまな URL から同じコンテンツにアクセスできるようになっていました。ある日、オンラインストアのオーナーは気付きました。冗長な URL があまりにも多いと、Googlebot がサイト全体をクロールできないかもしれない、と。そこで、好奇心旺盛で何でも知りたがる助手を偉大なる「ウェブの魔法使い」の元へ送り、Googlebot による重複コンテンツのクロールを減らすために「URL パラメータ」機能をどのように使用すればよいか、教えを請うことにしました。賢者として知られる「ウェブの魔法使い」は、URL パラメータに目を通すと、次のような設定を提案しました。

パラメータ名	コンテンツへの影響	Googlebot がクロールする対象
trackingId	なし	代表的な URL 1 つ
sortOrder	並べ替え	値が「lowToHigh」に指定されている URL のみ
sortBy	並べ替え	値が「price」に指定されている URL のみ
filterByColor	絞り込み	クロールしない
itemId	コンテンツ指定	すべての URL
page	ページ指定	すべての URL

助手はさっそく質問します。

助手: trackingId については代表的な URL を Googlebot に選ばせる（値は Googlebot が選択する）よう指定なさっていますね。「値が指定されている URL のみ」を選択して特定の値を自分で指定しなかったのはなぜですか？
ウェブの魔法使い: Googlebot がウェブをクロールしているときに、君のサイトにリンクしている URL で次のようなものが見つかったとしよう:

fairyclothes.example.com/skirts/?trackingId=aaa123
fairyclothes.example.com/skirts/?trackingId=aaa124
fairyclothes.example.com/trousers/?trackingId=aaa125

このとき、もしも Googlebot に「trackingId=aaa125」の URL だけをクロールするよう指定すると、Googlebot は URL 1 と 2 をクロールしなくなってしまうのだ。というのも、どちらの URL も trackingId の値が aaa125 ではないからだ。これらの URL のコンテンツはクロールされず、インデックスもされない。したがって、君の店が仕入れたすてきなスカート（/skirts/）がGoogle の検索結果に並ぶこともない。だからこの場合は、代表的な URL を選ばせるべきなのだよ。なぜかって？そのように指定すると、Googlebot がウェブ上で発見した 2 つの URL がこのパラメータの値だけ違っているとき（上の例でいうと URL 1 と 2）、Googlebot はそのうちどちらか 1 つをクロールするだけで、コンテンツをすべて取得できるからだ。上の例では、1 と 3 か、2 と 3 というペアで、合計 2 つの URL がクロールされることになる。おかげで、スカート（/skirts/）もズボン（/trousers/）も、1 つ残らずクロールされるのだ。

助手: sortOrder パラメータについてはどうですか？商品のリストが昇順でも降順でもかまわないと思うのですが。Google に代表的な値を選ばせるのではいけないのですか？
ウェブの魔法使い: Googlebot がクロールを続ける中で、次のような URL が見つかったとしよう:

fairyclothes.example.com/skirts/?page=1&sortBy=price&sortOrder=’lowToHigh’
fairyclothes.example.com/skirts/?page=1&sortBy=price&sortOrder=’highToLow’
fairyclothes.example.com/skirts/?page=2&sortBy=price&sortOrder=’lowToHigh’
fairyclothes.example.com/skirts/?page=2&sortBy=price&sortOrder=’ highToLow’

最初の 2 つの URL（1 と 2）の違いは sortOrder パラメータの値だけであり、その次の 2 つ（3 と 4）についても同じだ。しかし、URL 1 と 2 のコンテンツは同じではない。最初の URL ではスカートが安い順（’lowToHigh’）に表示され、2 番目の URL では高い順（’highToLow’）になっている。これを踏まえると、この状況で 1 つの代表値だけを使うのは得策ではないといえる。しかも、sortOrder パラメータだけが異なるいくつかの URL から Googlebot に代表的な値を 1 つだけ選択させると、そのたびに違う値が選択される可能性がある。たとえば上の例では、最初の 2 つの URL のうち、URL 1 が選択されたとしよう（sortOrder=’lowToHigh’）。一方で、その次の 2 つの URL では 4 が選択されたとする（sortOrder=’ highToLow’）。もしこの状況になったら、Googlebot は次のように、安い価格帯のスカートだけを 2 回クロールすることになるだろう:

fairyclothes.example.com/skirts/?page=1&sortBy=price&sortOrder=’lowToHigh’
fairyclothes.example.com/skirts/?page=2&sortBy=price&sortOrder=’ highToLow’

こうなると、高い価格帯のスカートは、まったくクロールされなくなってしまうのだ。このように、並べ替えのパラメータを扱うときは、一貫性が鍵となる。並べ替え順は常に同じにすることだ。

助手: sortBy の値についてはどうですか？
ウェブの魔法使い: sortOrder 属性によく似ているよ。商品一覧の URL がクロールされるときに、並べ替え順はどのページでも同じでなければならない。そうでなければ、一部の商品が Googlebot から認識されなくなるからね。ただし、どの値を選択するかについては注意が必要だ。店で書籍の他に靴も売っているとしたら、「title」という値は選ばない方がよいだろう。というのも、靴を表示する URL に「sortBy=title」が含まれることはまずないので、クロールされなくなってしまうからだ。同じように、「sortBy=size」と設定すると、靴のクロールは問題なくても、書籍はクロールされなくなってしまう。パラメータ設定の影響はサイト全体に及ぶことを忘れないように。

助手: filterByColor というパラメータの付いた URL はクロールさせないのですか？
ウェブの魔法使い: たとえば、スカートの一覧が 3 ページにわたってあるとしよう。そのうち何点かは青で、何点かは赤、残りは緑色だ。

fairyclothes.example.com/skirts/?page=1
fairyclothes.example.com/skirts/?page=2
fairyclothes.example.com/skirts/?page=3

このリストは、さらに絞り込むことができる。たとえば、ユーザーが青を選ぶと、青いスカートが次の 2 ページにわたって表示される:

fairyclothes.example.com/skirts/?page=1&flterByColor=blue
fairyclothes.example.com/skirts/?page=2&flterByColor=blue

この 2 つは新しいページのように見えるが（表示される商品のセットは他のどのページとも異なる）、実際のところ、新しいコンテンツは何もないのだ。というのも、青いスカートはすべて、元の 3 つのページに含まれているからだ。つまり、コンテンツを色で絞り込んだ URL を別途、クロールさせる必要はないということになる。そのような URL で表示されるコンテンツは既にクロールされているからだ。ここで注意してほしいのは、特定の URL をクロール対象から除外するために「クロールしない」を選択するときだ。そのコンテンツが Googlebot から別の方法でアクセスできるようにしておくことが肝心で、上の例でいえば、最初の 3 つのリンクを Googlebot が発見できる必要があり、このクロールを妨げるような設定がないように配慮しなければならないのだ。
- - -

もしご自分のサイトが URL パラメータを使用していて、コンテンツが重複して生成される可能性がある場合には、ぜひウェブマスターツールの新機能である「URL パラメータ」を試してみてください。ご感想やご質問はウェブマスターヘルプフォーラムまでお寄せください。

Written by Kamila Primke, Software Engineer, Webmaster Tools Team
Original version: Improved handling of URLs with parameters

再審査リクエストへの回答が、より具体的になりました

2011-10-21T09:59:00.000+09:00

あなたのサイトが Google の検索結果に表示されなかったり、以前より掲載順位が下がっているように見える場合（そしてウェブマスター向けガイドラインに違反していないと思われる場合）、再審査をリクエストすることができます。これまで Google は、ウェブマスターの皆さまにとって使いやすくなるよう、再審査プロセスの改善に取り組んできました。数年前からは、再審査リクエストの受付通知に加え、リクエストを処理したことをお知らせするメッセージもお送りしてきました。このメッセージはウェブマスターの皆さまにとって、審査完了のタイミングがわかるという意味で、一定の役割を果たしてきたと思います。一方でウェブマスターの皆様からは、リクエストの結果を知りたいというご意見を頂いておりました。そこで今年から再審査リクエストへのより詳しい返答をお送りするということを試験的に開始しており、非常に好意的なフィードバックを頂きました。

そこで今回、皆様からの再審査リクエストに応じて手動によるスパム判定を取り消したかどうかを、より多くのケースでお知らせするようにしました。サイトにまだガイドライン違反が見受けられる場合は、その旨をご報告いたします。ご不快に思われるかもしれませんが、サイトにまだ問題が残っているとわかれば、問題の原因究明のお役に立つと考えております。※ もし具体的な原因がわからない場合などはぜひウェブマスターヘルプフォーラムへお問い合わせください。ウェブマスターヘルプフォーラムには、経験豊富なウェブマスターの方々だけでなく、Google 社員も参加しており、「『不自然なリンクに関する Google ウェブマスターツールからのお知らせ』を受け取った際に確認をおすすめするポイント」のように具体的な確認方法をご紹介しています。

また、サイトに対して手動によるスパム判定がされていない場合（ほとんどのケースがこれです）も、より多くのケースでその旨をご報告するようにしました。その場合にサイトのランキングが上位にこないのは、 Google のアルゴリズムによる判定の結果と思われます。サイトに変更が加えられて改善が見られれば、Google のシステムはそれに適切に対応し、ランキングも変化しますので再審査リクエストをお送りいただく必要はありません。他の可能性としては、サイトにアクセス上の問題があって、Googlebot によるクロールやインデックス登録ができない状態であるケースも考えられます。ランキングに関する問題を解消する方法については、サイトの掲載順位が上がらない理由を参照してください。

Google では再審査リクエストのプロセス全体の透明性を高めるために様々な取り組みを行っています。個々のリクエストに対しての具体的な対応策についてはお答えできないものの、現在は多くのウェブマスターの皆様に、手動によるスパム判定がされているかどうかをお知らせし、再審査レビューの結果もご連絡するようになっています。理想的には、ランキングの仕組みを全て公開することも可能かもしれませんが、Google はウェブマスターに最大限の情報を公開するように努める一方でその情報をスパマーに悪用されないよう配慮する必要があります。Google では、今後も検索ユーザーとウェブマスターの皆さまのお役に立てるよう、よりよい方法を模索し続けていきたいと考えています。

Posted by Tiffany Oberoi and Michael Wyszomierski, Search Quality Team
Original version: Reconsideration requests get more transparent

サイトの状態が一目で確認できるようになりました。

2011-10-14T10:45:00.001+09:00

ウェブマスターの皆さんとお話する中で、よく聞くお話のひとつに「（サイト運営の）時間のやりくりが大変」というものがあります。ウェブマスターの中には、何十、何百という数のクライアントのサイトを管理している方もいれば、ご自分で事業を営んでいて、財務管理や在庫管理といった業務の合間に、1 日あたり 1 時間しかサイト管理に時間を割けないという方もいるでしょう。Google では、そんな皆さんの助けになればと、ウェブマスターツールに新しく「サイトの状態」という機能を追加し、問題が発生しているサイトが一目でわかるよう、ウェブマスターツールのページデザインもリニューアルいたしました。これによって、管理しているすべてのサイトのレポートを 1 つ 1 つクリックすることなく、重要な項目がひと目でわかるようになります。新しい管理画面は、以下のようになります。

上の図のように、サイトの状態に問題を抱えるサイトはリストの一番上に表示されます（アルファベット順に表示されるように切り替えることもできます）。サイトで検出された問題の詳細を見るには、こちらのアイコンか、それぞれのサイトの横に表示されている「サイトの状態を確認する」というリンクをクリックしてください。

この新しい管理画面は、現時点ではウェブマスターツールに登録されているサイトの数が、確認済みか未確認かに関わらず 100 以下の場合にのみご利用いただけます。将来的には、サイトの数によらず、すべてのアカウントで利用できるよう対応していく予定です。もし 100 個を超えるサイトを管理されている場合は、各サイトのダッシュボードの一番上の部分で状態をご確認いただけます。現在、次の 3 つの点についてサイトの状態がチェックされます。

サイトでマルウェアが検出されていないか
URL 削除ツールによって重要なページが削除されていないか
robots.txt にて、クロールがブロックされている重要なページがないか

それぞれの項目をクリックすると、サイトで検出された問題に関する詳細な情報を確認することができます。サイトの状態を示すアイコンや、「サイトの状態を確認する」リンクがサイトの横に表示されていないときは、そのサイトでは上記の問題は検出されていないということになります。

また、上記２、３においてチェックされる「重要なページ」について少し補足いたします。ご存知のとおり、削除された URL の一覧は、[サイト設定] 、 [クローラのアクセス] 、 [URL の削除] で確認できます。また、robots.txt のブロックによりクロールできなかった URL の一覧は、[診断] 、 [クロールエラー] 、 [robots.txt により制限] で確認できます。しかし、ウェブマスターの方々が意図的にコンテンツをブロックしたり削除したりすることはよくあるため、Google では、ウェブマスターが意図していないにも関わらずブロックされたり削除されたりしてしまったと思われる場合に限り、この警告を表示するようにしました。「重要なページ」に限定したのは、このような理由によるものです。現時点では、ページのクリック数（[ウェブ上のサイト] 、 [検索クエリ] にて確認できます）から重要度を判断していますが、今後この機能が進化するにつれてそれ以外の要素も付加されるかもしれません。もちろんウェブサイトに起きる問題は、上に挙げた 3 つの項目（「マルウェア」「削除された URL」「ブロックされた URL」）だけではありません。チェック項目は今後増加していく予定です。また、今回のアップデートはウェブマスターの皆様ご自身によるサイトの状態の判断や確認には比ぶべくもありませんが、ひとつひとつすべてのデータやレポートを掘り下げて調べなくても、サイトに起きている重大な問題を簡単にいち早く発見できるようになる手助けになれればと思います。

私たちが検出したサイトの問題が解決されたのち、ウェブマスターツールから警告が消えるまでには通常、数日を要します。これは、Google がサイトの再クロールを行って変更を確認し、さらにその情報を Google 検索とウェブマスターツールに反映されなければならないからです。1 週間以上経ってもサイトの状態に関する警告がまだ残っている場合は、問題が解決されていない可能性があります。その際はぜひウェブマスターヘルプフォーラムをご利用ください。皆様のご意見をお待ちしております。

Posted by Susan Moskwa, Webmaster Trends Analyst
Original version: Work smarter, not harder, with site health

ウェブマスターヘルプフォーラムからも参加！グローバルトップレベルユーザーサミット 2011 のご報告

2011-10-03T11:17:00.001+09:00

9 月 13、14 日にアメリカのカルフォルニア州サンタクララ、およびマウンテンビューの Google 本社オフィスにて、「グローバルトップレベルユーザーサミット 2011」が開催されました。このサミットは、世界各国のヘルプフォーラムで大きな貢献をされているトップレベルユーザーの方々へ日ごろの感謝をお伝えすると共に、より良いヘルプフォーラムコミュニティ運営のためにトップレベルユーザーの皆様と Google 社員との間でより深いディスカッションをおこなうことを目的とした、今年初開催のグローバルイベントです。

全世界から 300 人近いのトップレベルユーザーが集まったこのイベントには、日本からもウェブマスターヘルプフォーラムで日ごろ活躍されているトップレベルユーザーの方 2 名を含む合計 4 名の方が参加されました。

サミットに参加された日本のトップレベルユーザーの皆様（左から 4 名）と Google 社員

Google Japan Blog にサミットの様子や日本から参加されたトップレベルユーザーの方々の感想などをご紹介する記事が掲載されましたのでぜひご覧ください。また、ウェブマスターヘルプフォーラムで、「そもそもトップレベルユーザーとはどんな人たちなのか？そしてトップレベルユーザーになるには？」ということについて、ご紹介させていただいていますので併せてご覧ください。

Google Japan Blog 「グローバルトップレベルユーザーサミット 2011 のご報告」
ウェブマスターヘルプフォーラム「トップレベルユーザーサミットのご報告 & そもそもトップレベルユーザーとは？」

今後ともウェブマスターヘルプフォーラムをどうぞよろしくお願いします。

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

災害時、急激なアクセス集中に備えてウェブマスターができること

2011-09-30T09:37:00.009+09:00

台風や大雨、地震などの災害時には多くの方が災害情報や交通情報、避難所や防災マップといった緊急情報を確認するため、特定のサイトに突発的にアクセスが集中することがあります。こうした急激なアクセスの集中は、時にサーバーの処理能力を超え、サイトをダウンさせてしまいます。サイトがダウンしてしまうと、災害情報などの緊急情報を提供できなくなり、より多くの混乱を引き起こしてしまうでしょう。

突発的なアクセスの集中は避けることは難しいですが、あらかじめそれに備えることでサイトのダウンを防ぐことが可能です。そこで今回は、災害時などの急なアクセス集中に備えてできる比較的簡単な対策をご紹介したいと思います。

軽量化したサイトを別途用意する
災害時に備え、軽量化したサイトをあらかじめ別途用意しておきましょう。災害時にはその軽量化したサイトに置き換えます。しかし普段は使わないページを用意し、いざという時のために管理し続けるというのは負担が大きいかもしれません。そこで例えば携帯電話向けのサイトを用意し、災害時には携帯電話向けに提供しているページを PC 向けに提供するのもひとつのアイディアです。また、特にアクセスが集中するのは主にトップページであるケースが多いのではないでしょうか。そこで全ての代替ページを用意するのではなく、トップページのみ軽量化したページを用意しておき、リンク先は携帯電話向けのページにリンクするようにすることで、災害時にはトップページのみ差し替えるだけで大幅にサーバーの負荷を軽減することができます。

軽量化のポイントは、
- 画像やフラッシュなどの装飾的な要素は極力外し、メニューやナビゲーションなどの画像ファイルはテキストに置き換え、HTML を中心に作成する。
- 動的なページはサーバーの負荷が高いため静的な HTML ページを用意する（情報は手動で更新します）。
なるべく軽いファイル形式で提供する
データのサイズはなるべく小さくなるように心がけましょう。例えば提供する情報が文字情報の場合、ファイルサイズが大きくなる PDF ファイルなどでの情報の提供は避け、テキストデータなどの軽いデータで提供するようにしましょう。例えばこちらの PDF ファイルとリッチテキストファイルをダウンロードして比較してみてください。中身はほぼ同じ内容ですが、ファイルサイズは PDF が 180KB、テキストファイルは 37KB と、テキストファイルの方が圧倒的に軽いことがわかります。

また、同じ PDF ファイルでも、画像データから作成した PDF よりも、テキストエディタ等からテキストデータを保持したまま作成した PDF の方がデータが軽くなります。また、テキストデータを保持したまま作成された PDF は検索結果に表示されやすくなりますので PDF を作成する際は画像データから作成するのではなく、テキストデータを保持した形で作成することをお勧めします。
表や数値データは CSV や XML などの形式でも用意する
表や数値データは CSV や XML 形式のファイルでも用意しましょう。これらの形式のファイルは、比較的サイズが小さくなり、また、そのデータを利用して外部の開発者が別の災害情報サービスを提供することが可能になり、より多くの人に情報を届けることができるようになるためです。
サードパーティのサービスを活用する
サードパーティのサービス等を利用し、災害時に参照される情報を中心にミラーサイトを作成することも一つの方法です。Google では Google サイトや Blogger といったサービスを無料でご利用いただくことが可能です。

また、万が一サイトがダウンした場合でも Google では公的なサービスを提供するサイトについてはキャッシュデータを検索結果に表示し、ユーザーが閲覧できるようにしています。このサービスへのご登録は、こちらからお申し込みください。なお、こちらのご登録に関しましては、 go.jp ドメインのサイトや地方公共団体、各種公共サービスなど、公共性の高い非営利サイトに限らせていただきます。また、お申し込みからご登録まで少々お時間がかかりますのでご了承ください。

今回ご紹介しました対策についてのご質問は、ウェブマスターヘルプフォーラムへお寄せください。※災害時の問い合わせ窓口ではありませんのでご注意ください。

Posted by Google クライシスレスポンスチーム、サーチクオリティチーム

ページスピードサービス - ウェブパフォーマンスを高速化

2011-09-26T10:47:00.003+09:00

2 年前、Google はページスピードブラウザ拡張機能（英語）をリリースし、今年に入ってからは Page Speed Online API（英語）をリリースしました。これらを通して、デベロッパーの皆さまにウェブページ高速化のための具体的な提案を行っています。昨年には、mod_pagespeed（英語）という Apache モジュールをリリースしました。これは、自動的にウェブページを書き換えるものです。ウェブマスターの皆さまのさらなる負担の軽減と、面倒なインストール作業を不要にするために、ページスピード関連の最新のテクノロジーであるページスピードサービス（英語）をリリースしました。

ページスピードサービスとは、ウェブページの読み込みを自動的に高速化するオンラインサービスです。このサービスを使用するには、お申し込みのうえ、サイトの DNS エントリが Google を指すように設定していただく必要があります。ページスピードサービスによって、ウェブサーバーからコンテンツが読み取られ、ウェブパフォーマンス向上のためのベストプラクティスが適用されたページに書き換えられます。この書き換えられたページが、世界中の Google のサーバーを経由してエンドユーザーに提供されます。ウェブサイトのユーザーから見ると、サイトへのアクセス方法はそれまでと同じですが、ページの読み込みが高速になります。これで、ウェブマスターの皆さまは CSS の短縮化や、画像圧縮、キャッシング、gzip によるリソース圧縮などのウェブパフォーマンス向上のためのベストプラクティスに悩む必要はなくなります。

Google が実施した高速化のテストでは、概ねのサイトで 25% から 60%（英語）の改善が実証されています。ただし、効果はサイトごとに異なるので、皆さまのサイトが実際にページスピードサービスによってどれだけ高速化されるかを測定（英語）してみてください。この結果を見て、十分な効果が期待できるようであれば、こちらからページスピードサービスにお申し込み（英語）ください。そうでない場合は、しばらくしてからもう一度測定してみてください。Google では今後も、このサービスに改善を加えていく予定です。

現時点では、ページスピードサービスは少数のウェブマスター様のみにご提供しています（無料）。手頃な料金でご利用いただけるようにする予定であり、詳細は後日発表いたします。このサービスへのアクセスをご希望の場合は、こちらのウェブフォーム（英語）からお申し込みください。

Posted by Ram Ramani, Engineering Manager
Original version: Official Google Webmaster Central Blog: Page Speed Service - Web Performance, Delivered.

検索結果における PDF ファイルの取り扱いについてのヒント

2011-09-20T11:12:00.002+09:00

Google の使命は、世界中の情報を整理し、世界中の人々がアクセスできて使えるようにすることです。この使命を遂行するなかで、時として HTML 形式以外のファイル、たとえば PDF、表計算、プレゼンテーション用スライドといった形式のファイルに遭遇することがあります。ファイル形式が違うからといって、Google のアルゴリズムに支障が生じることはありません。Google では、関連性の高いコンテンツを抽出し、適切なインデックス登録を行って検索結果に反映させるよう取り組んでいます。このようなファイル形式は、標準的な HTML 形式とは大きく異なるものですが、実際にはどのようにインデックス登録されているのか、どういったガイドラインが設けられているのか、そしてファイルをインデックスに登録して欲しくない場合には、ウェブマスターの皆様はどうしたらよいか、ご存知でしょうか？

Google は 2001 年に PDF ファイルのインデックス登録を開始（英語）し、現在では数億件もの PDF ファイルがインデックスに登録されています。今回は、PDF のインデックス登録に関して、よく寄せられる質問とその回答をまとめてみました。

質問: Google では、どんな形式の PDF ファイルでもインデックス登録できるのですか？
答え:一般的に、各種文字コードを使用した PDF ファイルに含まれているテキストコンテンツは、どのような言語で書かれていようと、そのファイルがパスワード保護または暗号化されている場合を除き、インデックスに登録できます。テキストが画像として埋め込まれている場合は、Google ではその画像を OCR （英語）アルゴリズムで処理し、テキストを抽出することができます。簡単に言うと、PDF 文書内のテキストをコピーして、標準的なテキスト文書にペーストできるのであれば、そのテキストはインデックス登録が可能です。

質問: PDF ファイル内の画像はどうなるのですか？
答え: 現時点では、PDF ファイル内の画像はインデックスには登録されません。画像をインデックス登録するには、その画像用の HTML ページを作成する必要があります。ご自分のサイトの画像が検索結果に含まれる可能性を高めたい場合は、ヘルプセンターに記述されているアドバイスを参考にしてください。

質問: PDF 文書内のリンクはどのように取り扱われるのですか？
答え: 一般に、PDF ファイル内のリンクは HTML 内のリンクと同じように扱われます。つまり、リンクから PageRank をはじめとするインデックス登録のシグナルが渡されるので、Google は、その PDF ファイルをクロールしたのち、リンクをフォローできるようになります。現在のところ、PDF ファイル内のリンクに対しては nofollow 属性は設定できません。

質問: PDF ファイルを検索結果に表示させないようにするにはどうしたらいいですか？既に検索結果に表示されている場合は、どのようにしたら削除できますか？
答え: PDF 文書を検索結果に表示させないようにする一番簡単な方法は、そのファイル用の HTTP ヘッダーに X-Robots-Tag: noindex を追加するという方法です。既にインデックスに登録されている場合は、X-Robot-Tag で noindex を指定すれば、しばらく時間が経つとインデックスから除外されていきます。早急に削除したい場合は、Google ウェブマスターツールの URL 削除ツールを使用してください。

質問: PDF ファイルでも検索結果の上位にランクされますか？
答え: もちろんです。通常、他のウェブサイトと同じようにランキングされます。たとえば、[mortgage market review]、[irs form 2011]、[paracetamol expert report] で検索してみると、いずれも検索結果の上位に P
DF 文書が表示されます（注: この記事の作成時点）。これは、文書の内容と、サイトへの埋め込み方法、そして他のウェブページからのリンク状況に基づいた結果です。

質問: ページを HTML と PDF の両方の形式で提供していると、重複コンテンツと見なされるのでしょうか？
答え: できれば、コンテンツは 1 つだけにすることをお勧めします。それが難しい場合は、どちらのバージョンを優先するのかを必ず示すようにしてください。その方法としては、サイトマップに優先 URL を含める方法や、HTML 内または PDF 文書の HTTP ヘッダー内で canonical （優先）バージョンを設定する方法などがあります。詳しくは正規化に関するヘルプセンターの記事を参照してください。

質問: 検索結果に表示される PDF 文書のタイトルはカスタマイズできますか？
答え: 表示するタイトルの生成には、ファイル内のタイトルメタデータとその PDF ファイルを指すリンクのアンカーテキストという 2 つの主要要素を使用しています。Google のアルゴリズムに対して、適切なタイトルを示したい場合は、上記要素を両方ともアップデートすることをお勧めします。

詳しくは、Matt Cutt による動画 PDF ファイルを検索用に最適化する（英語）をご覧ください。また、インデックスに登録できるコンテンツ形式については、ヘルプセンターでご確認いただけます。ご質問やご意見がありましたら、ウェブマスターヘルプフォーラムへお寄せください。

Posted by Gary Illyes, Webmaster Trends Analyst
Original version: PDFs in Google search results

Google Chrome でサイトをうまく表示する方法

2011-09-12T11:15:00.002+09:00

Google Chrome が 2008 年 9 月にリリースされて以降、すでに多くの皆様に利用していただけるようになっておりますが、残念ながらいくつかのサイトが正しく表示されないという声がまだ聞かれます。サイトが正しく表示されないのは、もちろん Google Chrome 側の不具合が原因であることもありますが、一方でサイトがある特定のブラウザだけを対象にしている場合や Web 標準に沿わない形でサイトがデザインされていることもあります。

今までに、どうしたら Google Chrome でサイトを正しく表示させられるのか、ということに関してたくさんの質問がウェブマスターやデベロッパーのみなさんから寄せられました。今回は、このためのヒントをいくつかご紹介します。

Google Chrome を検出するためには

多くの場合、Safari と Google Chrome でサイトは同じように見えます。なぜならこれらは両方とも WebKit （英語）ベースのブラウザだからです。もしあなたのサイトが Safari で正しく表示されているのなら、Google Chrome でも同様に正しく表示されるはずです。

サイトによっては Chrome が他のブラウザと混同されてしまうことも少なくありません。Safari では正しく表示されているサイトが Chrome で正しく表示されないのならば、そのサイトが Chrome のユーザーエージェント文字列を認識していない可能性があります。

Google Chrome のユーザーエージェント文字列は次のようになります。

Mozilla/5.0 (Windows NT 6.0; WOW64) AppleWebKit/534.24 (KHTML, like Gecko) Chrome/W.X.Y.Z Safari/534.24

Chrome 11 におけるユーザーエージェント文字列の変更 - Google Japan Developer Relations Blog で紹介したように、Chrome 11 より変更になっていますので、ご注意ください。

ユーザーエージェントのタイプを検出したいのであれば、次の JavaScript が WebKit での検出に使えるでしょう。

var isWebkit =
navigator.userAgent.indexOf("AppleWebKit") > -1;

そうではなく、もし WebKit が特定のバージョン以上であることを確認したいのならば、以下の新しい機能が使えるでしょう。

var webkitVersion =

parseFloat(navigator.userAgent.split
("AppleWebKit/")[1]) ||
undefined;
if (webkitVersion && webkitVersion > 500 ) {
// WebKitの素晴らしい機能を使う
}

Google Chrome が利用している WebKit のバージョンは Ominibox に “about:version” と入力することで得ることができます。

一般的に、WebKit や Google Chrome を検出するために "Google" や "Apple" といった文字列を navigator.vendor に加えることはお勧めしません。なぜならそうしてしまうと、他の Webkit や Chromium をベースとしたブラウザを検出できなくなってしまうからです！

WebKit の検出の詳細については、webkit.org （英語）をご覧ください。

その他のヒント

Google Chrome は Active X プラグインをサポートしていませんが、NPAPI プラグインはサポートしています。つまり、Google Chrome では Firefox や Safari と同じように Flash や Java といったプラグインのコンテンツを見せることができます。
もしあなたのサイト上のテキストがうまく表示されていない場合は、適切なコンテンツタイプと文字コードの情報を HTTP レスポンスヘッダーもしくはページの始めやセクションのなるべくトップに近いところで記載していることを確認してください。
ブロックレベル要素をインライン要素の中に書かないようにしましょう。

誤った例: <a><div>こちらは正しく表示されません。</div></a>
正しい例: <div><a>こちらは正しく表示されます。</a></div>

もし JavaScript が Google Chrome でうまく動かないようでしたら、Chrome に組み込まれている JavaScript ツールやデベロッパーツールを使ってデバッグを行うことができます。
あなたのページで使っている文字セットは Official IANA LIst に準拠している必要があります。表の preferred MIME name の名前をご使用ください。
例: ISO-8859-1, Shift_JIS
HTTP Header と Meta tag で異なる文字エンコーディングを指定している場合、Google Chrome は、HTTP Header の指定を優先的に使用します。HTTP Header と Meta tag で異なる文字エンコーディングを指定することはトラブルの原因になります。詳しい情報は、The WHATWG Blog — The Road to HTML 5: character encoding（英語）を御覧ください。
基本的に文字エンコーディングは UTF-8 を使用されることをお勧めしています。何らかの理由により、旧来の文字エンコーディングを使用する必要がある場合は、これまでご紹介した内容を踏まえているかをご確認の上使用してください。

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

Written by Glenn Wilson, Product Manager, Google Chrome
Original version: Helping your site look great with Google Chrome

ウェブマスターツールの内部リンクと外部からのリンクの取り扱いを変更しました

2011-09-09T11:05:00.000+09:00

ウェブマスターツールではサイトへのリンクを、外部のサイトからのリンクとサイト内からのリンクの 2 種類に分類していますが、この度ウェブマスターツール内のリンクデータのカテゴリ分けを変更しました。今回の変更によって、リンクの合計数が変わることはありませんが、どれがサイト内からのリンクで、どれが外部のサイトからのリンクか、より実情に近いものになるのではないかと思います。

ウェブマスターツールでは、ドメイン名のみ（example.com）、サブドメイン（www.example.com や cats.example.com）、サブディレクトリを含むドメイン（www.example.com/cats/ や www.example.com/users/catlover/）といった様々な種類のサイトを管理できます。従来は、ウェブマスターツールに登録したサイトの URL から始まる URL のリンクのみが内部リンクに分類されていました。たとえば、www.example.com/users/catlover/ をサイトとして追加していた場合、URL が www.example.com/users/catlover/ から始まる www.example.com/users/catlover/profile.html からのリンクは内部リンクのカテゴリに入っていましたが、www.example.com/users/ や www.example.com からのリンクは外部リンクに分類されていました。また、登録したサイトが www.example.com だった場合、example.com からのリンクは外部からのリンクと見なされていました。リンクの URL がサイトと同じ URL から始まっていないためです（www が欠けています）。

しかし、最近では example.com と www.example.com は同じサイトとして扱われることが多くなってきました。そこで、example.com または www.example.com のどちらかをサイトに追加していれば、リンクのドメインに www が付いていてもいなくても内部リンクのカテゴリに分類されるように変更しました。また、他のサブドメインからのリンクも内部リンクに含めるようにしました。ドメインを管理している方は多くの場合、サブドメインも管理しているからです。したがって、cats.example.com や pets.example.com からのリンクも www.example.com の内部リンクとなります。

www.google.com へのリンク	外部リンク	内部リンク
従来のカテゴリ分けでは...	www.example.com/ www.example.org/stuff.html scholar.google.com/ sketchup.google.com/ google.com/	www.google.com/ www.google.com/stuff.html www.google.com/support/webmasters/
新しいカテゴリ分けでは...	www.example.com/ www.example.org/stuff.html	scholar.google.com/ sketchup.google.com/ google.com/ www.google.com/ www.google.com/stuff.html www.google.com/support/webmasters/

ただし、サイトがサブドメイン上（例: googlejapan.blogspot.com ）やサブディレクトリ（例: www.google.com/support/webmasters/）内にあり、ルートドメインにはない場合、内部リンク内にはそのサブドメインやサブディレクトリからのリンクのみが表示され、それ以外はすべて外部リンクとみなされます。これらの数がより正確になるように、いくつかの変更を加えています。

注意していただきたいのは、example.com や www.example.com などのルートドメインでは今回の変更に伴って外部からのリンクの数が少なく表示される可能性があることです。これは前述のように、従来は外部リンクに分類されていた一部の URL が内部リンクに分類されたためです。リンクの合計数（内部リンク + 外部リンク）は、今回のアップデートの影響を受けません。

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

Posted by Susan Moskwa, Webmaster Trends Analyst
Original version: Reorganizing internal vs. external backlinks

ウェブサイトがハッキングされた、さあどうする？ - サイトがハッキングされた場合の対応方法

2011-09-01T11:00:00.001+09:00

[本記事は 2008 年に公開された記事の抄訳です。また、ウェブマスターツールヘルプページでサイトがハッキングされた、またはマルウェアに感染した場合の対処方法が掲載されていますが、日本でもハッキングの事例が増えてきているため、改めてご紹介します。]

ウェブサイトのハッキング被害は多くのウェブマスターが経験することで、気をつけて予防策を講じていたとしても発生してしまうことがあるものです。予防のためのアドバイスとしては、最新のソフトウェアやパッチで常にサイトをアップデートしておくこと、Google ウェブマスターツールに登録して、インデックスの状態をチェックすること、ログファイルに目を配り、不審な動きが見られないか確認しておくことなどが挙げられます。（さらに詳しい情報は、2007 年に掲載した「Quick Security Checklist」（英語）の記事にまとめてあります。）

それでは、ハッキングされた時、どうすればいいでしょうか？サイトをハッキングされたときに最初にすべきことは、ホスティングサービスを利用している場合はそこに連絡をすることです。多くの場合、技術的に困難な作業のほとんどはホスティングサービス業者が対応してくれます。ウェブマスターの多くは共有ホスティングサービスを利用していますが、その場合以下に挙げていることを実行するのが困難な場合があります。アスタリスク（*）のついたアドバイスは、共有ホスティングサービスを利用しているウェブマスターのみなさんが、ホスティングサービス業者の協力を必要とする可能性が高いものです。サーバーに対して完全な管理権を所有している場合は、以下の 4 つの原則に従うことをお勧めします。

サイトをオフラインにする

サイトを一時的に、少なくとも問題を解決できたと確信できるまでは、オフラインにします（ネットワークから切り離します）。*
オフラインにできない場合は、クロールされないように 503 ステータスコードを返すよう設定します。
ウェブマスターツールの URL 削除ツールを使用して、侵入者によって追加された可能性のあるページや URL を検索結果から削除します。こうすることで、ユーザーがハッキングされたページを閲覧してしまうことを防ぎます。

被害を分析する

ハッカーの侵入目的が何だったのかを把握するすることは重要です。

狙いは機密情報でしょうか？
他の目的のためにサイトを乗っ取ろうとしたのでしょうか？

ウェブサーバー上で、改変またはアップロードされたファイルを探しましょう。
サーバーログから、ログイン認証の失敗、コマンドの履歴（特に root で実行されたコマンド）、不明なユーザーアカウントなどの不審な活動をチェックしましょう。
被害の範囲を特定します。他にも影響を受けたかもしれないサイトはありませんか？

復旧する

最善策は、信頼できるソースから OS を完全に再インストールすることです。ハッカーによる被害をすべて確実に取り除くには、これ以外に方法はありません。*
再インストールが完了したら、最新のバックアップを使用してサイトを復旧します。この際、バックアップがハッキングの影響を受けていないことを必ず確認しましょう。*
インストールされたソフトウェアにパッチを当てて最新版にします。ブログプラットフォーム、コンテンツマネージメントシステムや、その他サードパーティによるソフトウェアなどすべてが対象となります。
パスワードを変更します。

オンラインへの復帰

ウェブサイトを再びオンラインにします。
ウェブマスターツールを使用している場合は、

サイトにマルウェアが存在すると検知された場合は、これらが排除されたかどうかを判断するために調査を申請してください。詳しい情報はヘルプ記事「サイトがハッキングされた、またはマルウェアに感染した場合」の「4: Google にサイトの再審査を依頼する」をご覧ください。
インデックスに入れたい URL に対して URL 削除ツールを使用した場合は、ウェブマスターツールで削除を取り消してください。

ハッカーが再びサイトを攻撃する可能性がありますので、不審な動きに注意してください。

その他の質問と回答:

Q: クロールを防ぐためには、サイトをオフラインにするのと robots.txt を使用するのとでは、どちらが良いですか？
A: オフラインにする方が良いでしょう。マルウェアやバッドウェアがサイトの閲覧者に感染したり、ハッカーがサイトをさらに不正利用したりすることを防ぐことができます。

Q: サイトの問題解決後、どうしたら迅速に再度クロールしてもらえますか？
A: サイトがハッキングされたかどうかに関わらず、こちらのヘルプ記事にある手順を踏んでください。

Q: サイトをクリーンアップしましたが、ハッカーによって悪いサイトへリンクされていた場合、検索順位に影響はあるのでしょうか？
A: Google でもそのような事態は望んでいません。ハッカーやスパマーの行為によって、良いサイトの検索順位などに影響が出ないように務めています。念のために、ハッカーが追加した可能性のあるリンクは完全に削除してください。

Q: 自宅のコンピュータがハッキングされた場合はどうしたらいいですか？
A: その場合も、上記の対策が適用できます。復旧には細心の注意を払ってください。注意を怠ると、同様の被害が再発してしまう可能性が高くなります。OS を再インストールするのが最善です。

その他の役に立つ情報:

サイトが Google によってマルウェアに感染していると検知された場合、ウェブマスターツールのページに警告メッセージを表示しますので、あらかじめウェブマスターツールに登録しておくことを強くお勧めします。
Matt Cutts がブログに投稿した「Three tips to protect your WordPress installation」（英語）という記事にも実用的なコメントが多く寄せられています。

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

Written by Nathan Johns, Search Quality Team
Original version: My site's been hacked - now what?

リニューアルされたサイトリンクのご紹介

2011-08-24T17:55:00.001+09:00

Google は先日、検索結果の更なる品質向上を図るため、サイトリンクをアップデート（英語）しました。サイトリンクとは、一部の検索結果や広告の下部に表示される 2 列のリンクのことで、ユーザーはこのサイトリンクを通じてサイトの深い階層にあるページに直接アクセスすることができます。尚、今回のアップデートでもサイトリンクの基本は変わらず、サイトのリンク構成に基づき、アルゴリズムによって作成および順位付けされ、特定の検索ワードに対して有用な場合のみ表示されます。

今回のアップデートによるサイトリンクの改善点は、次の通りです。：

見やすく：リンクのテキストはフルサイズになり、通常の検索結果と同様に、緑色のURLおよび 1 行のスニペットが追加で表示されます。これによって、個々のサイトリンクおよびメインのサイトがより目立つことになり、検索ユーザーの目に止まりやすくなります。

柔軟に：これまで、各サイトのサイトリンクのセットは固定されており、それら全てが表示される、もしくは全く表示されないの二者択一で、特定の検索ワードによってこの一覧の表示順が変動することはありませんでした。今回のアップデートで、表示されるサイトリンクおよびその表示順は検索ワード次第で変動するようになり、より最適な検索結果を提供できるようになりました。更に、サイトリンクの最大表示数が 8 から 12 に引き上げられ、表示される数も検索ワード次第で変化するようになりました。

わかりやすく：これまでは、サイトリンクが表示されているサイト内のページがサイトリンクだけでなく、サイトリンクが表示されていない残りの検索結果にも表示されるといった事がありました。今回のアップデートで、サイトリンクが表示されたドメインとその他のドメインの区別が、より明確にされるようになり、サイトリンクが検索結果トップに表示された場合、その下に表示される残りの検索結果はその他のドメインからのものとなります。例外は、ある検索ワードの検索結果トップが、あるドメインのサブページである場合です。例えば［the met exhibitions］と検索した場合、www.metmuseum.org/special/ が検索結果トップとして表示されます。ここで表示されるサイトリンクは、 www.metmuseum.org/special 以下等から抽出されます。その一方で、残りの検索結果は他のドメインのページが表示されますが、store.metmuseum.org や blog.metmuseum.org/alexandermcqueen/about のような、metmuseum.org ドメイン内のその他のページが残りの検索結果に表示される場合があります。

品質の改善：これらユーザーの目に見える変更と同時に、目に見えない改善も図りました。具体的には、サイトリンクを生成したり順位付けしたりするためのデータ（ウェブサイトのリンク構成など）を従来のランキングシステムと統合して、より優れたアルゴリズムにしました。それによって、順位付けの観点から見て、「通常の」検索結果とサイトリンクの間に区別はなくなりました。

今回のアップデート実施後のサイトリンク

これらの変更点は Google ウェブマスターツールにも反映され、自分のサイトについて表示されるサイトリンクを管理することができます。不適切、または不正確なサイトリンクに対して順位を下げるよう設定することもできるようになり、アルゴリズムはこれらの申請を考慮に入れて、リンクの表示および順位付けを行います（サイトリンクの削除が保証されるわけではありません）。サイトリンクは時間経過や検索ワード次第で変動するため、固定された一覧から選択する方法はもはや現状に即さなくなっています。今回のアップデートによって、いかなるページのいかなる URL に対しても順位を下げる設定ができるようになります。ウェブサイト毎に、100 件まで順位を下げるための設定を行えます。最後に、Google ウェブマスターツールの現行のサイトリンクのブロック機能は、全て順位を下げるためのシステムに変更されます。詳しくは、ウェブマスターツールヘルプをご覧ください。

ご質問、ご意見等ございましたら、ウェブマスターヘルプフォーラムにお寄せください。

Written by Harvey Jones, Software Engineer, & Raj Krishnan, Product Manager, Sitelinks team
Original version: Introducing new and improved sitelinks