Bing Webmastertoolsも少しずつ新UIへお引越し中

たまにはと思ってBing Webmaster Toolsを確認していたのですが、ページトラフィックなど一部のページでは新しいWebmaster Toolsへ移行した旨の表示がされました。

旧UIも旧Google Webmaster Toolsだったけど、新UIもGoogle Webmaster tools感出てますね〜。どうもBing、日本語の検索イマイチ感あるし個人的にはどこまで見ようか毎回迷うところです。SEOでSevere判定されているところは直そうか、直すまいか。。。そりゃ直しておいたほうが良い事は分かるのですが。

2020年6月のGoogle AnalyticsとSearch Consoleドキュメント系アップデート

Google Analytics

引き続きWeb + Appのドキュメントが強化されたイメージです。

Universal Analyticsなどからの移行の手続きもガッツリ増えましたがイベントまわりの説明がだいぶ詳細になった気がします。そろそろ移行が近づいている雰囲気だけは感じました。。。

Search Console

Google検索の仕組み

クロールの部分に関して、大幅に修正が入りました。

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

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をヘルプに沿って対応してみると一見エラーはなさそうに見えますが、必ず中身を確認して自分が思っていたデータが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がキレイに書かれているウェブサイトでないと上手く抜き出せないかもしれません。