バイドゥ、ソゴウ、そしてYahoo JapanがAMP対応を表明。
*リンク先は全て英語記事です。
ニューヨークで行われているAMP Confにて、アジアの10億以上のユーザーに向けてAMPが展開されるというビッグニュースが発表された。中国の検索エンジンのバイドゥとソゴウがAMPに対応。そして、Yahoo Japanもだ。
Googleの検索のバイスプレジデントであり、AMPを率いるデイビッド・ベスブリス氏が基調講演で発表した。これらアジアの検索エンジンが対応を開始するということは、10億以上の人々がAMPを体験することを意味している。
2015年10月にAMPがローンチされて以来、非常に多くのパブリッシャーと開発者がAMP対応を進めており、世界中で数え切れないほどのAMP対応ページが作成されている。このプロジェクトに貢献している開発者は1万を超えるだろう。
AMPを利用しているパブリッシャーとEコマースの会社のリストに、バイドゥ、ソゴウ、Yahoo Japanが名を連ねる。このリストには、Bing、eBay、Pinterest、LinkedIn、Tumblr、WordPress、The Weather Company、Eventbrite、Shopify、Fandango、TripAdvisor、Disney、Food Networkなどが含まれている。
先月のアドビ社による報告では、米国のトップパブリッシャーは全体の7%のトラフィックをAMPページで獲得しているということだ。そのパブリッシャーによると、サイトの滞在時間とエンゲージメントにおいて、AMPページは高い値を示しているという。また、CTRとマネタイズの面でもAMPは優れていると報告をするパブリッシャーもいる。
ベスブリス氏によれば、17億のAMPページが存在し、毎週3千5百万の新たなAMPページが作成されているという。また、AMPを使用しているドメインの数は、世界中で86万にも上るという。
Googleの調査によると、（彼らが調査した）70%のモバイルページで、ビジュアル表現のあるコンテンツをロードするために、7秒から10秒かかるということだ。これに対し、AMPページは平均して1秒以内にロードされる。
Googleは、AMPであることがランキング要素にはならないと発言している。しかし、ページスピードはランキング要素だ。かつて、ベスブリス氏は、AMPページはランキングの恩恵をあずかるわけではない、と述べている。しかし、AMPページと通常のモバイルページの両方があった場合、GoogleはAMPページを優先的に提供している。
この記事は、Search Engine Landに掲載された「AMP — Accelerated Mobile Pages — rolling out to 1 billion more people in Asia」を翻訳した内容です。
検索結果画面に表示される新しい広告ラベルがグローバルでロールアウトを開始している。
＊記事内のリンク先の記事は全て英語となっております。
ここ数週間、Googleの検索結果画面に表示される広告ラベルの新しい表記を多くのユーザーが目撃していた。緑色の塗りつぶしのデザインではなく、新しいラベルは緑色の枠に白の背景となっている。
目撃例はこの数日で急速に増加していたが、Search Engine Landは、この新しいデザインが世界中でロールアウトを開始していると、Googleからの公式な発表を得ている。
「検索結果画面の表示のテストは常に行っている。緑色の枠の新しいデザインを表示するテストを行ったのち、Googleはこのデザインをロールアウトすることを決定した。新しいデザインは、読みやすく、広告であることをユーザーが簡単に見分けることができる。」と、Googleのスポークスパーソンは水曜日にSearch Engine Landに対し述べている。
Googleは検索結果画面に表示する広告ラベルのテストを長い間行っている。緑色の塗りつぶしのデザインは比較的短命に終わっている。ロールアウトされたのは2016年6月であった。当時、黄色から緑色にデザインを変更した理由について、Googleは検索結果画面の色を整える意図があったとしているが、特にモバイルを注力していたようだ。また、Googleは、「こうしたテストは消費者が広告と自然検索結果と区別することに特に影響を与えることは無い」、と強調している。同時期に行っていた似たようなテストは、同様の結果を示していると言われている。
今回の新しい緑色の枠のデザインは、1月24日にイギリスで目撃されたのが最初だ。その後、多くの国々で目撃例が増加していた。この変更が完全に完了するには数日間かかるだろう。そのため、現在も旧デザインが表示されていたとしても、それは驚くべき事象ではない。
我々が作成している、Google広告ラベルの変遷、という記事もまもなく更新される予定だ。
この記事は、Search Engine Landに掲載された「Official: Google’s green outlined ‘Ad’ label replacing solid green version」を翻訳した内容です。
マット・カッツ氏はUSデジタルサービスのエンジニアリング・ディレクターとなる。2014年以降Googleから遠ざかっていたが、2016年の最後の日に、彼は正式に退職した。
元Googleのサーチクオリティチームのトップであったマット・カッツ氏が、2016年12月31日をもって、Googleから退職したことを発表した。氏はUSデジタルサービスで働き続けることを決断し、この政府機関のエンジニアリング・ディレクターに任命されている。
マット・カッツ氏がGoogleから休暇を取得したのは2014年のことだった。その後、すぐにこの休暇期間を延長している。また、2015年5月に、サーチクオリティチームのトップという肩書を降ろし、依然、休暇期間中であると認めていた。
2016年の中頃から、USデジタルサービスで働き始めている。この仕事を非常に楽しんでいるようで、このUSデジタルサービスで働くことを公式に認めた。現在、彼はGoogleを休職しているのではない。USデジタルサービスのエンジニアリング・ディレクターとして働いているのだ。
マット・カッツ氏は自身のブログで、下記のように述べている。
政府機関で働いても、シリコンバレーの巨大な企業ほど給料をもらえるわけではない。無料のランチがついているわけでもないし、ここで働く多くの日々が、非常にストレスを感じるものだ。しかし、この仕事は非常に重要で刺激的なものであり、純粋に人々の生活を良くするための仕事に就くことができる。数年前からここで働く友人に言わせると、「この5年間は最も難しく、最悪であり、しかし最高の5年間であった。今までで一番報われたと考えているよ」、ということのようだ。
マット・カッツ氏はGoogleの最初の100人の従業員の1人である。検索マーケティングの業界では最も知られているGoogle社員の1人である。カンファレンスでたびたびスピーチを行い、計り知れない貢献をこの業界とGoogleに提供してきた。しかし、彼にとって次のステップへと進む時が来たようだ。Googleでの諸問題を解決するのではなく、この巨大な政府機関で働く決断をしたのだ。
下記にマット・カッツ氏が紹介してい動画を掲載しておく。USデジタルサービスの仕事がどれほど重要であるか、説明している動画である。
【SEO Japanによる追記】
2016年SMX Westにて。
この記事は、Search Engine Landに掲載された「Matt Cutts officially resigns from Google」を翻訳した内容です。
現在は”実験”中ではあるが、検索結果のランキングを決定する際に、デスクトップ版ではなくモバイル版のコンテンツを第一に見る計画の第一歩を踏み出した。
＊リンク先は、一部を省き、英語記事となっています。
Googleはモバイル ファースト インデックスの実験を開始している。ランキング・シグナルを見る際、モバイル版のコンテンツを第一に見るようするものだ。また、モバイル版のコンテンツがない場合は、デスクトップ版のコンテンツを見るようになる。
モバイル ファースト インデックスの実装は予期されたものであり、昨年にも、モバイル独自のインデックスの話しは聞いていた。しかし、モバイル ファースト インデックスの詳細を自身のブログでGoogleが公開したことは、今回が初めてのことである。
Googleは、デスクトップよりもモバイルでの検索がより多く行われていると説明している。しかし、GoogleはWebサイト（ページ）の評価を行う際、現在はデスクトップ版のサイトを見ている。これは、我々が1年前から指摘していた問題でもある。この問題を解消するために、Googleはコンテンツ、リンク、構造化データなど、モバイル版のサイトを（それが可能であれば）見るようになるのだ。
Googleは下記のように説明している。
この変更によって、Googleはモバイル版のコンテンツを第一にインデックスするようになり、デスクトップかモバイルからの検索にも関わらず、ランキングの決定にも使用するようになる。もはや、モバイルユーザーのためだけの”モバイルフレンドリー”といったものは存在しなくなる。仮に、あなたのWebサイトがモバイルフレンドリーでなければ、デスクトップの検索にも影響を与えることになるだろう。
Googleは実験を始めていると述べており、「今後数カ月にわたって小規模の実験を入念に行う」としている。また、Googleは、「素晴らしいユーザー体験を提供していると自信をもって判断した時点でより広範囲にわたって変更を反映する」、としている。
モバイル版のサイトが無くても、心配する必要は無い。その場合は、Googleはデスクトップ版のコンテンツをランキングに使用する。Googleは、「デスクトップ版のサイトしか存在しない場合、Google は引き続きデスクトップ版のサイトをインデックスします。モバイルユーザーエージェントを使用してアクセスする際も問題ありません。」と述べている。つまり、動的な配信やレスポンシブデザインのサイトの場合、特に何か必要としないことを意味している。
もちろん、モバイル版のサイトが無い場合は、モバイルフレンドリーのランキングブーストの恩恵にはあずかれない。しかし、これについては、今回のモバイル ファースト インデックスの件とは別の話しだ。
下記に、今回の変更に対しての準備について、Googleによるアドバイスを記載しておく。
Googleの検索結果やインデックス状況に変化があった場合、我々はそれらについて報告をするつもりだ。このモバイル ファースト インデックスが完全にロールアウトされた場合は、読者の皆様にはすぐにお伝えしよう。
この記事は、Search Engine Landに掲載された「Google begins mobile-first indexing, using mobile content for all search rankings」を翻訳した内容です。
現在のところ、Googleは検索に使用するためのインデックスを１種類しか持っていない。Googleのゲイリー・イリェーシュ氏は、モバイル検索用にインデックスを分離するプランを公表し、そして、そのインデックスが主要なものとなるようだ。
Googleは数ヶ月以内に、モバイル用にインデックスを分割する予定だ。今後はこのインデックスが、検索エンジンがクエリへの返答に使うための、主要なインデックスとなるようだ。デスクトップ用のインデックスはそのまま保持されるが、モバイル用のインデックスほど更新されない（最新のものとならない）とされている。
このニュースは、本日行われたPubconで、GoogleのWebマスタートレンドアナリストである、ゲイリー・イリェーシュ氏のキーノートにて発表された。ゲイリー氏は、この件についてのスケジュールは言及していなかったが、Search Engine Landが後に問い合わせたところ、”数ヶ月”以内に起こりうることを認めた。
Googleはモバイル版のインデックスの考えに基づいた実験を行っていることを、昨年のSMX Eastで発表している。以降、Googleはモバイル版のインデックスは理にかなったものであり、この考えを進めていくことを決定したようだ。
この、モバイル版のインデックスがどのような仕組みになるのか、実際には不明点が多い。例えば、モバイル版のインデックスが”主要”となるようだが、デスクトップのクエリには使用されないのだろうか？モバイル版のインデックスには、”モバイルフレンドリー”のコンテンツしか含まれないのか？デスクトップ版のインデックスはどの位の頻度で更新されるのか？デスクトップの使用は、Googleのクエリの中の少数派となっているが、それでもその使用量は大きいはずだ。
最も重要な変更は、モバイル用にインデックスを分割することにより、Googleは、モバイルのランキングを決定するためにデスクトップのコンテンツからデータを引き出している既存のシステムと比べ、”純粋な”モバイルコンテンツにおける（既存のシステムとは）異なった方法でランキングアルゴリズムを用いることができるようになる、という点であろう。
ゲイリー氏によるキーノートの参加者のツイートをたどればその内容が垣間見えることになるが、それでも全てが明らかになるというわけではない。
.@methode: Google creating a sep mobile index, which will be it’s primary index. Desktop will be a secondary index,less up to date #Pubcon
— Lisa Barone (@LisaBarone) 2016年10月13日
Mobile first index will change things since mobile sites tend to not be as large as desktop. @methode #pubcon
— Jennifer Slegg (@jenstar) October 13, 2016
Mobile index will be primary & desktop secondary-think about what are the main differences between your mobile & desktop #pubcon @methode pic.twitter.com/umwBoYA6Cx
— Eugene Feygin (@rawseo) October 13, 2016
Google will still have a desktop index, it just won’t be as fresh as the mobile index. #pubcon
— Lisa Barone (@LisaBarone) October 13, 2016
Sites often remove content and structured data from mobile pages for size. @methode #pubcon
— Jennifer Slegg (@jenstar) October 13, 2016
If the content on your mobile page is the same as desktop, those sites will be fine. @methode #pubcon
— Jennifer Slegg (@jenstar) October 13, 2016
Links will be scarcer on mobile. There will be loss of tokens (words). People put less content on mobile devices. #pubcon
— Lisa Barone (@LisaBarone) October 13, 2016
When @methode says tokens he’s mostly referring to words on the page. #pubcon
— Ryan Jones (@RyanJones) October 13, 2016
我々はGoogleに詳細を尋ねているが、詳細が明らかになるのはその変更が行われる時であろう。今後数ヶ月は待たされることになりそうだ。
この記事は、Search Engine Landに掲載された「Within months, Google to divide its index, giving mobile users better & fresher content」を翻訳した内容です。
デスクトップとモバイルでの勝利を手にしたまま、Googleは全く新しい分野の成功を目論む。特に家庭内における、ハンズフリーの検索である。
*記事内のリンクは全て英語となっています。
Googleはインターネットにおける検索の第一世代、つまりはデスクトップ検索での勝利を手にするために博打を打った。また、その成功をモバイル検索でも手にすることを可能とした。そして、今は第三世代へと変貌する局面に直面している。インターネットに接続されたデバイスの時代における、ハンズフリーの検索だ。Google AssistantとGoogle Homeの登場により、Googleがこの分野における勝利を手にすることも可能となる。
現状、ユーザーがGoogleを利用する場合、”タッチ”という作業が必要不可欠となっている。デスクトップでも、モバイルでも、ユーザーは文字を入力するためにキーボードをタッチしなければならない。音声検索を利用する場合でさえも、検索結果を選択するために、スマートフォンにタッチする必要がある。もちろん、最初の検索結果は音声で知らせてくれるのだが、それでもタッチという作業は発生してしまうのだ。
これは、Amazon Echoとは非常に異なる点である。Amazon Echoは製品に話しかけるだけで、本日の天気がわかったり、最新のニュースが知れたり、商品を注文したり、音楽を再生できたりする。Amazon Echoにはスクリーンは存在しない。Amazon Echoはタッチも必要としない。他の製品と比べても、人間に話しかけ情報を得るといった感覚に最も近しい製品であるのだ。Googleはこの分野において遅れをとっていた。今までは。
もし、（家電製品に組み込まれたあらゆるアシスタント機能を含む）ホーム・アシスタントという分野がかつてのスマートフォンの繁栄のように急激に成長していけば、Googleのポジションは危ういものとなってしまうだろう。Googleはこの分野で戦うための物理的なデバイスであるGoogle Homeを手にしたのだ。しかし、このデバイスには新たな知力も必要とされる。
Google Assistantはその知力となる存在であり、機械学習や人工知能の技術を活かしている。Google Assistantは、Googleへ話しかけるという行為をユーザーに促す目的で設計されている点が、非常に重要であろう。
もちろん、「既にGoogleに毎日話しかけている」と思うかもしれない。タイプして検索を行い、返事を得るということだ。しかし、Google AssistantはGoogleをさらなる高みへと導くものだ。まるで、何かを行うために人間に話しかけるているという感覚を、ユーザーに与えてくれるのだ。
「Googleにおける会話式のインターフェイスをゼロから構築するとさえ言える」。これは、Google Assistantを統括する、エンジニアリングのヴァイス・プレジデントである、スコット・ハッフマン氏が先週語った内容だ。
もちろん、音声検索という手段で、ユーザーは何年間もGoogleと会話してきた。しかし、Google Assistantはそうした経験をさらに高めるものであり、実世界におけるアシスタント（実際の人間）から何かしらの答えを得るような方法で、Googleとかかわりあうことを可能とするのである。
Google Assistantは、先月リリースされたメッセージアプリ、Google Alloの一部として、初めて一般公開された。
Alloでは、情報を得るためにGoogle Assistantに直接かかわりあうことができる。しかしながら、単純にGoogle検索を行った方が便利だと私は感じている。AlloにおけるGoogle Assistantが魅力的となる場面は、ユーザーの役に立とうと、会話中に情報を提示してくれる時である。
例えば、誰かと映画に行こうかと会話をしている場合、Google AssistantはGoogleの広大なデータベースから参照した情報を提供し、我々が見るべき映画を提示してくれるのだ。
非常に素早く、便利で、他のアプリで検索を行う必要が無い。
個人的な意見ではあるが、メッセージアプリとして認知されるために、Alloにも直面している課題はある。Alloの一部としてのGoogle Assistantを見るだけでは、十分な評価とは言えないだろう。仮にAlloが広く普及しなかったとしても、それはGoogle Assistantの失敗であるとは結論付けられないのだ。
なぜなら、Google Assistantはあらゆるアプリやデバイスに組み込まれる存在であるからだ。そして、Google PixelとGoogle HomeにGoogle Assistantが使用されることが、本日発表されている。
Googleは既に、Android端末（スマートフォン）に加え、iOSのデバイスにおいても、Google検索アプリによる圧倒的なシェアを獲得している。また、Google検索アプリに話しかけることで、必要な情報を得ることもできる。しかし、Google Assistantはさらに上を行く存在を目指しており、Googleとの関わりにおいて、より多くの情報と支援を与えているのだ。
Google Assistantは、あらゆる場面におけるGoogle Assistantとの会話を記憶する。そのため、Google HomeやAlloで交わされた会話を、それぞれの利用シーンで引用することができるのだ。(Google Homeで行われた会話の内容が、次にAlloを使用した際に、参照されることがある。)
また、アシスタント機能も非常に重要だ。現在のGoogle検索アプリでは、検索結果はリスト形式で返ってくる場合が多い。しかし、Google Assistantでは、アクションを起こす内容が提供されるのだ。
Google Assistantは文脈を解釈する知能も備えている。これは、以前は”Now on Tap“と呼ばれていたものであるが、例えばWebページを閲覧している時に、Google Assistantは役に立つであろう、関連する情報を提案してくれるのだ。
私は、ホームボタンを長押しして起動することができるこの機能が、Android端末に実装されていることをしばしば忘れてしまう。しかし、PixelのようなGoogle Assistantが実装されているスマートフォンの場合、追加情報があることを知らせるために、アニメーションが表示されるとのことだ。
Pixel以降、Android端末はどうなっていくのか？iOS端末におけるGoogleアプリとGoogle Assistantとの関係はどうなるのだろうか？
ハッフマン氏は次のように述べている。「最終的な目標は、広範囲おいてGoogle Assistantを普及させることだ。しかし、その順序や期限などは設けていない。我々は、新しいGoogle製のスマートフォンから始めていくことが、まずは最善であると考えている。」
Google Assistantで注視すべき分野はGoogle Homeであろう。Googleにとっても最も注力する分野だ。この分野がデスクトップの領域を支配するようになれば、既存のプレーヤーを窮地に追い込むことになる。モバイル検索が台頭した際、Googleは自身の強みを保持しながら、変化する環境に適応している。
インターネットに接続されたデバイスやホーム・アシスタント端末は新たな境地である。Googleにとって好ましいことは、この新たな領域こそが、Google Assistantにとって理想とも言える領域であることだ。
私は、Amazon Echoを長らく愛用している。そして、多くのAmazon Echoのユーザーと同様、私はこのデバイスを非常に気に入っている。音楽の再生、ニュースのヘッドライン、ショッピングリストへの追加などが音声で行うことができ、そのたびに「未来はここにある」というような感覚を覚える。
Amazon Echoにとっての課題は、複雑な作業や、既存の情報リソースでは対応できない内容が求められた場合だろう。そして、その課題に対して、Googleは解決策を提供している。Googleは既に、スマートフォンにおける音声検索とWeb全体から答えを導き出すという経験をすでに持っているのだ。
Google Homeによって、大まかな検索体験は保持しつつ、非常に狭い領域での対応が必要な場合も対処してくれるはずだ。Amazon Echoよりも低価格であることからも、Google Homeが大きな売り上げを見せ、多くの家庭に設置される可能性はあるはずだ。
Google AssistantがGoogle Homeに搭載されるが、人間の名前のようなものは付けられていない。AppleのSiri、MicrosoftのCortana、AmazonのAlexa。Googleは・・・、Google Assistantだ。
「信じてほしい。我々はその件について、本当に長い時間、社内で検討しているのだ。」とはハッフマン氏の言葉である。
「Google AssistantはGoogleのインターフェイスであり、代表するものだ。そのため、”ジョーイ”や”スージー”といった名前は付けづらい。」とも述べている。
映画スタートレックに登場するような、コンピューターに向かって話しかけるという状況とよく似ている。スタートレックに出てくるコンピューターにキャッチーな名前は付けられておらず、我々は”コンピューター”と呼んでいたのだ。
ハッフマン氏はGoogle Assistantは個性（パーソナリティ）を持つことになると述べている。Googleは確かにその取り組みを進めており、こちらの記事で詳細を確認することができる。
少なくとも、Google Assistantはいずれ正式な名前を付けられるだろう。先日のGoogle IOで発表された際は、”Google assistant”と発表されていた（assistantの”a”が小文字になっている）。Googleは、まだ満足のいく名前は付けれらていないのだ。
今回発表されたGoogle Assistantは、1つの名前であるが2つの意味を持っている。1つはGoogleが長い間をかけて構築してきた検索プラットフォームを多くのプロダクトに組み込むというもの。もう1つは、ユーザーを支援してくれる存在としての名前であり、ユーザーに愛される存在となることを望んでいる。
Google AssistantとGoogle Homeについての詳細は、本日行われたGoogleのイベントについての記事も確認してほしい。
この記事は、Search Engine Landに掲載された「With Google Assistant & Google Home, Google seeks to win the hands-free generation of search」を翻訳した内容です。
さて、9月に入りにわかに更新のうわさが出始めたペンギンアップデートですが、この度正式にローンチされたようです。これから開始される、というニュアンスであるため、今までの変動はペンギンと関係が無いと考えるべきでしょうか。とにもかくにも、パンダアップデートと同様にリアルタイムになったペンギンアップデート。今後しばらくは関連記事でにぎわうかもしれませんが、速報ベースでお届けします。– SEO Japan
＊記事内のリンク先は全て英語となっています。
Googleがウェブマスター向け公式ブログ（日本語版はこちら）にて、リアルタイム版のペンギンアップデート4.0のロールアウトを開始したことを発表した。ペンギンアップデートが最後に更新されてからほぼ2年が経とうとしていた。2014年10月に更新されたペンギンアップデート3.0であり、Googleが更新を認めた最後のペンギンアップデートであった。昨日、私はペンギン4.0のテストと見られる兆候があることを記事にしていた。Googleは、この兆候が、ペンギンアップデート4.0のローンチと関係があることを明らかにはしないだろうが、とにもかくにも、ペンギン4.0は現実のものとなった。
ペンギンアップデート4.0はリアルタイムのアルゴリズムのため、「我々は今後、更新についてのコメントを出すことは無い」、とGoogleは述べている。リアルタイムになることにより、Googleがあなたのページを再クロールし、再インデックスするとすぐに、これらのシグナルが直ちに新しいペンギンアルゴリズムに使用されるようになるとのことだ。
Googleはこうした処理を、パンダアップデートでも行っている。パンダアップデートが、コア・アルゴリズムの一部となった際に、このようになった。また、Googleはパンダアップデートの更新についてのコメントも行わないと述べている。
Googleは、ペンギンアップデートはロールアウトの最中だと述べている。そのため、完全にロールアウトされるまでは、その影響があなたには及ばないかもしれない。完全にロールアウトされるまでにどのくらいの時間がかかるか、私に予想することはできない。下記にGoogleからのコメントを引用する。
・Penguin のアップデートがリアルタイムになりました。
これまでは、Penguin の影響を受けるサイトのリストは、定期的に同じタイミングで更新されていました。ウェブマスターがサイトを大幅に改善し、インターネット上でのプレゼンスを強化すると、Google の多くのアルゴリズムではすぐに考慮されますが、Penguin など他のシグナルでは更新作業が必要でした。今回の変更により、Penguin のデータはリアルタイムで更新されるようになります。そのため、変更内容が従来と比べてはるかに早く（通常、Google が再クロールしてページをインデックスに再登録するとすぐに）反映されます。また、Google が今後の更新についてコメントすることもなくなります。
・Penguin でさらにきめ細かい対応が可能になりました。
新しい Penguin では、スパムに対して、サイト全体に影響を与えるのではなく、スパムのシグナルに基づいてランキングを調整するようになりました。
＊ウェブマスター向け公式ブログ（日本語）より、引用いたしました。
「リアルタイムになる」、ということはすぐに理解できるだろう。Googleがページをインデックスすると、ペンギンに関わるシグナルをすぐに再計算するということだ。
「より細かい対応」、ということについては少々複雑だ。察するに、過去はサイト全体に影響を与えていたが、今回の変更により、ページ単位で影響を与えるようになったということだと思う。そのため、あなたのサイト内で本当にスパムなページや本当にスパムなセクションがあれば、それらのみペンギンの影響を受けるようになるということだ。（以前はサイト全体に影響を与えていた。）これは、単に私の推測であるため、今後明らかにしていきたいと思う。
Penguin 1.0 on April 24, 2012
Penguin 1.1 on May 22, 2012
Penguin 1.5 on October 5, 2012
Penguin 2.0 on May 23, 2013
Penguin 2.1 on October 4, 2013
Penguin 3.0 on October 18, 2014
Penguin 4.0 on September 23, 2016
あなたのサイトがペンギン3.0にヒットしており、現在も順位が回復していないのであれば、いまだペンギン3.0の影響を受けているということになるだろう。完全にロールアウトされているかを見極めるために数週間かかると踏んでいるが、Analyticsのデータを確認し、順位の回復があるかどうかを観測すべきだろう。特定のセクションやページが影響を受けている場合、今回のアップデートによる影響があったかどうかを判断することが難しくなるだろう。
良いアイデアとして、リンクの否認ファイルを使用し、悪影響があると思われるリンクを否認するという方法がある。アルゴリズムの更新を2年間待たなければならないのと比べ、非常に速く（私は数日と見込んでいる）その効果が確認できるだろう。しかし、それと同時に、ペンギンにヒットされるタイミングも、今まで以上に速くなることも意味している。
何人かは昨日すでにその影響を目撃しているかもしれない。
この記事は、Search Engine Roundtableに掲載された「Google Penguin 4.0, The Real Time Penguin Algorithm Is Live」を翻訳した内容です。
＊記事内にある注釈はSEO Japanによる追記となっております。
Google Adwordsが昨日多くのアップデートを発表した。ショッピング広告・商品リスト広告とホテル・トラベル検索の広告が対象だ。
Googleは”ホテル スマートフィルタ（Hotel Smart Filters）”を追加した。これにより、検索者は評価や価格を元に、ホテル検索結果を絞り込むためのオプションを使用することができる。また、「サンフランシスコにある、200ドル以下のペットが泊まれるホテル」といったクエリにも対応し、検索者の希望にマッチした対応を行えるホテルを表示する。この機能は米国で使用することができ、今年の後半にグローバルで展開される。
また、Googleは先日我々が報じた、お値打ちのホテル料金（hotel deal）ラベル（注1）を検索結果に表示する機能をローンチした。さらに、検索者にとって有益なアドバイスを送る機能も追加している。例えば、「日付を少し変更すれば予算を抑えることが出来ますよ」、といったアドバイスだ（注2）。加えて、Googleはフライトの金額を伝えてくれる機能も追加した（注3）。この機能により、あなたがフライトの料金の変動を調べるために、毎日フライト料金を確認する必要がなくなることになる。Googleがあなたにアラートを送ってくれるからだ。
（注1）通常の料金よりも安い価格で提供されている場合、表示されます。このラベルの表示の判断はGoogleのアルゴリズムによって自動的に行われます。初期のテストでは、このラベルが表示されていた場合、他のホテルよりも2倍の予約数になったとのことです。
（注2）hotel dealと併せ、今後数か月かけて、グローバルに展開されるようです。
（注3）Googleフライト検索の新機能と言えます。価格が安くなった場合に限らず、上昇したときもお知らせしてくれます。お知らせの方法はメールとGoogle Nowのカードとなっています。今後数週間で、Googleフライト検索が使用できる26か国で使用可能になるとのことですが、個人的に試したところ、日本でも使えるようになっているようでした。
下記に、これらの機能のスクリーンショットを記載しておく。
個人的にはフライトの金額を伝えてくれる機能に興味があり、航空会社を限定できれば良いと思っている。実際に試してみたのだが、あなたも試すことが出来ると思う。
(1)検索した後、トラックボタンをクリックする。そして、経由なしで、ユナイテッド航空の便で、特定の日付で検索した。
(2)確認画面が表示される。
(3)あなた宛のアラートがある場合、赤のアイコンが表示される。これをクリックするとステータスページに行き、アラートのオン・オフや修正などを行うことができる。
ショーケース・ショッピング広告（Showcase Shopping ads）が登場した（注4）。これは、特定のアイテムの検索のさい、検索者によりリッチなカルーセル体験を提供するものだ。この機能は米国、イギリス、オーストラリアでのショッピングキャンペーンで利用可能である。検索結果にふさわしければ、今後数週間で、ショーケース広告内にあなたの商品が自動的に掲載されることになる（注5）。
（注4）”女性のスポーツ用の服”や”リビングルームの家具”など、具体的な商品名でなく、漠然としたクエリに対して表示されるようです。ちなみに、下記の例は”サマードレス”での検索となっています。
（注5）プレミアム版もテストしているようです。これにより、表示方法のカスタマイズが可能となるようです。
下記にこの機能のアニメーションを掲載する。
また、YouTubeのTrueView for shoppingにもコンパニオン・バナー（companion banner：注6）とプロダクト・ピッカー（product picker：注7）という機能が追加された。
（注6）YouTubeの動画画面の下に表示され、カルーセルのようにスクロールすることが可能です。ユーザーは動画を視聴しながら、この機能を体験できます。下記の画像の左側がこの機能になります。
（注7）TrueViewで表示されるカードの内容（商品）に優先度を付けることができる機能です。コンパニオン・バナーと共に、グローバルで更新が展開され始めたようです。下記の画像の右側が、この機能になります。
*上記画像は、Search Engine Landの記事がソースです。
さらに、他国の購入者はその国の通貨で価格を見ることができるようになった。お店がその国とは異なった通貨で販売していてもだ。（注8）
（注8）オーストラリア、スイス、カナダ、イギリスが対象のようです。例えば、イギリスにいる購買者がアメリカのお店の商品を閲覧したさい、ポンドでも価格が表記されるといった具合です。
この記事は、Search Engine Roundtableに掲載された「Google AdWords Adds Features To Shopping Ads & Hotel/Travel Search」を翻訳した内容です。
SMX Advanced初日の締めくくりは、恒例のGoogleによるSEOについてのトークセッションであった。
美しいシアトルの街からこんにちわ。満員御礼の我らがSMX Advancedの初日は、Googleによるキーノートで幕を閉じる。
今夜、創始者であり編集者でもあるダニー・サリバン氏が、GoogleのWebマスタートレンドアナリストであるゲイリー・イェーシュ氏と、1時間にわたるトークセッションを行う。業界では長い間の関心ごとであるペンギンアルゴリズムや、RankBrainやキーワードに基づいたトップレベルドメインについてなど、多くのアツいSEOのトピックが話されることだろう。
このトークセッションは、5:00pm(PT)に開始される予定だ。ライブブログはこちらのページで書くため、いつでも戻ってきてほしい。
準備ができたようだ。いつも通り、ダニー・サリバン氏は”DS”（SEO Japanでは”ダニー”とします）、ゲイリー・イェーシュ氏は”GI”（SEO Japanでは”ゲイリー”とします。）とそれぞれ表記する。また、オーディエンスによるツイートも随所に含める予定だ。さぁ、我々についてきてくれ！
ダニー:はじめは簡単な質問から始めたほうがよいかな。RankBrainの全てを我々に簡単に説明してくれる？（会場爆笑）真面目にいこうか。RankBrainは本当にランキング要素なのだろうか？
ゲイリー:最初の質問が簡単な質問であるなら、この先が思いやられるな。ここでも、我々が常に言っていることの繰り返しになる。基本的に、RankBrainはランキング要素だ。そして、機械学習の一部でもある。皆さんは機械学習をご存じだろうか？機械学習とは、データからパターンを特定しようと試みるものだ。過去の検索を見て、こうした検索に対して上手く作用したものに基づき、特定のクエリに対する最適な検索結果を予測しようとする。この仕組みは、ロングテールのクエリや、我々が今までに見たことのないクエリに最適な仕組みとなっている。
一例を挙げてみよう。”マリオブラザーズを攻略本を使用しないで攻略することは可能か？（can i beat Mario Bros without using a walkthrough）”というクエリがあったとする。RankBrainがないと、私の要求に答える結果は表示されないだろう。しかし、RankBrainがあれば、私を満足させる検索結果が表示されるはずだ。
つまり、RankBrainはクエリに対して、どのような検索結果が良いかを、より良く理解するのだ。RankBrainは、ストップワード（*）が除外されるべきでない場合もあることを理解する。時々、”with”という単語はクエリから除外されてしまうのだが、RankBrainはそれをそのままにしておいた方が良い場合も理解している。
*”a”や”the”や”such”など、言語処理をする前にフィルタリングされる（不要な）単語。
Machine learning tries to ID patterns and bucket the data#SMX @methode #14A#FacebookLive https://t.co/V18IVS8FhQ
— Kristine Schachinger (@schachin) 2016年6月23日
Rankbrain is a ranking signal, but @methode stopped short of saying it's the third most important ranking factor #smx
— Adam Dince (@AdamDince) 2016年6月23日
ゲイリー:単純な理解という話ではなく、検索結果にスコア付けをする理解という話だ。
ダニー:RankBrainのスコアがあるということだろうか？
ゲイリー:いや、そういったスコアは存在しない。君が本当に聞きたいことは、RankBrainのための最適化があるかどうか、ということだろう？（会場爆笑）
ダニー:ある意味、私の質問の全ては最適化に関することだよ？（会場爆笑）
#RankBrain works better on queries that have not been seen and on long tail queries #SMX @methode#FacebookLive https://t.co/V18IVS8FhQ
— Kristine Schachinger (@schachin) 2016年6月23日
ダニー:RankBrainは既存のシグナルを強化・活用するものなのだろうか？それとも、新しいシグナルなのだろうか？
ゲイリー:新しいシグナルだ。さっきRankBrainの最適化の質問だろう？と尋ねた理由でもあるのだが、RankBrainへの最適化を行うことはない。RankBrainはユーザーのクエリにふさわしい検索結果を提供する確信を得るためのものだ。コンテンツを自然な言語で書いていれば、それで全てが済む。コンテンツにキーワードを詰め込んでいれば、あなたにとって良くないこととなるだろう。
Rank Brain is new and unique signal. You don’t optimize for it. It enhances relevancy for Goog search results based on content@methode #SMX
— Sam Khandelwal (@subtletea) 2016年6月23日
you don't optimize for rankbrain. It's just another signal that serves better results for intent #smx #SMXadvanced Google AMA
— Steven Pope, MBA (@NewAgeMarketer) 2016年6月23日
ダニー:昨年、君はRankBrainはクエリの15%を処理すると話していたけど、現在はどうなんだい？（どのくらいの数のクエリ、という意味で。）
ゲイリー:それについてはわからないな。
ダニー:また、RankBrainは第3の要素であるとも述べていた。さらに、コンテンツとリンクが残りの上位2つだということだ。しかし、どっちが1番なんだい？
ゲイリー:え、そうなの？（会場爆笑）
ダニー:うん。そうだよ。
ゲイリー:その順番はクエリによるな。具体的な返答をすることはできない。なぜなら、非常に多くの要素に依存するからだ。
ダニー:Google assistantについては？
ゲイリー:率直に言って、何もわからない。皆さんがGoogle assistantとはどのようなものなのかを理解しようとしていることはわかっている。様々な素晴らしいアイデアとともに実験することは好ましいね。(機械学習についてのディスカッションがあったが、聞き逃してしまった。)”Her”という映画を見たことはあるだろうか？私は気味が悪いと感じるのだが、あれもGoogle assistantでできることについての良い例だと思うね。
ダニー:ドメイン内のキーワードをGoogleは見ているのだろうか？特に、キーワードに基づいたトップレベルドメイン(TLDs)について。
ゲイリー:トップレベルドメインは、特定のコンテンツや特定のURLとの関連性を測る上では、何も役割を果たしていない。国別のトップレベルドメインは特定の国々でのクエリにおいては影響を与えることもある。しかし、”弁護士(attorney)”や”ニュース(news)”のようなトップレベルドメインは、何も影響を与えない。
ダニー:ドメイン名は見ているのだろうか？
ゲイリー:ドメイン名を見る場合も確かにある。しかし、たいていの場合は見ていない。キーワードが含まれているドメイン名をわざわざ購入することはないだろうね。つまり、キーワードリッチなトップレベルドメインということだが、非常に不可思議なものだ。そんなことはしないほうがいい。
ccTLDS have an effect on ranking geographically #SMX @methode @dannysullivan #general
— Kristine Schachinger (@schachin) 2016年6月23日
Cctlds WILL play a role in local/country search results but gtlds don't impact ranking. @methode #smx
— Jenny Halasz (@jennyhalasz) 2016年6月23日
ダニー:2013年に、GoogleはSearch Consoleのデータを90日以上に延長すると言っている。それについてはどうだろうか？
ゲイリー:今は91日のデータを見ているよ。（会場爆笑）我々は今でも、どのようにして実現できるかを考えている。今年の初めに行われたGoogle Danceでも、多くのSEO担当者からこの件についてのフィードバックをもらったね。
ダニー:5月にGoogleはSearch ConsoleのデータをGoogle Analyticsに持ち運んだ。このデータは90日以上保管されるのだろうか？
ゲイリー:今までと同じだと思うね。
ダニー:もっと長いほうがいいな。（会場爆笑）
Lead of Google Search Console was "very direct" with the team to figure out how to make more longer data in SC happen via methode #smx
— Ben Schmaderer (@muc_webdesigner) 2016年6月23日
ダニー:ペンギンについて聞いてみよう。最後の更新は2014年の12月だ。イーロン・マスク氏が火星に到着する前にアップデートは行われるのかな？
ゲイリー:日付については何も言わない。なぜなら、多くの間違いを犯してしまったし、それがビジネスにとってよくないという話を聞いたからだ。
ダニー:年内だろうか？
ゲイリー:時期については何も言うことはないね。
There is no timeframe for a Google Penguin update #SMX #general
— SyncShow (@syncshow) 2016年6月23日
ダニー:パンダはどうだろうか？コア・ランキングアルゴリズムの一部になったということだが。（パンダの仕組みについての非常に長い質問を尋ねている。）
ゲイリー:パンダはリアルタイムにはなっていない。動いているが、数か月かかる。
Panda: @methode says it's not real-time, but it is continuously running. They roll it out, which takes *months* per cycle. Months. Wow #smx
— Glenn Gabe (@glenngabe) 2016年6月23日
ダニー:セキュアについて話してみよう。
ゲイリー:30%のページがHTTPSを使用していると思う。セキュア化をランキング要素にするかもしれないが、直近で行われるものではない。
Google looking if they can strengthen the https boost. Probably won't happen anytime soon. @methode #smx
— Jennifer Slegg (@jenstar) 2016年6月23日
I think around 30% of the results are secure. We're looking at whether we can increase the strength of the signal. @methode #smx
— Patrick Stox (@patrickstox) 2016年6月23日
ダニー:モバイルゲドン2が5月にあった。状態はどうだい？次はいつ起こる？
ゲイリー:”モバイルゲドン”（という表現）は好きじゃないな。
ダニー:非常に良い名前じゃないか。
ゲイリー:いや、全然良くない。
ダニー:では、君が名づけてくれ。くれぐれも、”モバイル検索アップデート”なんて可笑しな呼び方はしないでほしいな。
page speed is more important on mobile than desktop, will be a bigger factor @methode #SMX
— Jared Miley (@JaredMiley) 2016年6月23日
.@methode on mobilegeddon (which he hates btw): we won't do another one, but we might update it and add more signals. :-/ ? #SMX
— Jenny Halasz (@jennyhalasz) 2016年6月23日
ダニー:ソーシャルシグナルについてはどうだろうか？Facebookのいいねや、Twitterのリツイートなどは見ていないのだろうか？
ゲイリー:見ていないね。ソーシャルシグナルについては問題がある。なぜなら、誰かが手を引くことが可能な何かに依存したくはないからね。
（Google+についての質問があったが、聞き逃してしまった。）
ゲイリー:ちなみにだが、我々はオーサーシップを全く使用していない。
ダニー:全く？
ゲイリー:全くだ。
from @methode “we are not using authorship at all anymore…we are smarter than that.” but thanks for giving them all that data, SEOs. #smx
— MichelleRobbins (@MichelleRobbins) 2016年6月23日
ダニー:音声検索とタイピング検索を比較したい。こうしたデータを見ることはできるだろうか？
ゲイリー:可能ではある。すでに取り組んでいるか、どのようにして実現すべきか、どちらかを決断しようとしている。
*ここからはオーディエンスからの質問
"Tabbed content, do you love it or hate it?" –@dannysullivan "It's fine, it's fine, leave it." –@methode #SEO #SMX
— Jayna Grassel (@jaynagrassel) 2016年6月23日
ゲイリー:クリック数は、パーソナル化のように、非常に特別な状況で使用している。”apple”という検索を初めてしたとき、それが果物を意味しているのか、会社を意味しているのか、Googleはわからない。もしあなたが、会社のページを普段からクリックしていれば、Googleはそれを学習し、あなたが興味のあることを学んでいる。
@methode: Google uses clicks and CTR for personalization. Google can then surface more relevant results for future searches. #smx
— Glenn Gabe (@glenngabe) 2016年6月23日
Soooo clicks and CTR are used for "very specific things" in Google's algorithm…like personalization @methode #SMX #seo #Google
— Kristan Bauer (@kristandauble) 2016年6月23日
ゲイリー:皆さんがたまに行っているクリックの実験については、我々が行っているクリックの実験とぶつかるときがある。それは好ましくない。非常に迷惑なことだ。
"Unfortunately, all these click experiments people are running can sometimes interact with Google's own experiments." @methode #smx
— Jennifer Slegg (@jenstar) 2016年6月23日
Wow! Despite some tests that show CTR from SERPs affect Google rankings, @methode denies that CTR is a ranking factor. #smx
— Adam Dince (@AdamDince) 2016年6月23日
ダニー:（オーディエンスからの質問）HTTPS2(*)には対応すべきだろうか？
*原文ママ。
ゲイリー:新しい分野だね。実装したときのことは見ているが、HTTPSにダウングレードできる場合に限り、実装したほうが良い。我々は、Googleボットが正確に扱うことができるように取り組んでいるが、上手く扱うことができないブラウザもある。HTTPSに戻ることができなければ、自分の首を絞めてしまう可能性がある。
HTTPSへの移行に関しては、あなたがどのくらいユーザーをケアできるか、そして、それをWebサイトに取り込むことができるか、によるだろう。
ダニー:HTMLとXMLのサイトマップを送信しているにも関わらず、私のサイトの全てがインデックスされないのは何故だろうか？
ゲイリー:こうした質問は良く受けるが、最も多い理由は、noindex、robots.txt、 rel=canonical、クローキングといったものだ。
ダニー:異なる業界に異なるアルゴリズムを使用している？
ゲイリー:ユニバーサル検索においては、”画像に適したクエリ”というものがあったりする。しかし、業界ごとに異なるアルゴリズムを使用することはない。
ダニー:去年から絵文字が検索結果に表示されなくなった。しかし、Google Newsではまだ表示されている。タイトルタグ内に絵文字を使用してもいいかな？
ゲイリー:だめだ。
ダニー:最後に、皆さんに伝えたいアドバイスなどはあるだろうか？
ゲイリー:2つある。AMPには注意を払ってほしい。非常に大きなものになるだろう。開発者と相談し、実装方法を確認しておくべきだ。次に、(Google)assistantやチャットボットの発達には注目しよう。非常に大きなものになるだろうし、こうした機能を初めて使用したグループの一員になればいいと思う。
この記事は、Search Engine Landに掲載された「#SMXAdvanced keynote: Google’s Gary Illyes talks RankBrain, Penguin update & more」を翻訳した内容です。
Search Consoleにリッチ検索結果のフィルタが表示されていたスクリーンショットが流出していたが、現在は全てのユーザーが使えるようになっている。
GoogleはSearch Consoleの検索アナリティクスに、”リッチ検索結果”をフィルタリングできる機能を、ひっそりと追加した。
リッチ検索結果とは、リッチカードやその他のリッチスニペットで検索結果に表示された場合を指す。このレポートにより、どのくらいのインプレッションとクリックがリッチ検索結果からもたらされており、通常の検索結果と比較し、クリック率がどのように異なっているか、などを知ることができる。
下記に、検索での見え方に含まれている、リッチ検索結果フィルタのスクリーンショットを記載しておく。
Google I/Oにて、我々はこのフィルタが近いうちに実装されるという証拠を目撃しており、そして、それが現実のものとなった。ちなみに、Googleは数日前に、AMPフィルタをレポートに追加している。
Googleは、リッチ検索結果がレポート内で使用できるようになったことを公表していないが、あなたのアカウントでもきっと確認できるはずだ。
この記事は、Search Engine Landに掲載された「Google brings rich results filter to Search Analytics report within Search Console」を翻訳した内容です。
.yellow-background { background-color: #FFF8DC; padding: 20px 40px 20px 30px; margin: 5px 30px 5px 30px; border-radius: 10px; }
SEO担当者、Webマスター、デジタルマーケター。皆、それぞれお気に入りの”強力なツール”があることだろう。
その中でも、”絶対に必要なツール”についての記事を書きたいと思う。それなしでは、SEOを行うことができない、といったツールだ。
そのツールとは何だろうか？
GoogleのSearch Consoleだ。略してGSCと呼ぶこともある。（かつてはGoogle Webマスターツール、もしくは、GWTと呼ばれていた。）
GSCはGoogleから提供されている無料のサービスであり、あなたのサイトの検索における機能性を管理することができるツールだ。Search Consoleは一連のレポート集であり、検索でのランキングを戦略的に最適化すると同時に、エラーの修正も助けてくれるツールである。
今回の記事では、この強力なツールを用い、あなたのSEOをより良いものとするための方法について、記したいと思う。
乱暴な表現かもしれないが、SEOにとってのGSCは、人間にとっての酸素のようなものだ。必要とされ、それなしでは生きていけないものなのである。
*リンク先でメールアドレスを入力すれば、今回の記事のまとめをPDFでダウンロードできます。
今、あなたが読み進めているこの記事は、GSCにおける、大学卒と言えるレベルの内容を記載している。ここでの内容をマスターすれば、あなたはGSCニンジャとなることができるだろう。
そして、それはあなたのSEOに非常に大きな違いを生むこととなるはずだ。
まずはこの記事の概略を説明したい。非常に長い記事となっているため、キリの良いところで区切って読みたいと感じるだろう。
この記事はセクションとサブセクションに分かれているが、この分け方は、GSCのメニューに基づいている。
*元記事では英語画面のキャプチャですが、日本語画面のキャプチャに差し替えています。
上記のセクションの内、始めの4つのセクションに注力している。つまり、パートAからパートDまでである。パートEとパートFも重要ではあるが、あまり説明を必要としないものだからだ。
検索での見え方のセクションは、あなたのWebサイトが検索結果画面でどのように見えるか、をビジュアル化するのに役立つ。
ここでは多くのメニューがある。リッチカード、リッチスニペット、Accelerated Mobile Pages (AMP)などだ。さらに、通常のHTMLの修正もあり、こうしたメニューは、あなたのWebサイトを検索結果画面で目立たせたり、追加情報を表示させるといった作業を手助けしてくれる。
下記では、このセクション内のそれぞれについての要素を解説し、検索における優位性を得るための使用法を説明する。
（リッチスニペットとしての）構造化データをHTMLのコード内に記述すると、Googleがカテゴリ分けとインデックスをより良く行ってくれる。Googleはこれを利用し、”リッチ”な検索結果を提供してくれる。
下記のような検索結果は、構造化データを使用した例である。
上記は”blackberry sauce（ブラックベリー ソース）”とGoogleで検索した結果画面である。
上位4つまでの検索結果だ。
こちらを注意深く見てほしい。3位と4位の検索結果は、より”リッチ”に見えるだろう。なぜなら、評価、投票、レビューを表示しているからである。4位の検索結果では、カロリーの情報も表示されている。
上記の内、どの検索結果をクリックしたくなるだろうか？もちろん、あなたがどんな情報を探しているかに依るが、私は3位か4位の検索結果をクリックしたくなる。
なぜか？その理由は、こうしたリッチな検索結果は、そのサイトが私にブラックベリー・ソースの作り方を教えてくれるだけでなく、実際に作った人のレビューも知ることができると、伝えているからだ。
さらに、ソースを作るために必要な時間も知ることができる。他の人が実際に作り、それを好んでいるという点について、自信を持つことができるのだ。また、そのソースを食した場合、どのくらいのカロリーがあるのかも知ることができる。
リッチな検索結果のパワーを実感できただろうか？
視覚的にリッチな検索結果はより多くのトラフィックを運んでくれるだろう。
現在、Googleがサポートしているリッチスニペットの対象範囲は下記の通りである。
豊富なラインナップとは言えないかもしれないが、自身のサイトに追加できるリッチな情報の量には驚くだろう。
それは、非常に大きな違いを生むはずだ！
SEOのために構造化データを活用する方法：
私が上記で言及した要素の内、あなたのWebサイトで使用可能なリッチスニペットを全て実装するように、開発者に依頼しよう。コードの内容やヘルプの参照のために、Schema.orgのサイトを確認しよう。
GSCの構造化データのセクションを活用する方法：
こちらのセクションでは、リッチスニペットのコード内でエラーがある場所を確認できる。また、実際のデータを用いたテストを行うこともできる。（下記画像の青いボタンがそれにあたる。）
リッチカードは、Googleによる新たな発明だ。構造化データ（上記に記載）のような見え方であるが、視覚的によりアピールできるものになっている。両者の違いを確認するために、下記の画像を見てほしい。
画像のソース：https://webmasters.googleblog.com/2016/05/introducing-rich-cards.html
自身のコンテンツを視覚的にアピールできれば、大きなユーザー・エンゲージメントを獲得できるだろう。その結果、トラフィックや売り上げへの貢献も期待できる。現在のところ、リッチカードはレシピとムービーで使用可能だ。
SEOのためにリッチカードを活用する方法：
リッチスニペットと同様、レシピやムービーの情報に対し、リッチカードを実装してもらうように開発者へ依頼しよう。サンプルコードはこちらのページで見ることができる。
GSCのリッチカードのセクションを活用する方法：
ここでは、リッチカードのコーディングにエラーがあるかどうかを確認することができる。また、リッチカードに対応している数も見ることができる。リッチスニペットのセクションと同様、Googleは実際のデータを使用したテストを行えるツールも提供している。
画像のソース：https://webmasters.googleblog.com/2016/05/introducing-rich-cards.html
データ ハイライターは、構造化データの代わりとなる素晴らしいものだ。HTML内にスニペットのコードを記述するよう、開発者に依頼する必要がなくなる。
これは、構造化データと同じように、コンテンツをマークアップできるのだ。
また、このツールには限界があるとも言える。URL単位でタグを書かなければならないのだ。あなたのWebサイトが数千ものページがあるのであれば、大きな苦痛となってしまうだろう。
SEOのためにデータ ハイライター（*）を活用する方法：
*原文ではリッチカードと記載されていますが、おそらく間違いであるため、修正しました。
下記に、この機能を使うためのチュートリアルの動画を記載しておく。
HTMLの改善では、Googleがあなたのサイトをクロールし、インデックスする最中に発見した、問題のある個所を明らかにしてくれるレポートである。
下記に、このレポートに含まれる問題個所をまとめておく。
SEOのためにHTMLの改善レポートを活用する方法：
非常に簡単だ。Googleがレポートしてくれた問題を修正すればよい。
既にご存知かと思うが、下記に基本的なSEOのルールをまとめておく。
サイトリンクはGoogleによって自動的に生成される。サイトリンクへあなたが特別な変更を加える必要はない。Googleはアルゴリズムを用いて、いつ、どのようにして表示させるかを決定しているからだ。
下記に、サイトリンクが検索結果画面で表示される例を記載しておく。
サイトリンクをコントロールすることはできないが、それでも、改良したり、表示する可能性を高めるためにやれることはある。
検索結果画面に表示されるあなたのサイトのURLの下にGoogleがサイトリンクを表示するためには、関連性を強め、ユーザーの手助けとなり、意味のあるコンテンツをあなたのサイトに追加し続けることが大事だ。
あなたのコンテンツが多くの人にリーチすれば、Googleは自動的にサイト内のカテゴリを、サイトリンクとして表示するようになる。
*こちらの記事は、SEO Japanで翻訳しています。
「Accelerated Mobile Pages (AMP)とは何か？ニール・パテル氏による決定版ガイド。」)
Accelerated Mobile Pagesとは、開発者が読み込み速度の速い、HTMLとJSのページを構築するための技術だ。AMPはオープンソースの仕様に基づいている。
AMP HTMLの背景には、モバイルデバイスにおける読み込み速度の向上を目指す、という考えがある。インターネットに接続するためにモバイルデバイスを使用している人の数は増加し続けている。GoogleはAMP HTMLを導入し、Webサイトのオーナーがモバイルデバイスでの読み込みの遅延となる要素を排除できるようにしたのである。
SEOのためにAMPを活用する方法：
テクノロジーの恩恵を受けよう。開発者に依頼し、AMPの実装を進めよう。そして、通常のHTMLをAMP HTMLへと対応させるのだ。
GSC内のAMPセクションは、Webマスターへコードのエラーを伝えてくれる。詳細は、GoogleのWebマスターブログを確認しよう。（日本語記事はこちら。）
*上記の見出しは原文にはありませんでしたが、おそらくミスであるため、追加しておきました。
このセクションでは、あなたのサイトへのリンク、どのキーワードでランキングされているか、Googleからのペナルティ、モバイルフレンドリーなどの情報が得られる。
非常に多くの情報がこのセクションにはある。私は、ここのセクションがSEOにおける実行可能なデータのための、GSCで最も価値のあるセクションであると考えている。
このレポートはあなたのサイトについての詳細をレポートしてくれ、検索結果画面にどのくらいの頻度で表示されているかを示してくれる。
このレポートは、キーワード毎のクリック数、キーワードの地域別の順位、クリック率などの情報を表示してくれる。下記は、それぞれのカテゴリーをパートごとに分けたものであり、より良いSEOを行うための、それぞれの機能やフィルタの活用方法をまとめたものだ。
1.キーワード毎のクリック数
それぞれのキーワードが検索結果で何位に表示され、どのくらいのクリック数を獲得したかがわかる。バックリンクの構築、コンテンツの追加や最適化、特別なランディングページの作成などを行い、キーワード毎のクリック数を増加させよう。
2.キーワード毎のインプレッション数
それぞれのキーワードに対し、ユーザーがどのくらい反応したかがわかる。例えば、高いインプレッション数で低いクリック数を示した場合、ページのタイトルやディスクリプションが最適化されていなかったり、リッチスニペットが表示されていない、といった気づきを得ることができる。
3.CTR(click-through ratio)
クリック率はパーセンテージで表示される。基本的に、こちらのパーセンテージは、CTRとインプレッション率の比率で表されている。
4.掲載順位
キーワード毎の掲載順位がわかる。高順位を獲得したいキーワードを元に、キーワードやページを最適化しよう。
5.クエリフィルタ
任意のキーワードの掲載順位、1つのキーワードと別のキーワードとの比較、キーワードのソート、などを行える。こちらのフィルタを使用することで、それぞれのキーワードに対する、より深い洞察が得られるだろう。キーワード毎の分析を進め、高順位のキーワードにおけるパフォーマスをさらに改善しよう。
6.ページフィルタ
ページフィルタはURLをフィルタリングし、1つのページを別のページと比較したり（A/Bテストの場合、非常に便利だ）、クリック別のURLのより分けなどが行える。この機能を活用し、ページのパフォーマンスを、高・中・低に分け、順位を改善するためのSEO施策を行おう。
7.国別フィルタ
グローバルでオーディエンスを獲得したい場合に、国別フィルタは便利だ。私はこの機能を使用し、このブログを82か国語に翻訳するという実験を行った。そして、驚きの結果を得ることができた。このフィルタは、国ごとのサイトのパフォーマンスを計測することに役立ち、2か国間での順位を比較することができる。
8.デバイスフィルタ
デバイスフィルタはあなたのサイトにアクセスした、デスクトップ、タブレット、モバイルのそれぞれのデバイスをフィルタしてくれる。それぞれの数値をデバイス間で比較することができ、新たな気づきが得られるだろう。このフィルタを使用することで、どんなデバイスからのアクセスが多いかを把握し、そのデバイスに最適化した施策を行おう。例えば、モバイルからのアクセスが大部分を占めている場合、モバイルにおけるユーザー体験の向上に努め、読み込み速度の速いページの作成に注力しよう。
9.検索タイプフィルタ
こちらのフィルタは、Web、画像、動画の検索ボリュームを表示してくれる。例えば、あなたのサイトがギャラリーページを持っていたとしよう。しかし、画像検索でのランキングが低ければ、各画像のalt属性や画像タイトルを改良し、掲載順位の改善に役立てることができる。
10.日付フィルタ
このフィルタは日付の範囲を設定できる。2つの日付範囲からサイトパフォーマンスを比較することができる。ちょうど、Googleアナリティクスと同じように。
このセクションでは、あなたのサイトにリンクを張っているWebサイトと、バックリンクで使用されているキーワードの情報を得ることができる。
このレポートから多くの気づきを得ることができるはずだ。
下記に、その中でも大きな2つのポイントを挙げておく。
このセクションでは、該当のページヘ向けられている、内部リンクの本数を確認することが出来る。
下記に、このレポートのSEOにおける活用方法を記載する。
このレポートは、スパムやブラックハットの手法を理由に、あなたのサイトへGoogleがペナルティを与えた場合にお知らせしてくれるレポートだ。
ここで、”手動による対策”はアルゴリズムによるペナルティとは異なることを意識してもらいたい。アルゴリズムによるペナルティは自動で行われ、このセクションでは反映されないものだ。一方、手動による対策はより厳しいもので、広範囲な対応があなたに求められる。
レポートに記載された問題を修正し、あなたのサイトが有益なコンテンツを掲載していることを確認した後に、順位を戻すために再審査リクエストに必要事項を記載する。
Googleの品質ガイドライン（日本語ページはこちら）を読み、Googleがスパムだと考えているものを学ぼう。
このセクションは、メインのロケーション以外の異なる地域のユーザーに対して、その地域の言語に翻訳され、修正されたコンテンツを提供しているWebサイトのみ、利用価値のあるセクションとなっている。
例えば、あなたのサイトがイギリスからのユーザーをターゲットとしているのであれば、イギリス英語で書かれたページを彼らに見せたいはずだ。
もしくは、フランスやドイツの顧客に商品を販売したい場合、彼らの言語に翻訳したページを用意しておくべきだろう。
こうした場合、開発者はhreflangタグを使用し、その地域に適したページを表示するようにGoogleへ伝えることができる。
このセクションでは、そのhreflangタグが適切に使用されているかを確認できる。その情報は、コーディングを修正し、最適化するために必要となるはずだ。
このレポートでは、あなたのWebサイトにある、モバイルデバイスにおけるポジティブな体験を損なうような問題をリスト化している。
互いに近すぎる要素、スクリーン幅よりも広いコンテンツ、ビューポートが設定されていないコンテンツ、小さすぎて読めないテキストがある箇所などをレポートしてくれる。
このレポートに記載されているエラーは全て問題となるものだ。モバイルの最適化は重要なランキング要素であり、確実に標準レベルに達していなければならない。
SEOの目的から言えば、レポート内の問題を全て修正し、あなたのWebサイトがあらゆるデバイスで素晴らしい体験を提供していることを確信しなければならない。
このセクションは、GoogleがあなたのWebサイトとキーワードをどのようにクローリングし、インデックスしているかをレポートしている。
ここのインデックスのステータスは、GoogleによってインデックスされているURL、（robots.txtによる）ブロックされているURL、削除されたURLの状況を表示している。
インデックスがされていなかったり、ブロックされていたりするページがあれば、その原因を究明し、エラーを修正しよう。
インデックスに何らかの問題があれば、robots.txtファイルや、サイトマップの内容が正確かを確認してみよう。
ここのセクションでは、コンテンツ内のキーワードと、検索結果における重要性をレポートしている。
それぞれのキーワードを深掘りすることで、特定のキーワードやそれに近しいキーワードで表示されているページを理解することができる。
このレポートでは、上位に表示されていないキーワードとページを理解することにも役立つ。タイトル内、ヘッダー、alt属性、オンページSEO、タグ、コンテンツなどに、キーワードや関連語などを含めることにより、コンテンツを最適化するための手助けとなるだろう。
Googleはあなたのページを正確にインデックスし、レンダリングするために、JavaScript、CSS、JQuery、画像、ファイルなどに完全にアクセスすることを必要としている。
robots.txtやその他の方法でGoogleによる上記のリソースへのアクセスをブロックすれば、Googleがあなたのページをインデックスし、レンダリングすることを妨げてしまうことになる。
このセクションでは、ブロックされたリソースの設置個所を知らせてくれる。
検索結果のランキングを上昇させるために必要なものは、全て、ブロックを解除すべきだ。
いくつかのページはプライベートであるべきで、検索エンジンに見られたくない内容があるはずだ。
例えば、会員の個人情報、サードパーティー製のコンテンツ、ユーザーにとっては価値のないコンテンツなどは、検索エンジンがクローリングすることを避けたいと思うだろう。
このセクション内のツールは、Googleへ、そうしたURLをインデックスさせないように伝えることができる。”一時的に非表示にする”の内容を記載した後、キャッシュ、検索結果、どちらも、から該当のURLを削除するか選ぶことができる。一時的にURLを隠し、その後インデックス可能にすることもできる。
低品質なコンテンツ、価値のないコンテンツ、サードパーティーのコンテンツなどのURLを削除することは、SEOの改善につながる。そして、検索エンジンによる会員の個人情報へのアクセスをブロックすることは、あなたのブランドを守ることにつながる。
このセクションには、Googleボットのクロール率、抽出されたエラー、サイトマップ、ロボット、URLパラメータなどのレポート、そして、必要不可欠なFetch as Googleツールがある。
ここでは下記の項目を確認できる。
上記のエラーを修復することで、あなたのSEOが改善されるだろう。
クロールの統計情報は、1 日あたりのクロールされたページ数、ダウンロードされるキロバイト数、ページの読み込みに必要な時間、が表示されている。
これら全ての情報が行動を喚起するものではないが、注意すべき情報も含まれている。
概して、GoogleボットがあなたのWebサイトにおいてどの程度活発か、あなたのページがどの程度重いか、軽いか、を知ることができる。
ページスピードの改善のためにPage Speed Insightsを既に使用している方もいるだろう。そして、新鮮で、助けとなるようなコンテンツを定期的に投稿していることだろう。もしそうでなければ、Page Speed Insightsを使用して、アドバイスに従って改善しよう。
Fetch as Googleは、GoogleがあなたのURLを取得し、レンダリングする方法を試すことができる。
下記に、このFetch as Googleの使用法を記載する。
その後、Googleは下記のステータスを返す。
Fetch as Googleを使用し、ページの再インデックスをする場合は、どんなときか？
Robots.txtファイル(domain.com/robots.txt)は、検索エンジンへ、クロールすべき（または、すべきでない）ページを伝えるものだ。
クローラーがこのページを参照した場合、非許可となっていないものは全てクロールする。
例えば、CGI-BIN、管理者のログイン、パスワードを忘れた場合、会員の個人情報などのページへは、検索エンジンによるクロールをさせたくないはずだ。
こうしたページへ検索エンジンがクロールすることを防ぐために、robots.txtファイルを記述する必要がある。
robots.txt テスターセクションはrobots.txtファイルをテストし、エラーや警告を報告してくれる。また、あらゆるブロッキングの確認テストも行える。
sitemap.xmlはSEOにおいて非常に重要だ。検索エンジンへ、変更があった日付とともに、あなたのサイト内のURLを伝えることができる。これにより、検索エンジンがあなたのURLを効果的にクロールし、インデックスする手助けとなる。
GSC内のこのセクションで、サイトマップの送信を行うことができる。また、送信したURLとインデックスされたURLの数も確認できる。
このツールを活用し、あなたのURLの全てがインデックスされるように、sitemaps.xmlをチューニングしよう。
注意：コーディングについての知識がある場合のみ、このセクションを使用しよう。もしくは、開発者に依頼して、このセクションを使用してもらおう。
URLパラメータはURL毎に動的に付随される値だ。例えば、グローバルに商品を販売しているサイトの場合、異なる地域に適したページを表示するために、国別パラメータを使用しているだろう。
GSCのこのセクションでは、GoogleがこうしたURLを扱う方法を伝えることができる。
前述した通り、ここは非常にテクニカルな分野だ。そのため、開発者がいなければ、このセクションには近づくべきではない。間違ったパラメータを設定してしまうと、あなたのSEOを破壊してしまうだろう。
今日、セキュリティの問題はあらゆるWebサイトの関心ごとだろう。
Googleはこの問題を非常に重要に扱っている。下記のようなスクリーンを見たことがあるだろう。
Googleは検索結果にも、下記のような画像を表示している。
また、フィッシングの警告も行っている。
あなたのWebサイトが感染していたり、ハッキングされていたり、脆弱性があった場合、それについての情報をここのセクションで確認できる。
一方、下記のメッセージが表示されていれば、あなたのサイトはきれいな状態であるということだ。
もし、サイトがハッキングされた場合はどうすればいいだろうか？
下記の動画を確認しよう。
サイトがハッキングされた場合、時間とお金の両方の意味で、コストがかかってしまう。幸運にも、Googleはこうした場合のチュートリアルを公開しており、こちらで確認できる。
下記に、そのプロセスのまとめを記載する。
“その他のリソース”は、Googleのツール、ヘルプ、テスターのコレクションである。
下記に、まとめを記載しておく。
上記のリソースは全て役立つものであるが、全てが必須というわけではないだろう。
全てのツールに目を通すことに時間をかけるべきではないだろう。例えば、商品を販売しているサイトでなければ、”Google Merchant Center”を確認する必要はないだろう。
あなたのビジネスとSEOに最も重要なものを選び、それに注力すべきだ。
下記に、重要性を付けるために必要な4つのポイントをまとめておく。
今回のガイドを読み込んでいただければ、地球上の大多数の人間よりもGSCについての深い知識が得られたはずだ。さらに良いことは、ここで得られた情報をあなたのSEO、Webサイト、そして、ビジネスのために実際に活用することだ。
GSCは強力なツールだ。そして、あなたがGSCについて詳しくなればなるほど、より優秀なSEO担当者となるだろう。あなたはどう思うだろうか？すぐにでもGSCを活用し、あなたのサイトの順位の改善に役立てようと考えているだろうか？
この記事は、QUICKSPROUT「The Ultimate Guide to Using Google Search Console as a Powerful SEO Tool」を翻訳した内容です。
Search Console内の検索アナリティクスにて、1つの検索フレーズをもう1つの検索フレーズと比較できるようになった。
Googleがひっそりと検索アナリティクスに新しいオプションを追加した。1つのクエリを別のクエリと比較する機能だ。この機能は、 @Jonny_J_が最初に話題にしている。
“クエリを比較”フィルタの目的は、1つのクエリを別のクエリと比較することだ。現在、比較できるクエリは2つだけである。このオプションを使用した時の画像を下記に記載する。
このフィルタを使用するには、Search Consoleにログインし、検索アナリティクスを選択する。そして、クエリセクションをクリックし、”クエリを比較”を選ぶ。
すると、下記のポップアップが表示される。そして、それぞれのボックスに、検索フレーズを入力すればよい。
この記事は、Search Engine Landに掲載された「Google search analytics report adds the ability to compare queries」を翻訳した内容です。
*リンク先は全て英語となります。
*2016年4月の記事のため、一部追記を行っています。
モバイルページをスピードアップする時が来た。
Googleがモバイルフレンドリー・アップデートをローンチし、ランキング要素の1つとして以来、サイトオーナーはモバイル体験を高速化することへの関心をより強めている。
モバイルユーザーのためにページを最適化することは非常に好ましいことだ。しかし、そもそもページが素早く読み込まれなければ、ユーザーがあなたのコンテンツを楽しむ妨げになってしまうだろう。
解決策は何か？
＊リンクをクリックすると、名前とメールアドレスの入力が求められます。入力すれば、PDF版のガイド（英語）がダウンロードできます。
Accelerated Mobile Pages。そう、AMPと呼ばれる技術だ。
スピードはWebページをデザインする上で、欠かすことのできない要素だ。KISSmetricsのデータによると、「読み込みに3秒以上かかるWebページの場合、およそ40%のユーザーが離脱してしまう」、ということだ。
10万ドルを一日で売り上げるオンライン・ショッピングサイトの場合、読み込みが1秒遅れることで、毎年250万ドルの損失となる可能性がある。
Googleによれば、AMPを用いることで、読み込み時間が15%から85%短縮できるという実験結果もある。
2015年の12月にGoogleは、AMPがランキング要素となる可能性も示唆している。
そのため、WebマスターやマーケターやSEO担当者は、AMPがモバイルページに与える影響について分析をし始めた。その結果、AMPは実際にランキングに大きな影響を与えると指摘する事実も報告されている。
簡単に言えば、AMPに対応したページは上位に表示され、読み込み速度が速く、訪問者を顧客にコンバートしやすいようだ。
最近では、イギリス版のWhiteboard Fridayにて、distilled社のウィル・クリシュロウズ氏とトム・アンソニー氏がAMPの仕組みと、そこから得られる利益についての解説を行っている。
モバイルユーザーへのリーチの重要性を理解しているデジタルマーケターとして、AMPの詳細とメリットを詳しく把握したいのであれば、下記の記事を読み進めて欲しい。
AMPはモバイルコンテンツ戦略の一部となるべきである。
AMPはGoogleとTwitterのコラボレーションにより産まれた。
簡潔にいえば、Accelerated Mobile Pagesはモバイルページを高速化させるために設計されたプロジェクトである。要素を基本的なものに絞り込むことで、始めからモバイル・フレンドリーであり、読み込み速度の速いページを作成する。
詳細は、オープンソースのプラットフォームに記載されているので、ぜひ、確認してほしい。
AMPは、Googleがユーザーにフォーカスしているという、何よりの証拠となっている。
Googleがこのような新しいアップデートをロールアウトすれば、「より多くの利益をGoogleが得るために行われている」、と考える人もいるだろう。
この意見は非常に正しいと言える。なぜなら、ユーザーが幸せになればなるほど、よりGoogleに接する機会が増えることになり、Googleの広告ビジネスに大きな利益をもたらすことになるからだ。
しかし、そもそもGoogleは検索ユーザーへの大きな情熱を抱いている。そして、あなたも同様に情熱を持つべきなのだ。
Accelerated Mobile Pages (AMP) はオープンソースのプロジェクト、もしくは、プラットフォームであり、パブリッシャーがモバイルページの速度と可読性を改良する手助けとなることを目的としている。
つまり、「速度の速いモバイルページ＋読みやすいコンテンツ＝より良いユーザー体験」、ということになる。
Search Engine Landのポール・シャッピロ氏は、AMPの3つの構造を整理している。
AMPは、HTMLタグを削減しモバイルユーザーに適したもののみを読み込むことで、モバイルページの読み込み速度を劇的に向上している。
下記の図表と解説はウィル・クリシュロウズ氏のWhiteboard Fridayからの引用であるが、AMPのプロセスを簡潔に説明している。
【画像内和訳】
Will:この図表を見てほしい。通常のWebページで使用されているアイデアだ。図表内ではWWWと記載しよう。これは通常のデスクトップバージョンのページということだ。もしAMPバージョンのページがあれば、通常のページのソースコード内でAMP HTMLで記載したページへのリンクをrel=”canonical”で指定する。このリンクはAMP対応したページへ向けられているが、AMP対応したページをここでは、”hosted AMP page”と呼ぶことにしよう。
つまり、このAMPページというものは、必要なものだけを備えたHTMLで構成された、あなたのドメイン内にあるページである。実際にこうしたAMPページを見てみるために、Guardianを例に挙げてみよう。GuardianはAMP対応を行っている早期のパートナーの一つだ。GuardianのWebサイトに行き、どこかのニュース記事のURLの末尾に”/amp”と追加すれば、AMP HTMLのページを見ることができる。また、（通常のページの）ソースコードにAMP HTMLのリンクが確認できるだろう。
これが、”Hosted AMP”だ。Googleに対し、何かする必要はない。ただ作成すればよく、読み込み速度が速くなるように設計されている。しかし、キャッシュページのプラットフォームも用意されており、この図表では”gstatic”と記載している。
AMPは最適化されたHTMLによって記述されたページをレンダリングする。そして、そのページの読み込み速度は非常に速い。なぜなら、ページの読み込みを遅延させるHTMLタグの使用が許可されていないからである。
JavaScriptを使用しているページの場合は、AMPページではそのスクリプトはレンダリングされない。
その他のAMPについて知っておくべき情報を、下記に記載しておこう。
さらに、AMPバージョンのページを作成し、モバイルページの向上を図る場合、読み込み速度と読みやすさが問題となるため、記事の共有といった要素は重要視されていない。そのため、ソーシャルシェアボタンが適切に表示されない場合もある。なぜなら、ソーシャルシェアボタンの多くは、JavaScriptを使用して開発されているからだ。
*2016年5月にAMPはソーシャルボタンの機能を追加しました。
サイトスピード、ページビュー、検索順位の間には強い相関関係がある。
覚えておくべきことは、読み込み速度が速ければ、モバイルユーザーはサイト内でより多くのページを閲覧し、結果として直帰率が下がるということだ。
直帰率が下がり、サイトでの体験が向上すれば、Googleはそのページへ恩恵を与える。そのため、AMP対応のページがAMP対応でないページよりも上位に表示されていても、大きな驚きではないだろう。下記の二つのバージョンを比較してほしい。
読み込み速度の速いコンテンツの提供を可能としているFacebookのインスタントアーティクルズのように、AMPはユーザーのモバイル体験を次のレベルへと導くものである。
事実、AMP対応にすることで、多くの利益がもたらされる。その中でも、特に大きい5つのメリットを挙げてみよう。
1.Webページを即時に読み込む
スピードはモバイルページにおける真髄のようなものだ。優れたコンテンツは必要だ。しかし、ページへのアクセスが可能でなければ、ユーザーはそのコンテンツを読むこともない。
モバイルでの読み込み速度が1秒遅れることで、コンバージョン率が3.5%、ページビューが9.4%下がり、直帰率が8.3%増えるというデータもある。
このことからも、ページの読み込み速度を向上させる必要性が感じられると思う。そして、AMPはその目的を達成させる手助けとなるのだ。
人々がコンテンツ（記事、ブログ、動画、ポッドキャストなど）を消費する方法は劇的に変化している。コンテンツが配信される頻度は特にだろう。
もしも、あなたのモバイルページの読み込み速度がでんでん虫のように遅ければ、ターゲットとしたモバイルユーザーを顧客へとコンバートさせることは難しいだろう。AMPによって劇的にページスピードを向上させるための準備をしておこう。
AMPはあなたをモバイルページの向上を目的とした行動に駆り立てる存在である。
Googleは継続して自身のシステムを改良している。今のところ、モバイルフレンドリーは最も大きなアップデートだと考えられるが、AMPプロジェクトが頭角をあわらしてきた。
そして、この事態はある事実を意味している。つまり、Googleは完成されていないということだ。新しい検索アルゴリズムのアップデート、高度な新機能やツールの開発などは今後も行われるだろう。
さあ、準備を始めよう。AMPプロジェクトのサイトに訪問し、あなたのモバイルページを加速化させるのだ。
2.コンテンツマーケターのために、モバイルにおける露出を高める
Googleは自然検索結果内におけるAMPページの表示を開始した。検索結果に緑色（*注）のAMPという表記があるため、すぐに発見できるだろう。
*注：実際は灰色ですが、原文ママで緑色と記載しています。
検索結果内で目を引けば、クリック数が高まることは明らかだろう。
この緑色のAMPという表記は、他の検索結果よりも目立って表示されるため、クリック率の向上に一役買うことになるだろう。
そして、ユーザーは検索結果内でAMPページを探すようになるだろう。なぜなら、AMPページは通常のモバイルページよりも素早く読み込まれるからだ。
3.ランキングの上昇
サイトスピードとコンバージョン率には強い関係がある。読み込み速度の速いサイトでユーザーが幸せになれば、リストを購読したり、商品を買ったりといった行動を起こしやすくなる。
多くの予測がされているが、GoogleはAMPをランキング要素にはしていない。
読み込み速度とモバイルフレンドリーは良く知られた要素であり、AMPはモバイルページと密接にかかわりあっている。
これが、AMPが独立したランキング要素となっていない理由である。なぜなら、AMPはモバイルページのみの仕組みであり、デスクトップバージョンのページには何も影響を与えないからだ。
つまり、モバイルフレンドリーなサイトが自然検索結果で上位に表示されるため、AMP対応のページは、AMP対応でないページよりも、モバイルの検索結果ページで上位に表示されるということなのだ。
4.柔軟な広告サポート
多くの人がWebサイトやブログを開始する理由に、お金を稼いだり、日々の仕事の補完にといった理由を挙げるだろう。
デスクトップとモバイルのページを見てみれば、多くの違いがあることに気が付くはずだ。
ヘッダー画像、ナビゲーションのメニュー、サイドバー、ソーシャルボタン、フォーム、ポップアップ、その他の不要な要素などはコンバージョン率を下げる要因となっている。
しかし、AMPでは、モバイルページにおけるこうした阻害要因を取り除くことが可能なのだ。
全てのHTMLタグが使用されているわけではなく、合理的なCSSが使用されており、JavaScriptの問題は発生していないということが理由だ。また、コードも6倍軽くなっている。
これは、広告からの収益をより簡易に得られることを意味している。
例えば、AMPバージョンのThe Guardianを分析してみると、通常のページよりも、広告がより柔軟でよりユーザーフレンドリーに表示されるように設計されていることに、すぐに気が付くだろう。
AMPバージョンのページをクリックすれば、ほぼ瞬間的にコンテンツが読み込まれる。
AMP対応のページでは、広告は下記のように表示されている。
AMPページでサードパーティーからの広告を表示させれば、広告も瞬時に表示されるだけでなく、ユーザーの注意を惹きつけ、計り知れない価値をもたらすことになるのだ。
既にご存知の通り、こうしたコンテンツマーケティングによるアプローチは、あなたの影響力を高め、ユーザーが持つ疑問に対する答えを提供し、広告費におけるROIを向上させる、非常に簡単な方法であるのだ。
AMPページでのマネタイズの準備をするために、下記に現在AMPの広告に対応している広告ネットワークを記載しておく。
5.ユーザーのトラッキングをシンプルに
モバイルページへトラフィックを送るだけでは不十分だ。ユーザーがどのようにしてあなたのサイトにたどり着いたかを知る必要がある。
トラッキングは、ユーザーがどこからきて、どのページを見たか、などを判断する手助けとなる。
ユーザーとサイトのパフォーマンスをトラッキングすることは、AMPでは非常に簡単だ。なぜなら、すでに分析用のツールが準備されており、AMPバージョンのページを詳細に分析することが可能となっているからだ。
ユーザー行動は、あなたがトラッキングを行ったとき初めて影響を持つようになる。AMPでは、パブリッシャーは2つのタグから選択することができる。
これらのタグは、クリック、コンバージョン、動画、リンク、訪問数、新規顧客、既存顧客などの重要なデータ自動的にトラッキングしてくれる。
Digivateによれば、およそ16,000のモバイル対応のサイトが、AMPによって毎日レンダリングされているということだ。The New York Times、The Guardian、Financial Times、BBC、News Corp、Washington Postなどの主要なトップブランドやニュースメディアはすでにAMPに対応している。
また、WordPress、Parse.ly、Chartbeat、LinkedIn、Adobe Analytics、Pinterest、Twitterなどのテクノロジーソリューション・カンパニーもAMPに対応している。
Accelerated Mobile Pagesは発展途上の技術である。AMPプロジェクトの開発者によれば、Githubにて、”我々は毎週木曜日に全てのAMPページに対し、新しいリリースをしている”、とのことだ。
新しい機能も追加されるだろう。例えば、AMPバージョンのページか通常のモバイルページかをユーザーが選択できる機能が追加されると考えている。
どちらにせよ、AMP対応の準備は進めておく必要がある。そうすることで、今後何が起ころうとも、あなたは勝者の側に立つことになる。
AMPに対応する方法を検討する際にはいくつかの選択肢がある。初心者であれば、少なくとも2つのバージョンのページを保持することだ。
オリジナルのコンテンツはモバイルフレンドリーであるだろうが、それとは別に、AMPバージョンのページを作成する。そして、このAMPページが、劇的に読み込み速度を速めることになる。
また、AMPでは、フォーム要素やサードパーティー製のJavaScriptが許可されていないことを思い出してほしい。
マーケターとして、e-mailのリストを構築したいと誰もが思うだろう。AMPの弱点は、この目的が簡単に達成できないことだ。
さらに、コメントや他のアクションなど、ユーザーがモバイルページのコンテンツに参加することをAMPは許可していない。
繰り返しになるが、注目すべきはスピードであり、可読性なのだ。
WordPressのユーザーであれば、AMPを今すぐ開始するために、GitHubでプラグインをダウンロードしてインストールすればよい。
単純に、“Download Zip” をクリックしよう。
*WordPressのサイトですが、プラグインはこちらでダウンロードできます。
このプラグインは、通常のプラグインのように、WordPressのダッシュボードからインストールすることもできる。非常に簡単だ。
プラグインをインストールし実装すれば、各ブログ投稿のURLの末尾に “/amp/”と追加すればよい。ブラウザでの表記は下記のようになる。
また、The GuardianのAMPバージョンのページは下記の通りだ。
パーマリンクを設定していなければ、“?amp=1”を代わりに追加すればよい。
そして、GoogleのSearch Consoleにて、バリデーションと修正を行うことを忘れずに。これを行うことで、GoogleがあなたのAMPバージョンのページを発見する手助けとなる。
AMPは非常に強力だ。モバイルページをアップグレードすることで、サイトスピードにおける、Googleの期待を満たす手助けとなる。
将来は、Accelerated Mobile Pagesはソーシャルメディアにおける、モバイルとのかかわりに大きな影響を与えるだろう。私はそれを確信している。
AMP対応に注目すると同時に、モバイルマーケティングの戦略もしっかりと行うことだ。こうすることで、あなたのサイトへのモバイルトラフィックを発生させ、あなたのビジネスを成長させる原動力となる。
この記事を読み終える前に、一つだけ尋ねさせてほしい。モバイルページのスピードと可読性を高めたいと思うだろうか？もし思わないのであれば、何があなたをそうさせるのだろうか？
この記事は、NEILPATELに掲載された「The Definitive Guide to Accelerated Mobile Pages (AMP)」を翻訳した内容です。
Googleの新しいユーザーフレンドリーなツールはスモールビジネスの役にきっと立つだろう。モバイルフレンドリーであるかという点と、どのくらい読み込み速度が速いかを計測してくれるのだ。
＊リンク先は全て英語となっています。
Googleがスモールビジネス・ブログにて、新しいテストツールを発表した。このツールを使うことで、あなたのWebサイトがモバイルフレンドリーであるかを、また、デスクトップページとモバイルページの両方のスピードを、1つの場所で計測することができる。スモールビジネスのWebサイトが自身のサイトをテストすることが容易になったということだ。モバイルフレンドリーのテストツールやページスピードのテストツールをそれぞれ使用する必要がないのだから。
こちらで利用することができるこの新しいツールは、さまざまな項目を一度にテストすることができる。このツールの特徴は下記の通りだ。
(A)3つのスコア(下記に記載)を全て取得できる。
(B)あなたのWebマスターチームに共有できるよう、より包括的なレポートをEメールで送付してくれる。
(C)モバイルフレンドリーであるかを、0から100のスコアで計測してくれる。モバイル対応になっているか、そうでないか、といった計測ではない。
それぞれのスコアの内容は以下の通りだ。
モバイルフレンドリー
あなたのWebサイトをスマートフォンで閲覧した際の、顧客の体験の品質についての項目。モバイルフレンドリーであるためには、ボタンがタップ可能であること、小さい画面でもしっかりとナビゲーションが行われていること、そして、最も重要な情報が画面の上部の真ん中に表示されていることが必要。
モバイルスピード
モバイルのデバイスであなたのサイトを読み込むために必要な時間。もしも顧客が長時間待たされてしまった場合、彼らは別のサイトに移ってしまう。
デスクトップスピード
デスクトップコンピューターであなたのサイトを読み込むために必要な時間。顧客の接続状況ではなく、あなたのWebサイトの要素も対象。
下記にSearch Engine Landで試した際のスクリーンショットを記載しておく。
簡単に概要を確認することができ、以前からGooglが提供している、Webマスターやデベロッパー向けのツールよりも、非常に良いものだ。レポートを読み進めると、あなたのWebサイトをよりモバイルフレンドリーにする方法や、デスクトップとモバイルの両方のスピードを速める方法が記載されている。
下記は、GoogleがEメールで送付してくれるレポートのスクリーンショットである。
あなたのWebサイトも、ぜひこちらから試してみてほしい。
この記事は、Search Engine Landに掲載された「Google launches business-friendly tool that tests your website mobile-friendliness & page speed」を翻訳した内容です。
モバイルページのスピードは、現在モバイルのランキングに影響を与えていない。しかし、Googleのゲイリー・イェーシュ氏によれば、間もなく影響を与えるようになるかもしれないということだ。
*リンク先は全て英語となっています。
Googleのゲイリー・イェーシュ氏がシドニーで行われている、Search Marketing Summitにて本日発言した。Googleは、ページスピードのランキング要素をアップデートするつもりのようだ。モバイルフレンドリーアルゴリズムに関して、モバイルページのページスピードを考慮することになる。
この情報は、ジェニファー・スレッグ氏によってもたらされた。ジェニファー氏によると、ゲイリー氏は、”数年後”ではなく、”数か月後”に起こりうると述べたということだ。
今日における問題として、Googleがモバイルのランキングに使用しているシグナルの多くが、モバイルページではなく、デスクトップページを元にしていることが挙げられる。そのため、デスクトップページのスピードが非常に速ければ、モバイルページがとても遅かったとしても、モバイルのランキングに悪影響を与えることはない。
モバイルフレンドリーアルゴリズムが導入された際、Googleはデスクトップページではなく、モバイルページのスピードをランキング要素に組み込むことを望んでいた。
2010年4月にページスピードはランキング要素となった。2013年6月に、マット・カッツ氏はスピードの遅いモバイルページに悪影響が起こることをほのめかした。昨年には、ゲイリー氏がモバイルページのスピードをランキング要素にすることに取り組んでいると述べていた。そして、今回ゲイリー氏は、数か月後になることを示唆している。
しかし、ゲイリー氏はTwitterにて、まだ計画段階であるとも述べている。
他の要素についても言えることではあるが、デスクトップページではなく、モバイルページのシグナルを考慮することは、理に適っていることだ。これが、私だけの考えではなく、Googleの計画でもあるのだと思う。
この記事は、Search Engine Landに掲載された「Google says page speed ranking factor to use mobile page speed for mobile sites in upcoming months」を翻訳した内容です。
Googleで食べもの関連のクエリで検索すれば、スニペット内に画像サムネイルが表示される。
*リンク先は英語となっております。
食べもの関連の検索を行った場合、Googleは検索結果ページの主要部分に画像サムネイルを表示している。多くの検索者が目撃しているようで、Googleがここ数ヶ月の間で行っているテストの一環なのかもしれない。
個人的には、レシピと映画（動画）で利用可能な、Googleの新しいリッチカード機能とは関係がないと考えている。今回のサムネイル画像については、レシピサイトでなくとも、また、構造化データをマークアップしていなくとも、表示されているようだ。
下記に、モバイルとデスクトップの両方で、画像サムネイルが表示されている食べもの関連のクエリの検索結果を記載しておく。
この記事は、Search Engine Landに掲載された「Google now displays image thumbnails next to search snippets for food-related queries」を翻訳した内容です。
最も望まれていた機能の1つがSearch Consoleに実装された。プロパティセットと呼ばれており、検索アナリティクスのレポートをまとめることができる。
Search Console内の複数のプロパティをまとめることができるようになったと、Googleがアナウンスした。検索アナリティクスのレポートにて、統合されたデータを手にすることができる。
インプレッション数、クリック数、CTRなどの検索アナリティクスのデータは、プロパティ毎を基準としていることが、この機能が実装された大きな理由だ。そして、HTTPとHTTPS、WWW有りと無し、アプリなどのように、プロパティは個別に追加されており、サイト全体のデータを1つのレポートで見る術がなかったのだ。
Search Consoleのセットを使用することで、そのセットの検索アナリティクスの全データを1つのレポートで見ることができる。
Googleのアナウンスの一部を下記に抜粋する。
モバイルアプリ、モバイルサイト、デスクトップサイト。こうしたサイトの検索におけるビジビリティのまとまったデータをどのように確認していますか？今までは、全てのデータを別々に確認しなければなりませんでした。Search Consoleは”プロパティセット”というコンセプトを導入します。これにより、（アプリとサイトを含む）複数のプロパティを1つのグループにまとめることができ、全体のクリック数やインプレッション数を1つのレポートで確認できます。
セットを作成するには、Search Consoleにログインし、上部右側にある”セットを作成する（create a set）”ボタンをクリックする。すると、下記のダイアログが表示されるため、セット名と追加したいプロパティを選択する。
セットをまとめると、”プロパティセット”として、オーバービューセクションに表示される。下記に画像を記載しておこう。
今のところ、この機能は検索アナリティクスのレポートのみをまとめることができる。個々のプロパティのデバッグやより詳細なレポートをまとめたいと思うだろう。しかし、この機能は、多くのWebマスターやパブリッシャーが長い間待ち望んでいた機能であるのだ。
【追記】
Googleのブログにも記載がありますが、ロールアウトには数日かかる見込みのようです。しかし、特定のユーザーや地域に限定したものではなく、全てのユーザーが使用可能とのことです。Googleのジョン・ミュラー氏に質問したところ、そうした返信がありました。下記に、スクリーンショットを記載します。（Search Engine Roundtableによると、Googleのジネブさんは”36時間以内”と発言しているようです。）
@TomoyukiSugao It's gradually rolling out to everyone over a couple of days.
— John Mueller (@JohnMu) 2016年5月23日
この記事は、Search Engine Landに掲載された「Google Search Console now lets you group your sites together with property sets」を翻訳した内容です。
*Google I/Oの”AMPについての新情報”の紹介記事もあります。
Googleは現在よりも速くコンテンツを発見することができるのだろうか？Googleは可能だと考えているようだ。それを目的とした、リアルタイム・インデキシングAPIのベータ版をテストしている。
*リンク先は英語となります。
Google I/Oにて、検索とモバイルコンテンツのエコシステムと銘打たれたセッション内で、リチャード・ギングラス氏が、Googleはリアルタイム・インデキシングAPIをテストしていると述べた。このAPIの目的は、信頼されたパブリッシャーが、そのパブリッシャーのコンテンツを直ちにGoogleへ送信する手段を手にすることだ。その結果、Googleはコンテンツを発見するために、遅延が発生しないことになる。
そして、Googleは検索者に対し、直ちにそのコンテンツを提供することができる。リアルタイムで、遅延は発生しない。
下記にリチャード・ギングラス氏の発表時のスライド写真を掲載する。
Googleは、ここ数か月で、ベータ版のリリースをさらに拡大する予定らしい。しかし、それまでの間は、この新しいAPIについての新たな情報を我々が耳にすることはないだろう。Googleはライブ・カルーセル（注：1）という機能を実装しており、これは、ライブ配信を可能とするものだ。しかし、今回のAPIは、この機能とは別のものであるようだ。
注1：ライブ・カルーセルについては、SEO Japanの下記の記事をご参照ください。
「Googleが”ライブ”ラベルをライブブログの配信者用に表示することを開始。」
下記に、このAPIを使用したリアルタイムの検索結果がイメージ写真を載せておく。
この記事は、Search Engine Landに掲載された「Google beta testing a real-time indexing API」を翻訳した内容です。
