古い 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 ヘッダーを利用してください。
  • ウェブマスター ツールでは、デスクトップ向けサイトとモバイル向けサイトの両方を登録しましょう。このことにより、各サイトのトラブルシューティングがより捗ります。
  • * モバイル向けサイトの所有権が確認されている場合

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

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

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

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

    アップデート後

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

    【保存版】2013年のSEO周辺事情の振り返り、2014年に向けて改めて読んでおきたいSEO情報×50記事

    2013年度も終わりにさしかかり、今年のSEOを振り返る記事も既に多数出ていますが、それにやや乗り遅れて便乗する形で今年の主要な話題を一気に振り返るためのSEO総集編をお届けします。

    目次

    1. アルゴリズム/検索技術も色々と変わってきています
    2. 「コンテンツマーケティング」の考え方はSEOにも必須です
    3. 不自然リンク/ペナルティ対応等の事情もどんどん変わっています
    4. スマートフォン/モバイルのSEOに関わる大きな変更がありました
    5. 国内、国外で行われたサーチ系イベントレポートも充実
    6. その他SEO情報、SEOの方法論など
    7. まとめ

    このようなラインナップで、筆者のtwitterアカウント当サイトのFacebookページなどで言及した記事の中からピックアップしてお届けします。情報出典元が偏っていますが、重要な情報を、正確に、かつ下手な誤解を生まないよう配慮されて書かれている情報元は限られていると認識していますのでご了承下さい。

    アルゴリズム/検索技術も色々と変わってきています

    パンダアップデート、ペンギンアップデートと今では随分聞きなれたアルゴリズムに加え、新しく「ハミングバード」なるものも新しく導入され、心地良い感じに世間では勘違いされた情報がビュンビュンと出回ってきていますので、改めて、それぞれの意味やその対策などについて見直してみましょう。

    パンダアップデートが通常アルゴリズムと統合されました

    2011年の初回導入から早3年近く(驚き)、何かと世間を騒がせることの多い「パンダアップデート」ですが、これまでは通常のランキングアルゴリズムとは独立してデータ更新や「パンダ」アルゴリズムの刷新が行われていましたが、今ではその他のアルゴリズムに組み込まれる形で定期的に更新されるようになりました。

    ペンギンアップデート×2回、大きな影響は出ず

    「次のアップデートではかなり大きな変動が起こるだろう」と言われていて戦々恐々としていた2013年のペンギンアップデートですが、蓋を開けてみると「あれ?そうでもなくない?」といった反応が多かったように思います。今年は2回の更新でした。

    (勘違いしてる人の多い)ハミングバード、「会話型検索」への対応強化

    何故かはわかりませんが、一部のブロガーさん(?)等を筆頭に、「ハミングバードによってリンクの重要度が下がる」「コンテンツイズキングをハミングバードがもたらす」といった主旨の記事が出回ってしまいましたが、全くもってそういう類のものではありません。これはかなり勘違いされている方が多いです。

    (おそらく)主に音声検索の普及を見越した、従来型の単語やフレーズでの検索語入力だけでなく「会話型の検索語」に対しても、「単語」ではなく「意味」をより高い精度で解釈して検索結果を提示できるようにした、大規模なアルゴリズムアップデートとなります。しかし、普段ビジネスで定点観測するような商用キーワードに対して大きな影響があったかと言えば、ほとんど影響はありませんでした。

    その他:SSL化、オートコンプリートの是非、AppStore内SEO

    Googleの検索のデフォルトでのSSL化により検索キーワードデータの取得が非常に困難になったり、Googleオートコンプリート機能などでのネガティブワード表示に起因する訴訟でGoogleが敗訴したり(昨年に引き続き)といった話題や、Googleではありませんが最近はAppStoreでの検索アルゴリズムでも大きく変化があったようです。

    「コンテンツマーケティング」の考え方はSEOにも必須です

    人為的なリンクソリューションによるSEOが徐々に肩身狭い状態になっている中、本質的にランキング全般を改善するには、如何にコンテンツを軸としたリンク獲得、ひいてはマーケティングを行っていくかは間違いなくSEOにおける必須の課題となります。

    「コンテンツマーケティングって難しそうだしハードル高い」という声も多いですが、ここに挙げたような記事はその不安をある程度払拭し、またマーケティングにつながるコンテンツをどのように考えるのか、のヒントになると思います。

    不自然リンク/ペナルティ対応等の事情もどんどん変わっています

    今やSEOの話題では定期的にでてくる不自然リンク起因のペナルティや順位下落について。細かな話題は事欠かないですが大まかな流れとしては以下のようなトピックが挙げられます。

    色んなリンクが次々と「不自然リンク」認定へ

    リンク元がいくら信頼あるオーソリティサイトでもそのリンクがSEO目的とみなされればNG判定、リンク購入には有名サイトでも容赦なくペナルティ、プレスリリースや有料ディレクトリもnofollowを、などと、一部若干度が過ぎるのでは?と思うような対応もあり話題になりました。

    Google公式ブログから

    Googleサーチクオリティチームのスタッフも積極的に情報を公開し、ブログだけではなくセミナーや動画でもこの有料リンク問題については呼びかけを行うようになりました。不自然リンクに対するSEO業者の対応が悪質と見なされた場合についての言及など、少し強めな対応をとる姿勢を見せているように見えます。

    再審査リクエスト、対応も色々変わっているようです

    この1年で、再審査リクエストに対するGoogleの対応も大きく変わっています。具体的なリンクURLのサンプル提示、様々なタイプの通知テンプレートなど、正直やや不可解な部分もあるように感じていますが、ペナルティ解除に向けた取り組みの基本的なポイントは変わりません。

    メジャーなブログサービスもSEOスパム対策を強化

    livedoorブログや、最近ではサイバーエージェント社が運営するAmebaブログなどのブログサービスにおいても、検索エンジンスパムへの対応をより強化するような発表がありました。Googleの強めな呼びかけとも相まって、以前よりもリンクを削除できる可能性がかなり向上したというのは実感としてあります。

    スマートフォン/モバイルのSEOに関わる大きな変更がありました

    スマートフォンでのアクセスを全てスマートフォン版TOPにリダイレクトする、などの設定をしている場合、PCでの検索では上位にあるサイトがスマホ検索で全くヒットしなくなる、などの事象が実際に確認できています。ある意味、細かな技術要件とも言えますが、ユーザー体験を損ねないために正しい実装を心がけるべきポイントと言えます。

    国内、国外で行われたサーチ系イベントレポートも充実

    海外でのサーチ系イベントは過去から多く開催され一部レポートが出ていましたが、2013年度は国内でも多くのイベントが行われていたように思います。レポートも充実の内容で、今後のSEOの取り組みを踏まえても必読の内容です。

    その他SEO情報、SEOの方法論など

    その他、SEOの情報収集に役立つ記事や、今後の展望を踏まえてどのような取り組みが求められるか、その参考になりそうな記事をいくつかピックアップしておきました。

    まとめ

    このように、相変わらず激しく変化する検索エンジン環境の中で、それでもサービス利用者や商品を購入するターゲットユーザーが「検索して探す」ことをやめない以上、常にSEOの改善方法を模索していかなければならないことには変わりません。

    検索エンジンは今後も更に改良を進めますが、その方向は「ユーザーの検索に対して、より良い検索結果を返せるようにする」ことであることは変わりなく、具体的には、

    • ユーザーの検索意図を、文字や単語、ではなく意味や文脈でより正確に理解する
    • コンテンツの品質や信頼性をより高い精度で評価する
    • 不正なSEO手法を正しく検出して順位操作を防ぐ
    • 検索意図に応じた、より多様な検索結果を提示する

    などの方向性が挙げられると思います。

    その上でサイト運営者が何を考えるか?ですが、このような検索エンジン技術の進歩に伴い、「(検索エンジンが未熟だから結果的に有効だったような)余計なことを考えずにサイトを運営する」「アルゴリズムの欠陥を突くような手法を模索するのではなく、本質的にサイトの価値を高めることを考える」といった方向に、嫌でもシフトしていくことが求められます。

    2014年もSEO頑張りましょう。それではみなさん良いお年を。

    ヴォラーレ株式会社 土居

    おすすめの記事

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

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

    新しい API は他の Google の API と同じライブラリを利用していますので、移行することによって他のアプリやツールとの統合がより簡単になります。移行は簡単です。
    1. 好きなプログラミング言語向けの Google API クライアント ライブラリをダウンロードします。
    2. サイト確認 API とそのメソッド群について学びます。
    3. OAuth を利用した認証に対応します。
    4. 以上です!
    もし待ちきれない場合は、このコマンドラインを使ってみてください:
    1. oacurl をダウンロードし、インストールします。
    2. Google アカウントで認証を行います:
      $ java -cp oacurl-1.2.0.jar com.google.oacurl.Login \
        --scope https://www.googleapis.com/auth/siteverification
    3. 確認情報をリクエストします:
      $ 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
    4. ファイルを作成後、ウェブサイトに追加し、確認を行います:
      $ 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
    5. 以上です!
    この API で、Google サイト確認の実装がより容易になることを願っています。 ご質問やご感想はウェブマスター ヘルプ フォーラムまでお願い致します。