这篇文章上次修改于 555 天前，可能其部分内容已经发生变化，如有疑问可询问作者。

Menu
Published on May 27, 2024
谷歌搜索秘籍泄漏：揭秘内部工程文档 [译]
原文：Secrets from the Algorithm: Google Search’s Internal Engineering Documentation Has Leaked
探索你一直渴望了解的谷歌算法的秘密。

谷歌，如果你正在阅读这篇文章，那一切都已无法挽回。😉

好吧，让我们开始吧。谷歌搜索内容库 API 的内部文档不慎泄露。谷歌内部的微服务体系与谷歌云平台所提供的服务相似，其已废弃的文档 AI 仓库的内部文档不小心被公开到了客户端库的代码仓库中。该代码的文档也被外部的自动化文档服务记录下来。

根据变更历史，这一错误已在 5 月 7 日得到修正，但相关的自动化文档依然可以访问。为了避免潜在的法律责任，我不会在这里提供直接链接，但是因为该仓库中的所有代码都是根据Apache 2.0 许可发布的，任何人都可以自由地使用、修改并分发这些代码。

谷歌内部版本的已废弃文档 AI 仓库的文档截图，意外泄露了内容库的信息
谷歌内部版本的已废弃文档 AI 仓库的文档截图，意外泄露了内容库的信息

我已经审阅了 API 参考文档，并将其与过往的谷歌泄露事件以及美国司法部的反垄断证词进行了对比。我还结合了即将出版的《SEO 科学》(The Science of SEO) 中进行的广泛专利和白皮书研究。虽然我所审查的文档中没有谷歌评分算法的具体细节，但它提供了关于存储内容、链接和用户互动数据的丰富信息，以及关于这些数据如何被操作和保存的详尽描述，从而揭示了一系列的特征。

你可能会想把这些广泛地称为“排名因素 (ranking factors)”，但这样说并不精确。确实，很多因素都影响排名，但也有很多不影响。在这里，我将根据自己的广泛研究和这些年谷歌告诉或误导我们的信息，对一些我在初步审查这个庞大数据泄露后发现的最有趣的排名系统和特点进行解读。

虽然“说谎”这个词听起来很严厉，但在这里它是最准确的描述。我不完全责怪谷歌的公开代表保护公司的机密信息，但我确实不满他们试图贬低那些在营销、科技和新闻行业做出了可以验证的发现的人们。对未来的谷歌发言人的一个建议：有时候，最好的回答就是“我们无可奉告”。你的诚信至关重要。当出现像这样的信息泄露和像司法部审判那样的证词时，公众对你们未来的声明的信任将荡然无存。

注意事项
我们都清楚，总会有人试图质疑我基于这次泄露资料所作的分析和结论。他们可能会质疑这些发现的重要性，甚至说“这些我们早就知道了。”因此，让我们在探讨更多精彩内容之前，先明确一些可能的质疑。

时间和背景受限 – 假日周末的时间限制使我只能投入约 12 小时来深入研究这些内容。在此，我非常感激那些匿名的朋友们，他们的见解帮助我迅速了解了情况。类似于我去年报道的 Yandex 泄露案，我没有一个完整的视角。对于 Yandex，我们分析了源代码但缺少背后的逻辑；而这次，我们掌握了一些功能和模块背后的逻辑，却没有源代码。请原谅我现在以较为非结构化的方式分享这些内容，等到我对这些材料有了更深入的理解后，我将提供更有条理的解读。
无评分机制 – 我们不清楚各种特征在后续评分机制中的权重。我们不确定所有可用资源是否都被利用。我们知道某些功能已经过时。除非有明确的说明，我们无法知道具体的应用情况。我们不知道整个流程中的各个环节。现在我们了解了一系列名为排名系统的程序，这些大体符合 Google 的解释、SEO 观察到的现场排名情况及专利申请和信息检索的文献描述。这次泄露让我们对考虑中的内容有了更清晰的认识，这将指导我们在 SEO 中应重视和忽略什么。
这可能是序列文章的开端 – 这篇文章是我对审查材料的初步尝试。随着我继续挖掘更多细节，我可能会发表更多后续文章。我预计这篇文章将激发 SEO 社区竞相解析这些文档，未来几个月我们将共同揭示和重新解读这些信息。
这是最新信息 – 据我所知，这次泄露展示了截至 2024 年 3 月的 Google 搜索内容存储的当前活跃架构。根据提交历史，相关代码于 2024 年 3 月 27 日推出，直到 2024 年 5 月 7 日才被撤销。（预计 Google 的公关人员会否认这一点，但我们就不必过多纠结这个了。）
A screenshot of the repository commits with visual proof that the information was committed on May 7th 2024.
A screenshot of the repository commits with visual proof that the information was committed on May 7th 2024.

相关性不等于因果关系 – 实际上，这一点在此处并不适用，但我还是想确保一切都考虑周全。
API 文档覆盖了 2,596 个模块，其中涉及多达 14,014 个特性，例如以下展示的这些：

API 文档的截图，展示文本内容：GoogleApi.ContentWarehouse.V1.Model.CompressedQualitySignals，这是一条含有被压缩且包含在 Mustang 和 TeraGoogle 中的各文档信号的信息。对于 TeraGoogle, 这些信息被包含在 perdocdata 中，意味着它们可以用于初步的评分过程。注意：在 TeraGoogle 中，这些数据被存储在有限的服务内存（Flash 存储）中，用于庞大数量的文档处理。接下来的 ID 为 43，属性包括： ugcDiscussionEffortScore (类型：整数，默认值：无) - UGC 页面质量信号，数值放大一千倍后向下取整。 productReviewPPromotePage (类型：整数，默认值：无) - 产品评价页面的推广分数。 experimentalQstarDeltaSignal (类型：数字，默认值：无) - 此字段不在分片间传播，而是在服务时根据实验性 nsr 团队的数据进行填充。此字段的主要用途是供实验性 Q 组件读取，以便快速实施新的 delta 组件测试（详见 go/oDayLEs）。 productReviewPDemoteSite (类型：整数，默认值：无) - 产品评论的降级/提升信号，数值放大一千倍后向下取整。 experimentalQstarSiteSignal (类型：数字，默认值：无) - 此字段不在分片间传播，而是在服务时根据实验性 nsr 团队的数据进行填充。此字段的主要用途是供实验性 Q 组件读取，以便快速实施新的站点组件测试（详见 go/oDayLEs）。 exactMatchDomainDemotion (类型：整数，默认值：无) - 页面质量信号，来源于 proto QualityBoost 的字段转换，以节省索引空间。
API 文档的截图，展示文本内容：GoogleApi.ContentWarehouse.V1.Model.CompressedQualitySignals，这是一条含有被压缩且包含在 Mustang 和 TeraGoogle 中的各文档信号的信息。对于 TeraGoogle, 这些信息被包含在 perdocdata 中，意味着它们可以用于初步的评分过程。注意：在 TeraGoogle 中，这些数据被存储在有限的服务内存（Flash 存储）中，用于庞大数量的文档处理。接下来的 ID 为 43，属性包括： ugcDiscussionEffortScore (类型：整数，默认值：无) - UGC 页面质量信号，数值放大一千倍后向下取整。 productReviewPPromotePage (类型：整数，默认值：无) - 产品评价页面的推广分数。 experimentalQstarDeltaSignal (类型：数字，默认值：无) - 此字段不在分片间传播，而是在服务时根据实验性 nsr 团队的数据进行填充。此字段的主要用途是供实验性 Q 组件读取，以便快速实施新的 delta 组件测试（详见 go/oDayLEs）。 productReviewPDemoteSite (类型：整数，默认值：无) - 产品评论的降级/提升信号，数值放大一千倍后向下取整。 experimentalQstarSiteSignal (类型：数字，默认值：无) - 此字段不在分片间传播，而是在服务时根据实验性 nsr 团队的数据进行填充。此字段的主要用途是供实验性 Q 组件读取，以便快速实施新的站点组件测试（详见 go/oDayLEs）。 exactMatchDomainDemotion (类型：整数，默认值：无) - 页面质量信号，来源于 proto QualityBoost 的字段转换，以节省索引空间。

这些模块关联到 YouTube、Assistant、Books、视频搜索、链接、网页文档、爬取架构、一个内部的日历系统，以及 People API 的组件。像 Yandex 一样，谷歌的系统依赖一个庞大的单一存储库（或称“monorepo”）运行，其服务器则在一个共享的环境中工作。这表示所有的代码都汇集于一处，任何网络中的机器都可能成为谷歌系统的一部分。

泄漏的文件详细描述了 API 的各个模块，并把它们按照摘要、类型、函数和属性进行分类。我们主要看到的是各种协议缓冲区（或 protobufs）的属性定义，这些定义通过排名系统进行访问，用以生成 SERPs（搜索引擎结果页面，即谷歌在用户查询后展示的结果）。

遗憾的是，许多摘要中引用了 Go 链接，这些链接是谷歌公司内网中的 URL，用以提供系统各个方面的更多细节。但若没有谷歌的正确登录凭证来访问这些页面（几乎肯定需要是搜索团队的现任成员），我们只能自行解读。

谷歌的 API 文档揭示了其不实之处
谷歌的代表为了控制 SEO 专家的行为，采取了误导性的表述来解释其系统的运作方式。我不愿意用“社会工程”来描述这种行为，因为这个词背负着复杂的历史。我们不如将其称为“操纵感知”。谷歌的公开声明可能并非有意撒谎，而是试图通过误导潜在的垃圾邮件发送者以及许多合法的 SEO 专家，从而混淆他们对影响搜索结果的理解。

以下是我基于谷歌员工的言论和文档中的事实，提供的一些观点，以供您判断：

“我们不认同域名权威的概念”

谷歌的发言人多次声称他们不采用“域名权威”。我一直认为这是一种通过遗漏和模糊表述的误导。

当他们说不使用域名权威时，他们的意思可能是他们不使用 Moz 定义的“域名权威”这一指标。他们也可能指的是不衡量与网站相关的特定主题的权威性或重要性。这种通过语义游戏引起的混淆使他们可以避免直接回答是否计算或使用整站权威度指标的问题。

谷歌搜索团队的分析师加里·伊莱斯（Gary Ilyes）多次重申这一点。

图 1: 该图像是一次 Twitter 对话的截图。对话包括三条推文，讨论了回链对域名权威的影响。推文内容如下：2016 年 10 月 27 日，//Andrew Rodgers (@AndyNRodgers) 发推问：“@JohnMu，一个指向 jpg URL 的回链在算法中的影响是否与静态 URL 相同？@methode”参与度：1 赞，2 转发；他在回复中提问：“对于整体域名权威而言，一个指向 jpg URL 的回链是否和指向网页 URL 的一样有影响？”参与度：1 赞；Gary Illyes (@methode) 回复说：“我们真的没有‘整体域名权威’。不过，带锚文本的文本链接更佳。”时间戳显示为 2016 年 10 月 27 日上午 8:34，地点为印尼 Kebayoran Lama。

加里并不是孤例。约翰·穆勒，一个专注于协调 Google 搜索关系的搜索倡导者，在这段视频中明确表示：“我们没有网站权威分数。”

实际上，在 Google 的压缩质量信号中，有一个基于每个文档存储的功能，它计算了一个名为“siteAuthority” (网站权威) 的特性。

本图像展示了一个技术文档的片段，描述了“siteAuthority”属性。标题：siteAuthority 类型：integer(), 默认值：nil 描述：site_authority: 源自 quality_nsr.SiteAuthority，在 Qstar 中应用。
本图像展示了一个技术文档的片段，描述了“siteAuthority”属性。标题：siteAuthority 类型：integer(), 默认值：nil 描述：site_authority: 源自 quality_nsr.SiteAuthority，在 Qstar 中应用。

我们不确定这个指标是如何计算或在后续评分机制中如何使用的，但我们现在可以确定地说，它确实存在并被应用在 Q* 排名系统中。看来，Google 确实有一个整体的域名权威度。Google 员工可能会说“我们拥有它，但不使用它”，或者“你可能不了解它的含义”，或者……好吧，我说过要“限制评论”的，不是吗？让我们继续。

“我们不用点击量来排名”

这个说法现在可以彻底澄清了。

潘杜·奈亚克在司法部反垄断审判中的证词最近透露了 Glue 和 NavBoost 排名系统的存在。NavBoost 是一个利用点击数据来提升、降低或在 Web 搜索中加强某些结果的系统。奈亚克指出，Navboost 从 2005 年开始使用，之前是用 18 个月的点击数据。这个系统最近改为用 13 个月的数据，并且主要针对网页搜索结果，而 Glue 系统则关联于其他的通用搜索结果。即便在这些信息公开之前，我们已经有了一些专利（包括 2007 年的基于时间的排名专利），这些专利明确指出如何使用点击日志来修改搜索结果。

我们还知道，点击作为衡量成功的一个标准是信息检索领域的最佳实践。Google 已经转向使用机器学习算法，这种算法需要响应变量来优化性能。尽管有如此多的明确证据，但由于 Google 发言人的误导和搜索营销界无批判地重复 Google 公开声明的做法，SEO 社区中仍然存在很大的困惑。

加里·伊利耶斯（Gary Ilyes）多次讨论过这个点击测量的问题。他在一次讲话中强调了谷歌搜索工程师保罗·哈尔（Paul Haahr）在2016 年 SMX West 的演讲里提到的观点，即“在排名中直接使用点击量是不妥的。”

后来，他还在一个讲座上公开批评了 Rand Fishkin（Moz 的创始人兼 CEO，资深 SEO 专家），直言“不论 Fishkin 的新理论如何，逗留时间和点击率等通常都是纯粹的胡说八道。”

Reddit 帖子的截图，帖子是由用户名为 "garyillyes" 的 Gary Illyes 发布，他在回应名为 Lyndon 的用户。这是一串讨论的一部分，获得了 36 个赞、一个奖项以及其他 24 条回复。帖子的文本内容如下：garyillyes OP • 5 年前 嘿 Lyndon！我会迅速回答你，因为我在等飞机，有点无聊（原本计划明天回答问题）。RankBrain 是一个吸引公众关注的机器学习排名组件，它利用历史搜索数据预测用户对未知查询最可能的点击选择。这是一个卓越的工程成就，它在传统算法无法处理的情况下多次帮助我们脱险，例如算法会忽视查询中的 'not'。然而，它通常依赖于结果页面上（有时）几个月前的数据，而非实际着陆页面的数据。逗留时间、点击率（CTR）及 Fishkin 的最新理论，这些通常是无根据的说法。搜索实际上比大多数人认为的要简单。文本中的“逗留时间、点击率（CTR）及 Fishkin 的最新理论，这些通常是无根据的说法。搜索实际上比大多数人认为的要简单。”部分被黄色高亮显示。
Reddit 帖子的截图，帖子是由用户名为 "garyillyes" 的 Gary Illyes 发布，他在回应名为 Lyndon 的用户。这是一串讨论的一部分，获得了 36 个赞、一个奖项以及其他 24 条回复。帖子的文本内容如下：garyillyes OP • 5 年前 嘿 Lyndon！我会迅速回答你，因为我在等飞机，有点无聊（原本计划明天回答问题）。RankBrain 是一个吸引公众关注的机器学习排名组件，它利用历史搜索数据预测用户对未知查询最可能的点击选择。这是一个卓越的工程成就，它在传统算法无法处理的情况下多次帮助我们脱险，例如算法会忽视查询中的 'not'。然而，它通常依赖于结果页面上（有时）几个月前的数据，而非实际着陆页面的数据。逗留时间、点击率（CTR）及 Fishkin 的最新理论，这些通常是无根据的说法。搜索实际上比大多数人认为的要简单。文本中的“逗留时间、点击率（CTR）及 Fishkin 的最新理论，这些通常是无根据的说法。搜索实际上比大多数人认为的要简单。”部分被黄色高亮显示。

事实上，NavBoost (Navboost) 拥有一个完全专注于点击信号的模块。

该模块被定义为用于“Craps 排名系统”的点击和展示信号。如下所述，包括不良点击、优质点击、持续时间最长的点击、未压缩点击和未压缩持续时间最长的点击在内的各种点击都被作为衡量指标。根据 Google 的“基于位置突出性对本地搜索结果进行评分”的专利 (US8046371B2)，压缩是一种防止单一大信号主导其他信号的机制。换言之，系统通过规范点击数据来确保不会出现基于点击信号的操纵。Google 员工指出，专利和白皮书中描述的系统并不一定反映实际投入使用的系统，但如果 NavBoost 不是 Google 信息检索系统的核心部分，那么其存在将毫无意义。

本图展示了涉及多个点击相关属性的技术文档。每个属性都明确了其类型和默认值。文本内容如下：坏点击（badClicks）类型：float(), 默认值：nil；点击（clicks）类型：float(), 默认值：nil；好点击（goodClicks）类型：float(), 默认值：nil；展示次数（impressions）类型：float(), 默认值：nil；上次最长点击（lastLongestClicks）类型：float(), 默认值：nil；独角兽点击（unicornClicks）类型：float(), 默认值：nil - 与独角兽用户事件相关的点击子集；未压缩点击（unsquashedClicks）类型：float(), 默认值：nil - 在当前格式中未填充，使用了两种 CrapsClickSignals（压缩/未压缩）。我们正在迁移到一个新的格式，在那里这个字段将被填充。未压缩展示次数（unsquashedImpressions）类型：float(), 默认值：nil - 同上。未压缩的最长点击（unsquashedLastLongestClicks）类型：float(), 默认值：nil - 同上。
本图展示了涉及多个点击相关属性的技术文档。每个属性都明确了其类型和默认值。文本内容如下：坏点击（badClicks）类型：float(), 默认值：nil；点击（clicks）类型：float(), 默认值：nil；好点击（goodClicks）类型：float(), 默认值：nil；展示次数（impressions）类型：float(), 默认值：nil；上次最长点击（lastLongestClicks）类型：float(), 默认值：nil；独角兽点击（unicornClicks）类型：float(), 默认值：nil - 与独角兽用户事件相关的点击子集；未压缩点击（unsquashedClicks）类型：float(), 默认值：nil - 在当前格式中未填充，使用了两种 CrapsClickSignals（压缩/未压缩）。我们正在迁移到一个新的格式，在那里这个字段将被填充。未压缩展示次数（unsquashedImpressions）类型：float(), 默认值：nil - 同上。未压缩的最长点击（unsquashedLastLongestClicks）类型：float(), 默认值：nil - 同上。

这些基于点击的指标也在另一个与索引信号相关的模块中出现。其中一个指标是记录给定文档的“最后一个好点击”的日期。这显示了内容衰减（或流量随时间减少）同样是排名页面未能在其搜索引擎结果页面（SERP）位置上获得预期点击量的表现。

此外，文档把用户比作投票者，他们的点击行为则记录为投票。系统会统计不良点击数，并根据国家和设备对数据进行分类。

系统还记录了每次会搜索中点击时间最长的结果。因此，仅仅进行搜索和点击结果是不够的，用户还需要在网页上停留足够长的时间。长时间点击不仅仅是搜索成功的指标，尽管文档中没有提到“逗留时间”这一功能，长时间点击实际上与之测量的是同一个概念，这与 Google 的声明形成了对比。

多个来源指出，NavBoost 是 Google 最强大的排名信号之一，“Google 最强大的排名信号之一”。根据泄露文件，其中 84 次明确提到了“Navboost”，并且五个模块的标题涉及到 Navboost。还有证据显示，Google 在子域、根域以及 URL 级别进行评分，这明显表明他们对不同网站层级采取不同策略。关于子域和子目录的区别不展开讨论，但我们后续会探讨该系统数据是如何影响 Panda 算法的。

的确，虽然 Google 的文件中没有直接提到“CTR”或“停留时间”，但其核心理念——搜索结果的点击和评估成功搜索会话的指标——已被纳入考虑。这一点毫无疑问，Google 确实将点击行为及其后续的用户行为作为排名算法的一部分。

“不存在所谓的沙盒”

Google 的发言人一直坚称不存在一个根据网站的年龄或信任度低而将其隔离的所谓“沙盒”。John Muller 在一个现已删除的推特中回答了一个关于网站能否排名的问题，明确表示“不存在沙盒。”

这是 Twitter 上两位用户关于新网站是否存在 Google 沙盒的讨论截图。Vijay Kumar (@VijayKumarIM) 在 8 月 19 日的推文：“很高兴听到您的说法......通常新网站摆脱 Google 沙盒需要多长时间？”获得了 1 个点赞。John (@JohnMu) 在同一天回复：“不存在沙盒。”该推文获得了 7 个赞和 3 次转发，回复突出显示了用户的头像和验证标记，表明这是来自认证账号的回应。
这是 Twitter 上两位用户关于新网站是否存在 Google 沙盒的讨论截图。Vijay Kumar (@VijayKumarIM) 在 8 月 19 日的推文：“很高兴听到您的说法......通常新网站摆脱 Google 沙盒需要多长时间？”获得了 1 个点赞。John (@JohnMu) 在同一天回复：“不存在沙盒。”该推文获得了 7 个赞和 3 次转发，回复突出显示了用户的头像和验证标记，表明这是来自认证账号的回应。

在 PerDocData 模块的文档中，指出了一个名为 hostAge 的属性，其专门用于“暂时隔离新产生的垃圾内容”。

结果显示，Rand 早已指出，Google 确实设有一个沙盒。谁会想到呢？ 是的，Rand 早已知道。

“我们没有利用 Chrome 的任何信息来决定网页排名。”

Google 的 Matt Cutts 曾明确表示，Google 在进行有机搜索排名时，并不采用 Chrome 浏览器的数据。近期，John Mueller 也重申了这一观点。

其中一个涉及页面质量评分的模块，使用了基于 Chrome 的网站访问量作为评估指标。还有一个模块，似乎与生成站点链接有关，也包括了一个关于 Chrome 的特性。

一份泄露的内部演示文稿显示，自 2016 年 5 月以来，Chrome 的数据已被用于搜索优化。简言之，情况就是这样。