【翻訳】Google検索の内部エンジニアリング文書を読んでアルゴリズムを丸裸に(iPullRank, Mike King)

ipullrank.com

Googleさん、もしこれを読んでいるのなら、手遅れですよ😉

では、さっそく始めましょう。Google SearchのContent Warehouse APIの内部文書が流出しました。Googleの内部マイクロサービスは、Google Cloud Platformが提供するものを反映しているように見えます。また、廃止されたDocument AI Warehouseの内部版文書が、クライアントライブラリのコードリポジトリに誤って公開されていました。このコードのドキュメントは、外部の自動ドキュメントサービスでも取得されていました。

変更履歴によると、このコードリポジトリのミスは5月7日に修正されていますが、自動生成されたドキュメントは現在も公開されています。潜在的な法的責任を制限するために、ここではリンクを張らないことにしますが、そのリポジトリ内のすべてのコードはGithubで公開されていたため、Apache 2.0 ライセンスが適用され、誰でもその内容にアクセスし、使用、変更、配布する権利が与えられていました。

ALT:廃止されたDocument AI Warehouseの内部バージョンのドキュメントのスクリーンショットGoogleが誤ってコンテンツウェアハウスを公開していた

API リファレンスドキュメントを確認し、他のいくつかのGoogle の過去のリークや司法省反トラスト法違反に関する証言と関連付けてみました。私は、近刊予定の著書『The Science of SEO』のために行った広範な特許調査とホワイトペーパー調査と組み合わせています。私が確認した文書には、Google のスコアリング機能の詳細は記載されていませんが、コンテンツ、リンク、ユーザーインタラクションに関する保存データについては、豊富な情報が記載されています。また、操作および保存される機能については、記述の程度がさまざまです(驚くほど簡潔なものから驚くほど詳しいものまで)。

これらを大まかに「ランキング要因」と呼びたくなるかもしれませんが、それは不正確です。その多くは、いや、ほとんどはランキング要因ですが、そうではないものも多くあります。ここで私がしようとしているのは、広範な調査と、Googleが長年私たちに伝えてきたこと、あるいは嘘をついてきたことに基づいて、最も興味深いランキングシステムや機能(少なくとも、この膨大なリークを数時間で確認した際に私が発見できたもの)を文脈化することです。

「嘘」というのは厳しい表現ですが、ここではそれが唯一の正確な言葉です。Googleの広報担当者が自社の機密情報を守ろうとするのは必ずしも非難すべきことではありませんが、再現可能な発見を提示したマーケティング、テクノロジー、ジャーナリズムの世界の人々を意図的に貶めるような彼らの取り組みには問題を感じます。今後、これらの話題について話すことになるGoogle社員へのアドバイスです。時には「それについては話せません」とシンプルに言うのが最善です。あなたの信頼性が重要であり、このようなリークや司法省の裁判のような証言が出ると、今後の発言を信頼できなくなります。

注意事項

今回のリークによって、私の調査結果や分析を信用できないとする動きがあることは、誰もが知っていると思います。中には「そんなことはすでにわかっていた」と、なぜそれが重要なのかと疑問を呈する人もいるでしょう。それでは、良い話をする前に、注意点を先に述べておきましょう。

  • 限られた時間と状況 – 連休中、この件に深く集中して取り組めた時間は12時間ほどしかありません。匿名の複数の関係者が、彼らの洞察を共有することで私の理解を早めてくれたことに、心から感謝しています。また、昨年取り上げた Yandex の情報流出事件 と同様、私は全体像を把握していません。Yandex の場合はソースコードを解析できましたが、その背後にある考え方は何も分からなかったのに対し、今回は何千もの機能やモジュールの背後にある考え方のいくつかは分かっていますが、ソースコードはありません。もう少し時間をかけて資料に目を通した後、数週間後にこの件についてより体系的に報告できることをお許しください。
  • スコアリング機能なし – さまざまな下流のスコアリング機能において、各機能がどの程度の重み付けがなされているのかはわかりません。利用可能な機能がすべて使用されているのかもわかりません。一部の機能が廃止されていることはわかっています。明示的に示されていない限り、どのように使用されているのかはわかりません。パイプラインのどこで何が起こっているのかもわかりません。Googleの説明、SEO担当者が実際に確認したランキング、特許申請やIR資料の説明と、おおむね一致する一連の名称付きランキングシステムがあります。最終的に、このリークのおかげで、今後SEOで重視すべき点と無視すべき点を判断するための参考となる、現在検討されている内容についてより明確な全体像が明らかになりました。
  • おそらく最初の投稿の1つ目 – この投稿は私がレビューした内容の最初の概要となります。詳細を掘り下げるにつれ、後続の投稿を公開するかもしれません。この記事がきっかけとなり、SEOコミュニティがこれらのドキュメントを解析する競争に突入し、今後数か月間、私たちは共同でさまざまな発見や文脈の再構築を行うことになるのではないかと私は考えています。
  • これは最新の情報であると思われます – 私が知る限り、このリークは2024年3月時点でのGoogle検索コンテンツストレージの現在のアクティブなアーキテクチャを表しています。 (Googleの広報担当者が私が間違っていると指摘するでしょう。 実際に、そんなことは抜きにしていきましょう。) コミット履歴によると、関連コードは2024年3月27日にプッシュされ、2024年5月7日まで削除されていませんでした。

    ALT:2024年5月7日に情報がコミットされたことを示す視覚的な証拠とともに、リポジトリのコミットに関するスクリーンショット

  • 相関関係は因果関係ではありません - さて、これはここでは当てはまりませんが、念のため確認しておきたいと思います。

ランキング機能には14,000以上あり、ドキュメントにも記載されている

API ドキュメントには 2,596 のモジュールが記載されており、14,014 の属性(機能)が次のように表示されています。

これらのモジュールは、YouTube、アシスタント、書籍、動画検索、リンク、ウェブドキュメント、クロールインフラ、社内カレンダーシステム、People APIコンポーネントに関連しています。Yandex のように、Google のシステムも単一のレポジトリ(「モノリポジトリ」とも呼ばれる)で動作し、マシンは共有環境で動作します。つまり、すべてのコードは1か所に保存され、ネットワーク上のどのマシンでもGoogleのどのシステムの一部になることができます。

ALT:「共有環境」と題された図は、共有環境内のさまざまなコンポーネントとその配置を示すブロック図です。この図は複数のレイヤーに分かれており、各レイヤーは異なるタイプのアプリケーションやシステムサービスを表現しています。詳細は以下の通りです。最上位レイヤー:ランダムアプリ #2(背景色:シアン)CPU 負荷の高いジョブ(背景色:シアン)ランダムアプリ(背景色:シアン)ランダム MapReduce #1(背景色:シアン)Bigtable タブレットサーバー(背景色:シアン) 中間レイヤー:その他の各種システムサービス(背景色:青) 最下位レイヤー:ファイルシステム チャンクサーバー(背景色:青)スケジューリングシステム(背景色:青) ベースレイヤー:Linux(背景色:青) 図全体を点線で囲み、共有環境を示しています。Googleのロゴは画像の右下に表示されています。

リークされたドキュメントでは、APIの各モジュールが概要、タイプ、機能、属性に分けられて説明されています。私たちが注目しているのは、主に、ランキングシステム全体からアクセスされ、SERP(Search Engine Result Pages:Googleが検索クエリを実行したユーザーに検索結果を表示するページ)を生成するさまざまなプロトコルバッファ(またはプロトバッファ)のプロパティ定義です。

ALT:この画像は、Protocol Buffers (PB) を利用してデータをシリアライズするプロセスを示したフローチャートです。このフローチャートは、4つの主要なステップで構成されており、各ステップは矢印付きのブロックで表され、プロセスの流れの方向を示しています。データ構造を定義する.protoファイルを作成します。 出力: .protoファイル protocコンパイラを使用してコードを生成します。 入力: .protoファイル 出力: .java、.py、.cc、またはその他のソースファイル プロジェクトコードでPBコードをコンパイルします。 入力: .java、.py、.cc、またはその他のソースファイル 出力: コンパイルされたクラス PBクラスを使用してデータをシリアライズ、共有、およびデシリアライズします。 入力: コンパイルされたクラス 各ブロックは、「入力」と「出力」と書かれた矢印でつながっており、ステップ間の依存関係を示しています。 このフローチャートは、.proto ファイルでデータ構造を定義してから、プロジェクトでコンパイルされたクラスを使用してデータのシリアライズとデシリアライズを行うまでの流れを視覚的に説明しています。

残念ながら、多くの要約は Go リンクを参照しており、これは Google の社内イントラネット上の URL で、システムのさまざまな側面に関する追加情報を提供しています。ログインしてこれらのページを表示するには、Google の適切な認証情報が必要ですが(これはほぼ確実に、検索チームの現役 Googler であることが必要となるでしょう)、私たちは独自の方法で解釈するしかありません。

API ドキュメントは、Google の嘘を明らかにしている

Googleの広報担当者は、SEO担当者の行動を制御するために、同社のシステムの動作に関するさまざまな側面について、わざと誤解を招くような説明を行っています。私は、この言葉を「社会工学」と呼ぶほどには踏み込みません。その言葉には、さまざまな意味合いが含まれているからです。代わりに、「ガスライティング」という言葉を使います。Googleの公式発表は、おそらく意図的に嘘をつくというよりも、潜在的スパマー(そして多くの正当なSEO業者も)を欺いて、検索結果にどのような影響を与えるかを私たちから遠ざけるためのものと思われます。

以下、Googleの社員による主張と、文書化された事実を限定的なコメントとともに提示しますので、ご自身で判断してください。

ドメインオーソリティのようなものはありません」

Googleの広報担当者は、「ドメインオーソリティ」を使用していないと何度も述べてきました。私は、これは意図的に隠蔽された嘘だとずっと考えてきました。

ドメインオーソリティを使用していないと言うことで、彼らは特にMozの「ドメインオーソリティ」と呼ばれる指標を使用していないと言っているのかもしれません(明らかに🙄)。あるいは、ウェブサイトに関連する特定の主題(またはドメイン)の権威や重要性を測定していないと言っているのかもしれません。この意味による混乱により、サイト全体のオーソリティ指標を計算しているか使用しているかという質問に対して、彼らは直接答えることができないのです。

Google 検索チームの分析者で、ウェブサイト制作者向けの情報発信に重点を置いているゲイリー・イリーズ氏は、この主張を何度も繰り返しています。

ALT:画像はTwitterの会話のスクリーンショットです。この会話には3つのツイートが含まれており、バックリンクがドメインオーソリティに与える影響について議論しているようです。ツイートの本文は以下の通りです。2016年10月27日、//Andrew Rodgers (@AndyNRodgers) によるツイート:「@JohnMu jpg URLへのバックリンクは、静的URLと同じアルゴリズム上の影響力があるのでしょうか?@methode」エンゲージメント: いいね数:1、リツイート数:2 2016年10月27日 //Andrew Rodgers (@AndyNRodgers) によるツイート(最初のツイートへの返信): 「よくわかりません。 ドメインオーソリティ全体について、ウェブページのURLに対する影響力と同じくらい、jpg URLに対するバックリンクの影響力があるのでしょうか? 」いいね数:1 2016年10月27日 Gary Illyes (@methode) によるツイート(Andrew Rodgers への返信): 「私たちは『総合的なドメインオーソリティ』を本当に把握していません。アンカーテキスト付きのテキストリンクの方が優れています」 タイムスタンプ: 2016年10月27日午前8時34分 Kebayoran Lama, Indonesia 画像には、会話に参加した人のプロフィール画像と名前も含まれています。

そして、ゲイリーだけではありません。Google検索関係を調整する「検索擁護者」であるジョン・ミューラー氏は、このビデオの中で「ウェブサイトオーソリティスコアは存在しない」と述べています。

実際には、Googleはドキュメントごとに保存されている圧縮された品質シグナルの一部として、「siteAuthority」と呼ばれる計算機能を備えています。

この指標がどのように計算され、下流のスコアリング機能で使用されているのかは具体的には分かりませんが、Q ランキングシステムに存在し、使用されていることは間違いありません。Googleには、ドメインオーソリティが実際に存在することが分かりました。Google社員は、「私たちはそれを持っているが、それを使用していない」とか、「その意味を理解していない」とか言うでしょう。ちょっと待って、私は「限定的なコメント」と言ったよね? 話を進めましょう。*

「ランキングにクリック数は使用していません」

この件については、もう終わりにしましょう。

DOJ独占禁止法裁判におけるパンデュ・ナヤクの証言により、GlueとNavBoostのランキングシステムの存在が明らかになりました。 NavBoostは、ウェブ検索におけるランキングを上昇、下降、または強化するためにクリック数に基づく指標を使用するシステムです。ナヤク氏は、Navboostは2005年頃から存在し、過去には18か月分のクリックデータを転用していたと述べています。このシステムは最近、13か月分のデータを転用するように更新され、ウェブ検索の結果に重点を置くようになりました。一方、Glueと呼ばれるシステムは、その他のユニバーサル検索の結果に関連しています。しかし、その発表の前にも、クリックログをどのように使用して検索結果を変えることができるかを具体的に示すいくつかの特許(2007年のTime Based Ranking特許を含む)を所有していました。

また、クリックを成功の尺度とすることは、情報検索におけるベストプラクティスである#Online_measures)ことも知っています。Google機械学習駆動型アルゴリズムへと移行し、MLがそのパフォーマンスを向上させるには応答変数が必要であることを知っています。このような明白な証拠があるにもかかわらず、Googleの広報担当者の誤った説明や、Googleの公式声明を批判的に吟味することなく、検索マーケティング業界全体で恥知らずにも共謀して記事を発表していることから、SEO業界では依然として混乱が生じています。

ゲイリー・アイレスは、このクリック測定の問題について何度も言及しています。ある事例では、Google Searchのエンジニアであるポール・ハー氏が2016年のSMX Westでのライブ実験に関する講演で述べた内容を、 2016年のSMX Westでのライブ実験に関する講演で、Google Searchエンジニアのポール・ハー氏が述べたことを補強し、「クリックを直接ランキングに使用することは間違いだ」と述べています。

ALT:画像は、Googleの品質アップデートと品質評価におけるクリックの役割について述べたインタビューまたは記事の抜粋をスクリーンショットしたものです。テキストは以下の通りです。DS: 先月、品質アップデートがありました。Googleはどのように品質を評価しているのでしょうか?クリックはどのように関わっているのでしょうか?GI: クリックはさまざまな方法で使用しています。評価と実験のためにクリックを使用することが主な目的です。クリックにノイズを発生させようとしている人は非常に多くいます。例えば、Rand Fishkinはクリックに関する実験を行っています。クリックを直接ランキングに使用することは間違いでしょう。パーソナライズされた検索結果では、例えば「apple」と検索した場合、ほとんどの場合、意味を明確にするボックスが表示されます。ユーザーが企業名なのか、それとも食品名なのかを判断しなければなりません。そして、ユーザーがクリックした内容を確認します。「Using clicks directly in ranking would be a mistake(ランキングに直接クリックを使用するのは間違い)」という文章の一部が黄色で強調表示されています。

さらにその後、彼は自身のプラットフォームを利用して、ランド・フィッシュキン氏(Mozの創設者兼CEOであり、長年のSEO実践者)を中傷し、「滞在時間、CTR、フィッシュキンの新しい理論が何であれ、それらは一般的にでっち上げられたくだらないものだ」と発言したことで有名になりました。

実際には、Navboostにはクリックシグナルに完全に特化した特定のモジュールがあります。

そのモジュールの概要では、「Craps(クラップス)のクリックとインプレッション信号」と定義されており、ランキングシステムの一つとなっています。 下記のように、バッドクリック、グッドクリック、最長クリック、スクウォッシュされていないクリック、スクウォッシュされていない最長クリックがすべてメトリクスとして考慮されています。Googleの「位置の重要性に基づくローカル検索結果のスコアリング」特許によると、「スクイーズは、1つの大きなシグナルが他のシグナルを圧倒するのを防ぐ機能」です。つまり、クリックシグナルに基づく操作が暴走しないよう、クリックデータを正規化しています。Googleの社員は、特許やホワイトペーパーに記載されているシステムが必ずしも実際に使用されているシステムではないと主張していますが、NavBoostはGoogleの情報検索システムにとって不可欠な部分でなければ、構築して組み込む意味がないでしょう。

この画像には、クリックに関連するいくつかの属性を説明する技術文書が含まれています。各属性には、そのタイプとデフォルト値が詳しく記載されています。テキストは以下の通りです。badClicks Type: float(), default: nil clicks (type: float(), default: nil) - goodClicks Type: float(), default: nil impressions (type: float(), default: nil) - lastLongestClicks Type: float(), default: nil unicornClicks (type: float(), default: nil) - Unicorn ユーザーによるイベントに関連付けられたクリックのサブセット。 unsquashedClicks Type: float(), default: nil 現在のフォーマットではこのフィールドは使用されていません。代わりに、CrapsClickSignals(squashed/unsquashed)の2つのインスタンスが使用されています。このフィールドが使用される新しいフォーマットに移行中です。 unsquashedImpressions Type: float(), default: nil 現在のフォーマットではこのフィールドは使用されていません。このフィールドが入力される新しいフォーマットに移行中です。 unsquashedLastLongestClicks Type: float(), default: nil 現在のフォーマットでは入力されません。代わりに、CrapsClickSignals(squashed/unsquashed)の2つのインスタンスが使用されます。このフィールドが埋められる新しいフォーマットに移行中です。

これらのクリックベースの測定基準の多くは、インデックスシグナルに関連する別のモジュールにも見られます。その1つが、特定のドキュメントに対する「最後の良質なクリック」の日付です。これは、コンテンツの劣化(または時間の経過に伴うトラフィックの損失)が、ランキングページがSERPポジションで期待されるクリック数を獲得できないことにも起因していることを示唆しています。

さらに、このドキュメントではユーザーを投票者と見なし、クリックを投票として記録しています。このシステムでは、不正クリックの数をカウントし、データを国とデバイスごとに分類します。

また、セッション中に最も長いクリック時間がかかった検索結果も保存されます。つまり、検索を実行し、その結果をクリックするだけでは不十分で、ユーザーはページにかなりの時間を費やす必要があるのです。ロングクリックは、滞在時間と同様に検索セッションの成功度を測る指標ですが、このドキュメントには「滞在時間」という特定の機能はありません。しかし、ロングクリックは事実上同じことを測定しており、Google声明と矛盾しています。

さまざまな情報源指摘するようにNavBoostは「すでにGoogleの最も強力なランキングシグナルの一つ」です。リークされた文書では、「Navboost」という名称が84回、Navboostをタイトルに含むモジュールが5つ記載されています。また、サブドメイン、ルートドメイン、URLレベルでのスコア付けも検討している証拠があり、これは本質的に、サイト内の異なるレベルを別々に扱っていることを示しています。サブドメインとサブディレクトリの議論についてはここでは触れないことにしますが、後で、このシステムからのデータがパンダアルゴリズムにも影響を与えていることを説明します。

つまり、Googleがこの文書の中で「CTR」や「滞在時間」という言葉をそのまま使っているわけではありませんが、ランドが証明した精神、つまり検索結果のクリック数や検索セッションの成功の尺度については言及されています。この証拠は極めて決定的であり、Googleがクリック数やクリック後の行動をランキングアルゴリズムの一部として使用していることに疑いの余地はほとんどありません。

サンドボックスは存在しません」

Googleの広報担当者は、ウェブサイトが年齢や信頼性のシグナルに基づいて隔離されるサンドボックスは存在しない、と断言しています。現在は削除されたツイートで、ジョン・ミューラー氏は、ランキング対象になるまでにどのくらいの期間がかかるかという質問に対し、「サンドボックスは存在しない」と回答しました。

PerDocDataモジュールでは、ドキュメントに「ホストAge」という属性があり、これは「配信時に新しいスパムをサンドボックスでテストするために」使用されると記載されています。

結局、サンドボックスが存在することが判明しました。 誰が知っていたでしょうか? ああ、Randは知っていましたね。.

Googleはランキング付けにChromeのデータを一切使用していません」

マット・カッツは以前、Googleはオーガニック検索の一部としてChromeのデータを使用していないと述べています。さらに最近では、ジョン・ミューラーがこの考え方を強化しました

ページ品質スコアに関連するモジュールの一つに、Chromeからのサイトレベルのビューに関する測定値があります。また、サイトリンクの生成に関連すると思われる別のモジュールにも、Chrome関連の属性があります。

ALT:画像は「Realtime Boost Signal」というタイトルのスライドで、(go/realtime-boost)へのリンクがあります。スライドの内容は、リアルタイムブーストシグナルのソースと用途に関する情報、クエリの傾向を示すグラフなどが含まれています。以下がその詳細です。タイトル: Realtime Boost Signal (go/realtime-boost) コンテンツ作成に関するスパイクと相関関係 場所 (S2)、エンティティ、顕著な用語、Nグラム... ソース: Freshdocs-instant Chrome Visits (近日公開) (黄色で強調表示) Instant Navboost (近日公開) Twitter との契約による制限なし Query Rewriter: Freshbox、Stream など、どこでも使用可能 グラフ: 右上グラフ: 「Twitter Hemlock Query Trend」というタイトルで、「ノイズレベル (中央値 + 1IQR)」を示す赤い線と、「Spike」と書かれた矢印でスパイクを示しています。右下グラフ: 「Query [Dilma]」というタイトルで、「Spike 5 mins after impeachment process announced(弾劾手続き発表から5分後にスパイク)」というキャプションが付いています。Dilmaという用語のスコアの時系列にスパイクが見られます。スライドの下部には、「Realtime Boost 信号の作成において、鳥が傷つくことはありませんでした」という注釈があり、左下に Google のロゴが表示されています。

2016年5月に流出した社内プレゼンテーション資料によると、RealTime Boost システムでは、Chrome のデータが検索に届いていたことも示されています。つまり、言いたいことはお分かりでしょう。

Googleの広報担当者は善意に満ちていますが、彼らを信頼することはできるのでしょうか?

手っ取り早い答えは、秘密のソースに近づき過ぎないことです。

ここで挙げた人々に対して悪意を抱いているわけではありません。彼らが許される範囲内でコミュニティにサポートと価値を提供するために最善を尽くしているのは確かです。しかし、これらの文書は、彼らの発言をひとつの情報源として受け止め、コミュニティが何が有効かを確認するために実験を続けるべきであることを明確に示しています。

Googleのランキングシステムのアーキテクチャ

概念的には、「Googleアルゴリズム」は、一連の重み付けされたランキング要因を持つ巨大な方程式として1つのものとして考えることができます。実際には、多くの機能が事前に処理され、SERPを構成するために実行時に利用可能になる一連のマイクロサービスです。ドキュメントで参照されているさまざまなシステムに基づいて、100以上の異なるランキングシステムがあるかもしれません。これらがすべてのシステムではないと仮定すると、おそらく個別の各システムは「ランキングシグナル」を表しており、Googleが頻繁に話題にする200のランキングシグナルは、おそらくその方法によって得られるものなのでしょう。

ジェフ・ディーン氏の講演「Building Software Systems at Google and Lessons Learned」では、初期のGoogleでは各クエリを1000台のマシンに送信し、250ミリ秒未満で処理・応答していたと述べています。また、初期のシステムアーキテクチャの抽象化についても図解しています。この図は、Super Root が Google 検索の頭脳であり、クエリを送信し、最後にすべてをまとめることを示しています。

ALT:画像は「2007: Universal Search」と題されたフローチャートで、2007年のGoogleのユニバーサル検索システムの構成要素とプロセスフローを表しています。この図には、データの流れの方向を示す矢印でつながれたさまざまな要素が含まれています。詳細は以下の通りです。タイトル:2007: Universal Search フローチャート 構成要素: クエリ(入力クエリを示すテキストが上部にある)フロントエンドウェブサーバー(赤いボックス)クエリからフロントエンドウェブサーバーへの矢印スーパールート(青いボックス)フロントエンドウェブサーバーからスーパールートへの矢印キャッシュサーバーからスーパールートへの矢印広告システム(青いボックス)フロントエンドウェブサーバーから広告システムへの矢印広告システムからフロントエンドウェブサーバーへの矢印インデックスサービス(下部の青いバー)検索カテゴリー(すべての緑の三角形): 画像 ローカルニュース ウェブ(最も大きな三角形) ビデオ ブログ 書籍 接続: スーパールートから各検索カテゴリー(画像、ローカル、ニュース、ウェブ、ビデオ、ブログ、書籍)への矢印 Googleのロゴは画像の右下に表示されています。

著名な研究エンジニア、マーク・ナジョーク氏は、最近行った「生成型情報検索」では、RAGシステム(別名:Search Generative Experience/AI Overviews)を搭載したGoogle検索の抽象モデルが紹介されました。この図は、検索結果のさまざまなレイヤーを処理する一連の異なるデータストアとサーバーを示しています。

ALT:この画像は、Google DeepMind が発表した「検索拡張 GQA システムのアーキテクチャ」と題された図です。この図は、検索拡張生成型質問応答システムのコンポーネントとワークフローの概要を示しています。構造は、オフライン/クロール時間とオンライン/クエリ時間の 2 つの主要セクションに分かれています。 タイトル: 検索拡張 GQA システムのアーキテクチャ コンポーネントとワークフロー: コンテンツ(左側の雲のアイコン) クローラー(コンテンツに接続されたボックス) オフライン/クロール時間(左上部分): LM トレーナー(クローラーコーパスビルダーに接続されたボックス) 言語モデル(LM トレーナーとコーパスに接続されたボックス) コーパスビルダー(クローラーコーパスに接続されたボックス) ドキュメントエンベッダー(クローラーとベクトル DB に接続されたボックス) インデックスビルダー(クローラーと反転インデックスに接続されたボックス) 中心的なコンポーネントコーパスコーパスビルダーと言語モデルに接続) Vector DB(ドキュメントエンベッダーに接続) インバートインデックス(インデックスビルダーに接続) オンライン/クエリ実行時(右上部分): LM ジェネレーター(ボックスはコーパスサーバーと検索フロントエンドに接続) コーパスサーバー(コーパスと LM ジェネレーターに接続) エンベッディングサーバー(ベクトル DB と検索フロントエンドに接続) インデックスサーバー(反転インデックスと検索フロントエンドに接続) 検索フロントエンド(右中央のボックスはコーパスサーバー、エンベッディングサーバー、インデックスサーバーに接続) ユーザー(右側の雲のアイコンは検索フロントエンドに接続) 矢印と接続: 矢印は、コンテンツとクローラー、そしてシステム内の他のコンポーネント間のデータフローと接続を表しています。クローラーからの矢印は、LMトレーナー、コーパスビルダー、ドキュメントエンベッダー、インデックスビルダーへとつながり、それぞれのコンポーネントへとつながっています。中心となるコンポーネントコーパス、ベクトルDB、反転インデックス)は、オンライン/クエリ実行時のコンポーネントコーパスサーバー、エンベッディングサーバー、インデックスサーバー)へとつながっています。検索フロントエンドはオンラインコンポーネントからデータを集約し、ユーザーに検索結果を提供します。 注:検索フロントエンドからの矢印の隣にある「1」や「2」などのラベルは、クエリ処理におけるステップやアクションを示しています。この図は、データ検索と質問への回答を効率的に管理するために、オフライン/クロール時間とオンライン/クエリ時間のプロセスとコンポーネントを分離していることを示しています。

Google内部告発者ザック・ヴォルヒーズがリークしたこのスライドは、Google内のさまざまなシステムの関係を内部名称で示したものです。これらのうちのいくつかは、文書で言及されています。

ALT:画像は「全社的な機械学習の例」と題された図で、機械学習(ML)が Google や Alphabet のさまざまな製品にどのように統合されているかを示しています。この図は、異なる ML チームと製品間のつながりを示しており、円の大きさはつながりの数に比例しています。 タイトル: 全社的な機械学習の例 サブタイトル: 機械学習は、Google の幅広い製品や Alphabet の企業にとって中核をなすものです。 構成: ML チーム(緑の円): Sibyl Drishti Brain Laser SAFT Alphabet companies (red circles): [X] Chauffeur Life Sciences Google products (yellow circles): Nest Search Indexing Android Speech Geo Play Music, Movies, Books, Games Image Search G+ GDN Context Ads YouTube Search Translate Email Inbox Play Apps Product Ads GMob Mobile Ads Google TV Security Google Now WebAnswers Genie Connections: 線によって、さまざまなMLチームと複数のGoogle製品およびAlphabet社がつながっており、機械学習技術の連携や統合を示しています。例えば、「Brain」MLチームは、Nest、Search Indexing、Android Speech、Geo、YouTube、Translateなど、数多くの製品に接続しています。「Laser」チームは、Google TV、Security、Google Now、Play Appsなどの製品に接続しています。凡例:緑色の丸:MLチーム 赤色の丸:アルファベット社 黄色の丸: Google製品 円の大きさは接続数に比例します。 ロゴと免責事項:左下にGoogleのロゴ、右下に「Confidential & Proprietary」の注釈があります。 この図は、Googleとその親会社であるアルファベット社内のさまざまな製品やサービスにおける機械学習の広範な統合を視覚的に表したものです。

これらの3つのハイレベルモデルを使用することで、これらのコンポーネントがどのように連携しているかを考えることができます。私がドキュメントから読み取れる限りでは、このAPIGoogleのSpannerの上に構築されているようです。Spannerは、グローバルにネットワーク接続された一連のコンピュータを1つのものとして扱いながら、コンテンツの保存とコンピューティングを基本的に無限に拡張できるアーキテクチャです。

確かに、ドキュメントだけではすべての関連性を把握するのは難しいですが、Paul Haahrの履歴書には、ランキングシステムの一部が何をしているのかについて、貴重な洞察が示されています。私が名前を知っているものについて強調し、機能ごとに分類します。

クローラ

  • Trawler – ウェブクローラシステム。クローラキュー、クローラレートの維持、ページ変更頻度の把握などの機能を備えています。

インデックス作成

  • Alexandria – コアとなるインデックスシステムです。
  • SegIndexer インデックス内の階層構造に階層構造化されたドキュメントを配置するシステムです。
  • TeraGoogle – ディスクに長期保存されているドキュメント用の二次インデックスシステムです。

レンダリング

  • HtmlrenderWebkitHeadless – JavaScript ページのレンダリングシステム。奇妙なことに、これは Chromium ではなく Webkit にちなんで名付けられています。ドキュメントには Chromium についての言及があるため、Google はもともと WebKit を使用しており、Headless Chrome が登場してから切り替えた可能性が高いと考えられます。

処理

  • LinkExtractor – ページからリンクを抽出します。
  • WebMirror – 正規化および重複の管理システム。

ランキング

  • Mustang – 主なスコアリング、ランキング、配信システムです。

  • Ascorer – 再ランキング調整前にページをランク付けする主なランキングアルゴリズムです。

  • NavBoost – ユーザーの行動に関するクリックログに基づく再ランキングシステム。

  • FreshnessTwiddler – 新鮮度に基づくドキュメントの再ランキングシステム。

  • WebChooserScorer – スニペットのスコアリングで使用される機能名を定義します。

配信

  • Google Web Server – GWS は、Google のフロントエンドがやり取りを行うサーバーです。ユーザーに表示するデータのペイロードを受信します。
  • SuperRoot – これは Google 検索の頭脳であり、Google のサーバーにメッセージを送信し、再ランキングと結果の表示を行う後処理システムを管理します。
  • SnippetBrain – 検索結果のスニペットを生成するシステムです。
  • Glue – ユーザーの行動パターンを元に、ユニバーサルな検索結果を集約するシステムです。
  • Cookbook – 信号生成システム。実行時に値が作成されるという指摘があります。

先にも述べたように、このドキュメントには他にも多くのシステムが概説されていますが、それらのシステムが何をやっているのかは必ずしも明確ではありません。例えば、上の図の SAFT と Drishti もこのドキュメントに記述されていますが、その機能は不明です。

Twiddlersとは何か?

Twiddlers に関するオンライン上の情報は限られているため、ここで説明しておくことで、ドキュメントで遭遇するさまざまな Boost システムを適切に理解できると思います。

Twiddlersは、主要なアスコア検索アルゴリズムの後に実行される再ランキング機能です。WordPressのフィルターやアクションがどのように機能するかと似ており、ユーザーに表示する前に表示内容を調整します。Twiddlersは、ドキュメントの情報検索スコアを調整したり、ドキュメントのランキングを変更したりすることができます。私たちが知っている多くのライブ実験や名前の付いたシステムは、この方法で実装されています。このXooglerが示すように、Googleのさまざまなシステムにおいて、Twiddlersは非常に重要な役割を果たしています。

ALT:画像は、2023年9月27日付のDeedy(@deedydas)のツイートのスクリーンショットです。このツイートは、DeedyがGoogle検索を動かすサービス「superroot」のAPI定義を変更したときの経験について述べています。この変更により「twiddlers」が無効になり、YouTube検索に誤って影響を与え、数時間検索ができなくなりました。このツイートは、2023年9月23日付でAveta(@Aliafonzy43)が投稿した、上級エンジニアによる重大な生産上の問題に関する体験談を求めるツイートに対する返信です。画像内のテキスト: Deedy (@deedydas) 「ある時、私はGoogle検索の基盤となるsuperrootのAPI定義を変更し、「twiddlers」を無効にしました。しかし、その変更がYouTube検索のすべてに影響を与えることに気づかず、YouTube検索を数時間停止させてしまいました。Aveta (@Aliafonzy43)「私は、自分のコード品質が低いと言われたときに、すぐに修正したコードがプロダクション環境にプッシュされたことで、何らかの感情を抱いてもおかしくないと思っていることを、先輩エンジニアの皆さんにお話しいただきたいです。これが何かあるのか知りたいだけです」 追加情報:スクリーンショットを撮影した時点で、Deedyのツイートは29.6K回閲覧されていました。Deedy のツイートは、2023年9月27日午前3時22分に投稿されています。Aveta のツイートは、2023年9月23日に投稿されています。Deedy のプロフィール画像と認証マークは、スクリーンショットで確認できます。

ツイッダーはカテゴリーを制限できるため、結果の種類を具体的に限定することで多様性を促進することができます。例えば、特定の SERP においてブログ投稿を 3 件のみ表示するように設定することができます。これにより、ページ形式に基づいてランキングが望めない場合を明確にすることができます。

Googleがパンダはコアアルゴリズムの一部ではないと述べた場合、それは再ランキングのブーストまたはデモーションの計算としてTwiddlerとして導入され、その後、主要なスコアリング機能に移行したことを意味している可能性が高いです。サーバーサイドとクライアントサイドのレンダリングの違いに似ていると考えてください。

おそらく、Boostという接尾辞が付いた機能はすべて、Twiddlerフレームワークを使用して動作していると考えられます。 ドキュメントで特定されているBoostには、次のようなものがあります。

  • NavBoost
  • QualityBoost
  • RealTimeBoost
  • WebImageBoost

命名規則から、これらはすべて非常にわかりやすいことがお分かりでしょう。

私が確認した社内文書には、これについてより詳しく説明したものもありますが、この記事では、著者が私と同じ文書を見たようです。

SEO対策に影響を与える可能性のある重要な発見

皆さんが本当に知りたいことについてお話ししましょう。Googleが私たちに知られていなかったこと、あるいは私たちが確信を持てなかったことを行っているとしたら、それは私のSEOの取り組みにどのような影響を与えるのでしょうか?

先に進む前に一言。私の目標は常に、SEO業界に斬新なコンセプトを紹介することです。特定の使用事例にどのように適用するかについて、処方箋を示すことが私の目標ではありません。もしそれが目的であれば、iPullRankをSEOのために雇うべきです。そうでなければ、あなた自身の使用事例を推測し、開発するための材料は常に十分すぎるほどあります。

パンダがどのように機能するか

パンダが導入された当初は、多くの混乱がありました。これは機械学習なのか?ユーザーシグナルを使用しているのか?なぜ回復するために更新やリフレッシュが必要なのか?サイト全体に適用されるのか?なぜ特定のサブディレクトリのトラフィックが減少したのか?

パンダはアミット・シンガル氏の指揮のもとでリリースされました。シンガル氏は、機械学習の観察可能性に限界があることから、機械学習には明確に反対していました。実際、パンダにはサイトの品質に焦点を当てた一連の特許がありますが、私が注目したいのは「検索結果のランキング」という非記述的な特許です。この特許は、パンダが私たちが考えていたよりもはるかにシンプルであることを明確に示しています。これは主に、ユーザー行動や外部リンクに関連する分散シグナルに基づいてスコアリング修正子を構築することに関するものでした。その修正子は、ドメインレベル、サブドメインレベル、サブディレクトリレベルで適用することができます。

「システムは、独立したリンクの数と参照クエリの数から、リソースグループの修正係数を生成します(ステップ306)。例えば、修正係数は、グループに対する独立したリンクの数とグループに対する参照クエリの数の比率とすることができます。つまり、修正係数(M)は次のように表されます。

M=IL/RQ、

ここで、IL はリソースのグループに対してカウントされた独立したリンクの数、RQ はリソースのグループに対してカウントされた参照クエリの数です。」

独立したリンクは、基本的に私たちが考えるリンク元ドメインですが、参照クエリはもう少し複雑です。特許では次のように定義されています。

「特定のリソースグループに対する参照クエリとは、特定のリソースグループのリソースを参照するものとして分類された、以前に送信された検索クエリを指します。特定の以前に送信された検索クエリを特定のリソースグループのリソースを参照するものとして分類するには、特定の以前に送信された検索クエリに、特定のリソースグループのリソースを参照するものとして判断された1つ以上の用語が含まれていると判断することなどが含まれます。」

この文書を入手した今、参照クエリは NavBoost からのクエリであることが明らかです。

これは、パンダのリフレッシュは、コアウェブバイタル計算機能に似たクエリのローリングウィンドウの単純な更新であることを示唆しています。また、リンクグラフの更新がパンダではリアルタイムで処理されなかった可能性もあります。

繰り返しになりますが、パンダのもう一つの特許である「サイト品質スコア」も、参照クエリとユーザーの選択またはクリックの比率を示すスコアを考慮しています。

要点は、ランキングを維持したいのであれば、より広範なクエリセットを使用してより多くの成功したクリックを獲得し、リンクの多様性を高める必要があるということです。概念的には、非常に優れたコンテンツがそれを実現するので理にかなっています。より質の高いトラフィックを誘導し、ユーザー体験の向上に重点を置くことで、Googleにあなたのページがランキングに値するというシグナルを送ることができます。Helpful Content Updateからの回復にも同じことに重点を置くべきです。

著者は明確な特徴

E-E-A-Tについては多くのことが書かれてきました。専門性や権威性を評価することが曖昧であるため、多くのSEO担当者は懐疑的です。また、私は以前、ウェブ上で実際に使われているオーサーマークアップがほとんどないことを指摘しました。ベクター埋め込みについて知る前は、オーサーシップがウェブ全体で見られる十分なシグナルであるとは考えていませんでした。

ALT:画像は「How When Authorship Markup Tops out at 3%?(オーサーシップマークアップが3%で頭打ちになる理由)」というタイトルのプレゼンテーションスライドです。このスライドには、年ごとのさまざまなタイプのマークアップの使用率を示す棒グラフがいくつか含まれています。各グラフは異なるタイプのマークアップを表しており、特定のデータポイントを強調する矢印が付いています。スライドの左下隅に94という番号が付けられています。タイトル:How When Authorship Markup Tops out at 3%?(オーサーシップマークアップが3%で頭打ちになる理由)グラフ: RDFa の年間使用率 データ対象年:2012年、2017年 強調表示されたデータポイント:foaf(0.31%) その他のデータポイント:foaf、content、sioc、dcterms など マイクロデータの年間使用状況 対象年:2012年、2017年 注目データ:schema.org/author(1.5%) その他のデータ:schema.org/name、schema.org/url、schema.org/description など Twitterのメタタグの使用状況(年別) 対象年:2012年、2017年 注目すべきデータ:twitter(20%) その他のデータ:twittertwittertwitter、など JSON-LDの使用状況(年別) 対象年:2012年、2017年 注目すべきデータ:schema.org/author(1.1%) その他のデータ: WebSite、Organization、WebPage、Article、BreadcrumbList など。ダブリン・コアの使用率(年別) データ対象年:2012年、2017年 注目データ:dc.creator(0.06%) その他のデータ:dc.title、dc.subject、dc.description、dc.publisher など。各グラフは、各年における特定のマークアップを使用しているページの割合を示しています。赤い矢印は、特定のデータポイントを示しており、その重要性を強調しています。各グラフのX軸には、使用率が表示されています。

それでも、Googleは文書に関連する著者をテキストとして明示的に保存しています。

また、ページ上のエンティティがページの著者でもあるかどうかを判断します。

ALT:画像には、isAuthor という属性を説明する技術文書の抜粋が含まれています。テキストは以下の通りです。isAuthor タイプ: boolean()、デフォルト: nil 説明: エンティティがドキュメントの著者である場合に true。これは主にニュース記事(例えば、www.vogue.com/article/flint-town-netflix の /m/02x27qn)向けに開発および調整されていますが、他のコンテンツ(例えば、科学記事)にも適用されています。重要:このフィールドのセマンティクスは将来的に変更される可能性があり、削除されて別の API に置き換えられる可能性があります。このフィールドを使用する場合は、まず ke-authors@ に連絡してください。この属性は、エンティティがドキュメントの著者であるかどうかを示すブール値です。これは主にニュース記事用に設計されていますが、他の種類のコンテンツにも使用できます。

これらの文書で詳しく説明されているエンティティのマッピングと埋め込みを合わせると、著者を総合的に評価する指標があることは明らかです。

降格

ドキュメントでは、一連のアルゴリズムによる降格が説明されています。説明は限られていますが、言及する価値があります。パンダについてはすでに説明しましたが、私がこれまでに遭遇したその他の降格は以下のとおりです。

  • アンカーミスマッチ – リンクがリンク先のサイトと一致していない場合、リンクは計算上で降格されます。 以前にも述べたように、Googleはリンクの両側における関連性を探しています。
  • SERP 降格 – SERP から観察された要因に基づいて降格を示すシグナルで、クリック数から判断して、ページに対するユーザーの不満の可能性を示唆します。
  • Nav Demotion – おそらく、これはナビゲーションの実践やユーザー体験の問題が顕著なページに適用される降格措置です。
  • 完全一致ドメインの降格 – 2012年後半、マット・カッツ は、完全一致ドメインがこれまでほど価値を持たなくなるだろうと発表しました。 降格には特定の機能があります。
  • 製品レビューの降格 – これに関する具体的な情報はありませんが、降格としてリストされており、おそらく2023年の最近の製品レビューの更新に関連していると思われます。
  • ロケーションの降格 – 「グローバル」ページと「スーパーグローバル」ページが降格される可能性があることが示されています。これは、Googleがページを特定の場所に結びつけ、それに応じてランク付けしようとしていることを示唆しています。
  • ポルノサイトの降格 – これは明らかです。
  • その他のリンクの降格 – 次のセクションで説明します。

これらの可能性のある降格は戦略立案に役立つ情報となりますが、率直に言えば、優れたコンテンツと優れたユーザー体験を作り、ブランドを構築することが重要です。

リンクは依然として非常に重要と思われる

リンクの重要性が低下しているという最近の主張を否定する証拠は、私は見たことがありません。繰り返しになりますが、これは情報の保存方法よりもむしろ、スコアリング機能自体で処理される可能性が高いです。リンクグラフを深く理解するために、機能を抽出して調整することに細心の注意が払われてきました。

インデックス階層によるリンク価値への影響

sourceType と呼ばれるメトリクスは、ページがインデックスされる場所と、そのページの価値の緩やかな関係を示します。簡単に背景を説明すると、Google のインデックスは階層化されており、最も重要で定期的に更新され、アクセスされるコンテンツはフラッシュメモリに保存されます。重要性の低いコンテンツはソリッドステートドライブに保存され、不定期に更新されるコンテンツは標準的なハードドライブに保存されます。

ALT:画像には、「sourceType」という属性を説明する技術文書の抜粋が含まれています。テキストは以下の通りです。 sourceType Type: integer(), default: nil Description: アンカーのソースページの品質を記録するもので、ソースページのインデックス階層とは相関関係がありますが、同一ではありません。 インデックスパイプライン(Alexandria)によって構築された docjoins では、TYPE_HIGH_QUALITY とマークされたアンカーはベースドキュメントからのものです。TYPE_MEDIUM_QUALITY とマークされたアンカーは、中程度の品質の文書(厳密には補助階層文書ではありませんが、ほぼ補助階層文書と同じ)に由来します。TYPE_LOW_QUALITY とマークされたアンカーは、低品質の文書(厳密にはブラックホール文書ではありませんが、ほぼブラックホール文書と同じ)に由来します。source_type はアンカーの重要度を示す指標としても使用できます(source_type の値が低いほど、そのアンカーはより重要であることを示します)。そのため、TYPE_HIGH_QUALITY < TYPE_MEDIUM_QUALITY < TYPE_LOW_QUALITY の関係を厳守することが重要です。将来的に新しいソースタイプを追加する場合は、タイプ間の適切な関係も維持してください。freshdocs インデックス作成でのみ利用可能な TYPE_FRESHDOCS は特別なケースであり、重複アンカーの削除におけるアンカーの重要性の目的では、TYPE_HIGH_QUALITY と同じタイプと見なされます。この属性は、アンカーのソースページの品質を記録するために使用される整数で、ソースページのインデックス階層に関連付けられています。アンカーを「高品質」、「中品質」、「低品質」に分類し、アンカーの重要性の指標としても機能します。異なるタイプの間の関係を維持するための特定のルールがあり、フレッシュドックスインデックス用の特別なケースも含まれています。

これは、階層が高いほどリンクの価値が高いということを意味します。また、「フレッシュ」と見なされるページは、高品質と見なされます。言うまでもなく、リンクはフレッシュなページや上位階層に掲載されたページから取得したいものです。これが、高ランキングのページやニュースページからのランキングが、より良いランキングパフォーマンスをもたらす理由の一部です。ほら、デジタルPRがまたクールになったでしょ!

リンクスパムの速度シグナル

スパムアンカーテキストの急増を特定するための一連の指標があります。AnchorSpamDaysというフレーズに注目すると、Googleは事実上、スパムのリンク速度を測定する能力を持っています。

ALT:画像は「IndexingDocjoinerAnchorPhraseSpamInfo」というタイトルの技術文書の一部です。スパムアンカーフレーズ急増を識別するために使用されるさまざまな属性が説明されています。急増中に作成されたアンカーには、LINK_SPAM_PHRASE_SPIKE というタグが付けられます。 Title: IndexingDocjoinerAnchorPhraseSpamInfo Description: Following signals identify spikes of spammy anchor phrases. スパイク中に作成されたアンカーには、LINK_SPAM_PHRASE_SPIKE タグが付けられます。 属性: phraseAnchorSpamCount タイプ: number(), デフォルト: nil 説明: ユニークなドメイン内のアンカーに検出されたスパムフレーズの件数。 phraseAnchorSpamDays タイプ: number(), デフォルト: nil 説明: これらのフレーズの80%が検出された日数の合計。 phraseAnchorSpamDemoted タイプ: integer(), デフォルト: nil 説明: 降格されたアンカーの総数です。phraseAnchorSpamEnd タイプ: integer(), デフォルト: nil 説明: アンカースパムの急増が終了した時刻を補完して表示します。phraseAnchorSpamFraq タイプ: number(), デフォルト: nil 説明: ドキュメントのすべてのアンカーのうち、スパムフレーズが占める割合です。このドキュメントでは、インデックス作成システム内のスパムアンカーフレーズを監視および管理する方法について詳しく説明します。

これは、サイトがスパムを行っているかどうかを確認したり、ネガティブSEO攻撃を無効にしたりするために簡単に使用できます。後者について懐疑的な人に対しては、Googleはこのデータをリンク発見のベースラインと現在のトレンドを比較するために使用し、どちらの方向にもそれらのリンクをカウントしないようにすることができます。

Googleはリンクを分析する際に、特定のURLについて直近の20回の変更のみを使用する

以前、Googleファイルシステムウェイバックマシンと同様に、時間の経過とともにページのバージョンを保存できる仕組みについてご紹介しました。私の理解では、Googleはインデックスしたページを永久に保存します。これが、ページを無関係なターゲットに単純にリダイレクトしても、リンクエクイティが流れるとは期待できない理由の1つです。

ドキュメントはこの考え方を裏付けており、ページでこれまでに確認されたすべての変更を記録していることを示唆しています。

DocInfoを取得して比較用のデータを表示する場合、ページの最新バージョン20件のみが考慮されます。

これにより、Googleで「白紙の状態」を得るために、ページを何回変更し、インデックスに登録する必要があるかがわかるはずです。

ホームページのPageRankはすべてのページで考慮される

すべてのドキュメントには、そのドキュメントに関連付けられたホームページのPageRank(Nearest Seedバージョン)があります。これは、新しいページが独自のPageRankを獲得するまでの間、代理として使用されます。

おそらく、新しいページが独自のPageRankを算出されるまでは、この値とsiteAuthorityが代理として使用されることになります。

ホームページの信頼性

Googleは、ホームページをどの程度信頼しているかに基づいて、リンクの評価方法を決定します。

リンクの数はもちろん重要ですが、それよりもリンクの質と関連性に重点を置くはずです。

キーワードやリンクのフォントサイズが重要

私が2006年に初めてSEOを始めたとき、私たちがやったことの1つは、テキストを太字や下線にする、あるいは特定の文章を大きくしてより重要に見せることでした。過去5年間、私は今でもそれは行う価値があると言う人々を見てきました。私は懐疑的でしたが、今ではGoogleがドキュメント内の用語の平均加重フォントサイズを追跡していることがわかります。

リンクのアンカーテキストについても同様です。

ペンギン・ドロップス内部リンク

アンカー関連の多くのモジュールでは、「ローカル」とは同じサイトを意味します。この droppedLocalAnchorCount は、一部の内部リンクがカウントされていないことを示唆しています。

Disavow(否認)に関する言及が一切なかった

否認データは別の場所に保存されている可能性がありますが、この API にはありません。特に、品質評価者のデータが直接アクセスできることから、このことがわかります。これは、否認データがコアのランキングシステムから切り離されていることを示唆しています。

私の長年の推測では、disavowはGoogleのスパム分類器を訓練するための、クラウドソーシングによる機能エンジニアリングの取り組みであったと考えています。データが「オンライン」になっていないということは、この推測が正しい可能性を示唆しています。

私は、IndyRank、PageRankNSなどの機能について、リンクをどんどん挙げて説明していくこともできますが、Googleはリンク分析を非常に正確に実行しており、Googleが行っていることの多くは、私たちのリンクインデックスでは近似できないということを言っておきましょう。今お読みいただいたことを踏まえて、リンク構築プログラムを見直すには絶好の機会です。

ドキュメントが切り捨てられる

Googleトークンの数と、本文中の単語の総数とユニークなトークンの数の比率を計算します。ドキュメントには、Mustangシステムではドキュメントとして考慮できるトークンの最大数が示されており、これにより、著者は最も重要なコンテンツを先頭に配置し続けるべきであることが強調されています。

短いコンテンツは独自性に基づいてスコア化される

OriginalContentScore は、短いコンテンツは独自性に基づいて評価されることを示唆しています。そのため、短いコンテンツが必ずしも長さの関数ではないのかもしれません。

逆に、キーワードスタッフィングスコアもあります。

ページタイトルは依然としてクエリに対して測定される

ドキュメントによると、titlematchScore があるようです。説明を読むと、ページタイトルがクエリにどれだけ一致しているかは、Google が積極的に評価する要素であるようです。

ターゲットキーワードを最初に配置することは、今でも有効な方法です。

文字数カウントの指標はない

彼の功績として、Gary Ilyesは、メタデータ用の最適な文字数SEOがすべて決めている、と述べています。このデータセットには、ページタイトルやスニペットの長さをカウントする指標はありません。私がドキュメントで発見した唯一の文字カウント測定基準は、スニペットの一部として使用できるものを決定するために設定されていると思われる snippetPrefixCharCount です。

画像は技術文書ページの一部です。次の要素とテキストが含まれています:snippetPrefixCharCount Type: integer(), default: nil スニペットプレフィックスの文字数。セクション見出し、リスト概要、署名日付など。

これは、何度もテストされてきたことを裏付けるものです。長いページタイトルはクリック数を増やすには最適ではありませんが、ランキングを上げるには問題ありません。

日付は非常に重要

Googleは新しい検索結果に重点を置いており、文書では日付とページを関連付けるためのGoogleの多くの試みが示されています。

  • bylineDate – これはページに明示的に設定された日付です。

  • syntacticDate – これは URL またはタイトルから抽出された日付です。

semanticDate – これはページのコンテンツから取得される日付です。

ここでは、日付を指定し、構造化データ、ページタイトル、XMLサイトマップ全体で一貫性を保つことが最善の方法です。ページの他の場所の日付と矛盾する日付をURLに含めると、コンテンツのパフォーマンスが低下する可能性があります。

ドメイン登録情報はページについて保存されている

Googleレジストラとしての地位をアルゴリズムに与えているという陰謀説は長い間続いてきました。陰謀説を事実として裏付けることができます。彼らは複合ドキュメントレベルで最新の登録情報を保存しています。

前述の通り、これは新しいコンテンツのサンドボックス化を通知するために使用される可能性が高いです。また、所有者が変更された以前に登録されたドメインサンドボックス化にも使用される可能性があります。有効期限切れドメインの悪用スパムポリシーの導入により、このウェイトが最近引き上げられたのではないかと私は考えています。

動画中心のサイトは異なる扱いを受ける

サイトの50%以上のページに動画がある場合、そのサイトは動画中心のサイトと見なされ、異なる扱いを受けます。

Your Money Your Life は特に高いスコアが付けられている

ドキュメントによると、Google は YMYL Health と YMYL News のスコアを生成する分類器を持っていることが示されています。

また、彼らは「フリンジクエリ」、つまりこれまでに確認されていないクエリが YMYL であるかどうかを判断するために、それらのクエリを予測します。

最後に、YMYL はチャンクレベルでコア化されており、これはシステム全体が埋め込みに基づいていることを示唆しています。

ゴールドスタンダードのドキュメントがある

これは何を意味するのかは不明ですが、説明には「人間がラベル付けしたドキュメント」と「自動的にラベル付けされた注釈」が挙げられています。これは品質評価の機能なのかと思いますが、Googleは品質評価はランキングに影響しないと述べています。そのため、真相は永遠にわからないかもしれません。🤔

サイト埋め込みは、ページがトピックにどれだけ関連しているかを測定するために使用される

エンベッディングについては、次回の記事でさらに詳しく説明しますが、Googleがページやサイトを特にベクトル化し、ページエンベッディングとサイトエンベッディングを比較して、ページがどの程度トピックから外れているかを確認していることは注目に値します。

siteFocusScore は、サイトが特定のトピックにどれだけ集中しているかを表します。site radius は、サイト用に生成された site2vec ベクトルに基づいて、ページがコアとなるトピックからどれだけ外れているかを表します。

Googleは意図的に小規模サイトを排除している可能性がある

Googleには、サイトが「小規模な個人サイト」であることを示す特定のフラグがあります。このようなサイトの定義はありませんが、私たちが知っていることすべてに基づけば、そのようなサイトをランクアップさせるTwiddlerやランクダウンさせるTwiddlerを追加することは難しくないでしょう。

「有益なコンテンツの更新」によって反発や中小企業の炎上を招いていることを考えると、この機能を使ってそれに対処しようとしているのは不思議です。

私の未解決の疑問

私はこの話題をずっと続けていくつもりですが、いったん休憩に入ります。その間、この情報漏洩について、他の人々が独自の結論を導き出すことは避けられないでしょう。現時点では、皆さんに考えていただきたいいくつかの疑問が残っています。

「Helpful Content Update」は「Baby Panda」と呼ばれているか?

Compressed Quality Signals には、「baby panda」と呼ばれるものの言及が 2 か所あります。Baby Panda は Twiddler であり、これは初期ランキング後の調整用です。

Pandaの上で使用できると記載されていますが、ドキュメントにはそれ以上の情報は記載されていません。

「有益なコンテンツの更新」はパンダと多くの点で共通しているという点については、概ね同意できると思います。参照クエリ、リンク、クリックを使用するシステムの上に構築されている場合、コンテンツを改良した後で重点的に取り組む必要があるのは、これらの点です。

NSRとはニューラル意味検索(Neural Semantic Retrieval)のことか?

命名規則の一部として、NSRを含むモジュールや属性への言及が数多くあります。その多くはサイトチャンクやエンベッディングに関連しています。Googleは以前、「ニューラルマッチング」を大きな改善点として議論していました。私の推測では、NSR はニューラル・セマンティック・リトリーバル(Neural Semantic Retrieval)の略で、これらはすべてセマンティック検索に関連する機能です。しかし、場合によっては「サイトランク」の隣に言及しています。

Googleの反逆児がgo/NSRにアクセスして、匿名メールアドレスなどから「あなたの言うとおりです」と私にメールを送ってくれるといいのですが。

実行可能なこと

先ほども申し上げましたが、私は皆さんに何か処方箋を与えるつもりはありません。しかし、戦略的なアドバイスならいくつかあります。

  1. ランド・フィッシュキンに謝罪を - PubConでの「Googleが私たちに嘘をついたことすべて」という基調講演以来、私はランドの名誉を回復するキャンペーンを続けています。ランドは、私たちの業界が発展するよう何年も努力を続けてきましたが、その努力はGoogle側からもSEO業界からも多くの非難を浴びました。時には物事を正しく理解できなかったこともありますが、彼の心は常に正しい場所にあり、私たちがやっていることを尊重され、より良くするために多大な努力をしてきました。特に、クリック実験から導き出した結論、Googleサンドボックスの存在を示すための彼の度重なる試み、Googleサブドメインを異なる方法でランク付けしていることを示すケーススタディ、そして長い間軽視されてきたGoogleがサイト全体にオーソリティスタイルシグナルを採用しているという彼の信念については、間違っていなかったと思います。また、この分析についても彼に感謝しなければなりません。なぜなら、私にその文書を見せてくれたのは彼だったからです。今こそ、皆さんで彼に愛情を示してあげる良い機会です
  2. 優れたコンテンツを作成し、それをうまく宣伝する – 冗談ですが、本気でもあります。Googleは、そのアドバイスを与え続けていますが、私たちはそれを実行不可能だと考えています。一部のSEO担当者にとっては、それは彼らのコントロールの及ばないことです。Googleに優位性をもたらすこれらの機能を見直してみると、優れたコンテンツを作成し、それが共鳴するオーディエンスに宣伝することが、これらの指標に最も大きな影響を与えることは明らかです。リンクとコンテンツの機能に関する指標は、確かにかなりの効果をもたらしますが、Googleで長期的に成功を収めたいのであれば、ランキングにふさわしいコンテンツを継続的に作成する必要があります。
  3. 相関性調査を復活させる – Google がランキングを構築する際に使用している機能の多くについて、現在ではより深い理解を得られるようになりました。クリックストリームデータと特徴抽出を組み合わせることで、以前よりも多くのことを再現できるようになりました。垂直方向に特化した相関性調査を復活させる時期が来たと思います。
  4. テストと学習 – 縦軸の可視性とトラフィックチャートを十分に目にしていれば、SEOに関する情報や意見は鵜呑みにできないことがお分かりでしょう。この情報漏洩は、ウェブサイトに何が有効かを判断するために、さまざまな意見を取り入れ、実際に試してみる必要があることを示すもう一つの例です。Googleがどのように機能しているかを推測するために、経験談や口コミを見るだけでは不十分です。貴社が SEO に関する実験計画を持っていないのであれば、今がその計画を始めるのに最適な時期です。

私たちは何をすべきかを知っている

ここから得られる重要な教訓は、SEO担当者は自分が何をしているのか分かっているということです。長年にわたり、私たちは間違っていると指摘されてきましたが、その裏側を見て、私たちがずっと正しかったことが分かったのは良いことです。また、これらの文書にはGoogleの仕組みに関する興味深いニュアンスがいくつかありますが、私がSEOを戦略的に行う方法に劇的な変化をもたらすようなものはありません。

これらの文書は、熟練した SEO 担当者が長年にわたって提唱してきたことを裏付けるために主に役立つでしょう。 ターゲットとなるユーザーを理解し、彼らが何を求めているかを特定し、それに沿った最善のものを提供し、技術的にアクセスしやすくし、ランキングが上がるまでプロモーションを行う。

SEOに携わる人の中で、自分が何をしているのかよくわからないという人は、テストを続け、学び続け、ビジネスを発展させ続けてください。Googleは私たちなしでは何もできません。

ランキング機能をダウンロード

誰かが、すべての機能をダウンロードしてスプレッドシートに整理してくれるでしょう。それは私かもしれません。四半期も残り1か月しかなく、とにかくMQLを増やしたいと思っています。😆

ランキング機能リストを入手してください。

まだ始まったばかり

私がSEOについて常に気に入っているのは、常に進化し続けるパズルのようなところだということです。そして、私たちの努力によってブランドが数十億ドルの利益を上げるのを支援するのは楽しいことですが、Googleの仕組みを分析することに関するあらゆる調査によって私の好奇心を満たすことは、非常に満足感があります。ついにそのベールを剥ぐことができたことは、大きな喜びでした。

今はこれくらいしかお伝えできませんが、何か見つけたらぜひ教えてください! 何か私に伝えたいことがある方は、ぜひご連絡ください。私を見つけるのは簡単ですよ!