Google Webmaster Central | SEO-LPO.net

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 について詳しくは、デベロッパーサイトで関連する記事をご覧ください。なお、ご不明な点がありましたら、ウェブマスターヘルプフォーラムをご利用ください。

Posted by: Hillel Maoz, Engineering Lead, Search Console Team (favorite app: Flipboard) and Mariya Moeva, Webmaster Trends Analyst (favorite app: Spotify)
Original version: Official Google Webmaster Central Blog: Rolling out the red carpet for app owners in Search Console

"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 からご利用いただけます。ぜひお試しください！

Posted by Michael Fink, product manager Google Search Console
Original version: Official Google Webmaster Central Blog: Announcing Google Search Console - the new Webmaster Tools

#MobileMadness: サイトをモバイルフレンドリーにするためのキャンペーンを実施しました

Google サーチクオリティチームでは、先日開始したモバイルフレンドリーアップデートに先立ち、3 月の間 Google+ や Twitter 上で #MobileMadness と題したキャンペーンを実施し、サイトをモバイルフレンドリーにするために参考になる情報を発信しました。キャンペーン中は、参考になる tips（ヒント）のご紹介だけでなく、ウェブマスターオフィスアワーを開催してみなさんのご質問にお答えしたり、Google+ の投票機能を使ってウェブマスターの皆さんの声を聞いたりと、様々な企画を行いました。ここで 1 か月に渡ったキャンペーンについてまとめてご紹介したいと思います。

モバイルフレンドリー Tips

1 か月の間、サイトをモバイルフレンドリーにする際に参考になる tips （ヒント）をご紹介しました。
例えば、モバイルサイトをデベロッパーと共同で構築する際に気をつけたいポイントをまとめてご紹介したり、

Google+ 上での投稿

リダイレクトの設定で間違えやすい点をご紹介したりしました。

Google+ 上での投稿

他にも様々な tips（ヒント）をご紹介しましたので、ぜひ Google ウェブマスターコミュニティ上の投稿をご確認ください。

ウェブマスターオフィスアワー

3 月 19 日に実施したウェブマスターオフィスアワー（Hangouts On Air 形式の Q&A セッション）では、モバイルフレンドリーアップデート関連の質問もたくさん頂き、サーチクオリティチームのメンバーでお答えしました。

また、3 月のキャンペーン期間後にはなりましたが、モバイルフレンドリーアップデート直前の 4 月 16 日にもウェブマスターオフィスアワーを開催し、多くのご質問にお答えしました。

ウェブマスターみんなで投票

その他にも、Google+ の投票機能を使い、ウェブマスターのみなさんに、モバイルフレンドリーにまつわる質問にお答えいただきました。例えば、「この投稿を、どの端末から閲覧していますか？」という質問では、41 % の方がモバイル端末上から投稿を閲覧していることがわかり、モバイルからのコンテンツの閲覧が一般的になってきていることが垣間見えました。
また、「モバイル端末からブラウジングする際に、最も不快なことは何ですか？」という質問では、36% のウェブマスターが「インタースティシャル広告が表示される」ことを最も不快に感じているという結果になりました（英語圏のウェブマスターの回答では、43% のウェブマスターが「表示速度が遅い」ことを最も不快に感じているという結果となり、インタースティシャル広告が表示されることが最も不快と感じるのは 17% と、言語圏による違いも見られました。興味深いですね！）。

モバイルフレンドリーサイト 1 か月チャレンジの結果

キャンペーン中、「サイトを 1 か月でモバイルフレンドリーにすることにチャレンジしてみましょう」という呼びかけを行ったところ、世界中で多くのウェブマスターの方に参加頂きました。ここでは参加された方の声をいくつかご紹介します。

ニコラス・シェバリエールさん: #mobilemadness 以降、私たちが管理しているほぼすべてのサイトをレスポンシブデザインへと変更することができました。
ダニエル・ハリソンさん: まだレスポンシブデザインへの更新作業中です。2 週間後までには 100％終えられるように頑張ります。ギーナ・ガウジオ・グレーブスさん: 私たちのサイトはもう完全に #mobilefriendly です。[中略] さらに、多くの生徒たちのサイトも #mobilefriendly になりました!どうもありがとう!
アンドリュース・ベッカーさん: もう 2、3 日必要ですね。たくさんサイトがあるんですから :) 現在はだいたい 90％というところでしょう。

#MobileMadness キャンペーンにご参加いただいた皆さん、どうもありがとうございました! 最後にもう一度、モバイルフレンドリーテストやモバイルユーザビリティレポートを利用してサイトがモバイルフレンドリーとなっているか確認しましょう。また、モバイルガイドでは、サイトをモバイルフレンドリーにする上でのステップについてステップごとに詳しくご紹介していますので、ぜひご活用ください。

モバイルフレンドリーサイトのための確認シート

また、今回、サイトをモバイルフレンドリーにする上での確認シートを作成しました。こちらからダウンロードして、ご利用ください。

もちろん、何かご不明な点がある場合は、いつでもウェブマスターヘルプフォーラムへお寄せください。

Posted by Mary Chen, Webmaster Outreach
Original version: Official Google Webmaster Central Blog: #MobileMadness: a campaign to help you go mobile-friendly

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

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

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

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

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

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

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

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

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

Posted by Zineb, on behalf of the awesome Google Webmaster Tools engineers and UX designers.
Original version: Official Google Webmaster Central Blog: More precise data in the new Search Analytics report

4 月 21 日のモバイルフレンドリーアップデートについてのよくある質問

4 月 21 日に実施されるモバイルフレンドリーアップデートについてのよくある質問とその回答をご紹介します。Google ではこの 2 月にモバイルフレンドリーアップデートを発表し、モバイル版の検索結果におけるモバイルフレンドリーページ（スマートフォンで見やすく使いやすいページ）の掲載順位を全世界で引き上げるとお知らせしました（逆に、大きい画面のみを対象にデザインされたページは、モバイル版の検索結果で掲載順位が大きく下がる可能性があります）。この件についてよくある質問を以下にご紹介します。

全般的なよくある質問

パソコンやタブレットでの掲載順位もこの変更の影響を受けますか？
いいえ。今回のアップデートは、タブレットやパソコンからの検索には影響しません。影響する範囲は、スマートフォンから行われるすべての言語および地域での検索です。
ページ単位とサイト単位のどちらでモバイルの掲載順位が上がるのですか？
ページ単位の変更になります。たとえば、サイト内で 10 個のページがモバイルフレンドリーになっていて、他のページはモバイルフレンドリーでない場合、掲載順位が上がるのはモバイルフレンドリーになっている 10 ページのみです。
自分のサイトのページがモバイルフレンドリーかどうかを確認する方法はありますか？
個別のページが「モバイルフレンドリー」かどうかは、モバイルフレンドリーテストを使用して確認できます。

ウェブマスターツールのモバイルユーザビリティレポート

ウェブマスターツールの [モバイルユーザビリティ] ではサイト全体のモバイルフレンドリーへの現在の対応状況を知ることができます。

4 月 21 日までにモバイルフレンドリーページを準備できなかった場合、掲載順位においてモバイルフレンドリーと判断されるまでにどの程度の時間がかかりますか？
ページがモバイルフレンドリーかどうかは、ページがクロールされてインデックスに登録されるたびに判断されます。次のアップデートを待つ必要はありません。ページをモバイルフレンドリーにしたら、スマートフォン用の Googlebot によってページが再度クロールされてインデックスに登録されるのを待つか、ウェブマスターツールでFetch as Google の [インデックスに送信] を使用して処理をリクエストすることができます。URL が大量にある場合は、サイトマップの送信をご検討ください。前から存在する URL（レスポンシブウェブデザインや動的な配信などの URL）をモバイルコンテンツに使用する場合は、サイトマップに lastmod タグも含めてください。
モバイルの掲載順位変更が 4 月 21 日に実施され、4 月 22 日にトラフィックが減少しなかった場合、自分のサイトの掲載順位には影響がなかったと判断できますか？
サイトの掲載順位がモバイルフレンドリーアップデートの影響を受けたかどうかについて、4 月 22 日に最終判断を下すことはできません。モバイルフレンドリーアップデートの公開は 4 月 21 日より開始しますが、インデックス内のすべてのページにこのアップデートが反映されるまで 1 週間程度かかる見込みです。
所有するモバイルサイトのページが、モバイルフレンドリーテストではモバイルフレンドリーでないと判定されます。なぜですか？
スマートフォンで適切に動作するようデザインされたページがモバイルフレンドリーテストを通過しない場合、その原因としてよくあるのが、スマートフォン用 Googlebotによるリソース（CSS や JavaScript など）のクロールが禁止されていることです。これらのリソースがクロールできないと、ページがスマートフォンで見やすく使いやすいかどうか（つまり、モバイルフレンドリーかどうか）を判断することができません。対処方法は次のとおりです。

ブロックされたリソースがモバイルフレンドリーテストで表示されるかどうかチェックします（多くの場合、ページの画像も部分的にしか表示されません）。
必要なファイルに対する Googlebot のクロールを許可します。
ページがモバイルフレンドリーテストを通過するか再度チェックします。
Fetch as Google の [インデックスに送信] と更新した robots.txt を Google に送信を使用して、更新したページの再処理をリクエストします（または、ページが再クロールされてインデックスに登録されるのを待ちます）。

モバイルページがモバイルフレンドリーテストを通過しない原因の多くは、スマートフォン用 Googlebot による CSS や JavaScript などのリソースのクロールを許可していないことです。これらのリソースはページがモバイルフレンドリーかどうか判断するうえで重要です。

繰り返しますが、サイト所有者の皆様は Googlebot にページのすべてのリソース（CSS、JavaScript、画像を含む）のクロールを許可するようおすすめします。そうすることで、Google がページを正しく解析してインデックスに登録できるようになるほか、このケースではページがモバイルフレンドリーかどうかを判断できるようになります。

モバイルフレンドリーでないサイトにリンクしている場合はどうなりますか？
ページから、パソコンや大きな画面向けにデザインされたページなどのモバイルフレンドリーでないページにリンクしている場合でも、「モバイルフレンドリー」と判断されます。モバイルフレンドリーページからパソコン専用のページへの移動はモバイルユーザーにとって快適とは言えませんが、モバイルフレンドリーサイトが増えるに伴い、この点は問題にならなくなると思われます。
モバイルサイトを別にホスティングする（パソコン用は www でモバイル用は m.example.com となる場合など）よりも、レスポンシブウェブデザイン（パソコン版とモバイル版で同じ URL と同じ HTML を用いる）のページのほうが、モバイルフレンドリーとして掲載順位が高くなりますか？
いいえ。レスポンシブウェブデザイン（RWD）、モバイル用の別個の URL、動的な配信のどの設定を採用していても、モバイルフレンドリーかどうかの評価は同じになります。サイトでモバイル用の別個の URL や動的な配信を使用する場合は、モバイル SEO ガイドを参照して、モバイルページが Google に正しくクロールおよびインデックス登録されるようにすることをおすすめします。
モバイルフレンドリーでないサイトやページは検索から削除されるのですか？
モバイルフレンドリーであることは重要ですが、検索結果の掲載順位決定においては、様々なシグナルが利用されています。検索クエリの意図は大変重要なシグナルです。ですので、たとえクオリティの高いコンテンツが掲載されているページがモバイルフレンドリーではなかったとしても、関連の強いクエリでは高い順位に掲載される可能性があります。

専門的なよくある質問

ユーザーがパソコンからのユーザーのみなので、モバイルサイトを作成する理由が見当たらないのですが、その場合はどうなりますか？
必ずしもモバイルサイトが不要とは言えません。統計では、パソコンを持ったことがない、または既存のパソコンを買い替える考えがないという理由のいずれかで、「モバイルのみ」の利用となるユーザーの増加傾向が示されています。また、モバイルユーザーが少ないのは、そもそもサイトがモバイルフレンドリーでないから、という可能性もあります。

モバイルフレンドリーアップデートは、サイトの対象ユーザー、言語、地域、モバイルとパソコンのトラフィックの比率などに関係なく、すべてのサイトにわたって実施されるモバイル検索に適用されます。
YouTube 動画を埋め込んでいるためにモバイルユーザビリティエラーが表示されるページがあるのですが、どうすればよいですか？
YouTube 動画を埋め込む方法には注意を払うようおすすめします。モバイルページで <object> による「古いスタイル」の埋め込みを使用している場合は、幅広い互換性を持つ <iframe> による埋め込みに変更してください。YouTube では現在、ウェブでの既定のプレーヤーとして HTML5 を使用しているため、動画再生ページの「共有」機能や YouTube iFrame API から <iframe> タグを使用して埋め込む動画はモバイルフレンドリーになります。さらに複雑な方法で統合している場合も、スマートフォンに対してスマートフォンのネイティブサポートを使用するよう指示することから、モバイルフレンドリーになります。

他の動画サイトの Flash コンテンツについても、専用プラグインの使用を避けるために、上記に相当する HTML5 埋め込みタグやコードスニペットが提供されているか確認してください。
タップターゲットのサイズについての明確な標準はありますか？
はい。重要なタップターゲットは高さと幅を 7 mm 以上とし、また、小さいタップターゲットの間には 5 mm 以上のマージンを設けることを推奨しています。平均的な大人の指先のサイズは幅約 10 mm なので、これらのサイズを使用することにより、画面のスペースを有効に利用するとともに、操作しやすいインターフェースを提供することができます。
サイトをすばやくモバイルフレンドリーにするために、新たなレスポンシブサイトが完成するまでの間、機能を大幅に取り除いたバージョンのサイト（別のモバイルページ）の作成を考えています。この方法に問題はありますか？
まず、Google では 3 種類のモバイル設定をサポートしていることと、ウェブサイトをモバイルフレンドリーにするにはレスポンシブでなくてもよいことを心に留めておいてください。ご質問への回答としては、「機能を大幅に取り除いた」バージョンのサイトの作成は慎重に検討することをおすすめします。ページの形式をモバイル向けにできたとしても、ユーザーが通常のタスクを簡単に行えなかったり、全体のワークフローがスムーズでなかったりすれば、ユーザーの不満の原因となり、結果的に作業が無駄となる可能性もあります。もしも、暫定のモバイルサイトを作成する場合は、レスポンシブ版のサイトの完成後に必ず、サイトを正しく移転してください。たとえば、モバイル用の別の URL を参照することがないよう、すべての URL を更新して、対応するレスポンシブ版にモバイル用 URL を 301 でリダイレクトするようにしてください。

推奨事項
モバイルフレンドリーサイトをまったく作成したことがなくても、問題ありません！モバイルフレンドリーウェブサイトのドキュメントのはじめるをご覧ください。

モバイルサイトの作成をはじめる（https://developers.google.com/webmasters/mobile-sites/）。

既にモバイルサイトをお持ちの場合は、ウェブマスターツールのモバイルユーザビリティレポートをチェックして、サイトのページがモバイルフレンドリーと判定されることを確認してください。

他にご質問がありましたら、下記にお問い合わせいただくか、モバイルウェブサイトに関するウェブマスターフォーラムをご覧ください。

Written by Maile Ohye, Developer Programs Tech Lead

モバイルフレンドリーアップデートを開始します

今年の 2 月に発表したように、本日より、Google は全世界でモバイルフレンドリーアップデートを開始します。これにより、モバイル版の検索結果では、モバイルフレンドリーなページの掲載順位が引き上げられ、検索ユーザーは、小さなスクリーン上でも読みやすい、高品質で関連性の高い検索結果をより簡単に見つけることができるようになります。こういったページには、タップやズームなどをしなくてもテキストが読みやすい、タップターゲットの間隔が適切、再生できないコンテンツが含まれていない、横方向へのスクロールが発生しない、などの特徴があります。

4 月 21 日から実施されるモバイルフレンドリーアップデートにより、モバイル検索では、携帯端末で読みやすく使いやすいページの掲載順位が引き上げられます。

このアップデートには以下のような特徴があります:

携帯端末での検索の掲載順位にのみ影響する
世界中のすべての言語で検索結果に影響する
ウェブサイト全体ではなく、個々のページが対象となる

この変更は重要なものですが、ランキングにおける他のシグナルの重要性を無視するものではありません。検索クエリの意図は非常に重要なシグナルです。ですので、たとえクオリティの高いコンテンツが掲載されているページがモバイルフレンドリーではなかったとしても、関連の強いクエリでは高い順位に掲載される可能性があります。

サイトがモバイルフレンドリーかどうかを確認するには、モバイルフレンドリーテストで個々のページを確認するか、ウェブマスターツールのモバイルユーザビリティレポートでサイト全体の対応状況を確認してください。サイトがモバイルフレンドリーではない場合、Google 検索からのモバイルトラフィックが大幅に減少する可能性があります。しかし、サイトがモバイルフレンドリーに対応すれば、Google によるページの再処理（クロールとインデックス登録）は自動的に行われるので、ご安心ください。また、Fetch as Google の「インデックスに送信」機能を使用して、この処理を早めることもできます。処理が完了すると、そのページはモバイルフレンドリーとして順位付けされるようになります。

ご不明な点がありましたら、こちらのモバイルフレンドリーアップデートに関する FAQ をご覧いただくか、モバイルウェブサイトに関するウェブマスターフォーラムをご覧ください。

Posted by Takaki Makino and Doantam Phan

App Indexing でアプリのインストールを増やしましょう

[この記事は Lawrence Chang, Product Manager による Android Developers Blog の記事 "Drive app installs through App Indexing" を元に、北村が翻訳・加筆し、Google Japan Developer Relations Blog に掲載したものです。詳しくは元記事をご覧ください。]

開発者のみなさんがアプリを素晴らしいものにするため時間と努力を惜しまないのと同様に、我々もみなさんの素晴らしいコンテンツをより多くの人たちに届けるお手伝いをしたいと願っています。既に 300 億のアプリ内リンクがインデックスされていることからもわかるように、App Indexing は Android 向けアプリのインストール後のエンゲージに役立てられています。今週より、Android 向けアプリをインストールしていない方々にも、Google で検索することで、あなたのアプリを発見することができるようになります。App Indexing が実装済みで、あなたのアプリからインデックスされたコンテンツが Android 上の Google 検索の結果と一致した場合、検索結果にあなたのアプリのインストールボタンが表示される可能性があります。そのボタンを押下することで、ユーザーは Google Play ストアに移動し、アプリをインストール、そしてアプリ内の検索結果に該当する箇所に直接アクセスすることができます。

これらのインストールリンクの追加を皮切りに、アプリをインストールしているか否かに関わらず、App Indexing はすべての Android ユーザーのランキングシグナルとして利用されることになります。これにより、Google の検索機能が新しいユーザーの獲得だけでなく、既存ユーザーとのエンゲージメントにも役立つことを願っています。App Indexing について詳しくは g.co/AppIndexing を、Google 検索の他の活用方法については g.co/DeveloperSearch を御覧ください。

Posted by Lawrence Chang, Product Manager
Original version: Official Google Webmaster Central Blog: Drive app installs through App Indexing

ハッキングされたサイトの復旧事例をご紹介します

今日では、ハッキングされるウェブサイトの数は、1 日あたり数千に及ぶと言われています。ハッキングされたサイトは、ユーザーに悪意のあるソフトウェアを配布する、ユーザーの個人情報を収集する、ユーザーをまったく別のサイトにリダイレクトするなどの方法で、ユーザーに危害を加えるおそれがあります。もしサイトがハッキングされたら速やかに復旧したいものですが、その方法は単純ではありません。

Google では、サイトがハッキングされた場合にできるだけ簡単に復旧できるよう、セキュリティの問題、ハッキングされたサイトに関するヘルプ、ハッキングされたサイト専用のフォーラムなどを提供しています。最近、ハッキングされた 2 つのサイトのウェブマスターの方に、どうやってサイトを復旧したかについてお話を伺う機会がありました。こうした事例をご紹介することで、ハッキングの被害にあったウェブマスターの皆様がサイトの復旧を行う際のヒントになれば幸いです。

事例 1: レストランのウェブサイトがハッキングされ、複数のスクリプトが挿入された

このレストランでは Wordpress でウェブサイトを作成していましたが、ある日サイトがハッカーによって改ざんされたことを警告する Google からのメッセージがウェブマスターツールアカウントに届きました。Google では検索ユーザーを保護するため、このウェブサイトがハッキングされたことを示すラベルを Google 検索結果に表示しました。このサイトのウェブマスターであるサムさんがソースコードを確認したところ、「viagra（バイアグラ）」、「cialis（シアリス）」などの薬剤用語を使った不審なリンクが数多く見つかりました。また、「buy valtrex in florida（バルトレックス購入フロリダ）」のような meta description タグが HTML 上に追加されているページも数多く見つかりました。さらには、多くのページに（HTML 内にも）非表示の div タグが挿入され、さまざまなページにリンクしていました。もちろん、これらはサムさんが追加したものではありません。

サムさんは、ハッキングされたコンテンツを可能な限り削除して再審査リクエストを送信しました。リクエストは承認されませんでしたが、Google からメッセージがあり、PHP ファイル（もしくは、その他のサーバーファイル）内に不審なスクリプトが追加されていないか、.htaccess に変更が加えられていないか確認するようアドバイスされました。これらは、ハッカーがサイトを改ざんする際、スクリプトを追加するのによく狙うファイルだからです。通常、ハッカーはこのようなスクリプトを使って、ハッキングしたコンテンツを検索エンジンに対してのみ表示し、一般のユーザーにはそのコンテンツが表示されないようにしてしまいます。サムさんはすべての .php ファイルを確認し、ハッキング前にバックアップしておいたファイルと比較しました。その結果、footer.php、index.php、functions.php に新しいコンテンツが追加されていることが判明しました。これらのファイルをバックアップファイルで置き換えた後にハッキングされたコンテンツがそれ以上見つからないことを確認し、もう一度再審査リクエストを送信したところ、サイト内のハッキングされたコンテンツがすべて削除されていることを知らせる Google からの通知が届きました。

ハッキングされたコンテンツはすべて削除しましたが、サムさんとしては今後のハッカーの攻撃からサイトを保護しなければなりません。そこで以下の方法によりサイトを保護することにしました。

コンテンツ管理システム（WordPress、Joomla、Drupal など）を常に最新のバージョンに更新する（プラグインも忘れずに更新する）。
コンテンツ管理システムの管理機能を使用できるアカウントに、強度の高いパスワードを使用する。
コンテンツ管理システムでサポートされている場合は、ログインの 2 段階認証（英語）を有効にする（2 要素認証と呼ばれることもあります）。この方法は、パスワードの再設定に使用するアカウントにもおすすめします。Google、Microsoft、Yahoo（英語）など、ほとんどのメールプロバイダでサポートされています。
インストールされているプラグインやテーマが信頼できる提供元からのものであることを確認する。既にサポートが終了しているようなプラグインやテーマを使用し続けることは大変危険です。また、海賊版のプラグインやテーマには、ハッカーの侵入を容易にするようなコードが挿入されていることが多いようです。

事例 2: 事業用ウェブサイトに検出が難しいハッキングされたページが大量に見つかった

小規模事業主であるマリアさんは、管理しているウェブサイトがハッキングされていることを知らせるメッセージをウェブマスターツールで受け取りました。メッセージには、ハッカーが追加したページの例として http://example.com/where-to-buy-cialis-over-the-counter/ が挙げられていました。ホスティングプロバイダに相談したところ、ホームページのソースコードを確認してくれましたが薬剤に関するキーワードは見つからず、http://example.com/where-to-buy-cialis-over-the-counter/ にアクセスするとエラーページが返されるという状況でした。有料のマルウェアスキャンサービスも利用しましたが、サイト内に悪意のあるソフトウェアを見つけることはできませんでした。
その後、ウェブマスターツールの Fetch as Google 機能を使用して、Google が例示した URL（http://example.com/where-to-buy-cialis-over-the-counter/）にアクセスしてみましたが何も返されませんでした。どうしようもないため再審査リクエストを送信したところ、不承認メッセージが届き、以下の 2 点を試すようアドバイスがありました。

www のないサイト URL をウェブマスターツールに追加する。これは、ウェブマスターが見落としがちなフォルダにハッカーのコンテンツが隠されている場合があるためです。

http://example.com と http://www.example.com は同じサイトのように見えますが、Google ではこれらを別々のサイトとして処理しています。http://example.com は「ルートドメイン」で、http://www.example.com は「サブドメイン」です。マリアさんは http://www.example.com は確認していましたが、http://example.com は確認していませんでした。しかし、ハッカーが追加していたページは http://example.com/where-to-buy-cialis-over-the-counter/ のような www のないページで、こちらを確認することが重要だったのです。マリアさんが http://example.com を確認したところ、ウェブマスターツールの Fetch as Google 機能を使用してハッキングされたコンテンツを表示することができました。
.htaccess ファイルに新たなルールが追加されていないか確認する。

マリアさんが、ホスティングプロバイダにやり方を教わって .htaccess ファイルを確認したところ、次のような追加した覚えのない不審なコンテンツが追加されていました。

<IfModule mod_rewrite.c> RewriteEngine On RewriteCond %{HTTP_USER_AGENT} (google|yahoo|msn|aol|bing) [OR] RewriteCond %{HTTP_REFERER} (google|yahoo|msn|aol|bing) RewriteRule ^([^/]*)/$ /main.php?p=$1 [L] </IfModule>

この mod_rewrite（英語）ルールはハッカーが挿入したもので、特定の検索エンジンから訪れたすべてのユーザーと検索エンジンクローラを、ハッキングされたコンテンツの生成元である main.php にリダイレクトしているものでした。このようなルールで、携帯端末でサイトにアクセスしてきたユーザーをリダイレクトすることも可能です。同じ日、最近のマルウェアスキャンによって、main.php ファイルに不審なコンテンツが見つかっていたことも判明しました。さらには、ウェブサイト開発ソフトウェアの FTP ユーザー領域に、不明なユーザーが登録されていることにも気付きました。

マリアさんは main.php ファイルと .htaccess ファイルを削除し、FTP ユーザー領域から不明なユーザーを削除しました。これにより、サイトのハッキングを止めることができたのです。

今後ハッキングされないための対策

サーバーへのファイル転送に FTP の使用を避ける。FTP では、パスワードをはじめすべてのトラフィックが暗号化されません。代わりに SFTP を使用することで、パスワードを含むすべてのトラフィックが暗号化され、盗聴者からデータを保護できます。
.htaccess のような重要なファイルへのアクセス権限を確認する。この点については、必要に応じてホスティングプロバイダに相談してください。.htaccess はサイトの改善や保護に使用する重要なファイルですが、このファイルへのアクセスを許してしまうとハッカーに悪用されるおそれがあります。
サイトを変更する権限のあるユーザーを確認できる場所（管理パネルなど）をこまめにチェックして、不明なユーザーが追加されていないかどうか確認する。

Google では、ウェブマスターの皆様のサイトがハッキングされないことを願っておりますが、万が一ハッキングされた場合はハッキングされたサイトに関するヘルプをご覧ください。ハッキングされたサイトを復旧するためのさまざまな資料が用意されています。それでもご不明な点がある場合や、他のウェブマスターと情報交換していただける場合は、ウェブマスターヘルプフォーラムをご利用ください（フォーラムに投稿する際やサイトの再審査リクエストを送信する際は、#NoHacked を含めるようにしてください）。

最後に、ハッキングによる被害はなかなか気づかないことも多いようです。サイトの不正なハッキングをいち早く見つけ、普段からサイトのセキュリティ強化を意識しましょう！

Posted by Julian Prentice and Yuan Niu, Search Quality Team
Original version: Official Google Webmaster Central Blog: Case Studies: Fixing Hacked Sites

Web Components と JSON-LD でウェブサイト開発がより簡単に

JSON-LD は、Google などの検索エンジンに対してサイト上のコンテンツを記述する構造化データの実装に使用できる JSON ベースのデータ形式です。たとえば、イベント、店舗、人物などのリストがある場合に、schema.org ボキャブラリを JSON-LD スニペットとしてウェブページに埋め込むことで、構造化された方法でリストのデータをページに含めることができます。構造化データにすることで、Google がページの内容を把握しやすくなり、ナレッジグラフイベントやリッチスニペットなどの検索機能でコンテンツがハイライトで表示されやすくなります。

Web Components は、カスタマイズした再利用可能なユーザーインターフェースウィジェットとその動作を定義するための技術です。複数の技術で成り立ち、その仕様は現在も策定中です。ウェブデベロッパーであれば誰でも Web Components をビルドできます。まず、ユーザーインターフェースの個々のパーツについてテンプレートを定義し、Web Components を使用したいページにテンプレートをインポートします。Web Components の動作を定義するには、Custom Elements を使用します。ユーザーインターフェースのパーツの表示とロジックが Web Components にバンドルされるため、このバンドルを他のページや他のデベロッパーと共有したり、再利用したりでき、ウェブ開発が簡単になります。

JSON-LD と Web Components は、併せて利用するととてもうまく機能します。Custom Elements がプレゼンテーション層として機能し、JSON-LD は Custom Elements や検索エンジンが読み込むデータ層として機能します。つまり、schema.org/Event や schema.org/LocalBusiness など、どのような種類の schema.org についても、Custom Elements をビルドできることになります。

アーキテクチャは次のようになります。構造化データはデータベースに格納されます（例: チェーンの店舗の所在地）。このデータは JSON-LD スニペットとしてウェブページに埋め込まれます。つまり、Custom Elements によって読み込まれ、人間の訪問者に対して表示されたり、Googlebot によって Google のインデックス登録のために取得されたりできるようになります。

Custom Elements の詳細や独自の Custom Elements の使用方法については、以下をご覧ください。

HTML5 Rocks の最新記事と付属のコード例（リンク先はすべて英語）
JSON-LD のウェブサイト、W3C 仕様（リンク先はすべて英語）
"Web Components" の Wiki、webcomponents.org の Web Components コミュニティ（リンク先はすべて英語）
schema.org（リンク先はすべて英語）
Google の構造化データのドキュメント（リンク先は英語）

Posted by Ewa Gasperowicz, Developer Programs Engineer, Mano Marks, Developer Advocate, Pierre Far, Webmaster Trends Analyst
Original version: Official Google Webmaster Central Blog: Easier website development with Web Components and JSON-LD

オンラインフォームを入力しやすくするために

多くのウェブサイトでは、重要な目標を達成するための手段としてフォームを使用しています。たとえば、ショッピングサイトでは代金の決済、ニュースサイトでは会員の登録などです。ユーザーの多くは、ウェブ上の各サイトでオンラインフォームを入力するたびに、氏名、メールアドレス、電話番号、住所などの情報を繰り返し入力することになります。同じ情報を何度も入力するのは面倒なだけではありません。入力エラーが発生しやすく、ユーザーがフォームの途中で入力をやめる原因にもなってしまいます。パソコンよりも携帯端末で閲覧するユーザーが多くなり、フォームをすばやく簡単に入力できるようにすることが不可欠となっています。Google では 3 年前、フォームへの入力をすばやく、簡単に、スマートに行えるようにするため、Chrome で新たに「autocomplete」属性をサポートすることを発表しました。現在では、最新の WHATWG の HTML 標準（英語）に準拠する形で「autocomplete」属性が完全にサポートされています。これにより、ユーザーインターフェースやバックエンドに変更を加えることなく、入力要素項目に一般的なデータタイプ（「name」、「street-address」など）をラベル付けできるようになっています。既にたくさんのウェブマスターがフォームをマークアップしてオートコンプリートを実装し、フォーム入力の完了率を上昇させています。

たとえば、フォームのメールアドレス項目をオートコンプリートできるようにするには、次のようにマークアップします（サンプルフォームもご覧ください）。

<input type="email" name="customerEmail" autocomplete="email"/>

携帯端末ユーザーが増加した今、操作やブラウジングが簡単なウェブサイトにすることが非常に重要です。「autocomplete」属性でマークアップされたフォームが、今後ますます増えていくことを願っております。詳細については、「Web Fundamentals」の Label and name inputs properly （英語）で仕様を確認してください。ご質問などありましたら、いつもどおりウェブマスターヘルプフォーラムに投稿してください。

Posted by Mathieu Perreault, Chrome Software Engineer, and Zineb Ait Bahajji, Webmaster Trends Analyst
Original version: Official Google Webmaster Central Blog: Helping users fill out online forms

誘導ページについて、品質に関するガイドラインを更新しました

Google のサーチクオリティチームは、ユーザーに対するウェブスパムの影響を最小限に抑える方法について継続的に取り組んでいます。誘導ページもその対象の 1 つです。

Google では従来より、検索エンジンのためだけに作成された誘導ページについて、ユーザーの検索体験の品質に悪影響を及ぼす可能性があるとの見解を持っています。

たとえば、検索結果に表示されるすべてのページが、検索ユーザーを同じサイトに誘導するものであった場合を考えてみてください。ユーザーがある検索結果をクリックして閲覧し、その内容が目的に沿うものではなかったため検索結果ページに戻って次の結果をクリックしても、結局は最初に閲覧した目的に沿わなかったページと同じページに誘導されてしまい、ユーザーの利便性が大きく妨げられてしまいます。

Google では長い間、明確な独自の価値を提供していないにもかかわらず検索結果の上位に表示されることのみを目的とするサイトを目にしてきました。このような誘導は、サイト内の複数のページを利用したり、多数のドメインを利用したり、またはそれらを組み合わせた形で行われています。Google ではユーザーに表示される検索結果の品質向上を目的として、より適切にこのような種類のページに対応するためのランキングの調整を近日中に開始します。大規模かつ入念な誘導キャンペーンを実施しているサイトは今回の変更によって大きな影響を受ける可能性があります。

ウェブマスターの皆様に Google のガイドラインを十分にご理解いただけるよう、品質に関するガイドラインに誘導ページの明確な例を追加するとともに、その定義を更新しました。
誘導ページかどうかは、たとえば、以下のような項目に基づいて判断されます。

検索エンジン用に最適化することでサイト内の有用なコンテンツや関連性の高いコンテンツにユーザーを案内することを目的としているか。そうである場合、そのページがサイトのユーザーエクスペリエンスに不可欠か。
ページのコンテンツが極めて具体的であるにもかかわらず、一般的なキーワードで検索結果の上位に表示されることを目的としていないか。
検索トラフィックを増やすことを目的に、そのページにサイト上の既存の項目（場所や商品など）をまとめたコンテンツを繰り返して掲載していないか。
コンテンツや機能において独自の価値はなく、単にお金儲けのためにユーザーを別のページに誘導することのみを目的に作成されたページではないか。
ページが「孤立」して存在していないか。サイト内の他の場所からそのページへの移動が困難または不可能ではないか。検索エンジンのためだけに、サイト内の他のページやサイトのネットワークからそのページへのリンクを作成していないか。

誘導ページにつきましては、こちらのブログ記事「誘導ページ（Doorway Page）はガイドライン違反です」もご覧ください。誘導ページについてのご質問やご意見がありましたら、ウェブマスターヘルプフォーラムまでお寄せください。

Posted by Brian White, Google Webspam Team
Original version: Official Google Webmaster Central Blog: An update on doorway pages

古い 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 に置き換わる予定です。

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

Posted by John Mueller, fan of command lines & APIs, Google Zuerich
Original version: Official Google Webmaster Central Blog: Deprecation of the old Webmaster Tools API

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

ウェブページではデザイン性や機能性を高めるため、画像、CSS ファイル、JavaScript ファイルがよく使われます。このようなリソースがクロールからブロックされると、Googlebot では検索用にページをレンダリングする際にそのリソースを使用できません。そこで Google ウェブマスターツールでは、ウェブマスターの皆様がこのような問題を特定して解決できるよう、ブロックされたリソースのレポートを導入しました。

このレポートには、サイト上のブロックされたリソース（JavaScript、CSS、画像など）の提供元ホスト名が表示されます。行をクリックすると、ブロックされたリソースの一覧と、そのリソースが埋め込まれているページが表示されます。そこから、ページコンテンツのクロールとインデックス登録を可能にするために何が必要かを診断、解決する手順に進むことができます。

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

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

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

Posted by John Mueller, Webmaster Trends Analyst, Google Switzerland
Original version: Official Google Webmaster Central Blog: Unblocking resources with Webmaster Tools

検索結果をもっとモバイルフレンドリーに

ユーザーが携帯端末で検索した場合、探している情報がモバイルフレンドリーサイトで公開されていてもアプリで公開されていても、関連性の高いタイムリーな検索結果がユーザーに表示される必要があります。インターネットへのアクセスに携帯端末が使用されるケースが増えてきたため、Google のアルゴリズムもこうした使用状況への対応が必要となっています。これまでにも、サイトを適切に設定するための変更、最新端末で表示可能にするための変更を行ってきました。また、検索ユーザーがより簡単にモバイルフレンドリーなウェブページを探せるよう対応し、アプリの有益なコンテンツを検索結果に表示するようになる App Indexing を導入しました。

本日、Google はモバイルフレンドリーなコンテンツをユーザーがより発見しやすくするためにおこなった 2 つの重要な変更についてお知らせします。

1. 検索結果にもっとモバイルフレンドリーなウェブサイトを

Google では、4 月 21 日より、ウェブサイトがモバイルフレンドリーかどうかをランキング要素として使用し始めます。この変更は世界中の全言語のモバイル検索に影響を与え、Google の検索結果に大きな変化をもたらします。この変更によって、検索ユーザーは、クエリへの関連性が高く使用端末にも適した高品質な検索結果を見つけやすくなります。

モバイルフレンドリーサイトの作成について詳しくは、モバイルフレンドリーサイトのガイドをご覧ください。ウェブマスターの皆様は、以下のツールを使うことで、ご自身のページが Googlebot からどのように認識されているかを変更の前に確認することができます。

数ページをテストする場合は、モバイルフレンドリーテストを実施します。
サイトをお持ちの場合は、ウェブマスターツールアカウントでモバイルユーザビリティレポートを使用すると、サイト全体のモバイルユーザビリティ問題を一覧で確認できます。

2. 検索結果にもっと関連性の高いアプリコンテンツを

本日より Google は、インデックスされたアプリからの情報を、そのアプリをインストールしているログインユーザーに対して、ランキング要素の一つとして使用し始めます。これにより、インデックスされたアプリのコンテンツをより簡単に見つけることができるようになります。アプリのコンテンツが検索結果に表示されるようにする方法については App Indexing サイトで解説していますので、ぜひご覧ください。

モバイルフレンドリーサイトまたは App Indexing についてご不明な点がありましたら、ウェブマスタープロダクトフォーラムでお気軽にご質問ください。

Posted by Takaki Makino, Chaesang Jung, and Doantam Phan
Original version: Official Google Webmaster Central Blog: Finding more mobile-friendly search results

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

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

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

ここでは、スマートフォンでの閲覧の際、上下のスクロールのみによって簡単に読むことのできるサイトをモバイルフレンドリーと定義しています。左右へのスワイプやズームイン、ズームアウトが必要となる場合、スマートフォンで気軽に閲覧することは難しくなってしまいます。ここで指摘される問題は以下のようなものです。

Flash を利用している
viewport が存在しない（モバイルページにとっては非常に重要な meta タグです）
フォントが小さい
viewport が固定幅
コンテンツが viewport のサイズに合っていない
リンクやボタンがお互いに近すぎる位置に配置されている

これらの問題がウェブマスターツール内で表示されている場合、ぜひ解決法を探ってみてください。テンプレートを変えるだけで直ってしまうこともままあります。詳しい情報は、モバイルガイドを御覧ください。

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

Posted by John Mueller, Webmaster Trends Analyst, Zurich
Original version: Official Google Webmaster Central Blog: Tracking mobile usability in Webmaster Tools

XML サイトマップと RSS/Atom フィードのベストプラクティス

サイトマップを送信することは、サイトを最適化する上で重要な要素の一つです。サイトマップを送信することで、あるサイトに存在するすべての URL を検索エンジンが発見できるようになり、ページの内容が変更された時に素早くダウンロードすることが可能になります。そこで今回は、サイトマップにおける重要なフィールドについて、XML サイトマップや RSS/Atom フィードはいつ使えばよいのか、また Google 検索に最適化するためにはどうすればよいか、について解説します。

サイトマップとフィード

サイトマップは、XML サイトマップ（英語）、RSS 、もしくは Atom のいずれかの形式を使用します。主な違いは次のとおりです。XML サイトマップは、あるサイトに存在するすべての URL が含まれますが、RSS/Atom フィードは、最新の更新が含まれます。つまり:

XML サイトマップは一般的にファイルサイズが大きくなります。一方、RSS/Atom フィードのファイルサイズは小さく、サイトの最新の更新情報のみが含まれます。
XML サイトマップは RSS/Atom フィードほど頻繁にダウンロードされません。

Google では、最適なクロールを行うために、XML サイトマップと RSS/Atom フィードの両方を使用することをおすすめしています。XML サイトマップによって、Google はサイト内の全ページに関する情報を取得することができ、RSS/Atom フィードによって、サイト内のすべての更新情報を取得することができるからです。両者のおかげで、Google はインデックス中のコンテンツをいつも最新の状態に保つことが可能になります。ただし、サイトマップやフィードを送信したからといって、URL のインデックスが保証されるわけではありません。

XML サイトマップの例:

 <?xml version="1.0" encoding="utf-8"?> 
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"> 
 <url> 
   <loc>http://example.com/mypage</loc> 
   <lastmod>2011-06-27T19:34:00+01:00</lastmod> 
   <!-- optional additional tags --> 
 </url> 
 <url> 
   ... 
 </url> 
</urlset>

RSS フィードの例:

 <?xml version="1.0" encoding="utf-8"?> 
<rss> 
 <channel> 
   <!-- other tags --> 
   <item> 
     <!-- other tags --> 
     <link>http://example.com/mypage</link> 
     <pubDate>Mon, 27 Jun 2011 19:34:00 +0100</pubDate> 
   </item> 
   <item> 
     ... 
   </item> 
 </channel> 
</rss>

Atom フィードの例:

 <?xml version="1.0" encoding="utf-8"?> 
<feed xmlns="http://www.w3.org/2005/Atom"> 
 <!-- other tags --> 
 <entry> 
   <link href="http://example.com/mypage" /> 
   <updated>2011-06-27T19:34:00+01:00</updated> 
   <!-- other tags --> 
 </entry> 
 <entry> 
   ... 
 </entry> 
</feed>

"other tags" は必須タグと省略可能なタグの両方を表しており、両者はそれぞれの形式の標準によって定義されています。Google では、Atom/RSS フィードに必須タグを指定することをおすすめしています。この指定により、フィードは Google 検索だけでなく、フィードを扱う可能性のある他のプロパティでも表示することが可能になるからです。

ベストプラクティス

重要なフィールド

XML サイトマップと RSS/Atom フィードは、実際のところ、メタデータが付加された URL の一覧です。その中で、Google にとって最も重要な情報は、URL そのものとその最終更新日時です。

URL

XML サイトマップや RSS/Atom フィード内の URL は、以下のガイドラインに従ってください。

Googlebot が取得可能な URL であること。robots.txt によって Googlebot のアクセスを禁止している URL や、ページが存在しない URL が指定されているケースがよく見られますが、それらは間違った指定方法です。
正規 URL であること。内容の重複した複数のページの URL が指定されていることがありますが、これは間違った指定方法です。そのままでは、インデックスが改善されない一方で、あなたのサーバーの負荷が増大してしまいます。

最終更新日時

それぞれの URL に対して、その URL の最終更新日時を XML サイトマップと RSS/Atom フィードに指定してください。最終更新日時とは、そのページのコンテンツが実質的に更新された最新の日時です。ある更新が検索結果に影響を与える可能性がある場合、その更新日時が最終更新日時となります。

XML サイトマップでは <lastmod> を使用します
RSS では <pubDate> を使用します
Atom では <updated> を使用します

最終更新日時を正しく設定、更新するには:

日時を正しい形式で指定します。XML では W3C Datetime 形式（英語）、Atom では RFC3339 形式（英語）、RSS では RFC0822 形式（英語）を使用します。
コンテンツが実質的に変更されたときのみ、日時を更新します。
サイトマップやフィードが取得されるたびに、現在日時を最終更新日時として指定しません。

XML サイトマップ

XML サイトマップには、サイト内のすべての URL が記載されている必要があります。一般的に、XML サイトマップはファイルサイズが大きく、頻繁には更新されません。使用の際は、以下のガイドラインに従ってください。

単独の XML サイトマップの場合：（定期的に更新されるサイトの場合は、）更新は少なくとも一日一回行い、Google に ping（英語）を送信します。
複数の XML サイトマップの場合：それぞれの XML サイトマップにはできるだけ多くの URL を記載します。一つの XML サイトマップは、最大 5 万 URL もしくは（圧縮されていない状態で）10 MB までとし、ファイルがどちらかの制限に達するまで URL を記載します。XML サイトマップをひとつでも更新した場合は、その都度 Google に ping（英語）を送信してください（サイトマップインデックスファイルを使用している場合は、一度だけ送信してください）。それぞれの XML サイトマップにごく少数の URL のみを記載しているケースがしばしば見られますが、それは間違った指定方法です。その場合、Google にとって、想定された時間内で XML サイトマップすべてをダウンロードすることが難しくなります。

RSS/Atom

RSS/Atom フィードは、サイト内の最近の更新情報を伝えている必要があります。通常、RSS/Atom フィードはファイルサイズが小さく、頻繁に更新されます。Google では、RSS/Atom フィードを以下のように設定することをおすすめしています。

新たなページが追加されるか、既存のページが実質的に更新された場合、フィードにその URL と更新日時を追加します。
Google による更新情報の見逃しを防ぐため、RSS/Atom フィードには、少なくとも、前回の Google のクロール以降のすべての更新情報が記載されるようにしてください。Google では、そのための最適な方法として、PubSubHubbub（英語）の使用をおすすめしています。ハブが、可能な限り高速かつ効率的な方法で、関係するすべての購読者（RSS リーダーや検索エンジンなど）へフィードの内容を伝達してくれます。

XML サイトマップと RSS/Atom フィードの両方を使用することで、Google や他の検索エンジンによるクロールをうまく最適化することができます。その際に重要な情報は、正規 URL と最終更新日時です。これらを適切に設定し、サイトマップの ping や PubSubHubbub を通して Google などの検索エンジンに伝えることで、クロールを最適な状態で行うことが可能になり、意図した通りに、ウェブサイトが検索結果に反映されるようになります。

ご不明な点がありましたら、この記事にコメントいただくか、ウェブマスターヘルプフォーラムのサイトマップカテゴリまでいつでもお寄せください。

Posted by Alkis Evlogimenos, Google Feeds Team
Original version: Best practices for XML sitemaps & RSS/Atom feeds

地域対応ページのクロールとインデックス登録

地域対応ページでは、ユーザーの言語や検出された地域に応じてコンテンツが変更されます。Googlebot は通常 Accept-Language HTTP リクエストヘッダーを設定せずにページをリクエストし、米国からと判定される IP アドレスを使用するため、地域対応ページのすべてのコンテンツが正しくインデックス登録されるとは限りません。

このたび Google では、リクエストの言語や地域に基づいて配信コンテンツを変更していると判断されたページに対応するため、新しい地域認識クロール設定を Googlebot に追加しました。

地域分散クロール: Googlebot は、米国からと判定される現在の IP アドレスに加え、米国外からと判定される IP アドレスも使用します。
言語依存クロール: Googlebot は、リクエスト内で Accept-Language HTTP ヘッダーを使用してクロールします。

これらの新しいクロール設定は、地域対応ページが検出されると自動的に有効になるため、CMS やサーバー設定を変更しなくても、サイトのクロール方法や Google の検索結果での表示の変化にお気付きいただけることでしょう。

この新しい設定が追加された後も、地域ごとに rel=alternate hreflang アノテーションで別々の URL を使用することを引き続きおすすめします。ユーザーの操作やコンテンツの共有を円滑に行うために、そして地域別のコンテンツを可能な限りインデックス登録してランキングの精度を向上させるために、Google では今後も別々の URL の使用を推奨いたします。

ご不明な点やご意見・ご感想などありましたら、ウェブマスターヘルプフォーラムにてお聞かせください。

Posted by Qin Yin, Software Engineer Search Infrastructure, and Pierre Far, Webmaster Trends Analyst
Original version: Crawling and indexing of locale-adaptive pages

2014 年もウェブマスター向け公式ブログをご覧頂き、ありがとうございました。

2014 年もウェブマスター向け公式ブログをはじめ、ウェブマスターヘルプフォーラムや Webmaster Japan コミュニティ、そして Webmaster Hangout/Office Hour など、ご愛読、ご参加いただきありがとうございました。

ウェブマスターのみなさまにとって今年はどんな一年でしたでしょうか？今年公開した人気記事のランキングとともに今年一年を振り返ってみたいと思います。上位 5 つの記事を見てみましょう。

第 1 位：HTTPS をランキングシグナルに使用します
第 2 位：リンクプログラムによるガイドライン違反について
第 3 位：ウェブページをより深く理解するようになりました
第 4 位：検索ユーザーがモバイルフレンドリーページを見つけやすくするために
第 5 位：検索エンジンとの相性を考慮した無限スクロールのベストプラクティス

今年一番注目された記事は「HTTPS をランキングシグナルに使用します」でした。HTTPS のサイトへの導入については、多くのウェブマスターの方々からご質問を頂きましたが、ランキングのシグナルとして使用しているからというだけでなく、ユーザーにサイトをもっと安全に閲覧していただくためにもぜひ導入を検討していただければと思います。また、今年もう一つ注目を集めたのはモバイルではないでしょうか。今年は他にも「Google の検索結果に、誰もが表示できるウェブサイトを」など、モバイルユーザーの利便性を意識した改善をたくさん行っています。日本でもモバイルの検索結果に [スマホ対応] と表示されるようになりましたので、ぜひ一度モバイルフレンドリーテストであなたのサイトがモバイルフレンドリーかどうかチェックしてみてください。モバイルフレンドリーサイトの作り方についてはGoogle のウェブマスター向けモバイルガイドや、2 年前の記事となりますが、「Google がお勧めするスマートフォンに最適化されたウェブサイトの構築方法」をぜひご覧ください。

いかがでしたでしょうか？見落としていた記事はありませんか？見落としていた記事がある方は、ぜひ冬休み中、お時間があるときに目を通してみていただけたら幸いです。また、最近日本でもハッキングの被害が引き続き増えています。年末のお休みに入る前に、こちらの記事なども参考にしながら、ぜひ担当されているサイトがハッキングの被害に遭わないように設定を再度ご確認されることをお勧めします。また、年末年始の時期を狙い、詐欺サイトでオンラインショッピングのユーザーを騙したり、低品質なアフィリエイトサイトで営利を稼ごうといった悪質な行為を行うケースも残念ながら増える傾向にありますのでご注意ください。また、そのようなサイトを見かけた際はスパムレポートでお知らせください（関連 Google+ 記事）。

今年もありがとうございました。それではみなさん、よいお年を！

Takeaki Kanaya, Kiyotaka Tanaka and Kazushi Nagayama, Search Quality Team

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

Posted by Mariya Moeva, Webmaster Trends Analyst
Original version: Official Google Webmaster Central Blog: The four steps to appiness

検索ユーザーがモバイルフレンドリーページを見つけやすくするために

スマートフォンなどの携帯端末で Google の検索結果をタップした時、表示されたページのテキストが細かすぎたり、リンクの表示が小さかったり、またはすべてのコンテンツを見るには横にスクロールしなければならなかったりといった経験はありませんか？これは主に、ウェブサイトが携帯端末での表示に最適化されていないことが原因です。

この問題はモバイル検索ユーザーの利便性を妨げることになります。そこで本日 Google では、ユーザーが目的の情報をより簡単に見つけることができるようにするために、モバイル版の検索結果に [スマホ対応] というラベルを追加します。

この変更は、今後数週間で順次日本を含む世界中で公開する予定です。Googlebot によってクロールされ、以下の条件を満たしたページは、[スマホ対応] ラベルが適用される可能性があります。

携帯端末では一般的でないソフトウェア（Flash など）を使用していないこと
ズームしなくても判読できるテキストを使用していること
ユーザーが横にスクロールしたりズームしたりする必要がないよう、コンテンツのサイズが画面のサイズと一致していること
目的のリンクを簡単にタップできるよう、それぞれのリンクが十分に離れた状態で配置されていること

ページがモバイルフレンドリーの条件を満たしているかどうかを確認するには:

モバイルフレンドリーテストでページを確認します。
Google のウェブマスター向けモバイルガイドの最新のドキュメントで、モバイルサイトの作成方法と改善方法を確認します。
Google ウェブマスターツールで [モバイルユーザビリティ] レポートを確認します。このレポートには、1 つのページだけでなくサイト全体における主要なモバイルユーザビリティの問題が表示されます。
CMS （コンテンツマネジメントシステム）でホストされているウェブサイトを、モバイルフレンドリーテンプレートに移行する場合は、WordPress や Joomla などのサードパーティソフトウェア向け手順ガイドを確認します。

ここでご紹介したツールやガイドは現在のところ英語のみとなりますが、今後数週間で多くの言語でご利用いただけるようになります。

Google ではこのラベルを、モバイルユーザーにさらに優れたモバイルウェブエクスペリエンスを提供するための第一歩と考えています。また、このモバイルフレンドリーの条件をランキング要素として使用することも実験中です。

ご不明な点やご質問がありましたら、ウェブマスターヘルプフォーラムまでお寄せください。Google の願いは、モバイルフレンドリーサイトが今後ますます増えていくことです。すべてのユーザーが快適に利用できるウェブを作り上げていきましょう！

Posted by Ryoichi Imaizumi and Doantam Phan, Google Mobile Search
Original version: Helping users find mobile-friendly pages