CyberAgent SEO Information  (サイバーエージェントSEO情報ブログ)

CyberAgent SEO Information  (サイバーエージェントSEO情報ブログ)

サイバーエージェントSEOグローバルイノベーションプロジェクト(SGIP)です。当ブログでは、皆様がウェブサイトを運営するにあたって必要となるSEOに関する情報をご提供して参ります。


テーマ:

今日はこのメディアで取り組んだことについてお伝えします。SEO記事を期待された方はすいません。。

 

世の中には「記事提供」というものがあります。

分かりやすい例だと、Yahoo!ニュースには多くのニュースサイトが記事を配信・提供していますし、弊社のAmebaニュースも多くの記事提供を受けています。

記事提供の文化は、ユーザーからすると数多くのコンテンツをひとつのサイトやサービスで見ることができるという利点があります。

 

一方で記事提供者からすると、自分たちの作ったコンテンツが多くのユーザーに届くというメリットがある反面、

ユーザーがオリジナルのサイトにまではなかなか来てくれないというデメリットがあります。

 

特に、

「記事提供をしたら、提供先が検索エンジンで自分たちよりも上位に来てしまった」

という話は聞きますし、実際に時々見られることです。

現実として、提供先が検索エンジン上で正規コンテンツとして見られやすくなるテクニックも存在すると思います。

 

個人的にこの”記事提供”と検索エンジンの関係性、”記事提供”とSEOというところについては悶々とするものがありました。

 

自分たちが記事提供をしている場合に提供先が上に来てしまえば当然モヤモヤするところですが、

記事提供を受けている場合に自分たちが上に行ってしまうケースもあり、トラフィックが来てある意味美味しい思いができるものの、やはりモヤモヤしてものがありました。

 

「そのトラフィックは本来どこに行くべきなのか?」

ということを数年考えていました。

ここ最近は、提供を受けているものにnoindexを入れるようにすることを増やしていました。

(一部メディアはまだ対応できていませんでした・・)

 

noindexにすると、確かに検索トラフィックそのものは本来そのトラフィックを得るべきオリジナルサイトのほうが得ることが多いでしょう。

しかしながら、記事提供がなされた場合、提供先でその記事が話題になりソーシャルメディアでシェアされたりブックマークされたりリンクが張られるということも起こるわけで、noindexにすると極論これがなきものになるということがどうしても気になります。

リンクやシェアやブックマークはその”記事の内容”に向けられたものであり、ウェブサイト(プラットフォーム)に向けられているわけではないと考えるのが自然ではないかと思い、提供を受けている側が提供してくれている元記事にリンクを張るだけでなくcanonical属性を用いて検索エンジンに正規コンテンツを知らせ、その”記事”に集まった評判を元記事にも反映させるようにしたほうが良いのではないかと漠然と思っていました。

一言で言うと、

「そのコンテンツは誰のものなのか?そのコンテンツへの評価は誰のものなのか?元記事のものなのではないか?」

ということです。

 

そんな折、社内で提供を受けている記事が評判となり検索エンジンに対して提供を受けている記事に対してどういうシグナルを送るべきなのか?議論になりました。

サイバーエージェントのグループ会社運営の新R25です。

 

SEOをやっている人間としては正直言えば検索トラフィックは1つでも多く欲しい。

でも記事提供のcanonical文化が変わるチャンスかもしれないと思いながら社内のやりとりをぼーっと眺めておりました。

 

世の中、記事提供を受けているサイトが記事提供もとにcanonicalしているケースはレアなため、

「そこまでするべきなのか?」という意見も当然ある中で某氏の

という意見から、やはり本来の姿が何かで考えていこうという流れが進み記事提供元にcanonicalするという結論に至りました。

 

そこから約1週間を経て本日めでたく実装完了しました。

 

例えば、こちらのページ( https://r25.jp/article/540751228913636582 )

 

 

のソースを見ると、

 

 

となっており、こちらのページ( https://www.froggy.money/8557/ )にcanonicalによって正規化のシグナルを送っています。

 

 

過去の記事にも遡り、すべての記事提供元にcanonicalによって正規化のシグナルを送ることができているはずです。

 

ひょっとしたらこれによって"うっかり"上がっていたものがオリジナルに上位が入れ替わり検索トラフィックは多少落ちるかもしれません。

が、インターネット上のウェブサイトの関係性、エコシステムを考えたときにはこのやり方が正しいと思っています。

 

記事提供ができる、記事提供を求められるということは記事が良い記事だからでしょうし、提供先での評判はやはり提供元が受けるのが、そのエコシステム内では正しいと思います。

同じ考えを持っている運営者の方は実は結構いるのではないかと思っています。弊社の行った施策によって1サイトでも多くのウェブサイトが提供元に正規化シグナルを送ってくれるようになれば嬉しいです。

 

なお、AmebaNewsなどその他媒体についてはまだ対応ができていません。

長い間続けて来た習慣を変えるのは簡単ではありませんが、少しでも"ネットの世界"に貢献できれば幸いです。

もちろんアメブロ上にはcanonicalの問題が砂つぶに見えるほどに問題があるコンテンツが掲載されている状況は理解しています。

こちらもすぐとはいきませんが、一歩一歩可能な限りSEOの立場から対応してまいります。

 

[追伸]

なお、今回の新R25の英断は私がしたわけではありません。(1,2回だけ意見言ったかもですが・・・)

トラフィックが私以上に喉から手が出るほど欲しいであろう運営サイドが提供元にcanonical送ろうと決めたことに社内ながら敬意を表します。

また、本件についてご意見を伺った際に背中を押していただいた社外の有識者の皆さまありがとうございました。

 

木村 賢 ( @kimuyan )

 

[補足]

canonicalして提供先のGoogleの評価をもってくるみたいに(当ブログがSEOブログなので)読めてしまうかもしれませんが

・Googleはソーシャルシグナルを直接評価に使ってはいないと公表しています
・canonicalした場合にリンクの評価を引き継げるのかどうかも議論の余地はあると思います
以上今回はこのあたりはご容赦いただければと。。


テーマ:

昨日行われた、ISM Spin-off #4 - Google Search Night。

第一回目のレポートではGary Illyes氏のKeynoteの模様をお伝えしました。

今回は第二部に行われたAMA (Ask me Anything)です。

モデレーターは海外SEO情報ブログの鈴木謙一さん

回答者にGoogleから、Gary Illyesさん金谷武明さん長山一石さん小川安奈さんという超豪華メンバーです。

私も海外のSMXやPUBCONによく行くのですが、

これだけの人数のGooglerがAMAで回答してくれるというのはちょっとありません。

 

さて、今回はAMAの中から気になったトピックについて取り上げてみたいと思います。

急いでメモしていたため誤った内容あったらご指摘いただけると助かります。

なお、前回に引き続き当日実況していたTwitter(@kimuyan)もご覧いただけたら幸いです。

 

MFIでPCサイトのみを所有する場合の対応法について「変更はありません。モバイル版とパソコン版は同じです。」ってそんなわけないのでは?

[注]

https://developers.google.com/search/mobile-sites/mobile-first-indexing

この部分のことかと思います。

[長山さん]

MFIは、クロール&indexの話。

SP/PC双方のUserAgentでクロールした場合に同じものが返ってくるならそれはレスポンシブと同じなわけで、

PCサイトしかない場合には特別何かが変わるわけではない。

モバイルフレンドリーアルゴリズムによって、モバイルでは上位表示されにくいということとMFIの話は別。

MFIはクロール&indexの話で評価(アルゴリズム)の話ではない。

 

筆者注:”MFI"という事象においては何もしなくていいけど、スマホユーザーが増えてるんだからモバイルにも最適化しましょうよって話で良いと思います。

 

MFIにおいて「レスポンシブウェブデザイン」推奨から「動的な配信(ダイナミックサービング)」「別々のURL(セパレート)」もサポートするということに方針変更になったが、結局どれでもいいの?推奨をコロコロ変えないでほしい

 

[長山さん]

(推奨の)方針は変えていない。(ですね)誤解を生んでいるのなら申し訳ない。

3つの方式はMFIの構想における当初からサポートしている。

ただし、レスポンシブはさまざまな(metaとか構造化データとか動画とかetc…)設定のミスが起こりにくからおすすめ。

 

筆者注:昨年のPUBCONではGary氏がかなり強めにレスポンシブを推奨したので、むしろ3つ等しくサポートというところからレスポンシブの推し方が強くなったように筆者は感じます。むしろ。

 

MFIはランキングに影響を与えないというが、ベストプラクティスに完全に対応していない場合にMFI導入自体によるランキングの変動は本当に起こらないのか?

 

[Garyさん]

可能性はある。Garyが今日つけ麺をたべなかったことがランキングに影響を及ぼさないとは言い切れないでしょ。どんな可能性の否定できない。

 

筆者注:ベストプラクティスに対応しなければランクが変化する可能性は当然ありますよね。アメブロ(に限らず多くのブログサービスがそうですが)はPCのトップは概ね記事がいきなり表示されますが、SPは記事一覧要はリストが表示されます。これは「重要なコンテンツが一致している」とは言い難いと思いますので、正直どうなるかわからない部分もあると思います。一応、「Intentに応えられていれば問題ないだろう」とGoogleからもアドバイスをいただいていますが果たしてどうでしょうか??

また、ベストプラクティス通りに対応したとしてもクロール&indexの部分が再度行われたり、仕様が変わっているわけですから変化が起こらないことを否定するのは難しいよなあと思います。

 

MFIに移行したサイトにはSearch Consoleに通知が届くと言うが、それはもう始まっている?また、その通知は移行後どのくらいで届く?

 

[Garyさん]

通知は始まっている。

移行とほぼ同時に通知するようにしているが、MFI移行はクロールの時点で始まりそこからSearch ConsoleにMFI移行したことを送るまでのパイプラインの処理が多少かかる。

そのため移行して最短で数時間、最長で2,3日程度かかるものと思われる。

 

MFI移行できないサイトに移行不可の通知を送らないのか?何が原因で移行できないか指摘して欲しい。また、どうやって移行可能かどうかを判断しているのか?

 

[Garyさん,長山さん]

移行できない旨のメッセージを送る予定はない。ここ数ヶ月ブログポストなどでかなり情報を出してきたのでいったん様子見。

数年たってまだMFI Readyじゃないサイトが存在しているとかだったらまた考えるが・・・

移行可能かどうかは移行によってランクやトラフィックに影響が出ないことを考慮している。Classifierは存在している。

 

筆者注:MFI移行されないからランクが落ちるということはないはずなので「移行されない!」と焦る必要は今はないのではないかなと思います。MFI移行ボーナスポイントとかがもらないえるなら別ですがないようですし・・・

 

スマホではスクリーン領域が限られているため、すべてのコンテンツを表示させるとUXが低下する。

1:初期状態でコンテンツを非表示にする(隠す)のは構わないか?

2:ABテストを行なった結果、PCで長いコンテンツが好まれるものもSPでは短いコンテンツが好まれることがわかったが、その場合ベストプラクティスと異なるがSPで短くして構わないか?

3:パンくずをJSON-LDの中だけでマークアップしていいか?

 

[Garyさん]

1:良い

2:本当に短いほうがユーザーのためになるならすれば良い

3:ガイドラインに従え

[謙一さん]

3:JSON-LDでマークアップして目立たないところに設置しておけば??

 

筆者注:コンテンツを表示しないことが本当にUX向上に役立つのかは個々のサイトでしっかり検証したほうが良いと思います。「もっと見る」を嫌うユーザーも一定数いますし、”作り手のロジック”になっていないかは注意が必要だなと。自戒の念を込めて。「2」は本当にそうなのか?というニュアンスが込められているような回答だった気もしますし。「3」についてもできることなら"使ってもらえる”パンくずを考えていきたいものですよね。難しいですが。

 

新Search Consoleの次の機能は?

 

[Garyさん]

知らない、分からない。

(ここで謙一さんから、「旧バージョンのほうにある機能が移行されるだけじゃなく、新しい機能も追加されますよね?」)

[長山さん]

うーん。どうなんですかねえ。

[謙一さん]

きっと載るはずです。

(インデックスカバレッジなどすでに載ってますね)

 

音声や画像、動画、位置情報など今後視野に入れている新たな検索手段について教えてほしい

 

[Garyさん]

テキストでも音声でも画像でもいろいろな入力方法があるが、Googleとしてはやること(目指すこと)は変わらない。

入力情報を分析し、コンピュータにわかりやすい形に変換して、いかなる入力方法であってユーザーにとって良い検索結果を返すことを目指している。

 

PCの検索結果のスニペットの文字数が増えて逆に見にくくなったが改善計画はあるか?モバイルとデスクトップのUIに差があるのではないか?

 

[Garyさん]

ユーザーの構成比を考えると今、(UIを含め)何かを改善するという場合にはモバイルエクスペリエンスを優先させている。

PCで文字数が増えているのは強調スニペットの補語になるようなことを考えて行なっているが、PCとSPでUI(UX?)が異なるということはないのではないか?

 

筆者注:ちょっとよく聞き取れませんでした。この部分しっかり聞けた方教えてください。実際に文字数は異なっていますがIntentに答えられるというユーザー体験に差はでないはずということなのかなあと思います・・。個人的にUIのテストを頻繁に行うGoogleのUI/UXへのこだわりはすごいと思います。

 

JSで隠さざるを得ないコンテンツがある場合、初期状態で隠されているコンテンツの重要度は下がるのか?

 

[長山さん]

(ソースコードに入っておらず)何かしらのアクションをした際にJSが実行されてはじめて表示されるコンテンツはそもそもないものとして扱われる

[Garyさん]

CSSで隠しているものに関して重要度は下がらない。あるかないかの問題。コードにあれば良い。

 

筆者注:一時PCは隠されているコンテンツの重要度下げてませんでしたっけ??SPだとよりCSSで隠すケースは増えると思いますが、”重要なもの”ははじめから表示させたほうが”将来的にも"安全なのではないかなあと思っています

 

JSによって生成されているコンテンツはもともとHTMLにある(プリレンダリングされている)コンテンツよりもindexに時間がかかるのか?

 

[長山さん]

かかる。プロセスが異なるので静的なものよりも時間がかかる。

 

hreflang設定でよく見られるミスは?

 

[Garyさん]

英語には日本語版への記述があるのに日本語版には英語版への記述がないなど。

hreflangは片思いではダメ、両思いにしないとダメ。

そのほか、存在しない言語コードや意図しない地域を使ってしまうなど。

 

コンテンツの信頼性が求められるようになってきた。どのドメインが発信している情報か見ているのでは?この方法の課題や改善点は?

 

[Garyさん]

基本的にはページレベルシグナルでランキングを行なっている。そのほうが細やかなランクづけができる。

ただしサイトやドメインのシグナルも存在しており、例えば出来たばかりのサイトでページが非常に少ないという場合にはドメインやサイトレベルで見ていくということもある。

信頼性の話はフェイクニュースの文脈ではグローバルレベルで出ている。(Googleはさほどフェイクニュースに問題があったわけではないが)フェイクニュース対策のプロジェクトとして、フェイクニュースをどう拡散しないようにするかという文脈で出てくる。日本だと医療系のところで出てくる。

 

[長山さん]

日本Specificでやりたかったのは医療系において、信頼性・正確性が高い情報を出すということだった。

 

筆者注:医療系キーワードは政府等の行政や公共機関、病院、製薬会社等中心の上位表示となりさらに(問題にもなりましたが)一部大手企業運営の情報コンテンツが出ているという傾向が強いことを考慮するとドメインやサイトから信頼性を判断するということは行われたのではないかと思っています

 

Wikipediaなどで実在情報は使っている?Wikipediaに情報があると上位表示されるように見られるが?

 

[長山さん]

CTRと同じで因果と相関は違うということで良いと思う。

信頼性が高いサイトの共通点としてWikipediaに情報があるということだけでないか?

 

筆者注:ここは難しいなあと思います。相関が強くなっている姿を目指しても悪くはないのではないかなと。。

 

meta keywordタグをGoogleは無視しているが公式ドキュメントとして提供しているか?ドキュメントが見つからず上司が説得できず無駄な時間がかかっている

 

(ここでGoogleの4人が揉め始めた??実際は別の話をしていたらしいが・・・)

[長山さん]

あったと思う。少なくともMatt Cuttsが動画を作っていた。

※その後、金谷さんから補足ツイートがあり

https://support.google.com/webmasters/answer/79812?hl=ja

こちらにあるということです。

 

rel=“canonical”で指定していても正規ページとしてみなされないケースがある。それはどういうとき?また正規化のシグナルとしては何を使っている?

 

[長山さん]

わかりやすい例でいうと、多くの人がcanonicalの向け先を(ガイドラインをコピペして)sample.comにしていたときは無視した(苦笑

あとは、httpsとhttp両方があってcanonicalがhttpの場合はhttpsが優先されるだろう。

基本的には検索から来るならどれが良いのか?シンプルなURLであるか?とかリダイレクトがないか?などでも判断している。

(謙一さんから正規化に使っているシグナルくらい教えて!というプッシュ)

[長山さん]

canonical,sitemap,リダイレクト,ディレクトリ階層やパラメータ階層などURLのシンプルさ,https,リンクも関係がないとは言えない

 

検索マーケッターがAMPに取り組む際のアドバイスがあれば教えてほしい。AMPを導入したくなる情報はないか?

 

[安奈さん]

アリババのEコマースや台湾のヤフーオークションがAMPページのみで作られているのでぜひ見てほしい!

AMPストーリーはワシントンポストやCNNで採用されている。

 

参考URL: https://japan.cnet.com/article/35114656/

 

Speed Updateの影響は?

 

[Garyさん]

めっちゃ遅いというページは影響を受ける。めっちゃ遅くなければ影響は受けない。

 

筆者注:そもそも速度改善はSpeed Updateのためにやるべきものではないと思います。表示に4秒程度しかからないならSpeed Updateの影響を受けないとしても50%程度の人が離脱してしまう可能性があるわけですし・・・

 

Speed Updateの評価は4G回線?3G回線?あるいはユーザーの環境や地域に応じて変化するの?

 

[長山さん]

速度改善に取り組むなら、どういうユーザーが対象かを考えていれば良い。

(日本は回線が速くてほとんど4Gだがという前提とうけて)日本は本当に早いのか?Garyは日本にきてモバイルネットワークが遅すぎると言っていつもイライラしている。

[安奈さん]

例えば地下鉄内で回線速度を測ると3Gの理論値と変わらない場合もしばしばある。

速度改善が目的なのであれば、developer tool等でCPUや回線を非力なものにしてみれば良い。

 

PageSpeed InsightsのUnavailableはなぜ出るのか?どうすれば良いか?

 

[安奈さん]

単純にデータが足りていないので待つしかない。

[金谷さん]

出てこないと言われて調べたら出ていたことがあったので、しっかりデータは溜めてきている。

 

検索結果に表示されている日付が間違っているのはどう直せば良いのか?

 

[Garyさん]

日付はページ内のどこかの数値を持ってきているはずなので、そこを消すか変えるかするのが手っ取り早い。

日付抽出のプログラムにおける問題はGoogle側も把握しており改善する予定だが簡単にfixするものではない。

 

GoogleのSEOに関する公式情報が検索で探しにくい

 

[金谷さん]

ごめんなさいとしか・・・

でもGoogleが出てこないということで検索順位を操作していない、フェアであることが分かると思う。リンクも買ってないってことが(笑

[長山さん]

次回のインハウスSEOは金谷さんはインハウスSEO担当者として、向こう側に座ってくださいね。

 

ということで、新しい情報があったというわけではないと思いますが、疑問に思っていたところ、少しあやふやに覚えていたところが随分整理しやすかったのではないでしょうか?

ここでGoogleの方が話したことは、言ってみれば現在のGoogleの事象だと思います。すべてが、by designeかどうかはわかりません。

SEOをやる身としては事象を見て対処することも必要ですが、by desingeかどうか考えてあるべき論で考えることも必要ですね。

 

なお、この後Google Dance Tokyoで発表があったとおり、改めて長山さんが日本の検索から卒業されることが発表されました。

長きにわたり日本、日本語の検索を良いものにして頂きありがとうございました。

また、Google、Googleの検索とウェブマスター、SEO屋との関係構築にもご尽力いただいたことは我々として感謝しても感謝しつくせません。

直接的には関わりはなくなってしまうかもしれませんが、これからも遠くから日本の検索、ウェブマスター、SEO屋を見守っていただければと思います。

本当にありがとうございました。

 

最後に、ISM運営の皆様、本当にお疲れ様でした、ありがとうございました。


テーマ:

2018年4月6日 株式会社じげんさんにてISM Spin-off #4 - Google Search Nightが行われました。

ご存知、GoogleからGary Illyes氏をはじめとして、金谷武明さん長山一石さん小川安奈さん

海外SEO情報ブログ鈴木謙一さんが登壇されました。

 

Google検索における最新情報を聞くことができるチャンスとあって、

80人の募集定員はあっという間に満員となっていました。

 

さて、今回はそのSM Spin-off #4 - Google Search Nightより、

まず今回はGary Illyes氏によるKeynote(その名もThe つけ麺 Update)をレポートしたいと思います。

なお、本レポートは筆者のTwitter(@kimuyan)にて雑にツイートしたものですので興味ある方はそちらもご覧いただければと思います。

 

 

1,インフラストラクチャの改良

クロールしてからindexする時間を短くするというインフラの改善を行なっているそうです。

カフェインが出てきてからクロール&インデックスのスピードは格段に速くなったわけですが、さらに検索者にコンテンツが渡るのが早まるわけで、これはサイトオーナーにとっては嬉しい話です。

また、クロール&インデックスの話としてはIndex APIの話も出てきました。

現在いくつかのパートナーとテスト的な取り組みをしているということです。

特に大規模サイトにとっては”使える機能"になるかもしれませんね。まあ、そうなったらなったでプッシュするURLの選別とか行わなければならないのかな?という不安もなくはないですが・・・。

 

2,Search Consoleのリニューアルの話

新しい機能は徐々にリリースされていくということです。

2部のAMAで鈴木謙一さんが「古いSearch Consoleの機能は移りますよね?」という質問に対してはYESの回答はありませんでしたが概ね移るのかなあという印象ですね。

すべてがすべてかはわかりませんが。

新SearchConsoleについては、昨年のPUBCONでもGary氏がインフラストラクチャからすべて作り直しているのに近いという発言をされていましたが、今回もリファクタリングも行なっており、ほとんど裏側は作り直しということでした。

新しい機能が待ち遠しいところです。

Googlebotのレンダリングエンジンの変更のタイミング(こちらはSMXミュンヘンでJohn Muller氏が今年遅くか来年早い段階という発言をされていましたが今日、Gary氏に確認してもそのくらいだろうということでした)も絡んでくるのかなあと思ったり思わなかったり。Fetch as Googleを考えたら一回でこのあたりやったほうが楽なのかなあとか。

 

3,Mobile First Index(MFI)の話

基本的には今まで出てきた話と同じです。

すでにロールアウトは始まっており、MFI移行しているのはMFI移行してもランクやトラフィックが落ちないサイトということです。

MFI移行しているかどうかの確認方法は3つあり、

・Search Consoleのメッセージ

・SPクローラーが一気にくるようになる

・セパレートURLを採用している場合はキャッシュがSP側に変わる

ということです。

とは言え、3番目のセパレートのものはまだ移行していないと思いますが。。

なお、現時点でMFI移行したものに問題は発生していないということです。

世界中のすべてのサイトがいつかはMFI移行していくものの、その期限などは特にないということです。

どちらかというとサイト側がMFI対応できていくスピードに合わせる形なのかなあと思います。

 

MFIの準備として行うべきこととしては、

・デスクトップとモバイルのサイトにおいて重要なコンテンツを同じにする 

・metaデータ(title & description)は同じにする 

・構造化データをモバイル版にも記述する

・SPクローラーに制限をかけない

・hreflangをモバイル版にも正しく記述する

・rel-canonicalを正しく記述する

ここで「セパレートの場合はSPにむけてcanonicalする」という話が出たのですが、

のちに確認したところ、

“かつてのセパレートの仕様通りに、SPからPCへのcanonical(PCからSPへはalternate)で問題はない(変える必要はない)"ということです。

ただし、”PCからSPにcanonicalしているほうがベター"ということでした。(注

このあたりは今まで言ってきたことと少し異なりますが、PCとSPが同一コンテンツであることを示すことができていればどちらでも良いということのようです。(金谷さん談)

※注にありますように事実確認が必要な項目だと思っております。申し訳ございません※

なお、セパレートURLの場合はPC,SP双方にrobot.txtを正しく記述する必要があるということです。

こう考えるとセパレートは本当に面倒だしミスが発生しそうですね・・。

 

注: SPにcanonicalするほうがベターという話について、canonicalは他検索エンジンにも影響があり、Gary氏の発言通りにすると他検索エンジンで致命的な悪影響を及ぼすため聞き間違いではないかというご指摘を頂きました。

その場でのGary氏の話はこちらの通りではなかったかと思うのですが、内容を再度確認させていただくとともに、Googleの公式な発表が再度あるまでは当canonicalはご自身でご判断いただければと思います。

 

4,Speed updateの話

Speed UpdateはMFIとはまったく関係のない独立したものであるということです。

また、遅い回線で遅い分には関係ないそうです。

二部のAMAでは、「めっちゃ遅い場合にはランクに影響が出る」ということだったので神経質になる必要はなさそうです。

が、そもそも速度改善はSEOのために行うべきものではないかなと思います。

 

5,動画検索・画像検索

通常のオーガニック検索ではビッグワードは10年くらい大手企業が1位を占拠しているケースが多々あるが、画像や動画では大手企業が上位を取れていないケースがあるからチャンスがあるよという話から。

これは個人的には考えたことがあまりありませんでした。

動画検索、画像検索のTIPSとしては、

・構造化データを使う

・sitemap.xmlに記載する

また、sitemapについてはこちらの下記で定義されている構文を記述することでより良い状況が期待できるとことでした。

https://support.google.com/webmasters/answer/178636?hl=ja

https://developers.google.com/webmasters/videosearch/sitemaps (英語)

 

 

45分しかも通訳込みでしたが、そんな短時間と思えないくらいに普段の業務に役立ちそうなTIPSがたくさんあったと思います。

個人的にはMFIは概ね大丈夫かなと思うので(まだ確認したいところはありますが・・・)、動画検索や画像検索のところに工夫の余地があるなと思いました。

インフラストラクチャの改善の話も公式に聞くの初めてでしたし、Speed Updateが”SEOのランクにおいては"そこまで神経質になるものではないというのは聞いている人にとっては有益だったのではないでしょうか?

今回も日本のウェブマスター、SEO担当者に多くの情報を残していってくれたGaryさんに感謝です。

また来年も是非きていただきたいですね。

 

さて、第二部はAMA(Ask me Anything)でした。こちらも役立つ情報がたくさんありましたので次のポストで書きたいと思います。