Google Webmaster Central | SEO-LPO.net

Google に企業の電話番号や店舗の情報を表示させるための推奨される方法をご紹介

毎日、多くのユーザーが Google を利用して企業について検索しています。カスタマーサービス用の電話番号や、住所、営業時間などがよく検索されるものです。

このような情報は、通常、会社のウェブサイトの「お問い合わせ」ページに記載されています。Google が正確にそれらの「お問い合わせ」ページを発見し、適切な情報を抽出することができた場合、その情報がユーザーに伝えられる可能性は高まります。この情報を Google に理解させ、表示させるために推奨される方法を今日は紹介します。

企業の電話番号

現在、様々な企業の電話番号が Google 検索結果に大きく表示されています。例えば、Nest Labs のカスタマーサービス用電話番号を検索すると、以下のように表示されます（現在のところ google.com でのみご確認いただけます）。

本日、あなたのサイトに埋め込む構造化データマークアップを利用して、表示させたい電話番号を指定する schema.org マークアップのサポートを開始しました。サポートされる電話番号の種類は、以下のようなものです:

カスタマーサービス
テクニカルサポート
決済サポート
支払い

それぞれの電話番号に対して、フリーダイヤルかどうか、聴覚障碍者が利用できるか、グローバルで利用可能な番号なのか国別の番号なのか、を指定することができます。国別のカスタマーサービス用電話番号を指定する方法は、こちらをご覧ください (英語)。

店舗サイト向けの推奨

多くのユーザーが、Google を利用してさまざまな店舗を検索しています。多くの場合、最良の情報はウェブサイトのお問い合わせページや、支店リストページで見つかります。これらのページには、住所や電話番号、営業時間などが含まれています。

このようなページをユーザーにとっても Googlebot にとっても理解しやすいものにするために推奨される方法 (英語) も本日発表いたします。ここには、クローリング、インデックス登録、デザインに関する推奨事項、そして Google により正確にそのページをインデックスさせるための新しい構造化データマークアップに関するガイドラインが掲載されています。

また、Google Maps やナレッジグラフ、AdWords キャンペーンなどの Google のサービスに対して店舗の情報をアップデートするためのツールであるビジネスオーナー向けプレイスを利用することも引き続き推奨されています。

なにかご質問がありましたら、ウェブマスターヘルプフォーラムをご利用ください。

Posted by Justin Boyan, Product Manager, Jonathan Sidi, Product Manager, Pierre Far, Webmaster Trends Analyst
Original version: Surfacing your business's contact and local info in Google

App Indexing の最新情報

昨年、検索結果から Android アプリへ直接つながるディープリンクが Google の検索結果に表示される App Indexing を米国で提供を開始したことをこちらのブログでもお知らせしました。Google では今回、新たに 20 を超えるアプリを追加で有効にし、間もなく検索結果にアプリのディープリンクが表示されるようになります。また、英語のコンテンツへのアプリのディープリンクを全世界でご利用いただけるようになりましたことを、お知らせします。

Google では引き続き、すべての言語のサイト運営者様にご参加いただきたいと考えています。提供している Android アプリでディープリンクをサポートしていない場合や、ウェブサイトやサイトマップでこのようなリンクをまだ指定していない場合は、ぜひ対応していただき、こちらのフォーム（英語）から Google までお知らせください。

サイトマップやウェブサイトにディープリンクを追加する際に、考慮すべきベストプラクティスをいくつかご紹介します。

アプリのディープリンクは正規 URL にのみ含めるようにしてください。
ホームページにおいてもアプリのディープリンクを指定することをお忘れなく。
サイトマップに含まれているすべてのウェブサイト URL に対応するアプリのディープリンクを設定する必要はありません。提供しているアプリでサポートされていないディープリンクを含めないようにしてください。
ニュースサイトでニュースサイトマップを使用されている場合は、通常のサイトマップと同様に、ニュースサイトマップにもディープリンクのアノテーションを含めるようにしてください。
ネイティブ ARM コードを実行するディープリンクのアノテーションを指定しないでください。これにより、すべてのプラットフォームで App Indexing が有効になります。

アプリのコンテンツがインデックスに登録されると、提供しているアプリは、通常の動作の場合と同様に HTTP リクエストを送信する必要があります。これらのリクエストは、サーバー上では Googlebot から送信されたように表示されます。そのため、これらのリクエストを許可できるようにサーバーの robots.txt ファイルを設定する必要があります。

最後に、アプリの戻るボタンをクリックした場合に、必ず検索結果ページに直接戻ることを確認してください。

実装の詳細については、最新のデベロッパーガイドライン（英語）をご覧ください。この記事に関するコメントやご質問は、ウェブマスターヘルプフォーラムまでお寄せください。

Posted by Michael Xu, Software Engineer
Original version: App Indexing updates

インデックスステータスのデータがサイトのバリエーションに対応し、より正確に

Google ウェブマスターツールのインデックスステータス機能では、Google によってインデックスされた、サイトのページ数がレポートされます。以前は、HTTPS サイトのインデックスステータスのデータは独立して表示されず、HTTP サイトのレポートにすべて含まれていました。しかし、ここ数か月の間に、ウェブマスターツールを使用してウェブサイトのセクション（HTTPS を使用している場合など）ごとにインデックス登録された URL を追跡したいとのご意見をウェブマスターのみなさまからいただきました。

現在、URL 全体の約 10% が既に安全な接続を使用して HTTPS 経由でデータ転送を行っていることがわかっています。今後は、より多くのウェブマスターの方々がウェブサイトを HTTP から HTTPS に移行することを期待しています。Google では、サイトのインデックスステータスのデータに関してウェブマスターツールでの表示方法を改善しました。インデックスステータス機能では、プロトコル（HTTP と HTTPS）別や、確認済みのサブディレクトリレベルでインデックス登録されたサイト URL を追跡できるようになりました。

これにより、サイトの異なるセクションを簡単にモニタリングできるようになります。たとえば、次の URL は、それぞれ別々に確認を行った場合、ウェブマスターツールのインデックスステータスレポートでデータが区別されて表示されます:

HTTP	HTTPS
http://www.example.com/	https://www.example.com/
http://example.com	https://example.com
http://www.example.com/folder/	https://www.example.com/folder/
http://example.com/folder/	https://example.com/folder/

サイトの URL に HTTPS を使用している、または確認済みのサブディレクトリ（https://example.com/folder/ など）があるウェブマスターには、改善されたデータが表示されます。サブディレクトリのデータは、同じホスト名とプロトコルの上位レベルの確認済みサイトに含まれます。

ウェブサイトが HTTPS を使用している場合や一部のコンテンツが別のサブドメインでインデックス登録されている場合は、対応するインデックスステータスレポートに変更内容が表示されます。下のスクリーンショットは、HTTP と HTTPS のサイトのインデックスステータスのグラフの例を示しています:

HTTP サイトのインデックスステータス（減少）

HTTPS サイトのインデックスステータス（増加）

上の図を見ると、インデックスステータスグラフに「更新情報」（Update）という注釈が付いています。これは、このデータの収集の開始日を示しています。この変更によって、URL のインデックス登録方法や、ドメインレベルでインデックス登録された URL の総数が影響を受けることはありません。ウェブマスターツールに表示されるデータのレポートが影響を受けるだけです。

データを正確に表示するには、Google ウェブマスターツールでサイトの既存の類似パターンすべて（www. あり、www. なし、HTTPS、サブディレクトリ、サブドメイン）に対して確認を行う必要があります。Google では、優先するドメインや正規 URL を適宜設定することをおすすめします。

サイトマップを送信する場合は、対応する URL を使用してウェブサイトの優先する類似パターンに対して確認を行う必要があります。なお、robots.txt ファイルはプロトコルやホスト名ごとに区別されて読み取られます。

今回の更新がウェブサイトのインデックス登録に関する問題の解決に役立てば幸いです。詳しくは、インデックスステータスに関するヘルプセンターの記事をご覧ください。また何かご不明な点がありましたら、お気軽にウェブマスターヘルプフォーラムをご利用ください。

Posted by Zineb Ait Bahajji, WTA, thanks to the Webmaster Tools team.
Original version: More Precise Index Status Data for Your Site Variations

App Engine の利用する IP 帯域変更のお知らせ

Google では、それぞれのサービスについて、広い範囲の IP アドレスを利用しており、それらは予告なく変更される可能性があります。Google App Engine は様々なサードパーティアプリケーションがホストされている Platform as a Service（PaaS）です。この度、その IP アドレス帯域および、Google App Engine URLFetch や Sockets API が送信するヘッダーに関して変更が加わりましたので、お知らせいたします。

App Engine の IP 帯域を、インバウンドリクエストをフィルタするために利用することは推奨されていません。しかし、特定のアドレスを対象にしたフィルタを利用するサービスがあることは事実です。Google App Engine の IP 帯域は今月から変更されますので、その IP 帯域を特定するためには、こちらの指示（英語）に従ってください。

また、個別の App Engine アプリケーションを特定するためにこれまで利用されてきた HTTP User-Agent ヘッダー文字列は、これ以降利用されるべきではありません。新しく導入された Sockets API を利用することにより、URLFetch API を利用することなく、好きな User-Agent を設定した HTTP リクエストを送信することができます。

Posted by the Google App Engine Team
Original version: App Engine IP Range Change Notice

音楽家の皆さん、あなたの次の公演日をナレッジグラフに表示しましょう

大好きなバンドを Google で検索したとき、ナレッジグラフが表示され、そのバンドに関する情報が一覧できることに気づいた方もいるかと思います。この中には、コンサートのスケジュールに関する情報も含まれています。このスケジュールが正しく、完全であることはファンにとってもアーティストにとっても重要です。そこで、この表示に関して新しいアプローチをはじめることにしました。これからは、アーティストの公式ウェブサイト上に構造化データのマークアップが存在する場合、そこから直接その情報がナレッジグラフ内に表示されることになります。

もしあなたがアーティストの公式ウェブサイトの管理者なら、幾つかの方法 (英語) でこれを試してみることができます。

schema.org マークアップをサイト上で実装する。 RDFa や microdata に加えて新しくサポートされた JSON-LD フォーマットを利用すれば、今までにない簡便さでこれが実現できます。
もっと簡単な方法は、 Bandsintown や BandPage、ReverbNation、Songkick や GigPress といった、既に構造化データマークアップが埋め込まれているイベントウィジェットを利用することです。
また、ウェブマスターツールのデータハイライターを利用すれば、マウスだけであなたのサイト上のイベントをラベリングすることができます。

どの選択肢を選ぶにせよ、ヘルプセンターに詳細が載っています (日本語版も鋭意作成中です)。質問がありましたら、ウェブマスターヘルプフォーラムをご利用ください。

Posted by Justin Boyan, Product Manager, Google Search
Original version: Musical artists: your official tour dates in the Knowledge Graph

ファセットナビゲーションのベストプラクティスと 5 つのワーストプラクティス

ファセットナビゲーションは、検索結果を色や価格帯でさらに絞り込む仕組みです。ユーザーにとって便利な機能ですが、重複するコンテンツを持つ URL の組み合わせが数多く生成されてしまうと、検索に悪影響を及ぼすことがあります。例えば、コンテンツが追加されたり更新されたりした際クロールに時間がかかったり、あるいは、複数の重複 URL にシグナルが分散した結果、インデックス登録が正しく行われなかったり、といったことが起こる可能性があります。ここでは、これらの問題を解消し、ファセットナビゲーションサイトを可能な限り検索エンジンと相性の良いものにする方法を以下のとおり説明します。

ファセットナビゲーションでフィルタを選択すると URL の組み合わせが多くなる
例: http://www.example.com/category.php?category=gummy-candies&price=5-10&price=over-10

背景

サイトを構築する場合、個別のコンテンツ（つまり 1 つの商品/記事、または 1 つの商品/記事カテゴリ）にアクセスするための URL は 1 つだけ、というのが理想的な状態です。このような URL であれば、特定のコンテンツにアクセスするためのクリックパスやルートは明確で、ホームページやカテゴリページからクリックすることでアクセスできます。

検索ユーザーにも Google 検索にも理想的な状態

すべての商品/記事ページにアクセスできる明確な動線

左側はサイトでのユーザーの動線（つまりクリックパス）、右側はアクセスするページです。
個々のカテゴリページを表す URL は 1 つ
http://www.example.com/category.php?category=gummy-candies

グミのカテゴリページ
個々の商品ページを表す URL は 1 つ
http://www.example.com/product.php?item=swedish-fish

魚形グミの商品ページ

ファセットナビゲーションが原因となる望ましくない重複

同じ記事/商品の URL が複数存在する

カノニカル 重複
example.com/product.php? item=swedish-fish example.com/product.php? item=swedish-fish&category=gummy-candies&price=5-10
魚形グミの同じ商品ページに複数の URL でアクセスできてしまう

検索ユーザーや検索エンジンにとってほとんどまたはまったく価値のないカテゴリページが大量に存在する

URL	`example.com/category.php? category=gummy-candies&taste=sour&price=5-10`	`example.com/category.php? category=gummy-candies&taste=sour&price=over-10`

Issues	[sour gummy candy price five to ten dollars] で検索するユーザーがほとんどいないとすれば何の付加価値も提供しない。検索エンジンのクローラに何の付加価値も提供しない（「gummy candies」でも「sour gummy candies」でも同じ商品（「fruit salad」）が見つかる）。同じカテゴリがいくつものバージョンに分かれているため、インデックス登録のシグナルが分散してしまい、サイト所有者に悪影響を及ぼす。新しいページや更新されたページではなく重複したコンテンツに帯域幅やクローラの処理を費やすことになり、サイト所有者に悪影響を及ぼす。	検索エンジンに何の価値も提供しない（404 ステータスコードを返すべき）。検索ユーザーに悪影響を及ぼす。

ファセットナビゲーションのワースト・プラクティス

ワーストプラクティス 1: パラメータに標準的でない URL エンコードを使用している（「キー=値」ペアではなくカンマやかっこなどを使用している）

ワーストプラクティス:
example.com/category?[category:gummy-candy][sort:price-low-to-high][sid:789]
キー=値ペアに = ではなく : が使用されている
複数のパラメータが & ではなく [ ] で追加されている
example.com/category?category,gummy-candy,,sort,lowtohigh,,sid,789
キー=値ペアに = ではなく , が使用されている
複数のパラメータが & ではなく ,, で追加されている
ベストプラクティス:
example.com/category?category=gummy-candy&sort=low-to-high&sid=789
人間であれば「,,」のような非標準の URL パラメータを解読できますが、クローラがこのような URL パラメータを解釈するのは難しくなります。Google のクロールチームのソフトウェアエンジニアである Mehmet Aktuna は、「標準以外のエンコードを使用するのは、わざわざ災難を招いているようなものだ」と述べています。キー=値ペアには等号（=）を使用し、複数のパラメータの追加にはアンパサンド（&）を使用してください。

ワーストプラクティス 2: ページコンテンツを変更しない値を、パラメータではなくディレクトリやファイルパスとして追加する

ワーストプラクティス:
example.com/c123/s789/product?swedish-fish
（/c123/ がカテゴリ、/s789/ がセッション ID だがページコンテンツは変更されない）
グッドプラクティス:
example.com/gummy-candy/product?item=swedish-fish&sid=789（ディレクトリ /gummy-candy/ によってページコンテンツが意味のある形で変更される）
ベストプラクティス:
example.com/product?item=swedish-fish&category=gummy-candy&sid=789 （URL パラメータにしたことで柔軟性が増し、検索エンジンが効率的にクロールできる）
有用な値（たとえば「gummy-candy」）と有用でない値（たとえは「sessionID」）をパスに直接記述した場合、自動化されたプログラム（たとえば検索エンジンクローラ）がそれらを区別することは困難です。一方、URL パラメータを使用すれば検索エンジンにとって柔軟性が増し、クローラが各値のすべてのパターンにアクセスする必要があるかどうかを判断しやすくなります。
ページコンテンツを変更せず、URL パラメータとして設定されるべき一般的な値には次のものがあります:
セッション ID
トラッキング ID
リファラー ID
タイムスタンプ

ワーストプラクティス 3: ユーザー生成値を、クロールもインデックス登録も可能だが、検索結果では有用でない（場合によっては無限の）URL パラメータに変換する。

ワーストプラクティス（例: 緯度/経度、「～日前」といったユーザーごとに変動する値を含む URL をクロールとインデックス登録の対象にする）:
example.com/find-a-doctor?radius=15&latitude=40.7565068&longitude=-73.9668408
example.com/article?category=health&days-ago=7

ベストプラクティス:
example.com/find-a-doctor?city=san-francisco&neighborhood=soma
example.com/articles?category=health&date=january-10-2014
ユーザーごとに変動する値を含む URL をクロールするようにしても、処理が無限になる可能性があるだけで、検索ユーザーにとってはほとんど価値がありません。それよりも、最も一般的な値のカテゴリページを公開して追加情報を含めるようにすると、通常の検索結果ページより多くの付加価値を提供できます。ユーザー生成値を使用する場合は、生成値を別のディレクトリに格納し、robots.txt がそのディレクトリをクロールしないように設定します。
example.com/filtering/find-a-doctor?radius=15&latitude=40.7565068&longitude=-73.9668408
example.com/filtering/articles?category=health&days-ago=7
robots.txt を使用する場合:
User-agent: * Disallow: /filtering/

ワーストプラクティス 4: URL パラメータの追加に論理性がない

ワーストプラクティス:
example.com/gummy-candy/lollipops/gummy-candy/gummy-candy/product?swedish-fish
example.com/product?cat=gummy-candy&cat=lollipops&cat=gummy-candy&cat=gummy-candy&item=swedish-fish
ベタープラクティス:
example.com/gummy-candy/product?item=swedish-fish
ベストプラクティス:
example.com/product?item=swedish-fish&category=gummy-candy
関連性の低い URL パラメータを追加しても、重複が増えてクロールやインデックス登録の効率が下がるだけです。URL を生成する前に、不要な URL パラメータを削除してサイト内を「整理整頓」しましょう。ユーザーセッションに必要なパラメータが多い場合は、cat=gummy-candy&cat=lollipops&cat=gummy-candy& ... のように次々と値を追加するのではなく、Cookie を使って情報を保持するようにします。

ワーストプラクティス 5: 該当する検索結果のない絞り込み条件が表示されている

ワーストプラクティス:
該当する商品が 1 つもない絞り込み条件が選択可能になっている。

該当する結果がない絞り込み条件（この例では price=over-10）が選択できる状態になっています。これではユーザーがイライラし、検索エンジンで無用な問題が発生する原因にもなります。

ベストプラクティス:
ユーザーの選択が妥当な場合（つまり商品が存在するとき）にのみリンク/URL が生成されるようにします。該当する商品がないフィルタ条件はグレー表示されるようにします。使い勝手をさらに向上させるには、各フィルタ条件の横に該当する商品数を表示することも検討してください。

検索結果がゼロになる絞り込み条件（ここでは price=over-10）が選択できないようになっています。これにより、ユーザーが無駄なクリックをする心配がなく、検索エンジンのクローラが不要なページにアクセスすることもありません。

無用な URL をなくしてクロール領域を最小にするには、商品が存在するときにのみ URL が生成されるようにします。これにより、商品が存在しないページが表示されなくなり、ユーザーエクスペリエンスが高まるだけでなく、クローラが認識する URL の数も最小限に抑えることができます。また、ページの商品が一時的に在庫切れになっているわけではなく、今後もそのページに有益なコンテンツが掲載される可能性が低い場合は、404 ステータスコードを返すことを検討してください。404 を返すことで、ユーザーに対して他のナビゲーションオプションを示すダイアログを表示したり、関連商品を見つけるための検索ボックスを表示したりできます。

ファセットナビゲーションを新規作成/再設計する際のベストプラクティス

これからサイトにファセットナビゲーションを実装する場合は、独自のコンテンツページの「クロール領域」（Googlebot がサイト内で認識するすべての URL）を最適化し、重複するページのクロールを減らし、インデックス登録のシグナルを統合するための方法を検討しましょう。以下のようにいくつかの方法があります:

クローラがすべてのコンテンツページをクロールするのに必要な URL パラメータ（たとえば、アイテムごとに少なくとも 1 つのクリックパスを作成するために必要なパラメータ）を特定します。必要なパラメータとしては、item-id、category-id、page などが考えられます。
検索ユーザーにとって価値があるパラメータはどれか、クロールやインデックス登録において重複の原因になるだけの不要なパラメータはどれかを特定します。グミの例では、たとえば「taste」パラメータは検索ユーザーにとって有用です。[sour gummy candies] で検索すると、結果として example.com/category.php?category=gummy-candies&taste=sour が表示されます。一方、「price」パラメータは、category=gummy-candies&taste=sour&price=over-10 のような重複の原因になるだけです。以下に一般的な例を示します:

検索ユーザーに有用なパラメータ: item-id、category-id、name、brand...
不要なパラメータ: session-id、price-range...

不要なパラメータが含まれている URL の場合は、以下のいずれかの設定オプションを実装することを検討してください。なお、不要な URL パラメータは、クローラや、個別の商品にアクセスするためのユーザーのクリックパスでは必要ありません。

オプション 1: rel="nofollow" 内部リンクを使用する
すべての不要な URL へのリンクに rel="nofollow" を追加します。このオプションを追加すると、クローラによって不要な URL がクロールされるのを最小限に抑えることができ、ファセットナビゲーションによってクロール領域（クローラが認識する URL の領域）が極端に大きくなるのを防ぐことができます。なお、rel="nofollow" は不要な URL のクロールをブロックするわけではありません（クロールをブロックできるのは robots.txt の disallow だけです）。ただし、不要な URL へのクロールを許可することで、それらの URL からのインデックス登録のシグナルを、ユーザーにとって有用な URL に統合することもできます。それには、不要な URL に上位の URL への rel="canonical" を追加します。たとえば、example.com/category.php?category=gummy-candies&taste=sour&price=5-10 に rel="canonical" を追加し、上位 URL として example.com/category.php?category=gummy-candies&taste=sour&page=all）（すっぱいグミをすべて表示するページ）を指定します。
オプション 2: Robots.txt の disallow
不要なパラメータを含む URL に、robots.txt でクロールをブロックする /filtering/ ディレクトリを含めます。これにより、すべての検索エンジンが有用なコンテンツを自由にクロールできるようになりますが、不要な URL のクロールはブロックされます。たとえば、有用なパラメータが item、category、taste で、不要なパラメータが session-id と price だとします。例:
example.com/category.php?category=gummy-candies
このような URL を、別の有用な URL パラメータ（たとえば taste）にリンクさせることができます。
example.com/category.php?category=gummy-candies&taste=sour.
ただし、不要なパラメータ（たとえば price）を追加する場合は、URL に定義済みのディレクトリ /filtering/ を含めます:
example.com/filtering/category.php?category=gummy-candies&price=5-10
これでこの URL は、robots.txt によってクロールがブロックされます。
User-agent: * Disallow: /filtering/
オプション 3: ホストを別々にする
CDN を使用していない場合（CDN を使用しているサイトでは、上記のようなウェブマスターツールの柔軟な機能を利用することはできません）は、不要なパラメータを含む URL を別のホストに配置することを検討してください。たとえば、メインホスト www.example.com とサブホスト www2.example.com を作成します。サブホスト（www2）では、ウェブマスターツールのクロール速度を低く設定します（メインホストはできるだけ高く設定したままにします）。これにより、メインホストの URL は完全にクロールされますが、不要な URL が Googlebot によってクロールされる可能性が低くなります。
- メインホストのすべてのアイテムに、1 つ以上のクリックパスがあることを確認してください。
- インデックス登録のシグナルを統合したい場合は、サブホストからメインホストの上位 URL への rel="canonical" を追加することを検討してください（例: www2.example.com/category.php?category=gummy-candies&taste=sour&price=5-10 に rel="canonical" を追加し、上位 URL として www.example.com/category.php?category=gummy-candies&taste=sour&page=all（すっぱいグミをすべて表示するページ）を指定します）。

特定のカテゴリ/フィルタに該当商品がない場合はリンクをクリックできないようにします。
URL パラメータが論理的に表示されるようにします。

値を次々と追加するのではなく、不要なパラメータを削除するようにします。

悪い例
example.com/product?cat=gummy-candy&cat=lollipops&cat=gummy-candy&item=swedish-fish)

検索ユーザーにとって有用なパラメータを先に記述し、関連性の低いパラメータ（たとえばセッション ID）を後に記述します。URL が検索に表示されることもあるため、パラメータの順序に一定のルールを設けユーザーエクスペリエンスを高めます。

悪い例
example.com/category.php?session-id=123&tracking-id=456&category=gummy-candies&taste=sour

rel=”canonical” を使用して、個々のコンテンツページのインデックス登録を望ましいページに統合します。rel="canonical" は、ホスト名やドメインをまたがって使用できます。

ページ指定されたコンテンツ（たとえば「グミ」カテゴリの page=1、page=2）のインデックス登録を、以下のいずれかの方法で改善します:

シリーズを構成する各ページに、カテゴリの「すべて表示」ページへの rel="canonical" を追加します（例: 「グミ」カテゴリの page=1、page=2、page=3 に category=gummy-candies&page=all への rel="canonical" を追加します）。その際に、検索ユーザーのエクスペリエンスを損なわない（各ページがすばやく読み込まれるなど）よう注意してください。
rel="next" と rel="prev" でページ指定をマークアップして、リンクなどのインデックス登録のプロパティを構成ページ/URL からシリーズ全体に統合します。

コンテンツの並べ替え、フィルタリング、非表示を、URL の更新ではなく JavaScript で動的に行う場合でも、クロールやインデックス登録の対象となるメインのカテゴリページや商品ページの URL はユーザーにとって有用な情報です。JavaScript でコンテンツを動的に変更する場合は、サイト全体を表す URL としてホームページのみ（つまり 1 つの URL のみ）を使用することは避けてください。これでは検索ユーザーが、1 つの URL でサイト内のすべてのコンテンツにアクセスすることになってしまいます。また、動的なフィルタリングによってパフォーマンスが低下することがありますので注意してください。これにより、ユーザーエクスペリエンスが損なわれる可能性があります。

サイトマップには canonical URL のみ含めるようにしてください。

サイトに既にファセットナビゲーションが実装されている場合のベストプラクティス

前のセクションで説明したベストプラクティス（たとえば不要な URL の rel="nofollow"）は、既存のサイトのファセットナビゲーションを大幅に再設計する場合にも適用できます。ただし、既存のファセットナビゲーションの場合は、検索エンジンが認識したクロール領域が既に大きくなっているケースが多いようです。したがって、Googlebot によりクロールされる不要なページを増やさないようにすることと、インデックス登録のシグナルの統合を検討することが重要になります。

可能な場合は、標準のエンコードとキー=値ペアによるパラメータを使用します。
ページコンテンツを変更しない値（セッション ID など）は、ディレクトリではなく標準のキー=値ペアとして実装されていることを確認します。
特定のカテゴリ/フィルタに商品が存在しない場合には、クリック可能なアンカーを使用しないようにします（つまり、フィルタを実行して該当するアイテムが見つからない場合には、クリックされたり、URL が生成されたりしないようにします）。
URL パラメータが論理的に表示されるようにします。

値を次々と追加するのではなく、不要なパラメータを削除するようにします（例: example.com/product?cat=gummy-candy&cat=lollipops&cat=gummy-candy&item=swedish-fishのような URL は避けます）。

検索ユーザーにとって有用なパラメータを先に記述し、関連性の低いパラメータ（たとえばセッション ID）を後に記述します。URL が検索に表示されることもあるため、パラメータの順序に一定のルールを設けユーザーエクスペリエンスを高めます（例: example.com/category?session-id=123&tracking-id=456&category=gummy-candies&taste=sour& ではなく example.com/category.php?category=gummy-candies&taste=sour&session-id=123&tracking-id=456とします）。

サイトでの URL パラメータの動作について十分に理解している場合は、ウェブマスターツールの URL パラメータを設定します（この場合でも、個別のアイテム/記事へのクリックパスを明確にする必要はあります）。たとえば、ウェブマスターツールの URL パラメータを使用すると、パラメータ名、ページコンテンツに対するパラメータの効果、Googlebot がパラメータを含む URL をクロールする方法などを一覧表示できます。

ウェブマスターツールの URL パラメータを使用すると、サイトのパラメータに関する情報や Googlebot の動作に関する推奨事項を確認できる

rel=”canonical” を使用して、個々のコンテンツのインデックス登録を望ましいページに統合します。rel="canonical" は、ホスト名やドメインにまたがって使用できます。

ページ指定されたコンテンツ（たとえば「グミ」カテゴリの page=1、page=2）のインデックス登録を、以下のいずれかの方法で改善します:

シリーズを構成する各ページに、カテゴリの「すべて表示」ページへの rel="canonical" を追加します（例: 「グミ」カテゴリの page=1、page=2、page=3 に category=gummy-candies&page=all への rel="canonical" を追加します）。その際に、検索ユーザーのエクスペリエンスを損なわない（各ページがすばやく読み込まれるなど）よう注意してください。
rel="next" と rel="prev" でページ指定をマークアップして、リンクなどのインデックス登録プロパティを構成ページ/URL からシリーズ全体に統合します。

サイトマップには canonical URL のみ含めるようにしてください。

シンプルなままにしておけるなら、それがベストであるということは覚えておいてください。ご不明な点がありましたら、ウェブマスターヘルプフォーラムまで質問をお寄せください。

Written by Maile Ohye, Developer Programs Tech Lead, and Mehmet Aktuna, Crawl Team
Original version: Faceted navigation best (and 5 of the worst) practices

モバイルサイトを改善するためのチェックリストと動画をご紹介します

スマートフォン用ウェブサイトを改善したいけれど、どこから手をつければよいかわからないとお困りではありませんか？多くのアドバイスの中からどれを優先すればよいのか知りたいと思いませんか？このたび Google では、モバイルサイトを効率よく改善する上で役立つチェックリストを公開しました。このチェックリストでは、複数のトピックから関連するビジネスケースや研究・調査にリンクしています。また、一部のトピックでは、Google アナリティクスやウェブマスターツールのデータをサイトの改善に効果的に利用する方法を解説した動画を用意しています（字幕を日本語にしてご覧ください）。こちらのリストは、チェックリスト（英語）の簡易版となります。ぜひ、サイトの改善にお役立てください。

手順 1: ユーザーをイライラさせない

モバイルのユーザーエージェントからのアクセスに対して余分なウィンドウを表示しない | Google の推奨事項、記事（英語）

簡単に閉じることのできない JavaScript ポップアップ。
特にアプリをダウンロードするためのオーバーレイ表示（iOS 6 以降の Smart App Banner（英語）またはそれに相当するバナー、サイドナビゲーション、メールマーケティングなどの使用を代わりにご検討ください）。
タスクを完了する前のアンケートの表示。

端末に適した機能を提供する

ユーザーの端末で使用できないプラグインや動画を必要とする機能を削除します（たとえば、Adobe Flash は iPhone や Android バージョン 4.1 以降では再生できません）。| ビジネスケース
タブレットユーザーにはデスクトップバージョン（可能な場合はタブレットバージョン）を配信します。| 研究・調査（英語）
デスクトップバージョンの機能が携帯端末でもすべて利用できることを確認します。ユーザーがデスクトップバージョンでの表示を選択した場合には、セッション中はすべてデスクトップバージョンが保持されるようにします（つまり、各ページが読み込まれた後でユーザーがデスクトップバージョンを選択しないで済むようにします）。| 研究・調査（英語）

トラフィックが多くユーザーエクスペリエンスが悪いモバイル向けページを改善する

Google アナリティクスの直帰率とイベントのデータを使用して、トラフィックが多くユーザーエクスペリエンスが悪いモバイル向けページを改善する方法（スライド）

パフォーマンス向上のための簡単な修正を加える（競合サイトよりもパフォーマンスが低い場合は継続して修正する）| ビジネスケース（英語）

モバイルサイトのパフォーマンスを向上するための簡単な修正を加え、競合サイトとパフォーマンスを比較する方法（スライド）

「ユーザーの利便性を妨げない」のすべてのトピックを確認するには、フルバージョンのモバイルサイトを改善するためのチェックリストをご覧ください。

手順 2: 簡単にタスクを完了できるようにする

クロール、インデックス登録、検索時のユーザーエクスペリエンスを最適化する | ビジネスケース（英語）

robots.txt によりアクセスを制限しているリソース（CSS、JavaScript）の制限を解除します。
あなたのモバイルサイトの実装に適した検索エンジンのベストプラクティスを実装します。

レスポンシブデザイン: CSS @media クエリを組み込みます。
モバイルサイトを別に用意する: rel=alternate media と rel=canonical、および Vary: User-Agent HTTP ヘッダーを追加します。これにより、Google がリダイレクトスキップを実装しやすくなります。
動的な配信: Vary: User-Agent HTTP ヘッダーを組み込みます。

サイトの一般的なモバイルペルソナワークフローを最適化する

Google ウェブマスターツールと Google アナリティクスを使用して一般的なモバイルワークフローを最適化する方法（スライド）

手順 3: ユーザーをファンに変える

モバイルアプリの検索への統合を考慮する（※ 2014/3/5 現在のところ日本では未対応です） | お知らせ、情報（英語）

価値を提供するための新しい方法をブレーンストーミングする

実際の店舗などにおいて買い物客がどのようにモバイルを使用するか、という点を考慮して制作します。| ビジネスケース（英語）
スマートフォンの GPS、カメラ、加速度計を活用します。
共有など、ソーシャルを活用します。| ビジネスケース（英語）
スワイプ、シェイク、タップを使用した直感的かつ楽しい体感機能の実装を検討します。

Written by Maile Ohye, Developer Programs Tech Lead
Original version: Checklist and videos for mobile website improvement

検索に関するご質問を！ウェブマスターオフィスアワーでお待ちしています！

Google では、日本のウェブマスターのみなさまに向けて、昨年度から Google+ のハングアウトオンエア機能を利用したウェブマスターハングアウトを行ってきました。

みなさまからご好評を頂き、2014 年に入りハングアウト形式の情報発信を拡充しています。従来のオンライン講義形式のウェブマスターハングアウトだけでなく、リアルタイムに Google 社員がみなさまからのご質問にお答えする「ウェブマスターオフィスアワー」と称したイベントを頻繁に開催し、多くの方にご参加頂いています。

今回は「ウェブマスターオフィスアワー」についてその概要と参加方法をご紹介します。

ウェブマスターハングアウトとウェブマスターオフィスアワー

2014 年から、Google サーチクオリティチームでは、2 種類のハングアウトを実施しています。

従来から行っていた「ウェブマスターハングアウト」では、オンライン授業形式で Google 社員より様々なトピックについてまとまった情報をお届けしています（実施例）。
一方「ウェブマスターオフィスアワー」は、特定のトピックは決まっておらず、Google 社員がリ参加者から頂いた Google 検索やサイト運営上の質問にアルタイムで答えていく、カジュアルな Q&A セッションとなっています。例えば

Google 検索と相性の良いサイト運営法とは？
ウェブマスターツール上でエラーが出たけれどどう対処すればいい？
Goolge 検索に関して、知っておくとよい最新の情報を教えて！

といったご質問に Google 社員がリアルタイムでお答えします。

参加するには？

各回ごとに Google+ 上にイベントページを設置しますので、そちらで参加表明をお願いします。Webmaster Japan コミュニティやオフィスアワーサイトでも最新の日程をご確認いただけます。
イベント当日は、イベントページ上からライブ配信の動画を閲覧し、リアルタイムで質問をすることも可能です。イベント終了後は、録画された動画が公開されます。

質問するには？

ウェブマスターオフィスアワーで質問するには 2 つの方法があります。

イベントページ上に質問を投稿する：イベントページ上にテキストで質問を投稿して頂けます。イベント開催前から質問の投稿は可能ですので、聞きたい質問を思いついた際には忘れない内にご投稿ください :) 頂いた質問にはオフィスアワーの時間内に、リアルタイムにお答えしていきます。
ハングアウトに直接参加する：ビデオ会議形式で、Google 社員が参加しているハングアウトに直接参加し、顔を見ながら会話ベースで質問をすることも可能です。こちらは、映像にご自身の顔（カメラをオフにして参加することも可能です）や発言が記録され、公開されることをご理解の上ご参加ください。なお、ハングアウトに参加しないで閲覧するだけでは顔が映ることはありませんのでご安心ください :)

「こんな質問をしたらレベルが低すぎて恥ずかしいかな」といった声を聞くこともありますが、ご心配は無用です。

過去に実施したこちらのオフィスアワーの動画をご覧いただくとおわかり頂けるかと思いますが、初心者の方から上級者まで、どんなレベルの方でも気軽にご質問頂ける場となることを心がけていますので、疑問がありましたら、遠慮せずにご参加、ご質問をして頂けたらと思います。

また、一度質問しても不明点が残った場合に追加で「○○ の部分をもう少し詳しく説明して欲しい」とリクエスト書き込んだり、ハングアウトで直接参加して、質問の意図を説明してより詳しい回答を得たりといったことも可能です。リアルタイム、インタラクティブだからこそ、みなさまの疑問点をより具体的に解消できるのがウェブマスターオフィスアワーの魅力だと考えています。

過去の動画をもっと見るには？

こちらのプレイリストから過去の動画（ウェブマスターハングアウト、ウェブマスターオフィスアワー）をご覧いただけます。次回の開催は？次回のウェブマスターオフィスアワーは 3 月 5 日 17:00 （日本時間）を予定しています。また、今後も 2 週間に 1 回程度の開催を予定していますので、ぜひお気軽にご参加ください。

みなさまにウェブマスターオフィスアワーでお会いできることを楽しみにしております！

Kiyotaka Tanaka, Search Quality Team
Kazushi Nagayama, Webmaster Trends Analyst

サイトの不正なハッキングをいち早く見つける 3 つの方法

サイトが不正にハッキングされているのを見たことがありますか？

不正にハッキングされた可能性のあるサイトには検索結果上でメッセージを表示しています。

不正なハッキングによる被害は依然、世界中で増えています。例えば最近では、不正なハッキングによって、ブランド名や製品名（「財布」「バッグ」等）、「激安」などのキーワードやコンテンツを挿入し、オンラインでショッピングをしようとしているユーザーを別のショッピングサイトに誘導するケースが見られます。

また、他のスパム行為と比べ、不正なハッキングでよく見られる特徴としては、別言語のコンテンツが挿入されてしまうため、ハッキングされていること自体に気づきにくいという現象が起こりえます。例えばロシア語のサイトがハッキングされ、日本語の悪質なコンテンツを挿入されてしまう、といったケースがみられます。

Google では、不正なハッキングや悪質なコンテンツの挿入の被害にあっていると思われるサイトの検索結果に警告メッセージを表示し、検索ユーザーがサイトにアクセスしないよう注意喚起を行っています。しかし、ウェブマスターのみなさまが、日頃からサイトの状況を把握し、いち早く被害に気づくことが、検索ユーザーにとってもウェブマスターのみなさまにとっても被害を最小限に抑えるために何よりも重要です。

今回は、ハッキングの被害にいち早く気づくための最新のヒントをご紹介します。

1. サイト内に不自然なディレクトリや URL がないか確認する

みなさんのサイトでサイト演算子による検索（site:example.com）を試してみてください。サイト内にご自身で作成してないサブディレクトリやページが存在していないでしょうか？ハッキングにより不正にディレクトリを作成されたり、ページが挿入されたりすることがありますので、定期的にサイト内の状況を確認してみてください。[site:example.com 激安] や [site:example.com viagra] のように site: 演算子の後にハッキングで狙われやすいクエリ（キーワード）を付け足して検索することも可能です。また、こうした検索クエリで Google アラートを設定しておくと、変化により早く気づくことができるでしょう。

2. ウェブマスターツール上の「検索クエリ」に不自然なクエリが表示されていないか確認する

ウェブマスターツールには、ご自身のサイトがどのような検索クエリにヒットして検索結果上に表示されているかを知ることができる機能が備わっています。この「検索クエリ」にお使いの言語以外のクエリが表示されている場合、それがサイトがハッキングされていることを示すシグナルとなっていることがあります。

英語のサイトが日本語のコンテンツでハッキングされた例。
検索クエリのページに日本語の見知らぬクエリが表示されています。

別言語の読めない文字であるという理由で、こうしたデータを無視し、ハッキングの被害を見逃してしまうこともありますので、他言語の検索クエリを見つけても、「自分には関係のないデータだ」などと無視せずに、深く調査することをおすすめします。

3. ウェブマスターツールのメール転送機能を活用する

ウェブマスターツールでは絶えずサイトの状況をモニターしているため、サイトに何か問題があったときにはウェブマスターツールのメッセージセンターに通知されます。メール転送機能を使うと、これらの通知を Google アカウントに関連付けられているメールアドレスに転送することができますので、ウェブマスターツール内での確認の前に、みなさまがいち早く被害に気づくことができます。

以上、サイトの不正なハッキングをいち早く見つける 3 つの方法をご紹介しました。なお、不正なハッキングの被害が見つかった場合の対処方法や、未然に被害を防ぐためのヒントについては、以下のブログ記事やヘルプページをご覧ください。

これらのツールや情報を、被害にあう前から確認しておき、サイトが不正なハッキングの被害にあった場合にすぐに対処を行えるような状態にしておきましょう。また、サイト上で利用しているソフトウェアの更新状況を常に確認し、セキュリティの脆弱性に対応した最新のものにアップデートしておくことも重要です。

ご質問やご意見がある方は、ウェブマスターヘルプフォーラムのマルウェアへの感染、サイトのハッキングに関するカテゴリもぜひご活用ください。

Google サーチクオリティチームではこのような被害を防ぐため、日々より良い検索結果を提供できるよう改善に努めていますが、みなさまからの報告やフィードバックも問題を把握する上で重要な情報となっています。もし不正なハッキングの被害にあっていると思われるサイトを見かけた場合は（それが自分のサイトでなかったとしても）、スパムレポートからご報告をお願いします。

Megumi Hitomi, Search Quality Team

検索エンジンとの相性を考慮した無限スクロールのベストプラクティス

ご自身のサイトのニュースフィードやピンボードで、ユーザーの利便性を考えて無限スクロール（英語）を使用している方もいらっしゃるでしょう。しかし、Googlebot に対してとなると話が変わってきます。無限スクロールでは、クローラーがユーザーの行動（スクロールやボタンを押してさらにアイテムを読み込むなど）を常にエミュレートできるとは限らないため、フィードやギャラリー内のすべてのアイテムにアクセスできないことがあります。クローラーがアクセスできないコンテンツは、検索結果に表示されることもないでしょう。

無限スクロールページからリンクされている個別のアイテムを検索エンジンがクロールできるようにするには、無限スクロールを分割した一連のページ群を生成するようにしましょう。

無限スクロールページは、分割された一連のページ群に変えることで検索エンジンとの相性が良くなります。それぞれのページには類似の <title> が含まれ、 <head> では rel=next/prev の値が宣言されています。

Google のウェブマスタートレンドアナリストである John Mueller が作成したページ指定された無限スクロールサイトのデモで、実際の挙動を確認できます。このデモは、検索エンジンとの相性を考慮する上で重要なポイントを示しています:

対象範囲: すべての個別のアイテムがアクセス可能。従来の無限スクロールでは、最初のページ読み込み後に表示された個別のアイテムをクローラーが見つけることはできません。
重複なし: 各アイテムは一連のページ指定したページで一度だけ指定（つまり、アイテムの重複はありません）。

検索エンジンとの相性を考慮した無限スクロールのベストプラクティス

はじめる前に:

無限スクロールページのコンテンツを、JavaScript が無効でもアクセス可能な形で、複数のページに分割します。
各ページに含めるコンテンツの量を決定します。

検索ユーザーが直接このページにアクセスしても、探しているアイテムが簡単に見つけられるようにします（たくさんスクロールしなければコンテンツを見つけられないようなことは避けます）。
適当なページの読み込み時間を維持します。

コンテンツを分割し、それぞれのページ間で重複が発生しないようにします（バッファリングを除きます）。

検索エンジンと相性が良い例を左に、そうでない例を右に示します。右側の例では、コンテンツのクロールとインデックス登録にそれぞれ重複が発生する可能性があります。

検索エンジンが処理する無限スクロール用の URL を構成します。

コンポーネントを構成する各ページには完全な URL を含めます。このケースでは、構成エラーを避けるために完全な URL を使用することをおすすめします。

好ましい例: example.com/category?name=fun-items&page=1
好ましい例: example.com/fun-items?lastid=567
好ましくない例: example.com/fun-items#1
ユーザーが各ページ（の URL）から直接コンテンツにアクセスできること、および同じ Cookie やユーザー履歴のないブラウザからでもアクセス/参照可能であることを確認します。

URL パラメータのキー/値が次のベストプラクティスに従うようにします:

URL が概念上は今から 2 週間後でも同じコンテンツを表示するようにします。

相対時間に基づいた URL パラメータの使用は避けます:
好ましくない例: example.com/category/page.php?name=fun-items&days-ago=3

検索ユーザーにとってコンテンツの内容が想像できる価値のあるパラメータを設定します。

コンテンツにアクセスする主な手法として、検索ユーザーにとって価値のないパラメータを使用することは避けます:
好ましくない例: example.com/fun-places?radius=5&lat=40.71&long=-73.40

各ページで、<head> 内に rel=next と rel=prev の値を含めるページ指定を行います。<body> 内のページ指定の値は、ウェブマスターが意図しないところで、ユーザー生成コンテンツによっても挿入される場合があるため、Google のインデックス登録では無視されますので、ご注意ください。
無限スクロールページに replaceState/pushState を実装します。どちら（あるいは両方）を採用するかはあなた（のサイトのユーザーの行動）次第ですが、Google では、次のような場合には pushState を（単独または replaceState と併せて）含めることをおすすめします:

クリックや実際にページをめくるようなユーザーの行動がある場合
ページ指定したコンテンツが表示されるたびに閲覧履歴に保存できるようにする場合

テストを行います。

ユーザーが上下にスクロールする際に URL の中のページの値が調整されることを確認します。John Mueller のページ指定された無限スクロールサイトのデモでは、上下のスクロールの挙動を示します。
範囲外のページが 404 レスポンスを返すことを検証します（つまり、example.com/category?name=fun-items&page=999 では、コンテンツ内に 998 ページしかない場合に 404 レスポンスを返す必要があります）。
無限スクロールの実装によって引き起こされる可能性があるユーザーの利便性の問題（英語）を調べます。

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

Written, reviewed, or coded by John Mueller, Maile Ohye, and Joachim Kupke
Original version: Infinite scroll search-friendly recommendations

ウェブマスター向けトラブルシューティングページの提供を開始しました

本日、日本のウェブマスターの方に向けて、トラブルシューティングページの提供を開始しました。

トラブルシューティングページ上で表示される質問に、選択肢を選んで答えていくと、あなたが現在抱えている問題（検索結果におけるサイトのパフォーマンスに問題がある、ウェブマスターツール上に警告やエラーのメッセージが表示された、など）への対処法が表示されます。今までのヘルプ記事よりもインタラクティブになったことで、それぞれの問題に合わせた細かなサポートを提供でき、よりお役に立てれば幸いです。

サイト運営の中で、検索結果上でのパフォーマンスに何か問題が発生したら、まずはトラブルシューティングページを見てみてください。みなさんのご利用をお待ちしています！

また、ご利用になっての感想や、改善のアイディアなどがありましたら、ぜひウェブマスターヘルプフォーラムでお知らせください。

Kiyotaka Tanaka, on behalf of Search Quality Team Tokyo

サイト運営者様向けの Google サービスを WordPress から利用が可能に：Google サイト運営者向けプラグイン（ベータ版）

[この記事は、Inside AdSense ブログとのクロスポストです。]

この度、 WordPress の管理画面からサイト運営者向けサービスをご利用いただける Google サイト運営者向けプラグイン（ベータ版）の提供を開始しました。

独自のドメインで WordPress を運用されている場合 Google サイト運営者向けプラグインをご利用いただくと、WordPress の管理画面から一部の Google サービスにアクセスすることができます。

Google サイト運営者向けプラグイン（ベータ版）は以下の 2 つの Google サービスに対応しています。

Google AdSense: ウェブサイトに広告を掲載し、ウェブサイトを収益化するサービスです。Google サイト運営者向けプラグインを利用すると、ウェブサイトに簡単に広告を掲載することができ、HTML コードを手動で編集する手間を省けます。
Google ウェブマスターツール: Google 検索におけるウェブページの視認性について詳しいレポートを作成するツールです。新しいプラグインを利用すると、ワンクリックでウェブマスターツールを使ってサイトの視認性を検証できます。

Google サイト運営者向けプラグインは、WordPress.org のプラグインディレクトリ（英語）からダウンロードすることができます。詳細とご利用方法については、ヘルプセンターをご覧ください。

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

Posted by Michael Smith - Product Manager
Original version: Google Publisher Plugin beta: Bringing our publisher products to WordPress

スマートフォン用のコンテンツをクロールするための新しい Googlebot ユーザーエージェント

Google では数年にわたって、従来の携帯電話（フィーチャーフォン）とスマートフォンのコンテンツに対して別々のクローラーを使用してクロールとインデックス登録を行ってきました。こうしたモバイル固有のクローラーはすべて Googlebot-Mobile と呼ばれていました。しかし、フィーチャーフォンとスマートフォンでは端末機能がかなり異なっており、フィーチャーフォンのクロールやインデックス登録をブロックするつもりが誤ってスマートフォンのクロールやインデックス登録をブロックしてしまったという報告もウェブマスターから寄せられていました。この曖昧さにより、一部サイトのスマートフォン向けコンテンツのインデックス登録や、それらのサイトがスマートフォン向けに最適化されていることの認識が難しくなってしまっていました。

スマートフォン用の新しい Googlebot

状況を明確にし、ウェブマスターの皆様がより的確に管理できるようにするために、Google ではスマートフォン用の「Googlebot-Mobile」ユーザーエージェントの使用を 3～4 週間後に中止します。それ以降、スマートフォン用のユーザーエージェントはシンプルに「Googlebot」となりますが、ユーザーエージェントストリングのどこかに「mobile」という単語は引き続き残ります。新旧のユーザーエージェントは次のとおりです:

スマートフォン用の新しい Googlebot ユーザーエージェント:

Mozilla/5.0 (iPhone; CPU iPhone OS 6_0 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10A5376e Safari/8536.25 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)

まもなく使用を中止するスマートフォン用の Googlebot-Mobile ユーザーエージェント:

Mozilla/5.0 (iPhone; CPU iPhone OS 6_0 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10A5376e Safari/8536.25 (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)

この変更が影響するのはスマートフォン用の Googlebot-Mobile のみです。標準の Googlebot のユーザーエージェントには変更ありません。残りの 2 つの Googlebot-Mobile クローラーのユーザーエージェントストリングでは引き続きフィーチャーフォン端末が参照されます。これらのクローラーは次のとおりです:

標準の Googlebot ユーザーエージェント:

Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)

フィーチャーフォン用の 2 つの 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)

ウェブマスターツールの Fetch as Google 機能を使用してサイトのテストを実施できます。また、ヘルプセンターでは、Google のクローラーの一覧をご確認いただけます。

クロールとインデックス

ユーザーエージェントのアップデートでは次の点にご注意ください。スマートフォンクローラー用の新しい Googlebot では、Googlebot-Mobile ではなく Googlebot の robots.txt、robots メタタグ、HTTP ヘッダーの指定が適用されます。たとえば、新しいクローラーが導入されている場合、以下の robots.txt の指定によって、スマートフォン用の新しい Googlebot ユーザーエージェントと標準の Googlebot ユーザーエージェントによるすべてのクロールがブロックされます:

User-agent: Googlebot
Disallow: /

以下の robots.txt の指定によって、Google のフィーチャーフォンクローラーによるクロールがブロックされます:

User-agent: Googlebot-Mobile
Disallow: /

Google の分析では、このアップデートにより、ウェブマスターはコンテンツのクロールとインデックス登録をより管理しやすくなる一方で、URL に及ぼす影響は 0.001% 未満という結果になりました。ご不明な点がありましたら、以下をご覧ください:

Posted by Zhijian He, Smartphone search engineer
Original version: A new Googlebot user-agent for crawling smartphone content

リダイレクト発生時のクロールエラーの表示に関する改善について

これまで、ウェブマスターツールで報告されているクロールエラーに関して、ウェブマスターの皆さまの間に混乱が見られることがありました。今回の改善は、この点をより明確にし、エラーの診断をより容易にするものです。従来報告に表示されていたのはリダイレクト元の URL でしたが、この変更により、リダイレクト先の、実際にエラーコードを返している URL が表示されるようになります。

一例を見てみましょう:

A は B にリダイレクトしていますが、B はエラーを返しています。リダイレクトの種類やエラーの種類自体はここでは重要ではありません。

これまで、ウェブマスターツール上では、URL A の方をクロールエラーとして表示してきました。これからは、表示されるのは URL B の方になります。これにより、表示されているクロールエラーの診断がより容易になるでしょう。cURL やオンラインのサーバーヘッダーチェッカーなどのツールを利用して、URL B から実際にエラーが返されていることを確認することができます。

この変更が、全体のエラー数に影響を与える場合もあるでしょう。あなたのサイトが新しいドメインに移行した場合、リダイレクトが正確に行われていれば、これらのエラーは新しいドメインのウェブマスターツールでのみ確認することができるようになります。これにより、全体のエラー数が大きく変化する可能性があります。

この変更は、ウェブマスターツールでどのようにクロールエラーが表示されるかということにのみ影響するということにご注意ください。また、エラーを返すべき（例えば、存在しない） URL でクロールエラーが発生することによって、同一サイト内の他のページのインデクシングやランキングに影響が与えられることはありません（英語ですが、こちらの Google+ 上の投稿もご参照ください）。

この変更が、クロールエラーの診断をより容易にすることを願っています。気づいていなかったエラーが発生していたら、ぜひ直してあげてください。この記事に関するコメントやご質問は、ウェブマスターヘルプフォーラムまでお寄せください。

Posted by John Mueller, Website Error Analyst
Original version: Changes in crawl error reporting for redirects

モバイル向けに別サイトを持っている場合の検索クエリデータが改善されました

ウェブマスターツールの「検索クエリ」機能が、モバイル向けに別の URL を用意しているサイト（モバイル向けに m.example.com、デスクトップ向けに www など）に関して改善されました。2013 年 12 月 31 日より、モバイルサイト側* の「検索クエリ」で、フィルタを「携帯電話」に設定した場合、以下の両方が表示されます:

あなたのモバイル向けページが、携帯端末上のブラウザーの検索結果に表示された検索クエリ
リダイレクトスキップが発生した検索クエリ。この場合、検索結果上ではデスクトップ版の URL が表示されますが、それをクリックしたユーザーは直接モバイル版へと送られます（サーバーサイドリダイレクトのレイテンシから解放されることになります）。

リダイレクトスキップに関する情報が、モバイルサイト側で表示されています

この改善の前は、リダイレクトスキップが発生している検索クエリもデスクトップ向けのサイトに加算されていました。この変更により、表示回数やクリック数、CTR などの情報がモバイルサイト側で表示されることになりますので、モバイル向けの統計がより理解しやすくなりました。

モバイル向けに別の URL を用意する場合のベストプラクティス

モバイル向けに別の URL を用意する場合は、以下をおすすめします。

携帯端末に最適化されたウェブサイトの構築方法を参照する

デスクトップ向けサイトの側では、対応するモバイル向け URL へ向いた link rel=”alternate” タグを設置してください。これは、Googlebot があなたのモバイル向けサイトを発見する助けになります。
モバイル向けサイトの側では、対応するデスクトップ向け URL へお向いた rel=”canonical” タグを設置してください。
ユーザーエージェントに応じて自動的にサーバー側でリダイレクトを行なっている場合は、HTTP Vary: User-Agent ヘッダーを利用してください。

ウェブマスターツールでは、デスクトップ向けサイトとモバイル向けサイトの両方を登録しましょう。このことにより、各サイトのトラブルシューティングがより捗ります。

* モバイル向けサイトの所有権が確認されている場合

Written by Maile Ohye, Developer Programs Tech Lead
Original version: Official Google Webmaster Central Blog: Improved Search Queries stats for separate mobile sites

ウェブマスターツール「検索クエリ」機能が改善されました

あけましておめでとうございます。あなたの新年をより良いものにすることを願って、この度、ウェブマスターツールで人気の機能の 1 つを改善いたしました。「検索クエリ」機能で表示されるデータが、概算ではなくなります。

検索クエリ機能は、検索結果にあなたのサイトからのページが少なくともひとつ表示されている検索クエリについての情報を表示するものです。過去 90 日間で、ページが検索結果に表示された回数と、ユーザーが実際にあなたのサイトを訪れた回数（クリック数）を収集し、表示しています。

この度のアップデートの前と後を比較してみてください:

アップデート前

アップデート後

この改善により、あなたのサイトがユーザーによってどのように見られ、クリックされているかについて、より詳しい情報を得ることができるようになります。ご質問はヘルプフォーラムまでお願いいたします。

Posted by John Mueller, frequent searcher & Webmaster Trends Analyst, Google Switzerland
Original version: Official Google Webmaster Central Blog: More detailed search queries in Webmaster Tools

2013 年もありがとうございました – 今年のハイライトと人気記事ランキングのご紹介

2013 年も残すところあと数日となりました。今年はウェブマスターのみなさんにとって、どんな 1 年でしたでしょうか？

今年、ウェブマスターセントラルブログでは 50 近くの記事を掲載しました。このことからもわかるように、新たな機能の提供開始、イベントへの参加、Google 検索に関する様々なご案内など、Google サーチクオリティチームにとっても盛り沢山な 1 年となりました。

ここで日本のウェブマスターセントラルでの 2013 年ハイライトをご紹介いたします。

1. Google+ での情報発信をスタートしました
2013 年初めからスタートした Google+ 上での情報発信。今年１年でウェブマスターセントラルの新しい情報発信のチャンネルとして大きく発展しました。2 月からはウェブマスターハングアウトを開始、ハングアウトオンエア形式で Google 社員が最新の情報をご紹介したり、みなさまからのご質問にリアルタイムでお答えしたりと今まで以上にインタラクティブな情報発信を実施しました（今年のウェブマスターハングアウトの録画動画はこちらからご覧ください）。3 月に Google+ 上に開設したWebmaster Japan コミュニティでは、ウェブマスターミニTipsや#ウェブマスタークイズといった人気企画で盛り上がり、メンバー数も 1000 人に迫っています。来年もWebmaster Japan コミュニティを拠点に様々な取り組みを行っていきます。

2. イベントに参加し、多くのウェブマスターの方にお会いできました
2013 年はいくつかのイベントに参加し、ウェブマスターの方に直接お会いしてお話する機会もありました。6 月のウェブマスター一年生のためのホワイトハット SEO、9 月のWordCamp 2013、CSS Nite LP29「SEO 2013」などで多くのウェブマスターの方にお会いし、より良いサポートを提供していく上で非常に貴重なフィードバックをたくさん頂きました。来年も多くのみなさまにお会いできることを楽しみにしています。

3. トップレベルユーザーサミット 2013 を開催しました

9 月 30 日から 10 月 3 日にかけて、米国カリフォルニア州サンノゼ、およびマウンテンビューの Google 本社にて、「トップレベルユーザーサミット 2013」を開催しました。Google では、豊富な製品知識と経験に基づいて、公式ヘルプフォーラムで多大な貢献をしてくださっている方々を、「トップレベルユーザー」と呼んでいます。今回、日本のヘルプフォーラムからも 7 名のトップレベルユーザーの方がサミットに参加し、プロダクトやフォーラム運営について活発な情報交換をしていただきました。

この他にも、たくさんのハイライトがありましたが、ここで一つ一つをご紹介しきれないため、最後に、 2013 年にウェブマスターセントラルブログで多くのみなさまにお読みいただいた記事をランキング形式でご紹介します。「こんなトピックが話題になったな」と 2013 年を振り返って頂く際の参考にして頂きましたら幸いです。

1 位：「検索エンジン最適化（SEO）クイックチェックシート」が完成しました。あなたのお友達やご家族にもどうぞ！
2 位：検索エンジン最適化 ( SEO ) スターターガイドを更新しました
3 位：Google がお勧めするスマートフォンに最適化されたウェブサイトの構築方法
4 位：スマートフォン向け検索でのランキングの変更について
5 位：レスポンシブ・ウェブデザイン - メディアクエリのパワーを使いこなす

ランキングをご覧になるとお分かりのように、2013 年はモバイル/スマートフォン向けサイトの運営について多くの情報発信を行い、ウェブマスターの方の関心を強く集めた年でもありました。来年以降も情報発信を強化していく予定ですのでぜひブログ等でのアップデートをご確認下さい。

最後になりましたが、2013 年もヘルプフォーラムや Google + コミュニティ、ハングアウトなど、様々な場所でのご参加、フィードバックのご提供ありがとうございました。Google サーチクオリティチームでは、2014 年もますますみなさまのお役に立つ情報を提供できるよう、様々な取り組みを行っていきたいと思います。来年もどうぞよろしくお願い致します。

それではみなさま、よいお年を。

p.s. ウェブマスターヘルプフォーラム、Google+ Webmaster Japan コミュニティでも 2013 年の振り返りポストを行っています。ぜひご覧ください。

Kiyotaka Tanaka, on behalf of Search Quality Team Tokyo

新しいウェブサイト確認 API へ移行しましょう

ちょうど一年前に、Google サービス向けの新しいウェブサイト確認 API （英語）を発表しました。物事をシンプルに保ち、努力をより集中させるために、古い確認 API のサポートを 2014 年 3 月 31 日で終了致します。この変更はウェブサイトの確認方法にのみ関わるもので、他の API への影響はありません。ウェブサイト確認に関するより詳しい情報については、こちらのヘルプセンター記事をご覧ください。

新しい API は他の Google の API と同じライブラリを利用していますので、移行することによって他のアプリやツールとの統合がより簡単になります。移行は簡単です。

好きなプログラミング言語向けの Google API クライアントライブラリをダウンロードします。
サイト確認 API とそのメソッド群について学びます。
OAuth を利用した認証に対応します。
以上です！

もし待ちきれない場合は、このコマンドラインを使ってみてください:

oacurl をダウンロードし、インストールします。
Google アカウントで認証を行います:
$ java -cp oacurl-1.2.0.jar com.google.oacurl.Login \ --scope https://www.googleapis.com/auth/siteverification
確認情報をリクエストします:
$ echo '{ "verificationMethod": "FILE", "site": { "identifier": "http://www.example.com", "type": "SITE" } }' | \ java -cp oacurl-1.2.0.jar com.google.oacurl.Fetch \ 'https://www.googleapis.com/siteVerification/v1/token' \ --content-type JSON -X=POST
ファイルを作成後、ウェブサイトに追加し、確認を行います:
$ echo '{ "site": { "identifier": "http://www.example.com", "type": "SITE" } }' | \ java -cp oacurl-1.2.0.jar com.google.oacurl.Fetch \ 'https://www.googleapis.com/siteVerification/v1/webResource?verificationMethod=FILE' \ --content-type JSON -X=POST
以上です！

この API で、Google サイト確認の実装がより容易になることを願っています。ご質問やご感想はウェブマスターヘルプフォーラムまでお願い致します。

Posted by John Mueller, fan of long command lines & Webmaster Trends Analyst
Original version: Official Google Webmaster Central Blog: Switching to the new website verification API

動画：（ウェブマスターツールを使って）SEO 戦略を立てる方法

あなたの会社では、検索エンジン対策（SEO）の戦略を立てる際に、どこから手を付けたらいいか悩んでいませんか？ウェブサイト、ブログ、または YouTube チャンネルなど、様々なオンラインチャネルを上手に活用する最良の方法はなんでしょう？そんなあなたを、Google がお手伝いします！ 15 分未満で、架空の会社ウェブマスターセントラルを使って、ウェブマスターセントラルブログの SEO 担当者としての SEO の戦略的アプローチを概説します。

SEO 戦略の策定方法についての 15 分間のビデオ
字幕を日本語にしてご覧ください。

この動画では、次のようなトピックを解説しています。こちらをクリックすると、興味のある項目からご覧いただけます。

SEO 戦略を策定する方法

架空の会社「ウェブマスターセントラル」を設定
SEO 戦略の作成

障害を克服する

同様にスライドもご参照ください。

Written by Maile Ohye, Developer Programs Tech Lead
Original version: Official Google Webmaster Central Blog: Video: Creating a SEO strategy (with Webmaster Tools!)

自分が所有していないサイトのコンテンツの URL 削除プロセスを改善しました

インターネット上のコンテンツが変更されたり、削除された際に、検索結果上でもその情報がすぐに反映されると役立つ場合があるかもしれません。今回、Google は公開 URL 削除ツールを改善し、その新しいバージョンの提供を開始しました。今までよりも簡単に、自分が所有していないサイトのコンテンツに生じた変化について検索結果に反映させることをリクエストできます。

このツールは、自分が所有していないサイトのコンテンツの URL の削除手続きに役立ちます。ページからコンテンツが完全に削除されているか、コンテンツが変更されてスニペットとキャッシュの削除を希望する場合にお使いいただけます。もしあなたがそのサイトの所有者であるならば、ウェブマスターツールの URL 削除ツールをご利用いただいたほうがより早く、より簡単です。

ページを検索結果から削除する方法

もしページが完全に削除されている場合、Google 検索からその URL を削除するようにリクエストすることができます。この場合、そのページが適切な HTTP ステータスコード（403, 404, または 410）を返すようになっているか、noindex robots メタタグを設定しているか、robots.txt によってブロックされている必要があります（なお、 robots.txt によるブロックはその URL がインデックスされることを完全に防ぐものではありません）。HTTP ステータスコードは HTTP Header Checker で確認することができます。Google ではソフト 404 エラーもサポートしていますが、明確なステータスコードを返すようにサイトを設定することが望ましいです。

ページを削除する際のリクエスト方法をご紹介します。

ページの URL を入力します。以前のバージョンのツールと同じように、検索結果から削除したいコンテンツの正確な URL を入力してください。正確な URL を見つける方法はこちらをご覧ください。
URL の入力後、分析ツールが、そのページが既に存在していないことを確認します。確認結果をご覧の上、削除をリクエストしてください。
３ステップ目はありません！たった 2 ステップで簡単です。

検索結果上のキャッシュとスニペットを削除する方法

もしページが削除されていない場合は、そのページ上から当該のテキスト（名前など）が削除されている、または更新されていることを Google に伝えることができます。これによって、サイトの情報が Google 検索上で完全に更新されるまで、キャッシュページとスニペットが削除されます（タイトルや掲載順位には影響がありません）。このプロセスでは、ページの URL だけでなく、ページ上に過去には含まれていたけれど現在は削除された単語をリクエスト時に入力する必要があります。キャッシュの削除について詳しくはこちらのヘルプ記事をご覧ください。

更新されたページの URL を入力します。検索結果から削除したいコンテンツの正確な URL を入力してください。正確な URL を見つける方法はこちらからご覧ください。
ページが更新されているか削除されていること、そしてキャッシュとスニペットの情報が古いこと（現在のコンテンツと合致しないこと）を確認してください。
キャッシュやスニペットには残っていて、ページ上では現在削除されている単語を入力してください。参考ブログ記事もご覧ください（英語）。

URL の削除についてより詳しい情報をヘルプセンターでご紹介しています。併せてご覧ください。

また、ご質問がある際は、ウェブマスターヘルプフォーラムまでお寄せください。

Posted by John Mueller, Webmaster Trends Analyst
Original version: Official Google Webmaster Central Blog: Improving URL removals on third-party sites

カノニカル	重複
`example.com/product.php? item=swedish-fish`	`example.com/product.php? item=swedish-fish&category=gummy-candies&price=5-10`