媒體工具包

2024 年 6 月 05 日

一位匿名人士與我分享了數千份洩露的 Google 搜尋 API 文件;SEO 行業的每個人都應該看到它們


5月XNUMX日星期日,我收到一封電子郵件,寄件者聲稱自己獲得了Google搜尋部門內部洩露的大量API文件。電子郵件進一步聲稱,這些洩露文件已得到谷歌前員工的確認,並且這些前員工和其他人分享了有關谷歌搜尋運營的更多私人資訊。

他們的許多說法與Google員工多年來的公開聲明直接矛盾,特別是該公司一再否認採用以點擊為中心的用戶信號、否認在排名中單獨考慮子域名、否認為較新的網站提供沙盒、否認收集或考慮域名的年齡等等。

我當然心存疑慮。這位不願透露姓名的消息人士的說法似乎有些離奇——例如:

  • 在早期,Google的搜尋團隊意識到需要大量網路使用者的完整點擊流資料(瀏覽器存取的每個 URL),以提高其搜尋引擎的結果品質。

  • 一個名為「NavBoost」的系統(搜尋副總裁潘杜·納亞克在其司法部案件證詞中引用)最初從 Google 的工具列 PageRank 收集數據,而對更多點擊流數據的渴望成為創建 Chrome 瀏覽器(於 2008 年推出)的主要動機。

  • NavBoost 使用給定關鍵字的搜尋次數來確定趨勢搜尋需求、搜尋結果的點擊次數(我在 2013 年至 2015 年期間對此進行了多次實驗)以及長點擊與短點擊(我在 2015 年的這段影片中介紹了相關理論)。

  • Google 利用 cookie 歷史記錄、登入的 Chrome 資料和模式偵測(在洩漏中稱為「未壓縮」點擊與「壓縮」點擊)作為打擊手動和自動點擊垃圾郵件的有效手段。

  • NavBoost 也會根據使用者意圖對查詢進行評分。例如,達到一定的關注閾值以及對影片或圖片的點擊量,會觸發該查詢以及與 NavBoost 相關的查詢的影片或圖片特徵。

  • Google 會檢查主要查詢期間和之後的搜尋點擊次數和參與度(稱為「NavBoost 查詢」)。例如,如果許多用戶搜尋“Rand Fishkin”,但沒有找到 SparkToro,並立即將查詢更改為“SparkToro”,並在搜尋結果中點擊 SparkToro.com,那麼 SparkToro.com(以及提及“SparkToro”的網站)在“Rand Fishkin”關鍵字的搜尋結果中排名就會提升。

  • NavBoost 的數據用於在主機層面評估網站的整體品質(我的匿名消息來源推測,這可能是谷歌和 SEO 人員所說的「熊貓」)。這種評估結果可能是網站排名的提升,也可能是降級。

  • 在品質評估過程中,還會考慮其他次要因素,例如與非品牌搜尋查詢完全匹配的網域的懲罰(例如 mens-luxury-watches.com 或 milwaukee-homes-for-sale.net)、較新的「BabyPanda」分數和垃圾郵件訊號。

  • NavBoost 地理圍籬點擊資料會綜合考慮國家/地區、州/省/省級區域以及行動裝置和桌面裝置的使用情況。然而,如果谷歌缺少某些地區或用戶代理的數據,他們可能會將該流程普遍應用於查詢結果。

  • 在新冠疫情期間,Google對那些可能在新冠相關搜尋結果中排名靠前的網站使用了白名單。同樣,在民主選舉期間,谷歌對那些應該顯示(或降級)選舉相關資訊的網站使用了白名單。

而這些都只是冰山一角。

非凡的主張需要非凡的證據。雖然其中一些與谷歌/美國司法部案件中披露的信息重疊(其中一些內容您可以在2020年的這個帖子中閱讀),但許多信息都是新穎的,並暗示著內幕消息。

因此,上週五,即 24 月 XNUMX 日(在發送了幾封電子郵件之後),我與匿名消息人士進行了視訊通話。

更新(太平洋時間 5 月 28 日上午 10:00):匿名消息人士已決定挺身而出。這段影片公佈了其身份:Erfan Azimi,一位 SEO 從業者,EA Eagle Digital 的創始人。

在收到那封郵件和電話之前,我既沒見過也沒聽過Erfan。他要求我隱去他的身份,只引用了以下這段話:

雄鷹利用風暴達到難以想像的高度。
– 馬紹納·迪利瓦約

通話結束後,我確認了 Erfan 的工作經驗、我們在行銷界共同認識的人,以及他們聲稱與業內人士(包括谷歌員工)一起參加特定活動的一些細節,但我無法確認會議的細節或他們聲稱進行的討論的內容。

在通話中,Erfan 向我展示了洩密事件本身:超過 2,500 頁的 API 文檔,包含 14,014 個屬性(API 功能),這些屬性似乎來自谷歌內部的「內容 API 倉庫」。根據文件的提交歷史記錄,這些程式碼於 27 年 2024 月 7 日上傳到 GitHub,直到 2024 年 XNUMX 月 XNUMX 日才被刪除。 (註:由於本文在發布後經過編輯以反映 Erfan 的身份,因此下文中他被稱為「匿名消息來源」)。

該文件並未展示搜尋排名演算法中特定元素的權重等信息,也未證明排名系統中使用了哪些元素。但它確實展現了 Google 收集資料的驚人細節。以下是該文件格式的範例:

關於「好」點擊和「壞」點擊的洩露資料的螢幕截圖,包括點擊時長(即訪客在從 Google 搜尋結果點擊的網頁上停留了多長時間,之後才返回搜尋結果)

在向我介紹了幾個 API 模組後,消息來源解釋了他們的動機(圍繞透明度、要求谷歌承擔責任等)以及他們的希望:希望我發表一篇文章來分享這次洩密事件,揭示其中包含的許多有趣的數據,並駁斥谷歌員工「多年來一直在散佈」的一些「謊言」。

Google代表(Matt Cutts、Gary Ilyes 和 John Mueller)多年來否認在排名中使用基於點擊的用戶信號的聲明示例

這次 API 洩漏真實存在嗎?我們能相信嗎?

這個過程的下一個關鍵步驟是驗證 API 內容倉庫文件的真實性。因此,我聯繫了一些前谷歌員工朋友,分享了洩露的文檔,並徵求他們的看法。三位前Google員工回覆:其中一位表示,他們不願意查看或評論這些文件。另外兩位分享了以下內容(非正式且匿名):

  • “我在那裡工作的時候沒法接觸過這個代碼。但這看起來確實合法。”
  • “它具有 Google 內部 API 的所有特徵。”
  • “這是一個基於 Java 的 API。有人花了很多時間來遵循 Google 自己的內部文件和命名標準。”
  • “我需要更多時間來確定,但這與我熟悉的內部文件相符。”
  • “我從簡短的評論中沒有看到任何跡象表明這是不合法的。”

接下來,我需要協助分析和解讀文件中的命名約定以及更多技術細節。我之前接觸過一些 API,但距離我上次寫程式碼已經過去 20 年了,距離我專業從事 SEO 工作也過去 6 年了。因此,我聯繫了全球頂尖的技術 SEO 專家之一:iPullRank 的創辦人 Mike King。

在周五下午的 40 分鐘電話中,麥克回顧了洩露的文件並證實了我的懷疑:這似乎是來自谷歌搜尋部門內部的一套合法文件,包含大量有關谷歌內部運作的未經證實的信息。

2,500 份技術文檔,對於一個男人(他既是父親,又是丈夫,還是企業家)來說,一個週末就審閱完,實在是太不合理了。但這並沒有阻止麥克全力以赴。

他整理了一份關於谷歌 API 洩漏事件的極其詳細的初步審查報告,我將在下面的調查結果中進一步引用。他也同意參加 2024 月 8 日在華盛頓州西雅圖舉行的 SparkTogether XNUMX 大會,屆時他將更詳細地介紹這次洩漏事件的完整真相,並結合接下來幾個月的分析成果。

擔任此職位的資格和動機

在繼續之前,先聲明幾點:我不再從事 SEO 工作了。我的 SEO 知識和經驗已經過時六年多了。我缺乏技術專長或 Google 內部營運知識,無法分析 API 文件外洩並確認其真實性(因此我尋求了 Mike 的幫助以及前 Google 員工的意見)。

那為什麼要發表這個主題的文章呢?

因為當我與發送這些訊息的人交談時,我發現他們值得信賴、深思熟慮,而且知識淵博。儘管一開始我對此深表懷疑,但我沒有發現任何危險訊號,也沒有任何惡意動機。這個人的唯一目標似乎與我完全一致:要求谷歌對與私人談話和洩露文件相衝突的公開聲明負責,並提高搜尋行銷領域的透明度。而且他們認為,儘管我多年沒有從事SEO行業,但我仍然是公開分享這些資訊的最佳人選。

這些目標我近二十年來一直深切關注。雖然我的職業生涯已經改變了(我現在經營著兩家公司:SparkToro,一家開發受眾研究軟體的公司,以及Snackbar Studio,一家獨立電玩開發商),但我對搜尋引擎優化(SEO)領域的興趣和聯繫依然濃厚。我深感有義務分享關於這個全球主導搜尋引擎運作方式的信息,尤其是谷歌寧願保密的信息。遺憾的是,我不知道還能把這種可能具有開創性的東西分享給誰。

幾年前,在丹尼·沙利文離開新聞界擔任谷歌搜尋聯絡官之前,他曾是我在遇到如此重大洩密事件時會聯繫的信源。他擁有足夠的威嚴、履歷、知識和經驗來審查這樣的指控,並將其公正地呈現在公眾輿論的法庭上。過去幾年裡,我曾無數次希望丹尼能像他一樣,以冷靜、公正、對谷歌既強硬又公平的態度來處理這類有新聞價值的報道——這些報道甚至可以延伸到該公司在證人席上的陳述(例如,他那篇雄辯的文章,駁斥了谷歌關於有機關鍵詞數據隱私聲明的站不住腳的論調)。

無論谷歌付給他多少錢,都遠遠不夠。

親愛的讀者,抱歉,您不是丹尼,而是我。既然您是丹尼,我假設您可能不熟悉我的背景和資歷,所以請簡單介紹一下。

  • 我從 2001 年開始為西雅圖地區的小型企業做 SEO,並於 2003 年共同創立了 SEO 諮詢公司,即後來的 Moz(最初稱為 SEOmoz)。
  • 在接下來的15年裡,我從事搜尋行銷產業,並經常被公認為該領域頗具影響力的領導者。我撰寫/合著了《迷失與創辦人:新創企業世界痛苦而誠實的實地指南》、《SEO的藝術》以及《入站行銷與SEO》。
  • 包括《華爾街日報》、《Inc》、《福布斯》等數百家出版物都曾撰寫並引用過我在 SEO 和谷歌搜尋領域的文章,其中許多都引用了我主持了十年的熱門每週視頻系列:《白板星期五》。
  • 在 35,000 年出售給私募股權買家之前,Moz 的 SEO 軟體付費客戶數量已超過 50 名,營收超過 200 萬美元,團隊規模約為 2021 人。我於 2018 年離開並創辦了 SparkToro,並於 2023 年創立了 Snackbar Studio。
  • 我於 2001 年從華盛頓大學輟學,沒有獲得學位,但我在 Google 和 SEO 方面的工作成果被美國國會、美國聯邦貿易委員會、《華爾街日報》、《紐約時報》和約翰·奧利弗的《上週今夜秀》等數十家媒體引用。
  • 我擁有多項有關網頁規模連結索引設計的專利,並且是眾多連結索引指標的創建者,包括網域權威,這是一種基於機器學習的評分,常用於數位行銷領域,以評估網站在Google搜尋引擎中的排名能力。

好的。回到谷歌洩密事件。

什麼是 Google API 內容倉庫?

當瀏覽大量的 API 文件時,第一個合理的問題可能是:“這是什麼?它有什麼用?為什麼它存在?”

這次洩漏似乎來自 GitHub,其曝光的最可信解釋與我的匿名消息來源在通話中告訴我的一致:這些文檔是無意中短暫公開的(文檔中的許多鏈接指向私有的 GitHub 代碼庫和 Google 公司網站的內部頁面,需要特定的 Google 憑證登錄才能訪問)。在 2024 年 XNUMX 月至 XNUMX 月這段可能偶然的公開期間,API 文件被傳播到 Hexdocs(該網站索引公共 GitHub 程式碼庫),並被其他來源發現/傳播(我確信其他人有副本,但奇怪的是,直到現在我才找到任何公開討論)。

根據我之前接觸過的Google員工透露,幾乎每個谷歌團隊都有類似的文檔,解釋各種 API 屬性和模組,幫助專案工作人員熟悉可用的資料元素。此外洩的漏洞與公用 GitHub 程式碼庫和Google雲端 API 文件中的其他漏洞類似,使用了相同的符號樣式、格式,甚至流程/模組/功能的名稱和引用。

如果這聽起來像是個技術難題,那就把它想像成給Google搜尋引擎團隊成員的指示吧。它就像圖書館裡的書籍清單,某種卡片目錄,告訴那些需要了解哪些書可用以及如何取得的員工。

然而,圖書館是公共的,而Google搜尋卻是世界上最隱密、最嚴密保護的黑盒子之一。在過去的二十五年裡,Google搜尋部門從未發生過如此規模或細節的洩密事件。

我們能確定 Google 的搜尋引擎使用了這些 API 文件中詳述的所有內容嗎?

對此,各種解釋不一。谷歌可能已經淘汰了其中一些功能,將其他功能專門用於測試或內部項目,甚至可能開放了一些從未使用過的 API 功能。

然而,文件中提到了一些已棄用的功能,並特別註明了其他一些功能不應再使用。這強烈表明,截至2024年XNUMX月的洩漏事件,那些未標註此類細節的功能仍在使用中。

我們也無法確定三月洩漏的版本是否是該文件的最新版本。我在 API 文件中能找到的最新日期是 2023 年 XNUMX 月:

相關文字如下:

網站的網域級顯示名稱,例如 google.com 的顯示名稱為「Google」。更多詳情請參閱 go/site-display-name。自 2023 年 XNUMX 月起,此字段將被棄用,取而代之的是 info.[AlternativeTitlesResponse].site_display_name_response 字段,該字段還包含主機級網站顯示名稱及其他資訊。

理性的讀者會得出這樣的結論:截至去年夏天,該文件是最新的(其中還提到了 2023 年及之前幾年,甚至 2005 年的其他變化),甚至可能是截至 2024 年 XNUMX 月披露日期的最新文件。

谷歌搜尋顯然每年都在發生巨大的變化,而最近推出的一些功能,例如備受詬病的AI概覽,並沒有出現在此次洩密事件中。這次洩密事件中提到的哪些內容目前仍在Google的排名系統中積極使用?這還有待進一步的推測。這份寶庫包含一些引人入勝的參考資料,其中許多內容對於非谷歌搜尋工程師來說可能是全新的。

但是,我強烈建議讀者不要指著這次洩密事件中的某個 API 功能說:「看!這證明谷歌在排名中使用了 XYZ 演算法。」這並非鐵證。這是一個強有力的證據,比專利申請或谷歌員工的公開聲明更有力,但仍然不能保證。

話雖如此,自從去年谷歌高層在司法部審判中作證以來,這幾乎是確鑿的證據。說到那份證詞,正如麥克在他的貼文中所詳述的那樣,其中許多內容在洩漏的文件中得到了證實和擴展。 👀

我們可以從資料倉儲洩漏事件中學到什麼?

我預計未來幾年內,人們將從這海量文件中挖掘出一些有趣且適用於行銷的見解。它實在是太大太密集了,不可能只花一個週末瀏覽就能挖掘出一套完整的結論,甚至可能接近完整的結論。

不過,我將分享我仔細研讀的五個最有趣的早期發現,其中一些揭示了谷歌長期以來被認為在做的事情,另一些則表明該公司的公開聲明(尤其是關於他們“收集”什麼的聲明)是錯誤的。由於這樣做會很冗長,而且可能會被視為個人恩怨(考慮到谷歌過去對我工作的攻擊),所以我不會費心對比谷歌員工的言論和這份文件所暗示的內容。此外,麥克在他的文章中已經做得很好了。

相反,我將重點介紹有趣和/或有用的要點,以及我從所能審查的全部模組中得出的結論、邁克關於洩密事件的文章,以及這如何與我們所知的有關谷歌的其他事情結合起來。

#1:Navboost 以及點擊次數、點擊率、長點擊與短點擊以及用戶資料的使用

文件中的一些模組提到了諸如“goodClicks”、“badClicks”、“lastLongestClicks”、展示次數、壓縮點擊、未壓縮點擊和獨角獸點擊等功能。這些功能與 Navboost 和 Glue 相關,對於看過Google司法部證詞的人來說,這兩個詞可能很熟悉。以下是司法部律師 Kenneth Dintzer 對搜尋品質團隊搜尋副總裁 Pandu Nayak 進行交叉質疑的相關摘錄:

Q:那麼提醒我一下,navboost 是 2005 年的嗎?
答:大概在這個範圍內。甚至可能更早。

Q:它已經更新了。它不再是之前那個舊的導航助推器了?
答:不。

Q:還有一個是膠水,對嗎?
答:Glue 只是 navboost 的另一個名稱,它包含頁面上的所有其他功能。

問:好的。我本來打算晚點再說,但現在就可以了。 Navboost 會提供網頁搜尋結果,就像我們之前討論的那樣,對吧?
答:是的。

Q:Glue 能完成頁面上除網頁結果之外的所有其他操作,對嗎?
答:正確。

Q:它們一起幫助我們找到內容並對最終出現在我們的 SERP 上的內容進行排名?
答:確實如此。它們都是這方面的信號,是的。

這些 API 文件的精明讀者會發現它們支持 Nayak 先生的證詞(並與 Google 的網站品質專利一致):

優質 Navboost 資料模組
Navboost 資料的地理細分
Navboost 中的點擊訊號
資料老化展示次數與點擊次數

谷歌似乎有辦法過濾掉他們不想計入排名系統的點擊,並把那些他們想計入的點擊也計入其中。他們似乎也會衡量點擊時間(例如,跳轉——搜尋者點擊某個結果後,由於對找到的答案不滿意而迅速點擊了返回按鈕)和展示次數。

關於Google如何使用點擊數據,已經有很多文章進行了探討,我就不再贅述。重要的是,谷歌已經明確並描述了該衡量指標的功能,這無疑為數據提供了更多證據。

#2:利用 Chrome 瀏覽器點擊串流來支援 Google 搜索

我的匿名消息來源聲稱,早在2005年,谷歌就想獲得數十億網路用戶的完整點擊流數據,而現在,透過Chrome,他們實現了這個願望。 API文件顯示,Google計算了幾種類型的指標,這些指標可以透過Chrome瀏覽器存取單一頁面和整個網域的瀏覽量來呼叫。

這份文件描述了 Google 如何建立網站連結的功能,尤其值得關注。它展示了一個名為 topUrl 的調用,意思是「列出 two_level_score 最高的頂級 URL,例如 chrome_trans_clicks」。我的理解是,Google 很可能使用了 Chrome 瀏覽器中頁面的點擊次數,並以此來確定網站上最受歡迎/最重要的 URL,從而決定哪些 URL 應該被納入網站連結功能。

#3:旅遊、新冠疫情和政治領域的白名單

「優質旅遊網站」模組會讓理性的讀者得出結論,谷歌在旅遊領域存在一個白名單(尚不清楚這是否僅限於谷歌的「旅遊」搜尋標籤,還是更廣泛的網路搜尋)。文章中多處提到「isCovidLocalAuthority」和「isElectionAuthority」的標記,進一步顯示Google正在將某些特定網域列入白名單,這些網域適合用於顯示極具爭議或可能有問題的查詢。

例如,在 2020 年美國總統大選之後,一位候選人聲稱(沒有證據)選舉被竊取,並鼓勵其追隨者衝擊國會並對立法者採取潛在的暴力行動,即發動叛亂。

谷歌幾乎肯定會成為人們獲取有關此次事件資訊的首選網站之一,如果他們的搜尋引擎返回的是錯誤描述選舉證據的宣傳網站,這可能會直接導致更多爭議、暴力,甚至美國民主的終結。我們這些希望自由公正選舉得以延續的人應該非常感謝谷歌工程師在這種情況下使用白名單。

品質 NSR 資料屬性
音樂過濾器的助手 API 設定
影片內容搜尋查詢功能
優質旅遊網站數據模組

#4:採用品質評估員回饋

谷歌早就有一個名為 EWOK 的品質評級平台(SEO 領域的著名領導者 Cyrus Shepard 花了數年時間致力於此,並在此撰寫了相關文章)。現在我們有證據表明,搜尋系統使用了品質評級人員提供的一些數據。

這些基於評分員的訊號究竟有多大影響力,以及它們究竟有何用途,我初讀時並不清楚,但我猜想一些深思熟慮的SEO偵探會深入調查此次洩密事件,了解情況並發布更多相關信息。令我著迷的是,EWOK品質評分員產生的評分和數據可能直接用於Google的搜尋系統,而不僅僅是實驗的訓練集。當然,這些評分和數據也可能“僅用於測試”,但當你瀏覽洩露的文件時,你會發現,如果情況屬實,註釋和模組細節中會明確指出。

這個工具會根據透過 EWOK 進行的評估,給予「每個文件的相關性評級」。雖然沒有詳細的符號,但邏輯上很容易理解,就能想像這些人工評估對網站的重要性。

這一條提到了“人工評級(例如來自 EWOK 的評級)”,並指出它們“通常只填充在評估流程中”,這表明它們可能主要是該模組中的訓練數據(我認為這仍然是一個非常重要的角色,營銷人員不應該忽視質量評估員對其網站的良好認知和評級的重要性)。

Webref 提及評級模組
Webref 任務資料模組
文檔級相關性模組
Webref per Doc 相關性評級模組
Webref 實體連接

#5:Google使用點擊數據來確定如何在排名中加權鏈接

這則訊息非常有趣,直接來自最初分享洩密訊息的匿名人士。用他們的話來說:「Google有三個桶子/層級來對其連結索引進行分類(低、中、高品質)。點擊資料用於確定文件屬於哪個連結圖索引層級。請參閱此處的「SourceType」和此處的「TotalClicks」。總結如下:

  • 如果 Forbes.com/Cats/ 沒有點擊,它將進入低品質索引,並且連結將被忽略
  • 如果 Forbes.com/Dogs/ 擁有大量來自可驗證裝置的點擊量(所有先前討論過的 Chrome 相關資料),它就會進入高品質索引,並且連結會傳遞排名訊號

一旦連結因為屬於更高級別的索引而變得“可信”,它就可以提升 PageRank 和錨文本,或者被垃圾連結系統過濾/降級。來自低品質連結索引的連結不會損害網站的排名;它們只是被忽略而已。

關注自然搜尋流量的行銷人員應了解的要點

如果您在策略層面上關注自然搜尋流量的價值,但對Google運作的技術細節不太了解,那麼本節正適合您。我試圖總結這次洩密事件涵蓋的時期(2005 年至 2023 年)谷歌的大部分演變,我不會只限於洩密事件中已確認的要素。

  1. 品牌比什麼都重要
    Google 擁有眾多方法來識別、排序、排名、篩選和使用實體。這些實體包括品牌(品牌名稱、其官方網站、關聯的社群帳號等)。正如我們在與 Datos 合作的點擊流研究中發現的那樣,Google 一直在走一條不可阻擋的道路,那就是只給那些在網絡上佔據主導地位的大型、實力雄厚的品牌排名並輸送流量,而不是小型、獨立的網站和企業。

    如果我對那些尋求大幅提高自然搜尋排名和流量的行銷人員有一個普遍的建議,那就是:“在谷歌搜尋之外的領域,打造一個知名、受歡迎、知名度高的品牌。”

  2. 經驗、專業知識、權威性和可信度(「EEAT」)可能不像一些 SEO 人員想像的那麼直接重要。
    到目前為止,我們在洩密文件中發現的唯一提及主題專業知識的,是關於谷歌地圖評論貢獻的簡短說明。 EEAT 的其他方面要么被埋沒、間接地、以難以識別的方式標記,要么更有可能(在我看來)與谷歌使用和關注的內容相關,但與排名系統的具體元素無關。

    正如麥克在他的文章中指出,洩漏的文件表明谷歌可以識別作者,並將其視為系統中的實體。在網路上建立作者影響力確實可能帶來Google排名優勢。但排名系統中究竟是什麼構成了“EEAT”,以及這些元素的威力究竟有多大,這仍是一個懸而未決的問題。我有點擔心EEAT是80%的宣傳,20%的實質內容。正如HouseFresh最近一篇廣為流傳的文章所詳述的那樣,許多強大的品牌在谷歌排名中名列前茅,但卻缺乏經驗、專業知識、權威性和可信度。

  3. 當使用者有導航意圖(以及意圖創建的模式)時,內容和連結是次要的。
    舉個例子,假設西雅圖地區的許多人搜尋“雷曼兄弟”,並滾動到搜尋結果的第2、3或4頁,直到找到雷曼兄弟舞台劇的劇院列表,然後點擊該結果。谷歌很快就會知道,這就是該地區搜尋這些字詞的用戶想要的內容。

    即使維基百科上有關雷曼兄弟在 2008 年金融危機中所扮演角色的文章投入巨資進行鏈接建設和內容優化,它們的排名也不可能超過西雅圖劇院觀眾的用戶意圖信號(根據查詢和點擊計算得出)。

    將這個例子擴展到更廣泛的網路和整個搜尋領域,如果你能在目標地區吸引足夠多的潛在搜尋者,為你的網站創造需求,你或許就能擺脫對經典站內站外 SEO 訊號(例如連結、錨文本、優化內容等)的需求。 Navboost 的強大功能和用戶的意圖可能是Google系統中最強大的排名因素。正如Google副總裁亞歷山大·格魯舍茨基 (Alexander Grushetsky) 在 2019 年發給其他谷歌高管(包括丹尼·沙利文 (Danny Sullivan) 和潘杜·納亞克 (Pandu Nayak))的電子郵件中所說:

    我們已經知道,在特定指標上,單一訊號可能比整個系統更強大。例如,我非常確定 NavBoost 本身對點擊量(甚至可能在精準度/實用性指標上)的影響比其他排名因素更積極(順便說一句,Navboost 團隊以外的工程師也曾對 Navboost 的強大功能以及它“竊取勝利”的事實感到不滿)。

    那些尋求更多確認的人可以查看谷歌工程師 Paul Haahr 的詳細簡歷,其中指出:

    我負責基於日誌的排名項目。團隊目前的工作重點分為四個面向:1)Navboost。這已經是谷歌最強大的排名訊號之一。目前的工作重點是自動化建立新的 navboost 數據;


  4. 經典的排名因素:PageRank、錨文本(基於連結錨文本的主題PageRank)和文字匹配,這些因素的重要性多年來一直在下降。但頁面標題仍然非常重要。
    這是 Mike 出色分析的發現,如果不在這裡指出來,那就太愚蠢了。 PageRank 似乎仍然在搜尋索引和排名中佔有一席之地,但它幾乎可以肯定是從 1998 年的原始論文演變而來的。此文件洩露暗示,多年來,PageRank 的多個版本(rawPagerank,一個已棄用的引用“最近種子”的 PageRank,以及文檔首次提供時的 firstCoveragePageRank 等等)被創建和廢棄。此外,雖然洩露文件中確實存在錨文本鏈接,但它們似乎並不像我早年從事 SEO 工作時所預期的那樣重要或無處不在。


  5. 對於大多數中小型企業和較新的創作者/出版商來說,除非您在大量受眾中建立信譽、導航需求和良好聲譽,否則 SEO 的回報可能並不理想。
    SEO 是大品牌和熱門域名的遊戲。作為一名企業家,我並沒有忽視 SEO,但我強烈預計,在未來幾年裡,除非 SparkToro 成為行業內規模更大、更受歡迎、搜尋量和點擊量更高的品牌,否則這個網站的排名將繼續被那些存在了十多年的聚合器和發布商超越,即使是原創內容。

    對於其他創作者、出版商和中小企業來說,這幾乎肯定是事實。如果存在擁有知名品牌的大型熱門網站的競爭,你創作的內容不太可能在谷歌上取得好成績。谷歌不再獎勵那些精明強幹、聰明伶俐、精通SEO、掌握所有技巧的經營者。他們獎勵的是知名品牌、可搜尋衡量的知名度,以及搜尋者已知並點擊的知名網域。從1998年到2018年左右,人們可以合理地利用Google的SEO來啟動強大的行銷飛輪。但到了2024年,我認為這並不現實,至少在競爭激烈的英語網路領域是如此。


搜尋產業的下一步

我很高興看到那些擁有更豐富經驗和更深入技術知識的從業人員如何分析這次洩密事件。我鼓勵任何有興趣的人深入研究這份文件,嘗試將其與其他公開文件、聲明、證詞和排名實驗聯繫起來,然後發表他們的研究成果。

歷史上,一些搜尋行業最響亮的聲音和最活躍的出版商樂於不加批判地重複谷歌的公開聲明。他們寫的標題是“谷歌稱XYZ是真的”,而不是“谷歌聲稱XYZ;證據表明並非如此”。

請做得更好。如果這次洩密和司法部的審判能帶來哪怕一絲改變,我希望就是這個。

當初入行的新手閱讀搜尋引擎圓桌會議 (Search Engine Roundtable)、搜尋引擎土地 (Search Engine Land)、搜尋引擎期刊 (SE Journal) 以及眾多報道 SEO 領域新聞的機構部落格和網站時,他們並不一定知道該如何認真對待谷歌的聲明。記者和作者不應假設讀者足夠精明,能夠知道谷歌官方代表過去數十甚至數百條公開評論後來都被證明是錯誤的。

這項義務不僅是為了幫助搜尋產業,也是為了幫助全世界。谷歌是全球資訊和商業傳播領域最強大、最具影響力的力量之一。直到最近,他們才開始受到政府和記者的追究。搜尋行銷領域的記者和作家的工作在輿論場、民選官員的議事廳以及谷歌員工的心中都舉足輕重,他們都有能力改變現狀,或者忽視現狀,讓我們共同承擔風險。

感謝 Mike King 對這篇文件洩露事件提供的寶貴幫助,感謝 Amanda Natividad 的編輯幫助,以及向我分享此洩露信息的匿名消息來源。隨著本文被更多人知曉,我預計其更新將在未來幾天或幾週內發布。如果您有任何發現支持或反駁我在此陳述的內容,請在下方評論區分享。

版權所有 2024 SparkToro®。保留所有權利。來源:https://sparktoro.com。作者:Rand Fishkin。

若要查看所有文章,請造訪網路旅遊監測檔案庫。