ウェブマスターとコンテンツ クリエイターの方々のお役に立つために

魅力的なウェブサイトは、有益なコンテンツやサービスを世の中に届けようとご尽力されている、サイトを運営する皆様の努力が実を結んだものです。ウェブサイトの運営は、数年前に比べれば効率化されましたが、それでも骨の折れる仕事であることに変わりありません。私たちが Google 検索の改良に膨大な時間と労力を費やしている理由はそこにあります。ユーザーがコンテンツを見つけるまでのところは Google にお任せいただき、皆様にはユーザーの役に立つ魅力的なコンテンツを作ることに集中していただきたいのです。

Google 検索でどんな処理が行われているかは、あまり気にしても仕方ないと考えていらっしゃる方が多いかもしれません。確かにコンテンツを公開しておけば、Googlebot が自動的に見つけてクロールし、コンテンツを理解してインデックス登録し、サイト内の適切なページにユーザーを誘導してくれます。しかし、技術的なことを理解しているのとまったく知らないのとで、大きな差が生まれることもあります。

Google は、サイト所有者様向けのサポートやリソースの充実に力を注いできました。Google に質問したいと感じたときや、なぜそういう結果になったのか疑問に感じたとき、技術的な問題を解決する方法がわからないときは、世界中の Google エキスパートが力を合わせて作成しているこれらのリソースをぜひご覧いただけたらと思います。

最初におすすめしたいのが Google ウェブマスターです。すべてのサポート リソース(多くのコンテンツは 40 の言語に対応しています)を 1 か所にまとめ、探している情報に簡単にアクセスできるようにしました。例えば次のようなコンテンツがあります。

サポートが必要なときの 2 つ目の選択肢が Google ウェブマスター ヘルプ フォーラムです。現時点では、16 か国語(日本語英語スペイン語ヒンディー語フランス語イタリア語ポルトガル語ドイツ語ロシア語トルコ語ポーランド語バハサ インドネシア語タイ語ベトナム語中国語韓国語)で運営されています。フォーラムには専任の Google 社員がおり、皆様の質問にきちんと回答が寄せられているかどうか目を配っています。フォーラムを管理する Google 社員のほかに、トップレベル ユーザー プログラムのメンバーとして、コミュニティを積極的にサポートしてくれるユーザーがいます。彼らには、個別のウェブサイトのコンテンツに関する情報提供や分析など、Google ではなかなか難しいきめ細かい対応をお願いしています。フォーラムは基本的に公開されたディスカッションの場ですが、必要に応じて非公開で個別に返信することも可能です。

ウェブサイト所有者が利用できる 3 つ目のサポート手段が、オンラインのウェブマスター オフィスアワーです。現在のところ、日本語、英語、ドイツ語、トルコ語、ヒンディー語、フランス語で開催しています。ウェブマスター オフィスアワーでは、Google 検索でのウェブサイトの掲載についてなど、皆様からの質問に Google 社員ができる限りお答えします。カンファレンスやイベントの一番の醍醐味は参加者との質疑応答ですが、オンライン形式のオフィスアワーは、遠方でイベントに参加できない方々と意見交換できる貴重な機会となっています。今後のウェブマスター オフィスアワーやイベントの予定については、Google ウェブマスター カレンダーをご覧ください。

これらのリソース以外にも、How Search Works (検索の仕組み)というウェブサイトを頻繁に更新し、検索を利用したいと考えているすべての方が必要な情報を確実に見つられるよう、努力しています。

ウェブ上に公開したサイトは誰でも見ることができます。しかし状況によっては、ウェブサイトの問題についてフォーラムでオープンに議論したくない場合もあることは承知しています。特に慎重な対応が必要な問題で詳細を公にしたくない場合には、フォーラムの「非公開での返信」機能を使用して、経験が豊富な少人数のエキスパートに、必要最小限の情報を提供するかたちでサポートを受けることもできます。

Google 検索とウェブサイトに関連して他にご提案などございましたら、フォーラム、オフィスアワー、Twitter(@googlewmc)宛にお知らせください。

Google Dance Tokyo 2018 を開催しました

2018 年 4 月 3 日、Google 東京オフィスにおいて、Google の検索チームとウェブマスターやサイト運営に関わるみなさんを結ぶイベント、Google Dance Tokyo 2018 を開催しました(Google Dance Tokyo は、米国 Google 本社で開催されている、検索などオンライン マーケティングの担当者を対象としたソーシャル イベントである Google Dance の日本版です)。

Google Dance Tokyo 2018 Logo
イベントには例年通り当ブログでの告知からご応募いただいた方々や、Advanced Hosting Meetup の参加者、ウェブマスター ヘルプ フォーラムトップ レベル ユーザーや注目ユーザーのみなさんをご招待し、今年は昨年までの 2 倍を超える 220 名の方々にご参加いただきました。

イベントは徳生裕人(製品開発本部長)による Breakout Session から始まり、Google アシスタントを拡張する Actions on Google の最新情報をご紹介し、続く Special Session では長山一石(Ninja Spamologist)が「Webmastering 201」と題して、SEO 中級者になるために知っておくべき Tips をお話しました。

そしてQ&A タイムは、金谷武明(Senior Search Evangelist)と小川安奈(Mobile Solutions Consultant)が司会を務め、Gary Illyes (Webmaster Trends Analyst)と長山一石も加わり、今年はウェブマスター オフィスアワーとして会場からライブで中継しました。AMP や PWA に関するご質問から新しい Search Console、モバイル ファースト インデックスなど様々なご質問にお答えしました。

Google Dance Tokyo 2018 での #ウェブマスターオフィスアワーの様子

同時に開催した参加者によるライトニング トークはテクノロジーに関するもの、検索に関するもの、キャリアに関するものなど様々なトピックについて楽しいトークが披露され、大変盛り上がりました。イベント後に行ったアンケートでもどのライトニング トークも評判が高かったのですが、その中でも特に評判が高かったトークは「Google は教えてくれない「○○」のやりかた - 辻正浩」、「Twitter 廃人による Twitter フォロワー(オーディエンス)の増やし方(2018 年版) - 千代田まどか(ちょまど)」、「サーチコンソール + SNS を駆使した、読まれるコンテンツの作り方 - 湊川あい」(すべて敬称略)となりました。ご登壇いただきましたみなさん、ありがとうございました!

ソーシャル タイムでは大倉務(Software Engineer, Tech Lead Manager in Search)や今泉竜一(Engineering Director in Search)、長崎あずさ(Technical Program Manager in Google Assistant)も参加し、Google の検索チームと参加者のみなさんとで交流を深めました。

その他、当日の会場の様子に関しては、今年もハッシュタグ #GoogleDanceTokyo で多くの感想やコメントが投稿されましたので、ぜひご覧ください。

最後に、今年もみなさんから沢山のフィードバックやコメントを頂き、Google の検索チームとしても非常に有益なイベントとなりました。頂いたフィードバックは今後の検索エンジンの改善に役立てていきたいと思います。

お越しいただきましたみなさん、ありがとうございました!
またイベントやウェブマスター オフィスアワーでお会いしましょう!

※ 残念ながら当日お越しいただけなかったみなさん、検索のご質問はウェブマスター ヘルプ フォーラムやウェブマスター オフィスアワーでも受け付けておりますのでぜひご利用下さい。また、様々なイベントに参加しておりますのでぜひ直接イベントにお越し頂き、その際にご質問いただければと思います。

Posted by Takeaki Kanaya (Senior Search Evangelist), Kazushi Nagayama (Ninja Spamologist), Gary Illyes (Webmaster Trends Analyst), and Anna Ogawa (Mobile Solutions Consultant)

Symantec の PKI の無効化について: 要対応確認

この記事は Chrome セキュリティ チーム、Devon O'Brien、Ryan Sleevi、Emily Stark による Google Security Blog の記事 "Distrust of the Symantec PKI: Immediate action needed by site operators" を元に翻訳・加筆したものです。また、Google Developers Japan ブログに投稿された記事のクロスポストです。詳しくは元記事をご覧ください。

以前にお知らせしたように、Chrome での Symantec の認証局(Symantec が所有する Thawte、VeriSign、Equifax、GeoTrust、RapidSSL などのブランドも含む)への信頼が無効化される予定です。本投稿では、サイト運営者が今回の無効化によって影響を受けるかどうかを判断する方法と、影響を受ける場合、いつまでに何をする必要があるのかについて説明します。対象となる証明書の置き換えを行わないと、Chrome などの主要なブラウザの今後のバージョンで、サイトを正しく閲覧できなくなります。

Chrome 66

2016 年 6 月 1 日より前に発行された Symantec の SSL/TLS 証明書を使っているサイトは、Chrome 66 で動作を停止します。これにより、すでにユーザーに影響が出ている可能性があります。

サイトで対象となる証明書を使っているかどうかわからない場合は、Chrome Canary 版で変更をプレビューして、サイトが影響を受けるかどうかを確認できます。サイトに接続した際に、下のような証明書エラーや DevTools での警告が表示される場合、証明書を置き換える必要があります。新しい証明書は、どの信頼されている CA からでも取得できます。最近 Symantec の CA ビジネスを買収した Digicert も利用できます。

2016 年 6 月 1 日より前に発行された Legacy Symantec SSL/TLS 証明書を使っている場合に Chrome 66 ユーザーに表示される可能性がある証明書エラーの例。 


Chrome 66 のリリース前に、証明書を置き換える必要がある場合に表示される DevTools のメッセージ。

Chrome 66 は、Canary チャンネルと Dev チャンネルですでにリリースされています。そのため、これらの Chrome チャンネルを使っているユーザーは、すでに影響を受けている可能性があります。影響を受けるサイトが 2018 年 3 月 15 日までに証明書を置き換えなかった場合、Chrome ベータ版のユーザーにもエラーが発生し始めます。Chrome Canary 版から現在のサイトを開いてエラーが発生する場合、できる限り早く証明書を置き換えることを強くおすすめします。

Chrome 70

Chrome 70 以降、他のすべての Symantec SSL/TLS 証明書が動作しなくなり、前述のような証明書エラーが発生します。お使いの証明書が影響を受けるかどうかを確認するには、現在の Chrome を使ってサイトにアクセスし、DevTools を開きます。証明書を置き換える必要がある場合、そのことを通知するメッセージがコンソールに表示されます。

Chrome 70 のリリース前に、証明書を置き換える必要がある場合に表示される DevTools のメッセージ。

DevTools にこのメッセージが表示される場合は、できる限り早く証明書を置き換えてください。証明書を置き換えないと、早ければ 2018 年 7 月 20 日より、サイトで証明書エラーが発生し始めます。最初の Chrome 70 のベータ版リリースは、2018 年 9 月 13 日頃を予定しています。

Chrome のリリース予定スケジュール

下の表は、Chrome 66 および 70 の最初の Canary 版、ベータ版、安定版リリースの日程を示しています。リリースによって受ける影響は、最初の Canary 版リリースのタイミングから発生しはじめます。それ以降、ベータ版、そして最終的に安定版がリリースされるにつれて、対象端末が徐々に広がります。サイト運営者の方には、Chrome 66 および 70 の最初の Canary リリースが行われる前、遅くともベータ版のリリース日までに必要な変更を行うことを強くおすすめします。

リリース
最初の Canary 版
最初のベータ版
安定版リリース
Chrome 66
2018 年 1 月 20 日
~ 2018 年 3 月 15 日
~ 2018 年 4 月 17 日
Chrome 70
~ 2018 年 7 月 20 日
~ 2018 年 9 月 13 日
~ 2018 年 10 月 16 日

特定のバージョンの Chrome のリリース スケジュールに関する情報は、Chromium 開発カレンダーにも掲載されています。リリースのスケジュールが変更になった場合は、このカレンダーが更新されます。

特定の企業ユーザーのニーズに対応するため、Chrome 66 以降では、Legacy Symantec PKI の無効化を停止する Enterprise Policy も実装されます。2019 年 1 月 1 日には、このポリシーは利用できなくなり、すべてのユーザーに対して Legacy Symantec PKI が無効化されます。

特記事項: Chrome 65

以前のお知らせにありましたように、2017 年 12 月 1 日以降に Legacy Symantec PKI から発行された SSL/TLS 証明書は信頼されなくなります。対象となる証明書は、DigiCert と特別な契約を結んでいなければ取得できないので、これによって影響を受けるサイト運営者はほとんどありません。Chrome 65 時点で、対象となる証明書を使っているサイトにアクセスすると、エラーが発生してリクエストはブロックされます。このエラーを回避するには、対象となる証明書が Chrome などのブラウザではなく、以前の端末のみに対してサービスを提供するようにします。


Reviewed by Eiji Kitamura and Yoshifumi Yamaguchi - Developer Relations Team

モバイル ファースト インデックスを開始します

本日、Google は 1 年半の慎重な実験とテストの結果、モバイル ファースト インデックスのベストプラクティスに準拠したサイトの移行を開始したことを発表します。

これまで、Google のクロール、インデックス、ランキング システムでは、主にデスクトップ版のコンテンツが使用されてきました。そのため、その内容がモバイル版と大きく異なる場合、モバイル検索ユーザーに問題が発生する可能性がありました。 モバイル ファースト インデックスとは、モバイル版のページをインデックスやランキングに使用し、主にモバイル ユーザーが探しているものを見つけやすくすることを意味します。

検索結果の提供に使用するインデックスは引き続き 1 つのままです。 メインのインデックスとは別の「モバイル ファースト インデックス」はありません。 歴史的にデスクトップ版のコンテンツがインデックスされてきましたが、今後はモバイル版のコンテンツを使用していきます。
モバイル ファースト インデックスに移行しているサイトは、Search Console で通知します。 サイト所有者は、スマートフォンの Googlebot からのクロールが大幅に増加することに気づくでしょう。 さらに Google は検索結果と Google のキャッシュ ページにモバイル版のページを表示します。
Search Console でのメッセージ例(英語の場合)


Google がモバイル コンテンツを特定する方法の詳細については、デベロッパー向けドキュメントをご覧ください。 レスポンシブ ウェブデザインやダイナミック サービングを使用しているサイトでは、一般的にモバイル ファースト インデックスが設定されています。AMP ページと非 AMP ページを持つサイトの場合、モバイル版の非 AMP ページをインデックスします。

最初のローンチのタイミングで適用されなかったとしても、慌てる必要はありません。 モバイル ファースト インデックスは、コンテンツのランキング方法ではなく、コンテンツの集め方に関するものです。コンテンツが モバイル ファースト インデックスによって集められたものであったとしても、その他の方法で集められたコンテンツやデスクトップ版のコンテンツに比べてランキング優位性があるというわけではありません。 さらに、デスクトップ版のコンテンツのみをお持ちの場合でも、コンテンツは引き続きインデックスされます。

一方で、Google ではモバイル フレンドリーなコンテンツを引き続き推奨しています。 私たちは、インデックスのすべてのコンテンツ(デスクトップであろうとモバイルであろうと)を評価して、それがモバイルフレンドリーであるかどうかを判断します。2015 年以降、この評価によって、モバイルで検索しているユーザーは、モバイルフレンドリーなコンテンツを検索結果からより簡単に見つけられるようになりました。 これに関連して、2018 年 7 月初めより、表示に時間のかかるコンテンツは、デスクトップとモバイルの両方の検索結果に悪影響が出ることが、最近発表されました

要点をまとめると:
  • モバイル インデックスを、より広範に展開します。 この方法でインデックスされたとしても、ランキング優位性はなく、モバイル フレンドリーの評価とは独立して動作します。
  • モバイル フレンドリーなコンテンツは、モバイル検索結果の成果を上げる方法を検討しているウェブマスターにとって役立ちます。
  • コンテンツを高速に読み込むことは、モバイルとデスクトップ両方のユーザーにとってより良い成果を上げる方法を検討しているウェブマスターにとっては、依然として役立ちます。
  • いつものように、ランキングには多くの要素を使用します。 他の多くの信号が最も関連性の高いコンテンツであると判断した場合は、モバイルフレンドリーでないコンテンツや、読み込みが遅いコンテンツをユーザーに表示することがあります。

Google はこの変更を慎重に確認して評価し続けます。 ご不明な点がございましたら、ウェブマスター ヘルプ フォーラムまたはイベントでご質問ください。

ハッキングに強いサイトを作るヒント:サイバーセキュリティ月間によせて

2 月 1 日 ~ 3 月 18 日は「サイバーセキュリティ月間」です。
サイバーセキュリティ月間に合わせて、本日は、日本においても引き続き被害が多く見られる不正なハッキングから、サイトを守るための Tips を改めてご紹介したいと思います。

そもそも不正なハッキングはなぜ起きるのでしょうか。不正に金銭を取得することだったり、政治的または社会的なメッセージを伝えることだったりと、不正なハッキングの目的はさまざまです。悪質なハッカーはサイトの脆弱性を狙ってサイトに不正にアクセスし、あなたの管理権限を乗っ取ります。そして、サイトを改ざんし、別のサイトへの誘導などの踏み台に利用します。それによってあなたのサイトにアクセスしていると思っているユーザーは、知らない間にフィッシング サイトや偽のショッピングサイトに誘導され、その結果として個人情報や金銭を奪われるといった被害にあうかもしれません。みなさんのサイトがこうした犯罪に加担してしまわないよう、ぜひサイトのセキュリティを高め、ハッキングを防ぎましょう。

Google ではさまざまな形でウェブスパムなどへの対策を行っていますが、Advanced Hosting Meetup のようにインターネット サービスを提供する他の会社のみなさんと企業の枠を越えた対策も行っています。そこで、今回 Advanced Hosting Meetup のメンバーや、ホスティング会社としてさくらインターネット株式会社様と GMOペパボ株式会社様、そして WordPress コミュニティのみなさんにもサイトのハッキングを防ぐためのアイディアをお伺いしました。その中でみなさんからのアイディアに共通してみられたハッキングを防ぐためのコツを 3 つご紹介します。
  • パスワードを複雑なものにする


  • パスワードをデフォルトのままにしていたり、同じパスワードを複数のサービスで使いまわしていたり、一般的な推測されやすい単語にしていたりと、パスワードを適切に設定・管理されていない方が多く見られます。パスワードは覚えられないくらい複雑なものにして、パスワードマネージャなどを使うことをお勧めします。また、パスワードだけでなく、2 段階認証などが利用できる場合は 2 段階認証を必ず使うようにしましょう。
  • CMS やシステムを最新に保つ

  • CMS やプラグインは必ず最新に保つよう心がけましょう。CMS 側から提供されているアップデートは、多くの場合自動的に適用されるように設定できます。残念なことにデフォルトで自動アップデートになっているものを手動で停止してハッキングの被害にあうケースが数多く見られます。自動アップデートはオフにせず、必ず最新の CMS を使うようにしてください。
    ※ WordPress については、WordPress コミュニティで「あなたのWordPressを安全に保つ方法」という記事も公開されましたのであわせてご覧ください。
  • ファイアウォールをきちんと管理する


  • 多くのホスティング サービスではファイアウォール サービスを提供しています。しかし、デフォルトでオンになっているファイアウォールを停止したり、いくつかのポートを公開し、結果としてセキュリティを落としているサービスが数多く見られます。ファイアウォールはきちんと管理・設定しましょう。例えば、管理者権限があるサーバサービスではファイアウォールを適切に設定しないと脆弱なポートが開放されたままになってしまいます。きちんと設定して使用するポートだけを開放しましょう。また、多くのレンタルサーバ サービスではウェブ アプリケーション ファイアウォール(WAF)機能が提供されておりますので、これを ON にすることにより脆弱性を利用した攻撃などを防ぐことができるようになります。
最後に、昨年末にグローバルで行った #NoHacked キャンペーンの記事を改めてご紹介します。

ソーシャル
ブログ

インターネットの安全性を高めるためには、ウェブマスター(サイト運営者)のみなさんのご協力は不可欠です。
ぜひこの機会にみなさんのサイトが安全に管理されているか、確認してみてください。

インターネットがより安全に安心して使える場所となるように、Google は今後もさまざまな活動を実施していきます。

Takeaki Kanaya and Kiyotaka Tanaka, Online Safety Samurai, Google Japan

保護されたウェブの普及を目指して

この記事は Chrome セキュリティ プロダクト マネージャー、Emily Schechter による Chromium Blog の記事 "Chromium Blog: A secure web is here to stay" を元に翻訳・加筆したものです。また、Google Developers Japan ブログに投稿された記事のクロスポストです。詳しくは元記事をご覧ください。

私たちはここ数年間、サイトで HTTPS による暗号化を採用するよう強く働きかけることによって、保護されたウェブを目指してきました。そして昨年は、「保護されていません」と表示される HTTP ページを徐々に増やすことによって、HTTP サイトが保護されていないことをユーザーに理解してもらうよう努めてきました。2018 年 7 月に Chrome 68 がリリースされると、すべての HTTP サイトに「保護されていません」と表示されるようになります。

Chrome 68 では、すべての HTTP ページのオムニボックスに「保護されていません」と表示されます。

デベロッパーはサイトを HTTPS に移行し、ウェブを誰でも安全に使えるようにしてきました。昨年の進展はめざましく、その動きはさらに続いています。

  • Android と Windows の Chrome トラフィックの 68% 以上が保護されています。
  • Chrome OS と Mac での Chrome トラフィックの 78% 以上が保護されています。
  • ウェブ上のトップ 100 サイトのうち、81 がデフォルトで HTTPS を使用しています。

Chrome は、HTTPS をできるだけ簡単に設定できるようにするために貢献しています。デベロッパーがサイトを HTTPS に移行する助けになるように、ウェブページを改善するための自動ツール、Lighthouse最新 Node CLI 版では、混合コンテンツの監査が可能になっています。この Lighthouse の新しい監査機能を使うと、HTTP を使ってサイトに読み込まれているリソースや、サブリソースの参照を HTTPS 版に変更するだけで HTTPS にアップグレードできるリソースを見つけることができます。

Lighthouse は、ウェブページを改善する自動デベロッパー ツールです。

Chrome の新しいインターフェースでは、すべての HTTP サイトが保護されているわけではないことがわかりやすくなるため、ウェブをデフォルトで保護された HTTPS に切り替えるよう促す効果があります。HTTPS は、今までになく簡単で安価なものになり、パフォーマンスの改善や、HTTP で扱うには危険だった、パワフルな新機能を利用可能にします。デベロッパーの皆さんは、まずセットアップ ガイドをご覧ください。

Reviewed by Eiji Kitamura - Developer Relations Team

Google Dance Tokyo 2018 開催のお知らせ

Google Dance Tokyo を今年も開催します。本イベントは Google の検索チームと、ウェブマスターやサイト運営に関わる皆さんを結ぶことを目的にしたもので、今年で 3 回目の開催となります。

今年の Google Dance Tokyo では昨年に引き続き Gary Illyes、長山一石、小川安奈、そして金谷武明が参加し、Google 検索についてのセッションや Q&A の時間を設けるほか、Google 社員と参加者のみなさんの交流タイムなどを予定しています。開催概要は次のとおりです。

開催概要
日時:2018 年 4 月 3 日(火)
   13 時 00 分開場、14 時 00 分開始
   21 時 00 分頃終了予定
場所:Google 東京オフィス
費用:無料
定員:200 名(招待枠含む)

お申し込みはこちらから!
(締め切り:2018 年 3 月 5 日(月) 深夜 0 時まで)

今年も参加者のみなさんからの Lightning Talk タイムを設けたいと思います。
みなさまのご応募お待ちしております!

※ 参加者は抽選で決定し、3 月 8 日以降に当選者のみご連絡いたします。
※ 会場までの交通費等のサポートはありませんのでご了承ください。

Takeaki Kanaya, Senior Search Evangelist, Google

ユーザーからのフィードバックが Search Console の改善に役立ちました

新しい Search Console のベータ版が、いよいよ本格稼働しました。Google ではこれまで、皆様からのさまざまなフィードバックに耳を傾け、ユーザーの声をデザインに反映するための新たな方法を模索してきました。今回の新しいリリースでは、当初はユーザーの主要な目標をサポートする機能の構築に注力してきましたが、今後数か月は機能の拡張を進めていく予定です。UI にマテリアル デザインを採用するなど長らく期待されてきた変更点もある一方で、多くの機能は、Search Console ユーザーである皆様に継続的にご協力いただいた結果、実現したものです。

ユーザーのご意見を伺うにあたっては、主に次の 3 種類のコミュニケーション チャネルを利用してきました。

  • ヘルプ フォーラムのトップレベル ユーザー - ウェブマスター ヘルプ フォーラムトップレベル ユーザーの方々には、フォーラムに投稿されたトピックを提起するという重要な役割を担っていただいています。トップレベル ユーザーは、Google の検索チームと定期的にコミュニケーションをとり、Search Console ユーザーという大規模なコミュニティを支える存在です。
  • オープン フィードバック - 従来の Search Console についてのフィードバック コメントを分析し、ご要望が特に多かったリクエストを特定しました。このフィードバックは、Search Console の [フィードバックを送信] ボタンをクリックして送信できます。このフィードバックにより、昨年多く寄せられた「検索アナリティクス(検索パフォーマンス)レポートで 90 日以上のデータを見たい」というリクエストについて、その詳しい理由を把握することができました。前年の同時期との比較が必要だということがわかったため、16 か月分のデータを利用できるようにしたその決断が正しかったことを確認できました。
  • Search Console パネル - 昨年新たに構成されたコミュニケーション チャネルです。あらゆる規模のウェブサイトから Search Console ユーザーを無作為に 400 人選び、1 つのグループとしてご協力いただいています。このパネルのメンバーは年間を通して、サーベイによる新しいコンセプトの検証からインタビューやユーザビリティ テストに至るまで、ほぼすべてのデザインの試行錯誤の過程に参加してきました。Search Console パネルメンバーの皆様には、仮説検証からデザインを改良するまでに役立つ有益なフィードバックを提供していただいています。

こうした取り組みの一環として行ったもののひとつが、検索パフォーマンス レポートについて新しく提案されたデザインのテストです。具体的な目的は、「比較」機能と「フィルタ」機能の使い方がわかりやすいかどうかを確認することでした。できるだけリアルに感じられるテストにするため、実際のデータに接続した本物に近いプロトタイプを使用しました。このプロトタイプでは、本番用コードが 1 行も記述されていない状態でも、テスト参加者が自由にユーザー インターフェースを操作できるようにしました。

このテストでは、「比較」機能が見落とされることが多いことがわかりました。そこで、[新規] チップをクリックすると開く統合されたダイアログ ボックスに「フィルタ」と「比較」が表示されるデザインに変更しました。このデザインに加えて他のデザインについても、ユーザビリティや利便性を最適化できるよう引き続きテストを行いました。

ユーザーからのフィードバックは、実際のデザインの細部だけでなく、構成に関する判断にも取り入れています。たとえば、ユーザーのフィードバックを基に、Search Console の中心となる情報アーキテクチャを大きく変更した結果、新しい Search Console 内のナビゲーションやプロダクトの構成も大きく変わりました。エラーに関するレポートとインデックス カバレッジレポートは当初は別々であったため、同じエラーが複数検出されてしまいました。これらのレポートを 1 つにまとめて包括的に把握できるようにしたのも、ユーザーのフィードバックを受けた結果です。

公開日が近づくにつれて、さらに大規模なテストをいくつか実施しました。30,000 人のユーザーを対象に、新しい Search Console の一部のレポートと既存のレポートを比較する A/B テストを行いました。問題の修正率を記録して、新しい Search Console の方が良好な結果をもたらすことを確認し、テストについて調べるためフォローアップのアンケートを送信しました。この最新のフィードバックから、エクスポート機能が、単にあると便利というよりむしろ多くのユーザーにとって欠かせない機能であることがわかりました。また、最初のリリースで詳細なヘルプページを用意するという点でも、フィードバックが役立ちました。

新しい Search Console は、現在すべてのサイトでご利用いただけるようになっています。Google では、Search Console のフィードバック ボタンやユーザーパネルなどの手段を通じてご協力いただきながらデザインを進めることを重視しています。最良のプロダクトを作ることができるのは、ユーザーの皆様のおかげです。

新しい Search Console を試してみる

新しい Search Console は、まだ完成したわけではありません。今後取り入れてほしいという機能がありましたら、ぜひ Search Console 上のフィードバックボタンからお知らせください。皆様からのフィードバック、お待ちしています!

Lighthouse Chrome 拡張機能に追加された SEO カテゴリのご紹介

Lighthouse Chrome 拡張機能に、新しく SEO カテゴリが追加されましたのでご紹介します。

Lighthouse は、ウェブページの品質向上に役立つよう開発された、オープンソースの自動化されたツールです。サイトのパフォーマンス、アクセシビリティ、プログレッシブ ウェブアプリ(PWA)対応状況などについての確認でき、サイトの品質を向上させるための具体的な対策を提示します。デベロッパーの皆様が「暗礁に乗り上げないようにする」ことを目的としているため、「Lighthouse(灯台)」と名付けられました。

Lighthouse 内の SEO カテゴリでは、ウェブページの基本的な「SEO ヘルスチェック」を実行できます。その結果、デベロッパーやウェブマスターの皆様にウェブページで改善可能な箇所を見つけていただけるようになっています。Lighthouse は Chrome ブラウザでローカルに実行されるため、ステージング環境でも、公開中のページでも、認証が必要なページでも、同じように SEO 監査を実行できます。

SEO のおすすめの方法を提示

現在の SEO 監査項目はすべてを網羅したものではなく、Google ウェブ検索やその他の検索エンジンでの SEO を保証するものでもありません。現在のリストは、どのサイトも知っておくべき基本事項を検証、反映できるよう設計されており、あらゆるスキルレベルの SEO 担当者やデベロッパー向けに詳細なガイドを提供します。将来的には、さらに詳しい監査やガイドをご提供したいと考えています。ご利用になりたい監査の種類についてご意見やご提案がございましたら、ぜひお知らせください。

使用方法

現在、SEO 監査は以下の 2 種類の方法で実行できます。

Lighthouse Chrome 拡張機能を使用する:
  1. Lighthouse Chrome 拡張機能をインストールします。
  2. 拡張機能バーの Lighthouse アイコンをクリックします。
  3. [Options] メニューを選択し、[SEO] チェックボックスをオンにして [OK] をクリックしてから [Generate report] をクリックします。
  4. Lighthouse 拡張機能で SEO 監査を実行する
Chrome Canary で Chrome デベロッパー ツールを使用する:
  1. Chrome デベロッパー ツールを開きます。
  2. [Audits] に移動します。
  3. [Perform an audit] をクリックします。
  4. [SEO] チェックボックスをオンにして、[Run Audit] をクリックします。
  5. Chrome Canary で SEO 監査を実行する

現在の Lighthouse Chrome 拡張機能に含まれる SEO 監査項目は、今後拡張、強化していく予定です。確実に機能することが確認でき次第、Chrome デベロッパー ツールでもデフォルトで SEO 監査をご利用いただけるようにいたします。

皆様が現在取り組んでいるプロジェクトや今後のプロジェクトで、この機能がお役に立てば幸いです。SEO に関するこうしたヒントをご存知でなかった方や、SEO に関心をお持ちの方は、検索エンジン最適化(SEO)スターター ガイドをご覧になることをおすすめします。ご意見やご提案がございましたら、GitHubウェブマスター ヘルプ フォーラムでお寄せください。

ページの読み込み速度をモバイル検索のランキング要素に使用します

検索ユーザーはできるだけ早く質問に対する回答を見つけたいと考えています。研究(英語)では、ユーザーはページの読み込み速度を非常に気にかけていることがわかっています。 読み込み速度はこれまでもランキング シグナルとして使用されていましたが、それはデスクトップ検索を対象としていました。 そこで 2018 年 7 月よりページの読み込み速度をモバイル検索のランキング要素として使用することを本日みなさんにお伝えしたいと思います。

この ”Speed Update” (と私たちは呼んでいます)は、ユーザーに本当に遅い体験を提供しているようなページについてのみ影響し、ごくわずかな割合のクエリにしか影響しません。 そのページがどのような技術を用いて制作されたかに関係なく、すべてのページに同じ基準を適用します。 検索意図は依然として非常に強いシグナルですので、魅力的で検索クエリと関連性の高いコンテンツは、ページの読み込み速度が遅くても高い順位に掲載される場合もあります。

サイト制作に関わるみなさまには、パフォーマンスがそのページのユーザー体験にどのように影響するかを広く考え、そしてさまざまなユーザー エクスペリエンスの指標を考慮することをおすすめします。 ページがこの新しいランキング要素の影響を受けるかどうかを直接示すツールはありませんが、ページのパフォーマンスを評価するために使用できるリソースは次のようなものがあります。
  • Chrome のユーザー エクスペリエンス レポートは、ウェブ上の人気のあるサイトを Chrome ユーザーが実際に閲覧した際の、ユーザー エクスペリエンスの主な指標に関する一般公開データセットです。
  • Lighthouse は、ウェブページの品質(パフォーマンスやアクセシビリティなど)を監査するための自動化されたツールで、Chrome Developer Tools の機能の一部として提供されています。
  • PageSpeed Insights は、Chrome のユーザー エクスペリエンス レポートのデータを利用してページがどのくらいのパフォーマンスを発揮しているかを示し、その最適化を提案するツールです。
ご質問やご意見がございましたら、お気軽にウェブマスター ヘルプ フォーラムでお知らせください。

PageSpeed Insights にリアルワールドデータを導入しました

PageSpeed Insights では、指定のページがどの程度 Web のベスト プラクティスを適用しているのかを確認できます。従来の PageSpeed Insights は、実際のページ速度については一切言及していなかったため、表示される最適化についての提案内容をそもそも適用する必要があるのかを判断するのが困難でした。そこで本日より PageSpeed Insights では Chrome ユーザー エクスペリエンス レポート(以降 CrUX と呼ぶ)のデータを利用して、よりデベロッパーにとって意味のある提案を提供いたします。これに伴い、最適化スコアについても実際のパフォーマンスに沿った数値になるよう改善されています。
新しい PageSpeed Insights レポートには次の項目が追加されています。
  • 速度スコアでは、ページを「Fast」、「Average」、「Slow」のいずれかに分類します。このスコアは、指定したページの CrUX 上に記録されている First Contentful Paint(FCP)と DOM Content Loaded(DCL)の値の中央値を利用して算出されています。たとえば、FCP・DCL いずれの指標も CrUX に記録されている全データと比較して上位 1/3 に入っている場合、ページは「Fast」(高速)であると判断されます。
  • また、最適化スコアでは、ページにあとどのくらい改善の余地があるかを判断し、「Good」、「Medium」、「Low」のいずれかに分類します。この計算は、ページの外観と機能の変更は行わない前提で評価されます。
  • [ページの読み込み分布] には、指定したページの FCP と DCL の値がどのように分布しているかが表示されます。指定したページの各 FCP・DCL の値が、CrUX に記録されている全データと比較して「Fast」(上位の 1/3)、「Average」(中間の 1/3)、「Slow」(下位の 1/3)のいずれかに分類されます。
  • [ページの統計情報] には、指定したページのレンダー ブロッキング リソースを読み込むために必要なラウンドトリップの回数、使用した合計バイト数が表示されます。また、比較対象としてその他ページのラウンドトリップ回数と合計バイト数の中央値も確認できます。これは、ページの外観や機能への変更も視野に入れラウンドトリップ回数や合計バイト数を減らす対応を行うことで、スピード改善する余地があるかどうかを判断するのに利用できます。
  • [最適化についての提案] には、このページに適用可能なベスト プラクティスの一覧が表示されます。指定したページが、すでに上位 1/3 に入っていると評価された高速のページの場合は、デフォルトではこの提案は表示されません。
上記の変更について、詳しくは PageSpeed Insights についてをご覧ください。ご質問やご意見がございましたら、お気軽に PageSpeed Insights のコミュニティまでお寄せください。その際は、評価対象の URL についてもお知らせください。

新しい Search Console をご紹介します

数か月前、一部の方を対象に新しい Search Console のベータ版のユーザテストを開始したことをアナウンスしました。そしてこの度、Search Console のすべてのユーザーのみなさまにこのベータ版をご利用いただけるようになりましたことをお知らせします。どなたでも Google 検索上のウェブサイトの掲載状況を最適化する、よりシンプルになったこのプロセスを試すことができるようになります。新しい機能には、検索パフォーマンスインデックス カバレッジAMP ステータス、および Job Posting のレポートが含まれます。新しい Search Console をご利用いただく準備ができましたら、メッセージをお送りし、お知らせします。

Google は、みなさんが日々利用されており、最も人気のある機能を中心に新しい Search Console に追加することからはじめました。この機能追加はまだ完了していないため、今後も引き続き新しい Search Console(ベータ版)では従来の Search Console の機能を追加していく予定です。新しい Search Console が完成するまで、両方のバージョンを並行して提供します。この両バージョンはナビゲーションバーのリンクを介して簡単に行き来できるため、みなさんは両方のバージョンを使用できます。

新しい Search Console は、ゼロからの再構築となりました。これは、可能な限り実用性のあるインサイトをユーザーに提供し、それらに沿ったガイドを行うことで、あらゆる未解決の問題をユーザー自身が解決できるような相互に作用する問題解決モデルを構築するためです。社内のコラボレーションをシンプルにするために、ご自身の組織内でレポートを共有する機能も追加しました。


検索パフォーマンス レポート: 16 か月分のデータをご利用いただけます!


もしあなたが検索アナリティクスを日頃からご利用いただいているなら、新しい検索パフォーマンス レポートもきっと気にいるでしょう。検索アナリティクスでより長い期間のデータが見たい、という機能を待ち望んでいた方も多いと思います。新しいレポートでは、長期的な傾向をより簡単に分析し、前年度の比較を可能にするために、16 か月分のデータをご利用いただけます。近い将来、このデータは Search Console API(英語) 経由でも利用可能になります。


インデックス カバレッジ : Google のインデックスの包括的なレポート


新しくなったインデックス カバレッジ レポートでは、あなたのウェブサイトの URL のインデックス状況を確認することができます。正しくインデックス登録されている URL、潜在的な問題に関する警告、Google がいくつかの URL のインデックスを作成していない理由などを表示します。このレポートは、新しい問題が検出されたときに警告を出したり、修正状況を管理しやすくするなど問題の解決状況をトラッキングする新機能に基づいて構築されています。

それらはどのように機能するのでしょうか。
  1. 問題の原因を調べていくと、URL のサンプルが表示されます。エラーが発生している URL をクリックすると、ページの詳細が表示され、問題の原因を把握するのに役立つ診断ツールへのリンクが表示されます。
  2. 検索の問題を解決するには、社内の複数のチームが関与することがよくあります。適切な人が現在のステータスやそこに発生している情報にアクセスできるようにすることは、サイトをすばやく改善する上で重要です。新しい Search Console のほとんどのレポートでは、レポートの上部にある [共有] ボタンを使用して、レポートに共有可能なリンクを作成できます。問題が解決されたら、共有を簡単に無効にすることができます。
  3. 新しい Search Console は、問題が解決したことをユーザー自身が確認するのに役立つだけでなく、それに従って Google がインデックスを更新するのにも役立ちます。これを行うには、報告されている問題を選択し、[修正を検証] をクリックします。Google は、影響を受けた URL を優先度を上げてクロール・再処理し、サイトの問題をこれまで以上に迅速に解決することに役立ちます。
  4. インデックス カバレッジ レポートは、サイトマップ ファイルを送信しているサイトに最適です。サイトマップ ファイルは、検索エンジンに新しい URL や更新された URL を知らせるのに適した方法です。サイトマップ ファイルを送信することで、インデックス カバレッジ データにサイトマップ フィルタを使用できるようになり、URL の正確なリストに絞ることができます。

検索機能の拡張 : AMP および Job Posting ページを改善する

新しい Search Console は、AMP や Job Postings などの検索機能の実装支援も目的としています。これらのレポートは、Google がこれらのトピックについて特定したエラーと警告の詳細を提供します。インデックス カバレッジ レポートでご紹介した機能に加えて、2 つの追加機能を備えたレポートを追加しました。
  • 最初の機能は、問題を修正するプロセスでより速いフィードバックを提供することを目的としています。これは、[修正を検証] ボタンをクリックすると、いくつかの瞬間的なテストを実行することによって実現されます。あなたのページがこのテストに合格しなかった場合は、すぐに通知します。それ以外の場合は、影響を受けたページを再処理します。
  • 2 番目の新機能は、検証処理中に肯定的なフィードバックを提供することを目的とし、(検証に失敗した URL または保留中の URL に加えて)修正済みと認識された URL のリストを提供するよう検証ログの項目を拡張します。

AMP レポートと同様に、新しい Search Console は Job Posting レポートを提供します。あなたのウェブサイトに求人情報を掲載している場合は、Google for Jobs (現時点では特定の地域でのみ利用可能)で求人情報を直接表示することができます。


フィードバックをお待ちしています

信頼できる熱心なベータテスターからのフィードバックがなければ、このような改善をすることはできませんでした(フィードバックがどのように Search Console の改善に役立ったのかについては今後またお伝えする予定です)。もちろん、みなさんからのフィードバックも同様に重要だと考えています。混乱を招くものや間違っているものを発見した場合、または本当に気に入った機能がある場合は、サイドバーのフィードバック機能を通じてお知らせください。また、新しい Search Console のモバイル対応については今後対応予定です。

最後に、新しい Search Console のテストユーザーから最近寄せられた励ましのコメントを共有してこのブログの締めくくりとしたいと思います。

「新しい Search Console はシンプルでよく練られており、これまでそうなって欲しいと期待していたような UX となりました。修正の検証を実行したり、結果を電子メールで受け取ることもできます。それらは弊社サイトのページに影響を与えた厄介な AMP のエラーと警告の修正に大いに役立ちました。何より、検索アナリティクス レポートのデータの参照範囲は現在 16 ヶ月分にまで及んでおり、これは弊社の業務において大きな変革をもたらしました」 -  Noah Szubski, Chief Product Officer, DailyMail.com

ご不明な点などございましたら、お気軽にウェブマスター ヘルプ フォーラムでお知らせください。

2017 年もありがとうございました!ブログのアクセスランキングで振り返る 2017 年

2017 年もいよいよ終わりが近づいてまいりました。今年もウェブマスター向け公式ブログをはじめ、ウェブマスター ヘルプ フォーラムGoogle ウェブマスター コミュニティ、そして ウェブマスター オフィスアワー やイベントなど、多くの方にご参加、ご愛読いただき、ありがとうございました!

みなさんにとって今年はどんな一年だったでしょうか。今年は Google Analytics によるセッション数ランキングトップ 10 でウェブマスター向け公式ブログの 1 年を振り返ってみたいと思います。
  1. 日本語検索の品質向上にむけて
  2. 医療や健康に関連する検索結果の改善について
  3. モバイル ファースト インデックスに向けて
  4. Google 検索における最新の品質向上について
  5. HTTPS をランキング シグナルに使用します
  6. Google の検索結果からコンテンツを削除するには
  7. 3/24 開催イベントのお知らせ「オンラインメディアのための Google 検索入門&コンテンツ制作のベストプラクティス」
  8. Chrome の HTTP 接続におけるセキュリティ強化に向けて
  9. HTTPS ページが優先的にインデックスに登録されるようになります
  10. 良質なサイトを作るためのアドバイス
2016 年はモバイルの話題が中心でしたが、2017 年は検索結果の品質に関連する記事が 1 位、2 位、4 位、そして 10 位と数多く読まれていたようです。モバイルの記事は昨年 11 月にアナウンスしたモバイルファーストインデックスの記事が 3 位に入りました。また、HTTPS 関連の記事もトップ 10 に 3 つの記事が入っており、ホットな話題だったことが伺えます。

また、2017 年は Google Dance Tokyo#GoogleDanceTokyo) など主催イベントを 2 つ開催しました。特に今年初めて開催したオンラインメディア向けのイベント(#読者ファースト)はランキングでも 7 位と多くの方に関心を持っていただいたようで、来年もまた何か開催できたら、と思っています。

そして残念ながらランキング入りは逃したものの、ブログ ホスティング サービス運営者のみなさまと取り組んでいる Advanced Hosting Meetup プログラムは、参加サービスが増えるなど、活動の幅も広がっております。来年も少しでもユーザーのみなさまが快適にインターネット上の情報にたどり着けるように努力していきたいと思います。

最後となりますが、みなさんが年末年始も安心してオンライン ショッピングをご利用いただけるよう、昨年に引き続き #NoHacked キャンペーン(Twitter はこちら)を実施しましたので、ぜひご覧ください。みなさまの Tips も #NoHacked をつけてご投稿いただければと思います。

それでは、2017 年もありがとうございました!2018 年もどうぞよろしくお願いします。

Takeaki Kanaya, Kazushi Nagayama and Anna Ogawa, Search Quality Team

#NoHacked 3.0: 役立つリソース

#NoHacked キャンペーンを開始して 3 週間経ちました。今回は、サイトを安全に保つために役立つリソースをいくつかご紹介します。

  • 興味深い研究成果:
    ハッキング手法は常に進化しており、最新の傾向を把握してより効果的に対処するためには日々の研究が欠かせません。情報セキュリティ研究サイトでは、Google の最新の研究成果を公開しています。このうち、ウェブサイトへの不正アクセスに関する研究成果の一部をご紹介します。
  • ハッキングされたサイトに関するよくある質問
  • ハッキングされたサイトに関する用語集
  • #NoHacked 3.0 はこれで終了しますが、さらにコンテンツを用意して近いうちにまた開催する予定です。それまでの間、ご不明な点がありましたら、ウェブマスター ヘルプ フォーラムにご投稿ください。また、サイトへの不正アクセスに関してフィードバックやご質問があった場合もぜひ、ウェブマスター ヘルプ フォーラムまでお寄せください。Google 社員やセキュリティに詳しいユーザーからアドバイスを得られると思います。

    この投稿で #NoHacked キャンペーンは終了します。このキャンペーンを通じてコンテンツをお楽しみいただき、ハッカーの攻撃を防いでサイトの安全を確保していただければ幸いです。

    モバイル ファースト インデックスに向けてサイトを準備するためのヒント

    Google がモバイル ファースト インデックスの実験を開始することを発表した約 1 年前、この取り組みの進捗状況については追ってサイト運営者の皆様にお知らせすることを約束し、この数か月間、ハングアウト オンエアによるオフィスアワーPubcon などのカンファレンスで発表を行ってきました。

    概要を説明すると、Google の現在のクロール、インデックス登録、ランキングのシステムは、主にデスクトップ版のコンテンツを見ています。ただし、デスクトップ版とモバイル版でコンテンツが大きく異なる場合、この方法ではモバイル検索に不都合が生じる可能性があります。モバイル ファースト インデックスは、インデックス登録とランキングの決定についてモバイル版のコンテンツを使用することで、ユーザー(主にモバイル ユーザー)が探している情報を見つけやすくするための仕様です。この変更後は、スマートフォン用 Googlebot によるクロール回数が大幅に増え、検索結果に表示されるスニペットや Google のキャッシュ ページ内のコンテンツにはモバイル版のページのものが使用されるようになります。

    昨年のブログでご説明したように、レスポンシブ ウェブ デザインを採用しているサイトや動的な配信(デスクトップ版と同等のコンテンツとマークアップをすべて含んでいる)を正確に実装しているサイトに関しては、通常は特に何もする必要はありません。ここでは、モバイル ファースト インデックスに向けてサイトを確実に準備していただけるよう、いくつかのヒントをご紹介します。
    • モバイル版のサイトでも、高品質で重要なコンテンツを揃えるようにします。テキスト、画像(alt 属性を設定)、動画などを、通常のクロールやインデックス登録が可能な形式で準備します。
    • インデックス登録やユーザーが使いやすい検索機能を実現するためには、構造化データが重要です。モバイル版とデスクトップ版の両方のサイトに構造化データを追加するようにしましょう。モバイル ページの構造化データの URL はモバイル版にアップデートしましょう。
    • メタデータはモバイル版と デスクトップ版のどちらのサイトにも必要です。インデックス登録や検索結果の表示の際に、メタデータがコンテンツについてのヒントとなります。タイトル、メタ ディスクリプションなどは、モバイル版と PC 版の両方のサイトの全ページで同じ内容にしましょう。
    • モバイル用の別の URL を使用するサイトでは、モバイル版とデスクトップ版をリンクするための既存の rel=canonical 要素と rel=alternate 要素をそのまま使用します。
    • モバイル用 URL の hreflang リンクを確認します。国際化対応のために link rel=hreflang 要素を使用する場合は、モバイル用 URL とデスクトップ用 URL 間のリンク要素を個別に設定します。モバイル用 URL の hreflang では、別の言語や地域のバージョンのモバイル用 URL を指定する必要があります。デスクトップ用 URL の場合も同様にして hreflang リンク要素を使用します。
    • サイトをホストするサーバーについて、クロール速度が上がった場合に対応できるだけの容量があることを確認します。これは、モバイル版のサイトを別のホスト(たとえば m.example.com)から配信している場合に必要です。レスポンシブ ウェブ デザインを採用しているサイトや動的な配信を行っているサイトには関係ありません。
    Google では上記の基準に基づいて、モバイル ファースト インデックスに対応しているかどうかをサイトごとに評価し、準備が整ったサイトから移行していく予定です。このプロセスは、ごく一部のサイトに対してすでに開始されており、検索チームが経過を注意深く観察しています。

    モバイル ファースト インデックスの導入については、今後も慎重に取り組んでまいります。Google では、このように時間をかけて進めていくことで、ウェブマスターの皆様にモバイル ユーザー向けのサイトを準備していただけると考えています。そのため、モバイル ファースト インデックスのロールアウトを完了する時期についても、現在のところ特に定めていません。ご不明な点などございましたら、お気軽にウェブマスター ヘルプ フォーラムライブイベントなどでお知らせください。

    #NoHacked 3.0: 一般的なハッキングのケースを修正する

    これまで #NoHacked では、ハッキングの検出と防止に関するヒントをご紹介してきました。ハッキング攻撃を検出できるようになったところで、今度は、一般的なハッキング手法とその修正方法をご紹介いたします。

    • キーワードとリンクのクローキングによるハッキングを解決する
      キーワードやリンクのクローキングによるハッキングでは、意味不明な文、リンク、画像を含む大量のページが自動的に生成されます。これらのページには元のサイトのテンプレート要素が使用されていることがあるため、一目見ただけではターゲット サイトと区別がつきにくく、コンテンツをよく読むまで気付かないこともあります。通常このタイプのハッキングでは、クローキング手法を用いて悪意のあるコンテンツを隠し、挿入したページを元のサイトの一部として表示するか、404 エラーページを返します。
    • 意味不明な内容によるハッキングを解決する
      意味不明な内容によるハッキングでは、キーワードが埋め込まれた意味不明なページがターゲット サイト内に大量に自動生成されます。このハッキングの目的は、ハッキングしたページを Google 検索結果に表示し、訪れた人を無関係なページ(たとえばアダルトサイト)にリダイレクトすることです。
    • 日本語キーワードによるハッキングを解決する
      一般に、日本語キーワードによるハッキングでは、ランダムに生成されたディレクトリ名で、ターゲット サイト上に日本語テキストを含む新しいページが作成されます。こうしたページは、偽ブランド品を販売するストアへのアフィリエイト リンクを収益源としているのが特徴です。また、Google 検索への表示も目的としています。ハッカーのアカウントがサイト所有者として Search Console に登録されているケースもあります。

    最後に、サイトをクリーンアップして問題を修正したら、Google チームがサイトを審査できるように、再審査リクエストを送信してください。

    ご不明な点などありましたら、ウェブマスター ヘルプ フォーラムでお気軽にご投稿ください。それでは、また来週お会いしましょう。

    検索エンジン最適化(SEO)スターター ガイドを大幅に改訂しました

    世の中には、優れたウェブサイトを作成するための情報が溢れています。そんな中 Google によく寄せられる質問の 1 つが、「検索エンジンと相性の良いウェブサイトを作成したいのですが、おすすめの方法は?」というものです。これまで Google では、初心者向けのリソースとして「検索エンジン最適化(SEO)スターター ガイド」と「ウェブマスター アカデミー」を提供してきましたが、このたび SEO スターター ガイドを大幅に改訂し、検索エンジンと相性の良いウェブサイトの作成に役立つリソースとして公開することになりました。

    これまでの SEO スターター ガイドでは、検索エンジンがウェブサイトのコンテンツを、より簡単にクロール、インデックス登録、認識できるようにするためのおすすめの方法を紹介してきました。一方ウェブマスター アカデミーでは、サイトを作成し、Google 検索に掲載する方法を学習するための情報やツールを提供してきました。これら 2 つのリソースには、目的や内容の面で重複する部分があったわけです。そこで今回、ウェブマスター アカデミーと旧版の SEO スターター ガイドの PDF を廃止し、ユーザー フレンドリーで安全なウェブサイトの作成方法を網羅したガイドへと刷新しました。

    今回廃止された古い SEO スターターガイドとウェブマスターアカデミーの画像

    改訂版の SEO スターター ガイドは、旧版のスターター ガイドとウェブマスター アカデミーに代わるものです。これまで公開していたドキュメントに加え、検索エンジン最適化の必要性、構造化データ マークアップの追加、モバイル フレンドリーなウェブサイトの構築などの節を新たに設けました。
    新しい SEO スターター ガイドは、現時点では 9 つの言語(日本語、英語、ドイツ語、スペイン語、フランス語、イタリア語、ポルトガル語、ロシア語、トルコ語)での提供となりますが、近日中にこれ以外の 16 の言語にも対応する予定です。

    新しくなった SEO スターター ガイドをぜひご一読いただき、ご意見をお寄せいただけたらと思います。

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

    #NoHacked 3.0: ハッキング防止のヒント

    #NoHacked(英語) では先週、ハッキングの検出と、サイトがハッキングされる原因について解説しました。今週はハッキングの防止に焦点を当て、ヒントをいくつかご紹介します。

    • スパマーがウェブサイトのハッキングでよく利用する手段:
      攻撃からサイトを守るためには、サイトへの不正アクセスがどのように発生したかを把握することが重要です。ここでは、スパマーが主にどのような方法でサイトに不正アクセスするかを説明します。
    • 提供元に注意を払い、無料提供の有料テーマやプラグインに十分気をつける
      有料のプラグインが無料で提供されているサイトを見かけたことがある方もいらっしゃるかと思います。通常は購入しなければならないプラグインを無料で提供しているサイトに遭遇した場合は、十分にご注意ください。多くのハッカーは、人気のプラグインをコピーしておとりに使い、「バックドア」(マルウェア)を設置して対象のサイトに侵入できるようにします。同様のケースについて詳しくは、Sucuri 社のブログ(英語)をご覧ください。
      また、質の高い正規のプラグインやテーマであっても、次のような場合は危険なものとなる可能性があります。
    • 新しいバージョンが入手可能となったときにすぐに更新しない
    • テーマやプラグインのデベロッパーが更新を行わないので、時間の経過とともに古くなる

    どのような場合でも、サイトのソフトウェアをすべて常に最新の状態にしておくことは、ウェブサイトをハッカーから守るうえで不可欠です。

  • WordPress のボットネット
    ボットネット(英語)とは、第三者の管理下にあるマシンやデバイス、ウェブサイトの集まりで、多くの場合、悪意のある行為(ウェブスパムのキャンペーン、クリックボット、DDoS など)を働くのに利用されるものです。サイトがボットネットに乗っ取られていても、サイトには明確な変化が生じることがほとんどないため、見つけるのは困難です。しかし、サイトがボットネットに取り込まれると、サイトの評判、リソース、データが危険にさらされることになります。ボットネットの詳細や、ボットネットの検出方法、ボットネットがサイトに及ぼす影響について詳しくは、WordPress や Joomla! のボットネットに関する記事(英語)をご覧ください。
  • ご不明な点などありましたら、ウェブマスター ヘルプ フォーラムでお気軽にご投稿ください。それでは、また来週お会いしましょう。


    医療や健康に関連する検索結果の改善について

    Google では、今週、日本語検索におけるページの評価方法をアップデートしました。

    この変更は、医療や健康に関する検索結果の改善を意図したもので、例えば医療従事者や専門家、医療機関等から提供されるような、より信頼性が高く有益な情報が上位に表示されやすくなります。本アップデートは医療・健康に関連する検索のおよそ 60% に影響します。Google では、医療や健康だけに限らず、今後も継続的に検索の改善に取り組んで行きます。

    現在、毎日数百万件以上の医療や健康に関する日本語のクエリが Google で検索されています。これを分析してみると、医療の専門用語よりも、一般人が日常会話で使うような平易な言葉で情報を探している場合が大半です。日本のウェブには信頼できる医療・健康に関するコンテンツが多数存在していますが、一般ユーザー向けの情報は比較的限られています。

    もし、あなたが医療関係者で、一般のユーザーに向けたウェブでの情報発信に携わる機会がありましたら、コンテンツを作る際に、ぜひ、このような一般ユーザーの検索クエリや訪問も考慮に入れてください。ページ内に専門用語が多用されていたら、一般ユーザーが検索でページを見つけることは難しくなるでしょう。内容も分かりづらいかもしれません。ユーザーがあなたのサイトを見つけるために使用している検索キーワードのリストは、Search Console で確認することができます。もし、そのリストが専門用語で占められていたら、一般ユーザーの多くはあなたのサイトの情報にアクセスできていない可能性があります。

    Google では、アルゴリズムの改善やウェブマスターへの情報提供などを通じ、検索の改善に日々努めています。もし問題のある検索結果を見つけた場合には、デスクトップでは「フィードバックを送信」から、モバイルの場合は「ご意見・ご要望」からお知らせください。検索を改善するための情報として活用させて頂きます。

    AJAX クロールのページのレンダリング

    AJAX クロールに関するスキーム(英語)は、JavaScript ベースのページに Googlebot がアクセスできるようにするための方法として導入されましたが、廃止の予定であることを以前にお知らせいたしました。長期間にわたる Google のエンジニアの取り組みによって、Googlebot による JavaScript のレンダリング能力は大幅に向上してきました。こうした進歩を踏まえて、2018 年の第 2 四半期に、サイト側に JavaScript ベースのページのレンダリングを求めるのではなく、Google 側でレンダリングする形へと移行します。つまり、AJAX クロールに関するスキームは使用されなくなります。

    ご存じのとおり、AJAX のクロールに関するスキームでは、URL に「#!」が含まれているページか、「fragment メタタグ(英語)」が設定されているページのいずれかを対象として、URL に「?_escaped_fragment_=」が含まれたページをクロールします。この URL でクロールされるページは、完全にレンダリング済みのページか、それと同等の状態のページ(そのウェブサイト自体で作成されるもの)である必要があります。

    今回の変更に伴い、#! が含まれている URL は Googlebot によって直接レンダリングされるようになり、ウェブサイトの所有者はレンダリング済みのページを提供する必要がなくなります。こうした URL のページは Google 検索結果に引き続き表示されます。

    ほとんどの AJAX クロールのウェブサイトに対しては今回のアップデートに伴う大きな変化はないものと想定していますが、ウェブマスターの皆様は以下に説明するようにページを再度確認してください。サイトに潜在的な問題が検出された場合は通知が送信されます。

    サイトにおいて現在、#! が含まれている URL か fragment メタタグのいずれかをお使いの場合は、以下の手順を行うことをおすすめします。

    • Google Search Console でウェブサイトの所有権を確認して Search Console のツールへのアクセス権を取得し、問題が検出された場合に Google から通知が届くようにします。
    • Search Console の「取得してレンダリング」を使ってテストします。#! が含まれている URL とエスケープされた URL のテスト結果を比較して、違いがないかを確認します。ウェブサイトのさまざまな部分についてこのテストを実施します。サポートされている API について詳しくはデベロッパー向けドキュメント(英語)をご覧ください。また、必要に応じてデバッグガイド(英語)もご参照ください。
    • Chrome の [要素を検証] を使用して、リンクに「a」HTML 要素が使われていることと、必要に応じて(ユーザー作成コンテンツ内など)rel=nofollow が指定されていることを確認します。
    • Chrome の [要素を検証] を使用して、ページのタイトルと description メタタグ、robots メタタグ、その他のメタデータを確認します。また、レンダリングされたページで構造化データ(英語)が利用可能となっているかどうかも確認します。
    • Flash や Silverlight といったプラグイン ベースのテクノロジーに含まれているコンテンツを検索のインデックスに登録するには、JavaScript か「標準の」HTML に変換する必要があります。

    この変更がウェブサイトの運営と管理をより容易にし、サイト側でページをレンダリングする必要性が軽減することを願っています。ご質問やご意見がございましたら、お気軽にウェブマスター ヘルプ フォーラムJavaScript サイトのワーキング グループ(英語)までお寄せください。