AMPプロジェクトは、Roadmap（ロードマップ）を更新した。ロードマップは、AMPプロジェクトがその四半期に重点的に取り組んでいること、今後重点的に取り組む予定のこと、現在の進捗状況などを報告するもの。四半期の中間と終わりに、2回更新される。今回は、2016年の第3四半期（7〜9月）の終わりのロードマップ更新。amp-live-listの公開やECサイト対応の着手などが含まれる。
- AMPプロジェクトが第3四半期に取り組んできたこと――amp-live-listの公開やECサイト対応の着手など -
Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki
Googleが間もなく発売する Google Home（グーグル・ホーム）は、ウェブからの検索結果を返すときには、強調スニペットを読み上げるとのこと。Google Homeとは、10月4日に開催されたイベントでGoogleが発表した音声認識スピーカー。音声を認識し、音楽再生ほかさまざまなタスクを実行してくれる。
- Google Homeの検索結果には強調スニペットが読み上げられる -
Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki
Googleは、Googleアプリで利用できる「Now on Tap」と「Now カード」の名称の変更を検討しているようだ。ベータ版では、「Now on Tap」は「画面の検索」へ、「Nowカード」は「フィード」へと名前が変わっている。
- Googleアプリ、Now on Tapの名称を「画面の検索」に変更か？ Nowカードは「フィード」へ -
Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki
「AMPとApp Indexingを1つのコンテンツに同時に設定していた場合、AMPを優先して検索結果に表示する」「レシピのAMPリッチカードは間もなく公開予定」――Googleのダム・グリーンバーグ氏は、9月28日、米ニューヨークで開催されていたSMX East 2016でAMP関連で次のようにコメントした。
- AMPはApp Indexingよりも優先される、レシピのAMPリッチカードは間もなく公開予定 from #SMX East 2016 -
Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki
約2年ぶりにペンギンアップデートが更新されてから1週間が経過した。最新のペンギンについてわかってきたことをこの記事でまとめる。主な新情報は「ペンギン4.0はペナルティではなく無視」と「複数パートの分けて、アナウンス前から展開が始まっていた」の2つ。
- ペンギン4.0の更新から1週間たって判明したこと――ペナルティではなく無効化、ネガティブSEOを防げるか？、ペンギン3.0からのリカバリなど -
Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki
米ニューヨークで開催されるSMX East 2016に参加してくるので、今週残りのブログ更新をお休みします。Faber Companyが提供するコンテンツマーケティングツールのMIERUCAがSMX Eastに出展します。
- 【ブログ読者へご連絡】9/27〜9/30のブログ更新をお休みします -
Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki
Googleは、ペンギンアップデートの更新を実施した。前回の更新から実に2年近くが経過している。全言語が対象。今回の更新からはコアアルゴリズムに組み込まれ、リアルタイム更新になった。
- Google、ペンギンを2年ぶりに更新――コアアルゴリズムに組み込まれリアルタイムでアップデート -
Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki
Web担当者Forumの連載コーナー、「海外&国内SEO情報ウォッチ」を更新。今週は、『グーグルで、画像ユニバーサル検索枠の掲載位置が大幅ダウン!?』、『PageRankを操作する目的のウィジェットリンクはガイドライン違反です』、『ワイアードがHTTPS移行を完了。そして、イェルプも、ウェブマスター向け公式ブログも』など10記事+2記事。
- グーグルで、画像ユニバーサル検索枠の掲載位置が大幅ダウン!?【海外＆国内SEO情報ウォッチ】 -
Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki
AMPページに広告を掲載する際に、定められたJavaScriptの読み込みが必要になった。設定していなくても広告は表示されるが、将来的には、AMP HTMLのバリデーションエラーの原因になる可能性がある。WordPressのAMPプラグインでの対応方法を解説する。
- AMPページの広告掲載にはamp-ad用のJavaScriptの読み込みが必要に -
Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki
Googleは、Accelerated Mobile Pages (AMP) を通常の検索でサポートするモバイル検索を正式に公開した。ゆっくりと展開している。まず米Googleのモバイル検索から導入が始まったと思われ、日本のGoogleではまだ変化はない。
- Google、AMPをサポートするモバイル検索を正式公開。ゆっくりと展開し、まずは米国から導入開始か？ -
Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki
クリスマスイベントのように毎年毎年、繰り返し行われるイベント用に設置しているページを検索に強くするにはどうしたらいいのだろうか？簡潔に言うと、最新の回のイベントに関するコンテンツに対しては常に同じURLを使い続け、終了した回のイベントのコンテンツは別のURLのページに移動するのがベスト。
- Xmasイベントのように毎年開催するイベントには同じURLを使い続けるのがSEOに強い -
Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki
今週は特別編として、2016年度上半期（4月～9月）の間に起こった、検索エンジン関連の重要なトピックを、筆者の独断で振り返る。「10大ニュース」として選び始めたのだが、番外編をふくめて11個のトピックを選んだ。
- 鈴木謙一が選ぶ 検索エンジン関連重要10大トピック（2016年度上半期版）――1位はやはり“あれ”【海外＆国内SEO情報ウォッチ】 -
Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki
Googleは、モバイル検索結果にサムネイル画像を表示するようにした。スニペットの右側に、そのページに掲載されている画像のサムネイルを表示する。コンテンツに関連した、見栄えがいい画像をすべてのページに掲載すれば、検索結果でのクリック率が上昇するかもしれない。
- Google、モバイル検索結果にサムネイル画像を表示。CTRアップに期待？ -
Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki
[レベル: 中級]
Accelerated Mobile Pages (AMP) に対応したサイトを増やすことを目的としたAMPlifyキャンペーンをGoogleは先日スタートしました。
キャンペーンの第一弾として、AMPの始め方を紹介する記事を、英語版と日本語版のウェブマスター向け公式ブログで同時に公開しました。
英語版と日本語版のほか、ドイツ語版やフランス語版の公式ブログでも翻訳記事をすぐさま公開しているあたりにも、AMP普及に対するGoogleの気合の入れようを感じます。
書いてある内容は、AMPを始めるために必要なリソースの簡単な紹介です。
次のCMSはプラグインを使えば簡単にAMP化できるということで、それぞれの公式ページへ誘導しています。
一方で、AMPページを自作したりAMPの仕組みについて詳しく学んだりしたい人にはコードラボを紹介しています。
コードラボでは、AMPページを作成する手順を、解説に沿って実際にコードを修正しながら体験できます。
コードラボには、基礎編と上級編があります。
基礎編の「Accelerated Mobile Pages Foundations」では次が学べます。
上級編の「Accelerated Mobile Pages Advanced Concepts」では次が学べます。
ちょっと残念なのは、コードラボは英語だけの提供という点でしょうか。
とはいえ、たいていのコードは詳しく学ぶには英語は避けて通れません。
苦手な方も頑張ってください。;)
なお、AMPプロジェクトの本体サイトはかなりの部分で日本語化が進んでいます（ただし、最新の情報が反映されていない可能性もあるので、オリジナルの英語版はやっぱり参照すべき）。
AMPlifyキャンペーンを開始する際に「AMPの何を知りたいか？」をアンケートした結果、55%がAMPの始め方を学びたいと回答したそうです。
On Friday, 55% of you mentioned that you want to learn how to get started on #AcceleratedMobilePages.
この結果も受けて、AMPの始め方を紹介する記事をGoogleは最初に公開したようです。
「Googleの”オシ”も強くなってきたことだし、そろそろAMP化を真剣に考えるか」という人は公式ブログの記事を読んで、AMP対応を始めるといいでしょう。
- Accelerated Mobile Pages (AMP) の始め方をGoogleがブログで紹介 #AMPlify -
Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki
[レベル: 上級]
Googleは、構造化データを解説するデベロッパー向けサイトに「Courses（コース）」のリッチスニペットのセクションを追加しました。
Coursesは、教育機関（たとえば大学）の講座やクラスを定義できるschema.orgのボキャブラリです。
こちらはサンプルとして掲載されている、検索結果に表示されたコースのリッチスニペットです。
講座がリスト形式で並んでいます。
Androidの講座のようですね。
講座名と簡潔な説明、受講できる学校を表示項目に含めることができるようです。
実は、Courses はschema.orgでまだ正式に承認されていないボキャブラリです。
現在はまだPending（協議中）のドラフト状態です。
schema.orgでも、本サイトではなくペンディング用のサイトに掲載されています。
http://pending.schema.org/Course
早ければ、次のバージョンのschema.orgで正式に公開される可能性はあります。
正式な承認を受けていないschema.orgをGoogleがサポートするのは極めて珍しいことです。
そのため、実装しているサイトがほとんど存在しないせいか、実際の検索結果ではコースのリッチスニペットを僕は見つけることができませんでした。
どうして先行してサポートをGoogleが始めたのか、不思議です。
いずれにしても、提供する講座の概要をを検索結果で見やすく掲載できるので、大学や専門学校などの教育機関は使ってみたくなりそうです。
英会話や簿記、宅建のような習い事のスクールでも使えるんですかね？
H/T: Dan Brickley
- Google、Coursesのリッチスニペットを先取りでサポート開始。大学の講座をリスト形式で検索結果に表示 -
Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki
[レベル: 初〜中級]
Googleは、AMPに対応するように推奨する記事をウェブマスター向け公式ブログで公開しました。
特に新しい内容は記事には含まれていません。
簡潔にまとめれば、次のように説明し、
速く表示されるページをモバイルユーザーは求めています。
AMPはそうした要望をかなえられる仕組みだから、AMP対応しましょう。
関連コンテンツへリンクしているだけです。
気にかけるとしたら、次の一文でしょうか。
Later this year, all types of sites that create AMP pages will have expanded exposure across the entire Google Mobile Search results page, like e-commerce, entertainment, travel, recipe sites and many more.
ECサイトからエンタメ系、旅行、レシピに至るまでAMPページを作成したあらゆるタイプのサイトは、年内に、Googleのモバイル検索結果全体において表示機会を拡大するでしょう。
現在AMPコンテンツは、トップニュースとして、主に専用のAMPカルーセルの中だけでモバイル検索結果に掲載されます。
ニュース的な記事が掲載の対象です。
しかし、通常の検索結果にもAMPページを含めることをGoogleは決定しました。
開発版がプレビューとして試験公開されており、正式公開は年内を予定しています。
年内の正式公開は開発版の発表記事のなかでも触れられていましたが、サラッと書かれていたので見過ごしていた人がいるかもしれません（僕がそうだったw）。
つまり、「AMPを完全サポートしたモバイル検索を年内に公開するから、今から準備を始めよう」というのが今回の投稿された記事の目的の1つでもあるのでしょう。
今後数週間にわたって、AMPを始めるのに役立つ情報を発信するキャンペーンを実施するとのことです（日本語でのアナウンスはこちら）
What are the areas of Accelerated Mobile Pages (AMP) you want to hear more about:
In these next few weeks, we’ll help you understand how AMP makes mobile web faster for everyone and how you can use it! Be sure to follow us or share your experience using the hashtags #AMPlify #AcceleratedMobilePages
すでにAMP化しているなら問題ないとして、このようなアナウンスがあると、AMP対応したほうがいいのか悩みます。
僕の考えは次のようになります。
毎日たくさんの記事を発行するサイトで、新しいトピックを扱うことが多いならAMP対応したほうがいいでしょう。特に、Googleニュースに登録しているサイトは必須といっていいかもしれません。高速表示という優れたユーザー体験を提供できます。
通常なら表示されないような、検索ボリュームが大きいクエリでカルーセルに掲載されることも多く、検索トラフィックの増加にも繋がります。
Googleニュース検索、GoogleニュースアプリもAMPに対応しています。
企業のブログも（このブログのような）個人のブログも、多少の手間ひまをかけられるならAMP対応するといいと考えます。
ニュース系サイトと同様に、読みものコンテンツはAMPと相性がいいので、読み込み時間のストレスを与えることなくユーザーに記事を読んでもらえます。
WordPressやDrupalなどメジャーなCMSはAMP化のためのプラグインが出ているので、AMP対応するだけなら簡単です。日本でユーザーが多い、はてなブログもチェックボックス1つでAMP化できますね（現在は有料版のみ）。
AMPによる制限を許容できるなら、ブログのAMP対応はおすすめです。
ブログにかかわらず、基本的に更新がなく、ユーザーからのアクションも発生しない、閲覧するだけの記事コンテンツもAMPに向いていると考えます。
ブログではないけれど、サイトの中に読ませるだけのページがあればそこだけAMP化するというやり方はありでしょう。
ただ、限られた一部だけをAMP対応するのは返って面倒かもしれませんね。
個人的には、レシピサイトはAMP対応を推奨します。
通常の検索結果でのAMP表示もさることながら、レシピコンテンツの場合はトップニュースのようにカルーセルに別枠で表示される可能性があります。
検索結果での露出を増すチャンスになりそうです。
ECサイトは、判断が難しいところです。
カテゴリの一覧ページであれば、今でも十分AMP対応できるとAMPプロジェクトは強調していますが、ECサイトでの最終目的である”購入”ができない状態では、中途半端です。
eBayのように、ほかより先に試してみるというチャレンジングな精神があるならトライする選択肢はありえます。
ひょっとしたら、先行者利益があるかもしれせん。
なおECサイトに限らず、不動産サイトやトラベルサイトなどDBと連動させてたくさんのアイテムを扱うサイトもここに該当します。
ユーザー体験の観点から見たら、サクッと表示できるのでAMPは対応価値があります。
では純粋にSEO、言い換えたらランキングだけの観点から見たらどうでしょう？
完全に僕の個人的な予想ですが、しばらくはランキング要因には組み込まれないと思います。
なぜなら、AMP対応したくてもAMPに向いていない、AMP対応できないコンテンツ（ページ）が、今はまだ存在するからです。
モバイル対応とは異なり、今の時点ではまだAMP対応は誰にでもできるものではないのです。
対応したいのに対応できないのでは、不公平です。
ただし、モバイルフレンドリーのアルゴリズムに”スピード”の要素を組み込むことをGary Illyes（ゲイリー・イリェーシュ）氏は示唆しています。
もしこれが実現したら、AMPページは有利になるかもしれません。
AMPページだからということではなくて、高速表示するからという間接的な恩恵です。
最後も個人的な意見ですが、僕はAMPには対応べきだと思います。
ユーザーの立場に立つと、ページが速く表示されるのはやっぱり気持ちがいいものです。
自分のブログ読者にも、読み込みにかかるストレスを与えずサクッと記事を読んでもらいたいと考えます。
AMPはどのくらいもつの？ いずれなくなるんじゃない？ という懸念もないわけではないですが、まあ3、4年くらいもてば不満はありません。w
- Google、AMP化を勧めるキャンペーンを開始。今すぐAMP対応すべきか、それともまだ待つべきか？ -
Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki
[レベル: 上級]
この記事では、Googleが公開しているドキュメントに基づいて、AMPキャッシュの仕組みについて説明します。
具体的には、次を扱います。
あなたがAMPをすでに実装しているなら、知っておくと役に立つこともあるはずです。
では行ってみましょう⚡
AMP CDNにキャッシュされたコンテンツはたとえば次のようなURLになります。
https://cdn.ampproject.org/c/s/example.com/amp_document.htmlhttps://cdn.amproject.org/i/example.com/images/logo.png分解して、どんな構成になっているのかを見てみましょう。
※ここでは、Googleが提供しているAMP CDNのキャッシュについて話します。もしGoogle以外のAMP CDNを使うなら仕様は異なるでしょう。
AMPキャッシュのURLは常に https://cdn.amproject.org で始まります。
Googleが公開しているAMP CDNのURIになります。
https://cdn.amproject.org のあとには次の3つのいずれかが続きます。
これらは、コンテンツのタイプを表します。
/c −− HTMLドキュメント/i −− 画像/r −− フォントなどのリソースオリジナルのAMPページまたは画像、リソースがHTTPSで配信されているときは、コンテンツのタイプ (/c, /i. /r) の次に /s が続きます。
最後に来るのは、オリジナルのAMPページのURLから、http:// または https:// を取り除いた部分です。
URLがパラメータ (?) を含んでいてもそのまま使えます。
ここまでをふまえて、AMPキャッシュのURLをもう一度見てみましょう。
オリジナルのAMPページ（あなたのサーバーに直接アクセスしたときのAMPページ）のURLが次のようだったとします。
http://example.com/amp_document.html
このとき、AMPキャッシュのURLはこのようになります。
https://cdn.ampproject.org/c/example.com/amp_document.html
まず、固定の https://cdn.ampproject.org で始まります。
https://cdn.ampproject.org/c/example.com/amp_document.html
次に、コンテンツタイプがHTMLドキュメントなので、 /c が続きます。
https://cdn.ampproject.org/c/example.com/amp_document.html
そのあとは、元のURLから http:// を取り除いた example.com/amp_document.html で終わります。
https://cdn.ampproject.org/c/example.com/amp_document.html
同じAMPページをHTTPSで配信していたとします。
https://example.com/amp_document.html
AMPキャッシュのURLはこのようになります。
https://cdn.ampproject.org/c/s/example.com/amp_document.html
先ほどと似ていますが、コンテンツのタイプを表す /c のあとに、HTTPSを示す /s が入っています。
今度は、画像のAMPキャッシュURLを見てみましょう。
オリジナルの画像を次のURLで配信しています。
https://example.com/images/logo.png
AMPキャッシュのURLはこのようになります。
https://cdn.ampproject.org/i/s/example.com/images/logo.png
画像なのでコンテンツのタイプの部分が /i になっていることに気付いてください。
またHTTPSで配信しているので、/s が入ります。
簡単に言うと、AMPキャッシュの更新は、ユーザーにキャッシュを配信したときにオリジナルのコンテンツが更新されていれば、更新されたコンテンツをAMP CDNサーバーが自動で取得しキャッシュし直す仕組みになっています。
ただし新しいキャッシュが配信されるのは、その次のユーザーに対してです。
もう少し詳しいプロセスは次のようになります。
Max-Ageヘッダーなどを見る）コンテンツに更新が発生していた場合は、そのユーザーには現在のキャッシュを返しますが、次のユーザーには新しいキャッシュを返すというのが特徴的ですね。
ユーザーが頻繁に閲覧するページほど、最新の状態に保たれやすくなります。
逆に、ユーザーが閲覧しないページのキャッシュはいつまでたっても古いままです。
なおサーバーに負荷をかけないために、HTMLドキュメントに対しては最低でも15秒以上の間隔を空けてリクエストします。
画像やリソースに対しては最低でも1分以上の間隔を空けてリクエストします（間隔は将来変更される可能性あり）。
説明したように、ユーザーが閲覧する限りはAMPキャッシュは自動で更新されます。
しかしオリジナルのコンテンツを更新し、キャッシュも今すぐにでも更新したいことがあるでしょう。
そんな状況では、ユーザーの閲覧を待たずともAMPキャッシュを更新することができます。
方法はとても簡単です。
あなたが、AMPキャッシュのURLにアクセスすればいいのです。
オリジナルのコンテンツが更新されていることをAMP CDNが認識できれば、キャッシュも更新されます。
ユーザーには新しくなったキャッシュが返されます。
AMPキャッシュのURLは、この記事の初めに説明しましたね（なので、AMPキャッシュURLのフォーマットの理解は大切なのです）。
この記事のAMPキャッシュを更新したければ、次のURLにアクセスします。
https://cdn.ampproject.org/c/s/www.suzukikenichi.com/blog/anatomy-of-amp-cache/amp/
AMPキャッシュの更新には、Fetch as Googleのインデックス送信を使ったりしなくていいのです。
AMPページまたはAMPページで使っている画像やリソースは、本体を削除すればいずれAMPキャッシュからも削除されます。
一般的なウェブページや画像と同じです。
ですが、キャッシュを至急で削除したい場合に利用できる仕組みがあります。
“update-ping“を使います。
AMPキャッシュされている https://example.com/amp_document.html のAMPページを削除リクエストするには次のURLにアクセスします。
https://cdn.ampproject.org/update-ping/c/s/example.com/amp_document.html
AMPキャッシュのURLで、https://cdn.ampproject.org の次に /update-ping を差し込みます。
http://example.com/images/logo.png の画像のAMPキャッシュを削除リクエストするには、次のURLにアクセスします。
https://cdn.ampproject.org/update-ping/i/example.com/images/logo.png
update-ping に加えて、おさらいの目的も兼ねて以下にも注意してください。
/i になる/s は付かないHTTPとHTTPSは連動しません。
キャッシュは別々に保存されています。
なお、update-pingを使ったURLに「アクセスする」と表現しましたが、正確には「GETリクエストを送信」します。
“204 No Content”のHTTPステータスコードが返ってきます。
update-ping を使うとキャッシュが自然に削除されるのを待つよりもずっと早くキャッシュを削除できます。
この記事でのAMPキャッシュに関する説明は以上です。
ブログ読者に向けた解説というよりは、僕自身のためのまとめの意味合いのほうが実は強かったりします（AMPキャッシュの更新方法について、何度か質問されたことがあった）。
公式ドキュメントには、AMPキャッシュに関する情報がほかにも書かれていますが、僕にとって重要な部分に絞って説明しました。
AMPキャッシュの仕組みに興味を持ったなら、公式ドキュメントもお読みください。
- Google CDNのAMPキャッシュを大解剖――URLフォーマット、更新プロセス、更新方法、削除方法 -
Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki
Web担当者Forumの連載コーナー、「海外&国内SEO情報ウォッチ」を更新しました。今週取り上げた記事は次のとおりです。
こちらからどうぞ。
- グーグルの“隠れた”品質評価アルゴリズムに対応する方法【海外＆国内SEO情報ウォッチ】 -
Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki
[レベル: 初〜上級]
パスワードまたはクレジットカードの情報をHTTP接続で送るページに、安全ではないことを示すラベルをChromeブラウザで表示するようにするとGoogleはアナウンスしました。
2017年1月にリリースを予定しているChromeのバージョン56から実装します。
HTTP通信ではセキュリティが確保されません。
そのため、HTTPページでは送信する情報を第三者に盗み見されたり改ざんされたりする可能性があります。
そこで「Not secure」のラベルをアドレス欄に表示するようにしました。
日本語版では「安全ではありません」といったようなラベルになるのではないでしょうか。
下の画像はサンプルです。
上の段は現行のChrome（バージョン 53）です。
特別なラベルは何も付いていません。
しかし下の段のChrome 56からは「Not secure」のラベルがURLの前に付きます。
なお、公式アナウンスには、サイトが対象と書かれていますがページが対象です。
パスワードやクレジットカードの情報をHTTPで送るページがあれば、そのページだけにラベルが付きます。
サイト全体ではありません。
Not secureラベルの対象になるのは、パスワードまたはクレジットカードの情報をHTTPで送信するページです。
メールアドレスや住所、電話番号などそのほかの個人情報を送信するページは、（最初の時点では）対象になりません。
もう少し細かく言うと、パスワードやクレジットカードのフォームフィールドがあるHTTPページになるかと思います。
すでに説明したように、2017年1月リリースのバージョン56では、パスワード/クレジットカードをHTTPで送信するページだけがラベルの対象です。
しかし対象範囲をさらに拡大していきたいとのことです。
たとえば、シークレットモードでChromeを利用する場合です。
シークレットモードは、ユーザーがプライバシーを保護したいときに使われます。
そこで、シークレットモード利用時はすべてのHTTPページにNot secureラベルを表示するかもしれません。
最終的には、モードに関係なく、すべてのHTTPページにNot secureラベルを表示することを目指しています。
しかも赤色の警告マークも付けるかもしれません。
「安全ではありません」なんて表示されたらアクセスしたくなるユーザーがおおぜい出てくることでしょう。
まさかパスワードやクレジットカードの情報を送信する際に、HTTPSを使っていないのは今どきありえないと思います。
それでも、もし万が一そういったページでHTTPのままであれば大至急HTTPSに変えなければなりません。
もっとも、パスワードやクレジットカード情報をHTTPで送らせるなんていうのはChromeのNot secureラベル以前の問題ですが。:(
パスワードやクレジットカードの情報を送信するページを持っていないとしても、HTTPS化は避けて通れないでしょう。
時代の流れなのであらがうことは得策ではありません。
さっさとHTTPSに移行して本当に僕は良かったと思っています。
なお自分のサイトがどんな影響を受けそうか（あるいは受けないか）は、開発版のChrome Canaryで確かめることができます。
安定版がリリースされるだいたい6週間前に新機能が実装されるとのことです。
- Google Chrome、パスワード/クレジットカード情報をHTTPで送るページに安全ではないことを示す「Not secure」ラベルを表示。2017年1月リリースのバージョン56から -
Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki
[レベル: 中級]
Googleは、ローカルナレッジパネルに「ウェブ上のレビュー」を追加しました。
「ウェブ上のレビュー」には、さまざまなレビュー系サイトから集められた平均評価が掲載されます。
レビューサイト運営者は、Review snippetsを設定することで「ウェブ上のレビュー」に含めてもらいやすくなります。
レストランやショップ、テーマパーク、公園など場所や建物に関係するナレッジパネルにウェブ上のレビューは掲載されます。
こちらは昭和記念公園のナレッジパネルに掲載されたウェブ上のレビューです。
Facebookとジョルダンのウェブページに投稿されているレビューの情報が採用されています。
こちらはテーマパークのウェブ上のレビューです。
こちらはレストランのウェブ上のレビューです。
レビューの採用元がそれぞれ異なっているのがわかります。
どこから引っ張ってくるかはアルゴリズムによって判断されます（提供元として選ばれやすくする方法は後述）。
最大で3つのサイトからのレビュー情報が掲載されます。
PC検索でもウェブ上のレビューを見ることはできます。
詳しく書かれたレビュー記事を引用する「Critics reviews」という機能が先月から米国では試験的に始まっています。
Critics reviewsとウェブ上のレビュー（英語では「Reviews from the web」）はともに掲載されます。
Critics reviewsは米Googleだけですが、「ウェブ上のレビュー」は世界中のGoogleで利用可能です。
さて、ここまでは一般ユーザーに向けての「ウェブ上のレビュー」という新機能の紹介です。
あなたがレビューを集めるサイトを運営しているなら、ローカルナレッジパネルのウェブ上のレビューに掲載されやすくすることができます。
ウェブ上のレビューは、技術的な用語では「Review snippets（レビュー スニペット）」と呼ばれます。
ローカルビジネスの場合のレビュー スニペットにはschema.orgを用いた次の2つの構造化データのマークアップが必要です。
構造化データを使うことにより、レビューのデータをGoogleは集めることができます。
そして、あなたのサイトでのレビューの対象とナレッジグラフに登録されているローカル”エンティティ“とを結び付けることができます。
レストランやお店、テーマパークなどのレビューを集めているサイトならレビュー スニペットに必要な構造化データを設定しておくといいでしょう。
ナレッジパネル経由でのアクセスが増えることが期待できます。
- Google、ローカルナレッジパネルに「ウェブ上のレビュー」を追加。レストランやテーマパークなどに対するさまざまなレビューサイトでの評価が検索結果でわかる -
Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki
