だいぶ前からなのかもしれませんが、stableのChromeを利用しているとGoogleのプロダクトとはh3-Q050ということでQUIC version 50で会話しているんですね。
Googlebotもhttp2で会話出来るようになるということで今運営している一部ウェブサイトは未だにhttp1.1だったりする訳ですが、早めにイケてるクラウドに移してhttp2化したいという気持ちでいっぱいです。
Google Search Consoleで単語ごとの推移を見ていると色々気づく事がありますが、その中の一つで単語ごとの 平均掲載順位のバラツキ。
例えば以下は後半バラツキが少なくなっていますが、このバラツキが少なくなったポイントでその単語にフォーカスしたコンテンツを投下しています。
運営しているウェブサイトの中に単語としては存在していたものの、あまり気にしていなかったキーワードに関して、単純にGoogle側が検索クエリに対し"関連が多少あるのでは？"と判断されているため掲載順位が低くても表示がされていました雰囲気がありますが、そこにちゃんとそのキーワードにフォーカスを当てたコンテンツを入れてあげるとバラツキが減少し安定するという現象です。
考えてみれば当たり前なのかもしれませんが、過去のデータを個人的にDBへ保管していたのでざっと他のキーワードについても調べてみて次の施策へ繋がりそうな気がしてきました。
DBで何でも出来るので現在はあまり気にしていませんが、今度Search Consoleのキーワードで正規表現も利用できるようになるということで更に期待ですね！
ChromeOSだからなのか何かflagをonにしているからなのか分かりませんが、chromeのアドレスバーから検索をしていると時々モバイルと同じカード表示になりますね。何だろう。。
Google側のABテストかもしれませんが、最初は違和感あったものの何回かに一回、この表示担っていたこともあり結構慣れてきました。
普段のGoogle検索結果が左に寄っているので、どちらかというとセンターに表示されている状態のほうが視線をわざわざ動かさずに済んで良いなと思いました。
8/25にChrome85のstableが登場するわけですが、ここでリリースされるCSS content-visibility property。web.dev側でも記事が登場しましたが、コンテンツ版のlazy loadのような動きをするようで、とても気になっています。web.devの記事に違いが載っています。
display: none: hides the element and destroys its rendering state. This means unhiding the element is as expensive as rendering a new element with the same contents.visibility: hidden: hides the element and keeps its rendering state. This doesn't truly remove the element from the document, as it (and it's subtree) still takes up geometric space on the page and can still be clicked on. It also updates the rendering state any time it is needed even when hidden.
要するにdisplay : noneだとレンダリングプロセス自体が行われないし、visibility : hiddenの場合はhiddenの状態でレンダリング処理が走ってしまう。ということでon screenまでレンダリング処理が行われないcontent visibilityというものが登場したという理解。
Chrome85に関する記事の中では
非表示の場合、その要素の中身（サブツリーまたは置換された要素の中身）は描画やヒットテストが行われないまま、CSS の包含関係が適用されます。そのため、レンダリングが最適化されます。
ということで、イマイチ伝わってきませんがweb vitalsを意識すると、そのうち強く推奨されるようになるかもしれません。モバイル版Android Chrome85でもページの速度を表示するように出来るようですし。
あとprefers-reduced-dataとtrust token apiについても、かなり気にはなっている。。。特にtrust token apiは今後話題になるかポシャるのか。。。ただ話題にのぼるのはまだ先だろうなと思っています。
たまにはと思ってBing Webmaster Toolsを確認していたのですが、ページトラフィックなど一部のページでは新しいWebmaster Toolsへ移行した旨の表示がされました。
旧UIも旧Google Webmaster Toolsだったけど、新UIもGoogle Webmaster tools感出てますね〜。どうもBing、日本語の検索イマイチ感あるし個人的にはどこまで見ようか毎回迷うところです。SEOでSevere判定されているところは直そうか、直すまいか。。。そりゃ直しておいたほうが良い事は分かるのですが。
引き続きWeb + Appのドキュメントが強化されたイメージです。
Universal Analyticsなどからの移行の手続きもガッツリ増えましたがイベントまわりの説明がだいぶ詳細になった気がします。そろそろ移行が近づいている雰囲気だけは感じました。。。
クロールの部分に関して、大幅に修正が入りました。
1
| ページをレンダリングし、テキスト コンテンツとそれ以外のコンテンツ、および全体的な視覚的配置を分析して、そのページを検索結果のどこに表示するかを決定します。サイトが Google にとってよく理解できるものであれば、それだけそのコンテンツを必要とするユーザーに表示されやすくなります。 |
ページのレンダリングに関しては最新版Chromeが利用されることとなり、Web Vitals指標まわりのCLSにも関連してくるかもしれませんが単純にテキスト・コンテンツのレンダリングだけでなく全体的な視覚的配置の分析も行われるということが明確に書かれた訳ですが、レンダリングした結果Above the foldが広告で埋め尽くされたり、コンテンツが表示された後に非同期で広告が差し込まれたりしてコンテンツの位置が変化するものなど、視覚的配置要素が検索エンジン側にも評価されるという感じでしょうか。
サイトがGoogleにとってよく理解できるもの という表現はイマイチふわっとしていますが、構造化データを指しているのか、それとも自然言語処理的な文脈で例えばキーワードが詰まっていたりと不自然ではないかどうかなどを見ているということなのでしょうか。
サイトクローラビリティの部分ですと、まずは1点目
1
| サイトのページが Google からアクセス可能なこと、および正しく認識されることを確認します。Google は匿名ユーザー（パスワードなどの認証情報を持たないユーザー）としてウェブにアクセスします。ページ上のすべての画像やその他の要素を、Google が正しく認識し、理解できるようにしてください。モバイル フレンドリー テストツールでページの URL を入力すると、簡単に確認できます。 |
視覚的配置を見ることからリソースをbotに対してブロックするなということが強調された形だと思います。
またコンテンツとして追加されたのが プライマリクロール / セカンダリクロール と ドキュメント の部分です。
プライマリクロールとセカンダリクロールに関しては多少誤解していたような気がしまして、本ドキュメントを読むと私達が通常クローラーと言われてイメージするものがプライマリクローラーで、セカンダリクローラーは例えばPCのクローラータイプでレンダリングした際どのように機能するかを判断するものとしています。
これはドキュメントの部分で、何となく概要は理解できるようになっている気がしますが、1プロパティ(ドメイン等)に所属するドキュメント(1コンテンツ)の束がまず存在し、そのドキュメントごとに正規のURLと代替URL(重複URL)のようなセットで持っていて、かつその正規・代替URL(重複URL)にはバージョンと呼ばれる「モバイル」「PC」「AMP」のフラグがついているというイメージのようです。代替・重複URLに割り当てられたページURLはクロール頻度が低下し、また代替URLのバージョンに「PC」が付いていた場合、PCのGoogle検索結果では正規URLではなく代替URLが検索結果に表示されるというわけです。
代替ページの検知はrel=alternateやrel=canonical、リダイレクトやリンクタグで検出され、重複ページは同一コンテンツが複数URLでアクセス出来る等によってGoogle側で重複とみなされるという感じです。少し感じるのは今まで以上にcanonicalやalternateによる事故にはもしかしたら気をつけたほうが良いのではないか?という点と、バージョンによる違いでGoogle検索結果が変わる可能性、つまりPCでの検索とモバイルの検索で結果が全く違うという状況となるような気がします。現在でも違うは違うのですがそこまで大きな違いというものではないと思っています。
逆に今まではどうやってたんだ？という雰囲気はありますが、単純にバージョンを持たずに全URLに対して重複コンテンツなのか？などを判定してフラグ付されていただけなのかもしれません。このあたりはよく分かりませんがGoogleがMFI移行後もPCから検索すればPCサイトが表示されますと言っている意味が分かりますね。
Web Lightのユーザエージェントが公開されました
Mozilla/5.0 (Linux; Android 4.2.1; en-us; Nexus 5 Build/JOP40D) AppleWebKit/535.19 (KHTML, like Gecko; googleweblight) Chrome/38.0.1025.166 Mobile Safari/535.19
ちゃんと調べたことは無かったのですがGAタグはPVのみ計測でイベントは計測されないという事なんですね。またrobots.txtは無視するということで、これは例えばGoogle検索結果に表示されたページを見ようとしたら一定以上読み込みに時間がかかりWeb Lightモードに切り替わって表示されるというケースの場合、対象のURLの閲覧をユーザが指定して開くから無視するという感じでしょうか。クローラーでも何でもないので、単純にウェブページを簡易化して見るためのプロキシというイメージで、特にそこに関してrobots.txtを適用する必要性は何もないと。
ここは日本でどのくらい表示されることがあるのか若干気になりますね。私自身、それほど良い回線環境ではないので時々Web Light表示は見かけます。。。
日本語に現段階では対応していないのですがSpeakableをヘルプに沿って対応してみると一見エラーはなさそうに見えますが、必ず中身を確認して自分が思っていたデータがspeakableとして選択されていることを確認する必要があります。
ヘルプだと、こんな書き方がされています。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | {
"@context": "https://schema.org/",
"@type": "WebPage",
"name": "Quick Brown Fox",
"speakable":
{
"@type": "SpeakableSpecification",
"xpath": [
"/html/head/title",
"/html/head/meta[@name='description']/@content"
]
},
"url": "http://www.quickbrownfox_example.com/quick-brown-fox"
} |
このspeakableはxPathかcssSelectorのどちらかで設定が出来ることとなっています。xPathやcssSelectorでちゃんと対象が抜き出せているのかを確認する必要があるという話なのですが、最初に述べたとおりこのxPathやcssSelectorで適切にデータが抜き出せなくても現在エラー表示にはなりません。
中身を見るとxPathの場合、xPathの欄と適切に抜き出せていた場合は value 欄がありますが、適切に抜き出せなかった場合はこの value 欄がありません。ただ、その状態でもエラー表示にはならないということです。
私はxPathで実装したのですが、このspeakableで指定できるxPathはやや癖があるのか、何度も適切に抜きだされているかを確認しながら作業したのですが最終的にはChromeのDev Tools側でコピーできるxPathを基に作るのが一番早かったです。
Dev ToolsにxPathのコピーとFull xPathのコピーの2種類があります。どちらもspeakableには使えそうでしたが、少し注意点としては意外と(?)HTMLが定義に従って丁寧にかかれていないと抜き出す事が出来ないということくらいでしょうか。この点は試行錯誤しているときに気づいたのですが、 text() を使って抜き出そうとしても抜き出せない事もあったりして、当たり前なのかもしれませんが、ちゃんとHTMLがキレイに書かれているウェブサイトでないと上手く抜き出せないかもしれません。
