Search Console にアプリ開発者向けの便利な機能をご用意しました

Google 検索のインデックスに登録したアプリ内コンテンツが、どのような検索クエリで何位に表示されているか、人気のあるアプリページはどれか、エラーになっているページはないか、などの情報を取得できれば便利になると思いませんか?このたび改名した Search Console に、アプリ内コンテンツが Google にどのように認識され、検索結果でどのように扱われるかに関する新しいレポートを公開しましたので、お知らせいたします。

Google では Search Console を、コンテンツの形式を問わず検索に関心を寄せるすべての人にとっての包括的な情報源にすることを目指しています。つまり、アプリの所有者や開発者の皆様も、Search Console を検索の統計情報を把握するために役立つ新たなツールとしてご利用いただけます。


アプリを Search Console に追加する

Search Console を開き、アプリ名を android-app://com.example という形式で入力します。データは認証済みのアプリ所有者にだけ表示されるため、Google Play アカウントを使用して、アプリへのアクセス権があることを Search Console に通知する必要があります。Google Play でアプリへのアクセス権がない場合は、アプリの所有者に連絡して Search Console でアプリの確認手続きを行ってあなたを追加してもらってください。

サイトとアプリを関連付ける

App Indexing を機能させるためには、アプリとサイトを関連付ける必要があります。この関連付けはアプリ内コンテンツの認知や掲載順位の向上にも役立ちます。

検索でのアプリ内コンテンツのパフォーマンスをトラッキングする

新しい検索アナリティクス レポートでは、上位クエリ、上位のアプリページ、トラフィックに関する詳細情報を国別に表示できます。また、包括的なフィルタのセットも用意されており、レポートを特定のクエリタイプや地域で絞り込んだり、クリック数、表示回数、CTR、掲載順位でソートしたりすることができます。


検索アナリティクス レポートを使用して、自分が最も重要と考えているアプリ内コンテンツと、実際に検索で表示され最多のクリック数を獲得したコンテンツを比較します。これらが一致していれば、問題はありません。見てもらいたいコンテンツと、ユーザーが必要としていて見つけられたコンテンツが同じであることになります。これらがあまり一致していない場合は、ナビゲーションの再構成や、最も重要なコンテンツを見つけやすくするなどの対応が必要な可能性があります。また、ユーザーに見つけてほしいアプリ内コンテンツへのディープリンクが設定してあるか確認することもおすすめします。

アプリ内コンテンツを確実に Google に登録する

アプリ内コンテンツをインデックスに登録する際にエラーが発生した場合、検索結果にはそのアプリページのディープリンクを表示することができません。クロールエラー レポートで、検出されたエラーの種類と回数を確認できます。

アプリ内コンテンツが Google にどのように認識されているか確認する

あるアプリ URI が機能するかどうかをチェックしたり、そのアプリ URI が Google でどのようにレンダリングされるか確認できるよう、Google ではアプリ用 Fetch as Google ツールのアルファ版を作成しました。このツールは、アプリ内コンテンツとウェブページのコンテンツを比較してコンテンツの不一致などのエラーをデバッグする場合にも便利です。多くの場合、コンテンツの不一致のエラーは、アプリ内のブロックされたリソースや、ユーザーにログインや登録を求めるポップアップなどが原因で発生します。このような問題を確認して解決できるようになりました。




みなさんが所有するアプリの最適化やトラブルシューティングを開始するには、所有するアプリを Search Console に追加する必要があります。App Indexing について詳しくは、デベロッパー サイトで関連する記事をご覧ください。なお、ご不明な点がありましたら、ウェブマスター ヘルプ フォーラムをご利用ください。

"Google Search Console" – ウェブマスター ツールが新しくなりました

Google ウェブマスター ツールは、これまで 10 年近くにわたって、すばらしいウェブサイトを作成し、Google 検索に表示させるためのツールとして、絶え間なく進化を続けてきました。昨年 Google では、このツールをさらに便利なサービスにするため、ウェブマスター ツールをよくご利用いただいているユーザーの皆様がどのような立場で、何を目標とされているかについての調査を行いました。

その結果、従来のいわゆる「ウェブマスター」は、ウェブマスター ツールのユーザーの一部でしかないということがわかってきました。ウェブマスター ツールは、小規模事業主から、SEO の専門家、マーケティング担当者、プログラマー、デザイナー、アプリ デベロッパー、個人のサイト運営者、そしてもちろんウェブマスターまで、さまざまな方々にご利用いただいていたのです。すべての方々に共通していたのは、「作ったものをオンラインで公開したい、Google 検索ですぐに見つかるようにしたい」という気持ちでした。そこで、Google ウェブマスター ツールの名称を Google Search Console に一新し、Google 検索に関心を寄せるすべての方々を対象にサービスを提供することになりました。


今後は Google Search Console としてさらにサービスを充実させて参ります。ウェブマスターの皆様をはじめ、さまざまなタイプのユーザーの皆様に Google Search Console をご利用いただき、検索結果でのコンテンツの表示の診断や改善にお役立ていただければと思います。今回のサービスの変更は、今後数週間で順次公開予定です。ぜひ今後の最新情報にご注目ください。

Google Search Console は g.co/SearchConsole からご利用いただけます。ぜひお試しください!

検索アナリティクス レポートで精度の向上したデータをご覧になれます

ウェブサイトを管理する際は、サイトがどのように検索されるか、コンテンツが Google の検索結果でどのように表示されるかを深く理解する必要があります。このデータはこれまで検索クエリ レポートに表示されており、このレポートはおそらくウェブマスター ツールで最も使用されていた機能でした。Google では長年にわたり、ウェブマスターの皆様から寄せられたフィードバックや機能リクエストに耳を傾けてきました。これまで多くの方々から寄せられていたリクエストとしては、デスクトップ経由とモバイル経由のトラフィックの比較や、多国間での指標の比較、2 つの期間での指標の比較などがありました。

そのような声に応え、Google ウェブマスター ツールの新しいレポート機能である検索アナリティクスを発表しました。検索アナリティクスを利用することで、トラフィックの解析結果を最大限に活用していただけるようになります。

新しい検索アナリティクス レポートでは、サイトの検索データを分類し、さまざまな方法でフィルタリングして、より精度の高い分析を行うことができます。たとえば、モバイル経由のトラフィックを 4 月 21 日のモバイル アップデートの前後で比較して、アップデートがトラフィックに与えた影響を把握するといったことが可能です。

searchanalytics1.png

また、国際化したウェブサイトをお持ちの場合は、自社ブランドが最も多く検索されている国を確認することもできます。指標として「インプレッション」を選択し、ブランド名でフィルタリングして、結果を国別にグループ化すれば、国別に並び替えられたインプレッションのリストを表示できます。

searchanalytics2.png

上記の 2 つの例は、数ある使用例のほんの一部にすぎません。検索アナリティクスではトラフィックの解析を非常に深く掘り下げられるので、ウェブサイトのパフォーマンス向上に向けた最適な意思決定に役立ちます。

検索アナリティクス レポートには従来の検索クエリ レポートと異なる点がいくつかあります。新しいレポートのデータは、以前のデータに比べかなり正確で計算方法も異なります。詳しくは、ヘルプセンターの検索アナリティクスの記事のデータに関する説明をご覧ください。まだ以前のレポートを使用する必要のある方もいると思いますので、今後 3 か月間、以前のレポートも Google ウェブマスター ツールでご利用いただけます。新しいレポートについて詳しくは、ヘルプセンターの検索アナリティクスの記事をご覧ください。

この新しい検索アナリティクス レポートが皆様のトラフィック解析のお役に立てば幸いです。Google ウェブマスター コミュニティからぜひフィードバックをお寄せください。レポートについてご質問がある場合やサポートが必要な場合は、ウェブマスター プロダクト フォーラムでお気軽にご質問ください。

最後になりましたが、検索アナリティクスのアルファ版のテストにお時間を割いていただき、このようなレポートに仕上げるためのお手伝いをしてくださった Trusted Tester の皆様とウェブマスター フォーラムのトップレベル ユーザーの皆様に心より御礼申し上げます。皆様のフィードバックや助言なくして、この機能を完成させることはできませんでした。ご協力ありがとうございました。

古い Webmaster Tools API 廃止のお知らせ

昨年の秋、多くの重要な自動処理の実装に役立つ新しい Webmaster Tools API 提供の開始をアナウンスしました。そしてこのたび、保留となっていた ClientLogin の終了(英語)とともに、2015 年 4 月 20 日に古い Webmaster Tools API (英語)を廃止します。

古い API を利用している場合でも、新しい API への移行は簡単です。新しい API は、メッセージとキーワードの機能を除いて古い API の機能をすべてカバーしています。Python (英語)、Java (英語)、および(コマンドラインに慣れた方のため、およびテストを容易にするために)OACurl (英語)のサンプルを用意しています。加えて、サイトを自動的に追加するためのSite Verification API (英語)も提供しています。 Python を使った検索クエリのダウンロード機能(英語)は当分の間提供を続けますが、今後数か月の間に新しい API に置き換わる予定です。

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

ウェブマスター ツールを利用してリソースのブロックを解除しましょう

ウェブページではデザイン性や機能性を高めるため、画像、CSS ファイル、JavaScript ファイルがよく使われます。このようなリソースがクロールからブロックされると、Googlebot では検索用にページをレンダリングする際にそのリソースを使用できません。そこで Google ウェブマスター ツールでは、ウェブマスターの皆様がこのような問題を特定して解決できるよう、ブロックされたリソースのレポートを導入しました。
このレポートには、サイト上のブロックされたリソース(JavaScript、CSS、画像など)の提供元ホスト名が表示されます。行をクリックすると、ブロックされたリソースの一覧と、そのリソースが埋め込まれているページが表示されます。そこから、ページ コンテンツのクロールとインデックス登録を可能にするために何が必要かを診断、解決する手順に進むことができます。

取得してレンダリングすると、これらのブロックされたリソースがどの程度問題であるかが表示されます。URL の取得とレンダリングをリクエストすると、Googlebot としてレンダリングされたスクリーンショットと一般ユーザーとしてレンダリングされたスクリーンショットの両方が表示されます。これにより、ページが Googlebot から異なって認識されることに大きく影響する問題を、より簡単に特定できるようになります。

ウェブマスター ツールでは、ウェブマスターが関与しうると思われるホストのみを表示するため、現時点では、さまざまなサイトで使用されているホスト(一般的な解析サービスなど)は表示されません。すべての robots.txt ファイルを更新するのは時間がかかるため、ブロックされたときに表示が大きく異なってしまうリソースから開始することをおすすめします。関連する手順について詳しくは、ウェブマスター ツールのヘルプセンター記事をご覧ください。

この新機能が、ウェブサイト上のブロックされたリソースを特定してブロック解除する際に、皆様のお役に立てば幸いです。ご不明な点がありましたら、お気軽にウェブマスター プロダクト フォーラムまでお寄せください。

ウェブマスター ツールでモバイル ユーザビリティが確認できるようになりました

スマートフォンが普及するにつれ、モバイルでの閲覧に対応したサイトを作ることは、ますます重要になってきています。今回は、先日ウェブマスター ツールに追加されました、モバイル ユーザビリティを確認できる機能をご紹介いたします。

この新機能によって、あなたのサイトがモバイルで閲覧される際に問題となりうる点が表示されるようになりました。進捗を確認するために、時系列でのグラフもついています。

ここでは、スマートフォンでの閲覧の際、上下のスクロールのみによって簡単に読むことのできるサイトをモバイル フレンドリーと定義しています。左右へのスワイプやズームイン、ズームアウトが必要となる場合、スマートフォンで気軽に閲覧することは難しくなってしまいます。ここで指摘される問題は以下のようなものです。
これらの問題がウェブマスター ツール内で表示されている場合、ぜひ解決法を探ってみてください。テンプレートを変えるだけで直ってしまうこともままあります。詳しい情報は、モバイルガイドを御覧ください。

ご不明な点やご質問がありましたら、ウェブマスター ヘルプ フォーラムまでお寄せください。

App Indexing の実装に不可欠な 4 つのステップ

ディープ リンクは、オーガニック検索内で最近見かけるようになった「新入り」ですが、目を見張るような速さで普及しています。ユーザーがログインしている場合、Android での Google 検索結果のうち、15% が App Indexing によるアプリ ディープ リンクを表示しています。前四半期だけで、アプリ ディープ リンクのクリック数が 10 倍に急増しました。

App Indexing を今年 6 月に公開して以来、デベロッパーの皆様からさまざまなフィードバックが寄せられました。ほとんどの実装はうまく行きましたが、うまく行かなかった実装からも多くを学ぶことができました。この記事ではそうした経験を踏まえ、App Indexing の実装を成功させるうえで欠かせない 4 つのステップについて解説します。また、アプリのパフォーマンスを把握したり、アプリの利用を促進したりするための便利な新機能も紹介します。

1. デベロッパーにウェブマスター ツールへのアクセス権限を付与する

App indexing は、ウェブマスターとアプリ デベロッパーが協力して取り組む必要があります。ウェブマスター ツールには、デベロッパーが必要とする情報も表示されます。現時点で表示されるのは以下の情報です。
  • アプリ内のインデックス登録済みページのエラー
  • Google 検索でのアプリ ディープ リンクのクリック数とインプレッション数(週単位)
  • サイトマップに関する統計情報(アプリ ディープ リンクをサイトマップで実装した場合)
今後これらの他にもさまざまな情報を追加する予定です。

しかしながら、ウェブマスター ツールへのアクセスが許可されているデベロッパーは非常に少ないようです。アプリ関連の問題の修正に必要な情報を確実に伝達するには、デベロッパーにウェブマスター ツールへのアクセス権限を付与することが不可欠です。

確認済みのサイト所有者であれば、新しいユーザーを追加できます。付与したい権限レベルに応じて [制限付き] または [フル] を選択してください。

2. 検索結果からのアプリへのアクセス状況を把握する

ユーザーは、検索結果からアプリにアクセスしてくれているでしょうか。アプリ ディープ リンクのパフォーマンスをトラッキングする方法として次の 2 つを追加しました。
  • ウェブマスター ツール アカウントのメッセージ センターに、週ごとのクリック数とインプレッション数が送信されるようになりました。
  • アプリ ディープ リンクによってどれくらいのトラフィックがアプリにアクセスしたかを、リファラー情報(具体的には ACTION_VIEW インテントのリファラー extra)を使用してトラッキングできるようになりました。将来的には、この情報を Google アナリティクスに統合して簡単にアクセスできるようにする予定です。デベロッパー サイトでは、リファラー情報をトラッキングする方法(英語)について解説しています。

3. アプリの重要なリソースがクロール可能であることを確認する

ウェブマスター ツールのクロール エラー レポートで、「コンテンツの不一致」エラーが発生する大きな原因の 1 つがリソースのブロックです。クロールでは、アプリ ページをレンダリングするために必要なすべてのリソースにアクセスする必要があります。これにより、アプリ ページのコンテンツが、関連付けられているウェブページと同じかどうかを確認できます。

アプリ ページのレンダリングに不可欠なリソースにアクセスできない場合に、どのリソースがブロックされているかを簡単に特定できるようになりました。アプリで「コンテンツの不一致」エラーが発生した場合は、詳細ダイアログの手順 5 に沿ってブロックされているリソースの一覧を確認してください。

4. Android アプリのエラーに注意する

アプリのインデックス登録時のエラーを簡単に特定できるようにするため、検出されたすべてのアプリ エラーをメッセージとして送信することになりました。また、そのほとんどがクロール エラー レポートの [Android アプリ] タブにも表示されます。

従来の「コンテンツの不一致」エラーと「インテント URI が無効」エラーに加え、以下の 3 つのエラー タイプを追加しました。
  • APK が見つからない: アプリに対応するパッケージが見つからない
  • First Click Free(英語) がない: アプリへのリンクがコンテンツに直接つながっておらず、ログインしないとアクセスできない
  • 戻るボタンの違反: アプリへのリンクをたどって移動した後、戻るボタンで検索結果に戻ることができない
これまでの経験から、エラーの大部分はアプリの一般的な設定が原因であることがわかっています(リソースがブロックされている、ユーザーが検索結果からアプリを開こうとすると地域選択のポップアップが表示されるなど)。これらの点に注意することで、関連する URI の問題をすべて解決できるはずです。

App Indexing 実装がうまく行くことを願っています。ご不明な点がありましたら、いつでもウェブマスター ヘルプ フォーラムまでお寄せください。

Webmaster Tools API を更新しました

夏の間、ウェブマスター ツール チームは Webmaster Tools API (英語)の更新に取り組んできました。この新しい API は、他の Google API と統一されており、アプリやウェブ サービスの認証がより簡単に行えるようになりました。また、API からウェブマスター ツールのいくつかの主な機能にアクセスすることもできます。

他の Google API を使用したことがあるなら、この新しい Webmaster Tools API も簡単に使い始めることができるでしょう。Python (英語)、Java (英語)、および(コマンドラインに慣れた方のために)OACurl (英語)のサンプルを用意しています。
この API では次のことができます。
  • サイトの表示、追加、削除(現時点では、アカウントに最大 500 件のサイトを追加できます)
  • サイトマップの表示、追加、削除
  • 個々のサイトマップについて、警告、エラー、インデックス登録数の取得
  • サイトについて、すべての種類のクロール エラーを時系列で取得
  • 特定の種類のクロール エラーについて、サンプルを表示
  • クロール エラーを個別に「修正済み」にする(処理には影響を与えませんが、画面表示をシンプルにできます)
この API をどうぞご活用ください。API の使用に関して不明な点がありましたら、お気軽にヘルプ フォーラムでご質問ください。

robots.txt ファイルのテストが簡単になりました

クロールするべきか、しないべきか、それが robots.txt の問題です。

正しい robots.txt ファイルを作成して維持することは、ときに難しい場合もあります。ほとんどの場合はそうではありませんが(そもそも robots.txt ファイルを必要としないサイトも多くあります)、大きな robots.txt ファイル内で個々の URL をブロックしている(またはブロックしていた)指定を見つけることは、難しい作業となる場合もあるでしょう。そこで、robots.txt ファイルの編集を容易にするために、このたび、新しい robots.txt テスターを発表いたします。

新しいテスターは、ウェブマスター ツールの [クロール] セクションにあります:


ここでは、現在の robots.txt ファイルの確認、および URL のクロールがブロックされているかどうかのテストを行うことができます。複雑な指定をわかりやすくするため、最終的に決定に使われた箇所がハイライト表示されます。ファイルに変更を加えてテストを行うこともできます。変更を有効にするには、変更したファイルをサーバーにアップロードしてください。Google のデベロッパー サイトでは、robots.txt の指定とファイルの処理方法について詳しく説明しています (英語)。

また、古いバージョンの robots.txt を確認したり、サーバー側の問題によってクロールがブロックされている状況を確認したりすることもできます。たとえば、robots.txt ファイルが Googlebot に対して 500 サーバー エラーを返している場合、通常そのサイトのクロールは一時停止されます。

既存のサイトでエラーや警告が表示される可能性もあるため、robots.txt ファイルをよく確認することをおすすめします。また、robots.txt テスターをウェブマスター ツールの他の機能と組み合わせることも可能です。たとえば、新しい Fetch as Google を使用してウェブサイトの重要なページをレンダリングした際、ブロックされた URL が見つかったら、robots.txt テスターを使って、その URL をブロックしている指定を見つけて修正することができます。CSS、JavaScript、モバイル コンテンツをブロックする古い robots.txt ファイルが原因で問題が発生することはしばしばありますので、そのような問題は、修正すべき箇所がわかれば簡単に修正できます。

今回更新したツールを使うことで robots.txt のテストとメンテナンスが容易になれば幸いです。何かご不明な点がある場合や、robots.txt の指定の作成についてアドバイスが欲しい場合などは、ぜひウェブマスター ヘルプ フォーラムをご利用ください。

ウェブマスター ツールで hreflang のアノテーションに関するトラブルシューティングができるようになりました

複数の国のユーザーをターゲットとしているウェブマスターの方は、rel-alternate-hreflang について耳にされたことがあるかと思います。まだこの機能をご存知でない方のために簡単にご説明しますと、このアノテーションにより Google などの検索エンジンが適切な言語や地域のバージョンのページを検索ユーザーに表示できるようになり、結果としてユーザーの満足度の向上につながります。

実装したこのアノテーションが検索エンジンで使用できる状態であるかどうかを確認することは、特にページが多くあるサイトでは容易ではなく、この点については世界中のサイト運営者の方から声が上がっています。そこで Google では本日、rel-alternate-hreflang アノテーションのデバッグを簡単に行うことができる機能を公開します。

[インターナショナル ターゲティング] 機能の [ターゲット言語] セクションで、hreflang アノテーションによく見られる 2 つの問題を特定できます:
  • リターン リンクの欠落: アノテーションは、そのアノテーションが参照しているページから確認する必要があります。ページ A がページ B にリンクしている場合、ページ B からもページ A にリンクしていなければなりません。そうでない場合、アノテーションが正しく解釈されない恐れがあります。
    この種のすべてのエラーについて、検出した場所と日時、リターン リンクが配置されるべき場所が表示されます。
  • 不適切な hreflang 値: hreflang 属性の値は、ISO 639-1 形式で指定した言語コード(「es」など)か、国コード(ISO 3166-1 Alpha 2 形式で指定)と言語コードの組み合わせ(「es-AR」など)のいずれかである必要があります。
    Google のインデックス登録システムがこれらの形式以外で指定された言語コードや国コードを検出した場合は、URL の修正例が表示されます。

さらに、地域ターゲットの設定をウェブマスター ツールのこの機能に移行し、インターナショナルおよび多言語ターゲティングに関連するすべての情報を 1 か所で確認できるようにしました。

この新機能が、サイトでの rel-hreflang 実装に関する問題を解決する際の一助となりましたら幸いです。この機能についてご不明な点やご意見、ご感想などがありましたら、ウェブマスター ヘルプ フォーラムにご投稿ください。

Android の App Indexing が誰でもご利用いただけるようになりました!

もしあなたがウェブサイトと Android アプリを両方持っているのなら、それらを連携させることで、スマートフォンやタブレットから Google で検索しているユーザーにとって、検索結果からアプリへの起動を非常に簡単にすることができるようになりました。

検索結果に表示されるアプリのディープリンクは、あなたのアプリが既にインストールされている端末の検索結果において、アプリ内のコンテンツへのアクセスをより容易にします。ウェブサイトのページを対応するアプリ側の部分へと接続することで、サイトオーナーとして、適切なコンテンツを、適切なタイミングでユーザーに見せることができるようになります。


いくつものアプリが既に App Indexing を実装しています。今週の Google I/O で、ディープリンクの設定、サイトのアプリへの接続、パフォーマンスやエラーのトラッキングといった一連のプロセスをより容易にするための機能を発表いたしました。

簡単に始められます

このたび、アプリのディープリンクをインデックスさせるために必要なプロセスを大きく簡易化しました。アプリが既に HTTP によるリンクをサポートしているのであれば、
あなたの URL 群がインデックスされると共に、Google はアプリとサイトの繋がりを発見し、検索結果でディープリンクを使用したアプリへの直接的な遷移を可能にします。

アプリのディープリンクの発見とインデックス作業を Google に任せることもできますが、あなた自身がこれらのディープリンクを埋め込み、公開することをおすすめします。もしあなたのアプリがカスタム ディープリンクスキームをサポートしている場合は特にそうです。そのためには、2 つの方法があります:
  • 各ウェブページに対して、rel="alternate" 属性を持った link 要素を <head> 部分に埋め込むか、サイトマップを利用して android-app URI を指定する。デベロッパー サイト上で実装方法を確認できます。
  • App Indexing API (英語)を利用する。
また、このたび、アプリページをインデックスする際に発生した問題について報告を行う新しい機能をウェブマスター ツールに追加しました。ここでは、各アプリページとウェブページのペアについて検知されたエラーと、デバッグのためのサンプル アプリ URI確認することができます。


また、それぞれの問題について、その詳細なデバッグ方法も確認することができます。アプリのディープリンクの QR コードも含まれていますので、携帯電話やタブレットで簡単にリンクを開けます。エラーが検知された場合、ウェブマスター ツール上でメッセージもお送りいたします。


App Indexingは既に日本のデベロッパに導入されており、たとえば次のようなアプリですでに実装されています。


ぜひ App indexing をお試しください。何かご質問があれば、ウェブマスター ヘルプ フォーラムへ!

サイトの移転をより容易に

ウェブマスターの皆様にとって、サイトの移転ほど厄介で悩ましい問題はないかもしれません。このたび Google では、スムーズなサイト移転をサポートすることを目的に、Googlebot と相性の良い移転の方法についての詳細なガイドを作成しました。では、サイト移転とは正確には何であり、それを適切に行うにはどうすればよいのでしょうか。


サイト移転の基本


一般的に、サイト移転とは、以下のいずれかの方法でコンテンツを移動させることです。
  • URL を変更せずにサイトを移転する: URL 構造には変更を加えずに、ウェブサイトをホストしている基底のインフラストラクチャのみを変更します。たとえば、www.example.com を、同じ URL とサイト構造を維持したまま別のホスティング プロバイダに移行する場合などがこれにあたります。
  • URL を変更してサイトを移転する: この場合、ウェブサイトの URL の変更にはさまざまなパターンがあります。
  • プロトコル: http://www.example.com を https://www.example.com に変更する
  • ドメイン名: example.com を example.net に変更する
  • URL のパス: http://example.com/page.php?id=1 を http://example.com/widget に変更する
サイトの移転が適切に行われていないケースや、サイトの移転を問題なく完了するうえで非常に重要となる手順が踏まれていないケースも多く見られます。そこで Google では、ウェブマスターの皆様が適切にサイトの移転を計画、実施できるよう、ヘルプセンターのサイト移転ガイドラインを更新しました。また同時に、このガイドラインに沿ってサイトの移転が行われた場合にサイトの移転を検出して処理できるよう、クロールとインデックス登録のシステムの改良も続けています。

レスポンシブ ウェブ デザインへの変更


モバイル用の URL を別に設定している場合や動的配信を行っている場合にウェブサイトでレスポンシブ ウェブ デザインを使用するよう変更するにはどうすればよいか、といった質問も増えつつあります。この設定の変更について詳しくは、スマートフォン向けサイトの推奨事項についてまとめたサイトに新たに追加されたこちらのページをご覧ください。

ご不明な点がある場合はウェブマスター ヘルプ フォーラムで質問してみてください。

「Hosting Meetup @ Google」を開催しました!

Google は 5 月 15 日、ホスティング サービスの運営者のみなさまを対象にしたイベント「Hosting Meetup @ Google」を開催しました。今回は、そのイベントの様子をご紹介します。


ブログなどのホスティング サービスは、低コストで簡単に利用できることから広く利用されています。一方で、その利便性を悪用し、Google のウェブマスター向けガイドラインに違反するようなスパム目的に利用されるケースがあることもわかっています。

今回のイベントは、こうした背景から、Google 検索と相性のよいホスティング サービスの運営について考えることを目的として実施しました。

当日は、ウェブマスター ツールや構造化データ、複数デバイス対応などに関して、Google 検索と相性の良いホスティング サービス運営のためのヒントのご紹介と、ホスティング サービス上でよく見られるウェブマスター向けガイドライン違反(ウェブ スパム)について、その傾向や対処方法などをお話しました。



ホスティング サービスからウェブ スパムがなくなり、かつ、Google 検索と相性の良いサイト構築を心がけていただくことで、Google がホスティング上のサイトを見つけやすくなり、より多くの検索ユーザーがそうしたサイトを訪問する可能性が高まります。

そのための具体的なアクションとしては、

ウェブ スパムの削減について関連ヘルプ記事
  • スパム ポリシーの制定・見直し
  • スパムへの対処(サイトの自動生成の禁止。Captcha の導入、違反箇所の修正方法、スパム サイトへの対処方法など)
  • ユーザーへの啓蒙
  • ウェブマスター ツールをユーザーが利用できるようにする
Google と相性の良いサイトの構築のヒント
  • ウェブマスター ツールの活用
  • 構造化データの導入
  • 適切な複数デバイス対応
こういった内容をぜひサービスの運営に取り入れていただき、Google 検索と相性のよいサービスの運営を行っていただければと思います。

ホスティング サービスの運営者の方々からも Google のウェブマスター向けガイドラインについてのご質問や、スパムへの対処方法のベスト プラクティスについてのご質問など、数多くのご質問をいただき、非常に有意義な意見交換をすることができました。

ご参加いただきましたみなさま、ありがとうございました!


また、今回イベントに参加できなかったホスティング サービスのみなさまのために、同一の内容をテーマとしたウェブマスター ハングアウトを実施いたしますので、ぜひご参加ください。

イベント詳細
2014 年 6 月 10 日 12 時 ~ 12 時 30 分

あわせてホスティング サービスの運営者のみなさまを対象とした情報をまとめたサイトを設けました。今回のイベントでお話した内容や、関連する情報についてまとめて掲載しておりますのでぜひご覧ください。

今後も、ウェブマスター ハングアウトやGoogle+ Webmaster Japan コミュニティなどを通してウェブマスターのみなさまの疑問にお答えしたり、交流を図っていきたいと思いますので、ぜひご参加ください!

Google サーチ クオリティ チーム

Fetch as Google でページをレンダリングできるようになりました

ウェブマスター ツールの Fetch as Google 機能を使用すると、Googlebot がどのようにページを取得しているかを確認できます。ここで表示されるサーバー ヘッダーや HTMLは、技術的問題やハッキングの影響を診断するのに役立ちますが、その理解が難しい場合もあるでしょう。「このコードの意味は何?」、「本当に自分のブラウザで見ているのと同じページなんだろうか?」「今日の昼ごはんはどこで食べよう?」...。昼ごはんをどこで食べるかについてはお助けできませんが、他の問題を解決するために、このたび Google はウェブマスター ツールを拡張し、Google がページをどのようにレンダリングしているかを確認できるようにしました。

レンダリングされたページを表示する

Googlebot は、ページをレンダリングする際、そのページに関係するすべての外部ファイルをできるだけ見つけて取得しようとします。その際、画像、CSS、JavaScript ファイルだけでなく、CSS や JavaScript によって間接的に埋め込まれるファイルも取得した上で、Googlebot のページ認識のプレビュー画像を描画することになります。

Fetch as Google 機能は、ウェブマスター ツールの [クロール] セクションにあります。[取得してレンダリング] をクリックして URL を送信して処理が完了するのを待ちます(ページによっては少し時間がかかる場合があります)。処理が完了したら、表示された行をクリックして結果を確認します。


robots.txt によってブロックされたリソースの取り扱い

Googlebot は、すべてのファイルを robots.txt の指示に従って取得します。クロールを許可していないファイルがある場合(または、Googlebot のクロールが許可されていないサードパーティ サーバーからファイルを埋め込んでいる場合)、そのファイルはレンダリング時に利用できません。同じように、サーバーが応答しない場合やエラーが返された場合も、それらのファイルを利用することはできません(こうした問題の詳細は、ウェブマスター ツールの [クロール エラー] セクションで確認できます)。こうした問題が発生した場合は、プレビュー画像の下に詳細が表示されます。

サイトに表示されるコンテンツやそのレイアウトに大きく影響する埋め込みリソースについては、Googlebot がアクセスできるかどうかを確認しておくことをおすすめします。Fetch as Google が使いやすくなるだけでなく、Googlebot がそれらのコンテンツを見つけてインデックスに登録することが可能になります。サイトに表示されるコンテンツやそのレイアウトにあまり影響しない一部のコンテンツ タイプ(ソーシャル メディア ボタン、フォント、ウェブサイト分析スクリプトなど)は、クロールできない状態のままでも構いません。詳しくは、以前ブログに投稿した「ウェブページをより深く理解するようになりました」という記事をご覧ください。

今回のアップデートによって問題の診断が容易になり、誤ってクロールがブロックされていたコンテンツが発見され、クロールされるようになることを願っております。ご不明な点やご意見などありましたら、ウェブマスター ヘルプ フォーラムまでお寄せください。

「構造化データ」がよく分かる!初心者向け徹底解説

SEOの文脈においても頻繁に話題になる「構造化データ」。意外にそこまで詳細に理解されている方は多くないのでは?と思います。ここでは構造化データやリッチスニペットの概要から、HTMLでの記述方法、テストツールなど、全体像を掴んで頂ければと思います。今回はコンサル部門サブマネージャーの巣鷹による執筆。

目次

セマンティックWebについて
構造化データとは
構造化データを使用するメリット
ボキャブラリーとシンタックス
構造化データをマークアップする方法
HTML上で直接マークアップする方法
データ ハイライターを用いる方法
テストツールのご紹介
まとめ

セマンティックWebについて

構造化データとセマンティックWebという考え方は切っても切り離せないものです。今回は構造化データを説明する前にセマンティックWebというものに簡単に触れておきたいと思います。

「セマンティックWeb」は、例えば以下のように説明されています。

Webページおよびその中に記述された内容について、それが何を意味するかを表す情報(メタデータ)を一定の規則に従って付加することで、コンピュータが効率よく情報を収集・解釈できるようにする構想。インターネットを単なるデータの集合から知識のデータベースに進化させようという試みがセマンティックWebである。
引用元:http://e-words.jp/w/E382BBE3839EE383B3E38386E382A3E38383E382AFWeb.html

コンピュータ(検索エンジン)は従来、テキストを単なる”文字”として認識し情報として蓄積していました。しかし、それでは検索エンジンは文字を記号としてしか認識することができず、その意味を推し量ることはできません。

そこで、文字を”意味”としてその背景や文脈まで解釈し、それを蓄積していこうというのがセマンティックWebの考え方です。

構造化データとは

セマンティックWebを実現するための手段として、構造化データがあります。構造化データは、言葉に対して意味をメタデータとして持たせることで、ロボットがそのもつ内容の解釈を容易にし、検索エンジンはより有用な検索結果をユーザーに提供できるようになります。

わかりづらいので例を。例えば、以下のような例を考えます。

--</pre>
<div>私は土居 健太郎 (天照SEO)です。</div>
<pre>
--

私達がこれを見た時に、この人は土居健太郎という”名前”の人物で、天照SEOという”ニックネーム”を持っているのだとある程度推測することができます。

検索エンジンもその推測ができないわけではありませんが、これを明確にニックネームだと定義することは難しいのです。そこで、そうした情報の「意味」を検索エンジン等に明確に伝えてあげましょうというのが構造化データの考え方です。

構造化データはHTMLに直接マークアップする、もしくはウェブマスターツール上で設定しますが(設定方法は後述します。)、上述した土居健太郎の例でいうと以下のような記述となります。

--</pre>
<div itemscope="" itemtype="http://schema.org/Person">私は<span itemprop="name">土居 健太郎</span> (<span itemprop="nickname">天照SEO<span itemprop="nickname">)です。</span></span></div>
<pre>
--

nameやnicknameという値が含まれているのが御覧頂けるかと思いますが、特定の情報に対してHTMLマークアップを行う(メタデータを付与する)ことでその情報の説明が付与することができるようになります。

構造化データを使用するメリット

検索エンジンがサイトコンテンツの把握を容易に行えます

上述した通り、特定のテキストあるいは画像がどういう情報なのかを指し示すことで、検索エンジンはコンテンツの内容がどういう意味を持つものか、容易に把握できるようになります。

構造化データを用いることで、前述した文章は、「私の名前は土居健太郎で、ニックネームは天照SEOです」のように、情報の持つ意味がより明確に検索エンジンに伝わり、適切に認識されるようになります。

リッチスニペットが表示されます

通常の検索結果においてサイトが表示される際には青色のリンク、その下meta descriptionやサイト内テキストから引用したスニペットが表示されますが、構造化データを用いることで、リンクの下に通常とは異なる情報が表示されることがあります。これを「リッチスニペット」と言います。

リッチスニペットの画像

こういった検索結果を見たことがある方は多いのではないかと思います。

これにより検索結果で目につきやすくなり、クリックされやすくなるなどのメリットがあります。リッチスニペットに対応されているコンテンツは、上の画像のレビュー情報やレシピ、筆者情報以外にも音楽や映画、イベント、パンくずなどがあります。

ボキャブラリーとシンタックス

構造化データを理解する上で、この2つの言葉についてきちんと理解しておく必要があります。

ボキャブラリー

冒頭の例では文章全体に”http://schema.org/Person”という値を、土居健太郎に”name”、天照SEOに”nickname”という値を付けました。その指定する値を定義している規格のようなものがボキャブラリーです。

ボキャブラリーの代表的なものにschema.orgがあります。schema.orgはGoogle、yahoo!、Microsoftの大手検索エンジン企業が共同で取り組んでおり、値の数は日々拡張されています。

先ほどの例では人物の説明でしたが、人物の説明には名前やニックネームはもちろんのこと、所属する団体や誕生日なども情報として持つことがあるかと思います。そういった部分もある程度網羅されており、こちらのページ(※リンク先は英語です)にてまとめられています。propertyという欄で人物の説明に対してマークアップ可能な値が表示されています。

なお、schema.orgで構造化データマークアップに対応している情報のタイプはこちらでまとめられています。実際にHTMLをマークアップする際にはこれらの中からコンテンツに合致するタイプを選択し、実装します。
※マークアップしたい項目について、リンク先に利用可能な値が記載されています。

また、見て頂くとわかるかと思いますが、プロパティは階層構造となっています。

例えば「Thing(もの)」という大項目の子として「Book(本)」や「Event(イベント)」という項目、「Event(イベント)」の子として「BusinessEvent(企業向けイベント)」といった階層を形成しています。

シンタックス

ボキャブラリーは値を定義しているだけのものですので、HTMLにマークアップする際にはどうマークアップするかの仕様が必要ですが、その仕様がシンタックスです。

--</pre>
<div itemscope="" itemtype="http://schema.org/Person">私は<span itemprop="name">土居 健太郎</span> (<span itemprop="nickname">天照SEO<span itemprop="nickname">)です。</span></span></div>
<pre>
--

ちなみにこの文章でいうとitemscopeやitemtypeの部分がシンタックスで決められている仕様です。

シンタックスには代表的なもので以下の4つがあります。

  • Microdata
  • RDFa
  • Microformats
  • JSON-LD

Googleが推奨しているのはMicrodataです。

また、JSON-LDはHTML上で各情報に直接マークアップするその他のシンタックスとは異なり、スクリプトを用いて記述するため、各データに直接マークアップする必要がなく、一箇所で構造化データを記述できるとぃう利点があります。

先ほどの例

再度、土居健太郎の例を用いて詳しく見てみましょう。
※以下の例はボキャブラリーにschema.orgとシンタックスにMicrodataを用いています。

--</pre>
<div itemscope="" itemtype="http://schema.org/Person">私は<span itemprop="name">土居 健太郎</span> <span itemprop="nickname"> (天照SEO) <span itemprop="nickname">です。</span></span></div>
<pre>
--

1. itemscope
itemscopeという属性がdivに付与されています。これはこのdivに構造化データが付与されているということを意味します。

2. itemtype
itemtypeはitemscopeで示された構造化データが何に関するものなのかを示すために用います。上述したデータでいうとhttp://schema.org/Person という人物を表す値が用いられているためdiv内の情報が人物を表す情報であると確認できます。

人物以外にも組織や会社を表すhttp://schema.org/Organization や、商品であればhttp://schema.org/Product などが定義されています。

3. itemprop
itempropはitemtypeで示された人物や組織・会社などの詳細な情報を示すために用いられます。

上の例ではdivに対してitemtypeで人物の情報であると提示されているので、itempropがnameと指定されているspan内の情報は、人物の名前であることが読み取れます。また、その次のnicknameが記載されているspanはニックネームを表しています。

構造化データをマークアップする方法

構造化データを検索エンジン(Google)に伝える際には大きくわけて2つの方法があります。

  • HTML上で直接マークアップする方法
  • データ ハイライターを用いる方法

前者のHTMLに直接マークアップする方法は文字通り上述した土居の例のようにHTMLタグに構造化データの要素を追加します。

一方でデータ ハイライターを用いる場合、ウェブマスターツールのページ上でクリックすることによりページの構造化データを(HTMLをいじることなく)Googleに伝えることが可能です。

Googleヘルプには以下のように書かれています。

■HTML の使用が適しているケース:
・サイト上のイベント、レシピ、その他の各種データの Google による認識方法を明確にコントロールしたい場合。
・HTML マークアップを一貫してすべてのデータ項目に追加できる場合。
・サイトの構造が頻繁に変わる場合。
・Google 以外の検索エンジンでもウェブサイトのコンテンツが認識されるようにしたい場合(データ ハイライターで抽出されたデータを利用できるのは Google のみです)。

■データ ハイライターの使用が適しているケース:
・サイトで表示するデータが、イベントに関するものである場合。
・サイトで構造化データやリッチ スニペットを使用することを検討しているが、HTML マークアップを更新するためのリソースの準備がまだできていない場合。
・HTML マークアップを記述するよりも、ウェブページをポイントしてクリックするほうがよい場合。
・サイトで HTML マークアップを変更できない、またはデータ項目を一貫してマークアップできない場合。
引用元:https://support.google.com/webmasters/answer/99170?hl=ja

どちらの方法もメリット・デメリットがありますので、運営されている体制やサイトの状況などにより、どちらを使うか検討することが望まれます。

ではそれぞれ実際に説明していきましょう。

HTML上で直接マークアップする方法

この方法には大きく分けて二つあります。それぞれ説明します。

ボキャブラリーとシンタックスを参考にHTMLにマークアップしていく方法

今回はボキャブラリーにschema.orgとシンタックスにMicrodataを用いてマークアップする方法を紹介します。

一般的に構造化データがマークアップされている情報は人物や商品、パンくずが多いですが、こちらにまとめられている通り、マークアップできる情報は他にも沢山あります。

今回は以下の文章について考えてみましょう。

--</pre>
<div>ヴォラーレ株式会社は五反田に位置する企業です。2007年1月15日に高橋飛翔が創業しました。企業情報はこちらのサイトから御覧ください。<a href="”">http://www.volare.jp/</a></div>
<pre>
--

①まずはitemscopeを入れましょう。

上述した通り、構造化データであることを示すはじめの一歩はitemscopeを該当するタグに入れることです。

--</pre>
<div itemscope="">ヴォラーレ株式会社は五反田に位置する企業です。2007年1月15日に高橋飛翔が創業しました。企業情報はこちらのサイトから御覧ください。<a href="”">http://www.volare.jp/</a></div>
<pre>
--

②itempropで何を示している情報なのかを指定しましょう。

今回はヴォラーレ株式会社の情報ですので、itemtypeで企業情報であることを示すhttp://schema.org/Corporationを用います。

--</pre>
<div itemscope="" itemtype="http://schema.org/Corporation">ヴォラーレ株式会社は五反田に位置する企業です。2007年1月15日に高橋飛翔が創業しました。企業情報はこちらのサイトから御覧ください。<a href="”">http://www.volare.jp/</a></div>
<pre>
--

これでこのテキストは企業に関する情報であることをマークアップできました。

③itempropを使って各情報についてそれぞれマークアップしていきます。
企業に関する情報の際に使えるitempropはこちらのページで挙げられています。マークアップしてみると以下のようになります。

--</pre>
<div itemscope="" itemtype="http://schema.org/Corporation"><span itemprop="”name”">ヴォラーレ株式会社</span>は<span itemprop="”lacation”">五反田</span>に位置する企業です。<span itemprop="”foundingDate”">2007年1月15日</span>に<span itemprop="”founder”">高橋飛翔が創業しました。企業情報はこちらのサイトから御覧ください。<a itemprop="”URL”" href="”">http://www.volare.jp/</a></span></div>
<pre>
--

「ヴォラーレ株式会社」は企業名なので「name」を、「五反田」は住所にあたるので「lacation」を、その他創業日や創業者、コーポレートサイトへのURLもマークアップしています。

構造化データマークアップ支援ツールを用いた方法

ウェブマスターツールには、構造化データマークアップを支援する機能があります。

先に説明した方法だとschema.orgなどを理解した上でマークアップする必要がありましたが、こちらの方法はそれよりも容易に構造化データを用いることが可能になります。

ここでは弊社の開発室が運用しているブログを用いて説明します。

①構造化データマークアップ支援ツールに該当するページのURLを入力し、今回マークアップするデータを選択した上でタグ付け開始をクリックします。

構造化データマークアップ支援ツールの画面「

今回はブログ記事のマークアップですので、記事を選択しました。

②実際にマークアップしてみましょう。

ブログ記事ページイメージ

タグ付けはツール内でページが読み込まれた画面で行います。右にタグ付けできるデータが並びます。この例で言うと、前の画面で記事を選んだため、著者や公開日など、記事に関連するデータが並んでいます。

ではまず一番上にある「名前」(今回の場合は記事タイトルです)をマークアップしてみましょう。

タイトルがハイライト

タイトルに当たるところをドラッグすると、選択肢が出てきますのでそこから「名前」を選択しますと右側にマークアップしたいテキストもしくは画像が追加されます。著者情報や公開日なども 同様の要領で指定していきます。

データの指定が終わったら右上にある「HTMLを作成」をクリックするとそのページのHTMLが出力されます。

イメージ

③出力されたHTMLをサイトに反映させます。
どういったサイト運用をされているかにもよりますが、出力されたHTMLでマークアップされた部分(黄色くハイライトされています)、もしくはソース全てをコピーしてHTMLを実装しましょう。これでマークアップは完了です。

データ ハイライターを用いる方法

データハイライターを用いた場合には 直接HTMLをいじる必要がなく、構造化データマークアップ支援ツールのようにブラウザ上でクリックすることで構造化データをGoogleに伝えることが可能です。

①ウェブマスターツールでデータハイライターを開きます。

データハイライター画面

ハイライト表示を開始しましょう。

ハイライト表示

先ほどと同様に構造化データを設定したいURLを入力し、タイプを選択します。今回は天照SEOブログを用いますので、タイプに「記事」を選択しました。

また「このページをタグ付けし、他のページも同様にタグ付けする」の場合は(幾つかのサンプルページにてタグ付けを行うことで)同様のページ群もGoogleが学習して構造化データを認識してくれるようになります。一方で「このページだけをタグ付けする」場合はGoogleに学習させず選択したページのみをタグ付けしたい場合に用います。

ブログ記事のように同じようなページ群がある場合には前者、そうでない場合には後者が望まれると思います。
今回はブログ記事ですので前者を選択しました。

②タグ付けを行います。

アイテムを選ぶ

上述した構造化データマークアップ支援ツールと同様に、タグ付けしたいところをクリックもしくはドラッグし、タグ付けするデータを選択します。タグ付けが終了したら右上の「完了」を選択しましょう。

③Googleに自動でタグ付けして欲しいページを選択します。
※この選択肢は「このページをタグ付けし、他のページも同様にタグ付けする」を選択した場合にのみ表示されます。

ページセットの作成画面

左の項目ではGoogleが同様だと判断したページ群が選択肢として表示されます。それでは問題がある場合は「カスタム」で設定しましょう。※ページ群の設定は正規表現で行います。

これらを選択したら「ページセットを作成」に進みましょう。

④サンプルページで上手く設定できているか確認します。

確認画面

Googleは最初にタグ付けした設定から他のページでも同様の構造化データをタグ付けします。このページでは③で選択した構造化データを設定したいページ群の中から、構造化データ部分をハイライトした状態でサンプルページが表示されます。自分の意図通りに設定されている場合には、右上の「次へ」をクリックしましょう。

次々にサンプルが表示されますので、問題がある場合には手動で設定を修正しましょう。5ページ分のサンプルを確認すると、「完了」という項目が右上に表示されるので次に進みましょう。

⑤最終確認画面

採取確認画面

最後に確認したサンプルページを再度見直して、問題が無い場合は右上の「公開」ボタンを押しましょう。これでデータハイライターによる構造化データの設定は完了です。

テストツールのご紹介

構造化データ テスト ツール

構造化データ テスト ツールで正しく構造化データが記述できているかを確認できます。URLもしくはHTMLを入力することでそのページに設定した構造化データが正しく設定されているか、どの項目が設定されているかに加えて、検索結果上でどういう表示がなされるページなのかを確認できます。

テストツール

構造化データのマークアップを行った後には出来る限りこのツールを用いて、正しく設定されたかを確認するようにしましょう。

※なお、このツールで表示される検索結果プレビューが必ずしも本物の検索結果で表示されるとは限らないようです。

ウェブマスターツールの「構造化データ」項目

ウェブマスターツールの構造化データでは、構造化データの設定にエラーが無いか一覧で確認することができます。検索結果のプレビュー機能は無いですが、構造化データにエラーがあるデータタイプやページが一覧で確認できますので、URLを何度も入力する必要のある構造化データテストツールよりもその点は便利です。

まとめ

ここ最近の検索エンジンまわりの動きを見ても、構造化データを利用する重要性は高まるはずなので、サイトによっては是非チャレンジされると良いかと思います。しかし、サイトの全体的なマークアップに構造化データを適用するというのはコスト的に現実的でない場合が多く、そのあたりのバランスは今はまだなかなか難しいのかなと思います。

最後に、こちらも参考にどうぞ。

皆様のお役に立ちましたら幸いです。

ヴォラーレ株式会社 巣鷹

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

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 ファイルはプロトコルやホスト名ごとに区別されて読み取られます。

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

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

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

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

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

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

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

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

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


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

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


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

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

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

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


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

以上、サイトの不正なハッキングをいち早く見つける 3 つの方法をご紹介しました。なお、不正なハッキングの被害が見つかった場合の対処方法や、未然に被害を防ぐためのヒントについては、以下のブログ記事やヘルプ ページをご覧ください。
これらのツールや情報を、被害にあう前から確認しておき、サイトが不正なハッキングの被害にあった場合にすぐに対処を行えるような状態にしておきましょう。また、サイト上で利用しているソフトウェアの更新状況を常に確認し、セキュリティの脆弱性に対応した最新のものにアップデートしておくことも重要です。

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

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

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

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

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

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

Google サイト運営者向けプラグイン(ベータ版)は以下の 2 つの Google サービスに対応しています。
  • Google AdSense: ウェブサイトに広告を掲載し、ウェブサイトを収益化するサービスです。Google サイト運営者向けプラグインを利用すると、ウェブサイトに簡単に広告を掲載することができ、HTML コードを手動で編集する手間を省けます。
  • Google ウェブマスター ツール: Google 検索におけるウェブページの視認性について詳しいレポートを作成するツールです。新しいプラグインを利用すると、ワンクリックでウェブマスター ツールを使ってサイトの視認性を検証できます。
Google サイト運営者向けプラグインは、WordPress.org のプラグイン ディレクトリ(英語)からダウンロードすることができます。詳細とご利用方法については、ヘルプセンターをご覧ください。

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

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

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

一例を見てみましょう:

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

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

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

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

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

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

ウェブマスター ツールの「検索クエリ」機能が、モバイル向けに別の URL を用意しているサイト(モバイル向けに m.example.com、デスクトップ向けに www など)に関して改善されました。2013 年 12 月 31 日より、モバイル サイト側* の「検索クエリ」で、フィルタを「携帯電話」に設定した場合、以下の両方が表示されます:
  • あなたのモバイル向けページが、携帯端末上のブラウザーの検索結果に表示された検索クエリ
  • リダイレクトスキップが発生した検索クエリ。この場合、検索結果上ではデスクトップ版の URL が表示されますが、それをクリックしたユーザーは直接モバイル版へと送られます(サーバー サイド リダイレクトのレイテンシから解放されることになります)。
リダイレクトスキップに関する情報が、モバイル サイト側で表示されています

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

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


モバイル向けに別の URL を用意する場合は、以下をおすすめします。
  • デスクトップ向けサイトの側では、対応するモバイル向け URL へ向いた link rel=”alternate” タグを設置してください。これは、Googlebot があなたのモバイル向けサイトを発見する助けになります。
  • モバイル向けサイトの側では、対応するデスクトップ向け URL へお向いた rel=”canonical”  タグを設置してください。
  • ユーザー エージェントに応じて自動的にサーバー側でリダイレクトを行なっている場合は、HTTP Vary: User-Agent ヘッダーを利用してください。
  • ウェブマスター ツールでは、デスクトップ向けサイトとモバイル向けサイトの両方を登録しましょう。このことにより、各サイトのトラブルシューティングがより捗ります。
  • * モバイル向けサイトの所有権が確認されている場合