回到主页

JavaScript索引令人惊讶的证据

当我开始从事这个行业时,标准的建议就是告诉我们的客户搜索引擎无法执行JavaScript(JS),任何依赖JS的东西都会有效地隐形并且永远不会出现在索引中。多年来,这种情况逐渐发生变化,从早期的解决方案(例如我的同事Rob在2010年写的可怕的转义片段方法)到我们今天看到的索引管道中JS的实际执行,至少在Google上。

在本文中,我想探讨一些我们在野外和受控测试中看到的关于JS索引行为的事情,并分享一些关于它必须如何工作的初步结论。

JS索引的简要介绍

从最基本的角度来看,支持JavaScript的索引背后的想法是在用户看到它时更接近看到页面的搜索引擎。大多数用户在启用JavaScript的情况下浏览,并且许多站点在没有它的情况下失败或者受到严重限制 虽然传统索引仅考虑从服务器接收的原始HTML源,但用户通常会看到基于DOM(文档对象模型)呈现的页面,该页面可以通过在其Web浏览器中运行的JavaScript进行修改。支持JS的索引会考虑呈现的DOM中的所有内容,而不仅仅是原始HTML中显示的内容。

即使在这个基本定义中也有一些复杂性(括号中的答案,因为我理解它们):

  1. 那些从服务器请求其他内容的JavaScript呢?(这通常包括在内,受超时限制
  2. 在页面加载后执行一段时间的JavaScript怎么样?(通常只会将索引编入一段时间, 可能在5秒内完成)
  3. 那些在某些用户交互上执行的JavaScript如滚动或点击?(通常包括在内
  4. 外部文件中的JavaScript而不是内联文件呢?(这通常会包括在内,只要这些外部文件不会被机器人阻挡 - 尽管请参阅下面的实验中的警告

有关技术细节的更多信息,我建议我的前同事贾斯汀就此主题撰写文章。

我对JavaScript最佳实践的看法的高级概述

尽管过去令人难以置信的解决方案(这对我来说似乎总是更多的努力而不是优雅的退化),至少在2012年,随着PushState的推出,“正确”的答案已经存在。罗布也写了这篇文章。然而,当时,它非常笨重和手动,它需要协同努力,以确保在用户的浏览器中为每个应被视为“页面”的视图更新URL,服务器可以为这些视图返回完整的HTML页面响应每个URL的新请求,并且后退按钮由JavaScript正确处理。

在此过程中,在我看来,太多的网站被一个单独的预渲染步骤分散了注意力。这种方法相当于运行无头浏览器来生成静态HTML页面,其中包括JavaScript在页面加载时所做的任何更改,然后提供这些快照而不是JS依赖页面以响应来自机器人的请求。只要快照确实代表用户体验,它通常以Google容忍的方式对待机器人。在我看来,这种方法是一种糟糕的妥协,它太容易受到无声的失败和过时的影响。我们已经看到一些网站由于服务于Googlebot破坏的体验而遭受流量下降,这些体验未被立即检测到,因为没有常规用户看到预呈现的页面。

如今,如果您需要或想要JS增强功能,更多顶级框架能够按照Rob在2012年描述的方式工作,现在称为isomorphic(大致意思是“相同”)。

同构JavaScript提供与每个URL的呈现DOM相对应的HTML,并更新每个“视图”的URL,该视图应作为单独的页面存在,因为内容通过JS更新。通过这种实现,实际上不需要呈现页面来索引基本内容,因为它响应于任何新的请求而被服务。

最近发表的这篇研究让我着迷- 你应该去阅读整个研究。特别是,你应该观看这个视频(在帖子中推荐),其中演讲者 - 一位Angular开发者和传播者 - 强调需要采用同构方法:

用于审核JavaScript的资源

如果你在SEO工作,你会越来越多地发现自己被要求弄清楚一个特定的实现是否正确(希望在现场部署之前在暂存/开发服务器上,但是我们在开玩笑吧?你也会这样做)。

要做到这一点,这里有一些我发现有用的资源:

  1. Justin再次描述了使用DOM和查看源代码之间的区别
  2. Chrome内置的开发人员工具非常出色,而且有些文档实际上非常好:
    • 您可以在控制台中查看错误并与页面状态进行交互
    • 一旦你通过调试最基本的JavaScript,你将需要开始设置断点,这允许你从指定点单步执行代码
  3. 来自Google的John Mueller的这篇文章提供了一份体面的最佳实践清单
  4. 虽然它涉及更广泛的技术技能,但任何尚未阅读它的人都应该查看Mike关于技术SEO复兴的帖子。
一些令人惊讶/有趣的结果 JavaScript执行可能会有超时

我已经将上面链接到ScreamingFrog的帖子提到了他们为测量 Google用来确定何时停止执行JavaScript 的超时所做的实验(他们发现了大约5秒的限制)。

然而,它可能比这更复杂。该段一的线程 是有趣的。这是来自黑客新闻用户,他使用用户名KMag,并声称自己曾在谷歌工作过2006 - 2010年索引管道的JS执行部分。这与另一个用户推测谷歌不会关心加载“异步”的内容(即异步 - 换句话说,作为资源继续下载时在后台触发的新HTTP请求的一部分加载):

“实际上,我们确实关心过这个内容。我不能自由地解释细节,但我们确实执行了setTimeouts达到一些时间限制。

如果它们很聪明,它们实际上使确切的超时成为加载源的HMAC的函数,使得很难进行实验,找到确切的限制,并欺骗索引系统。早在2010年,它仍然是一个固定的时间限制。“

这意味着虽然它最初是一个固定的超时,但他正在推测(或者可能在没有直接这样做的情况下共享)超时是以编程方式确定的(可能是基于页面重要性和JavaScript依赖性),并且它们可能与确切的源代码相关联(对“ HMAC ” 的引用与如果页面已经改变的发现的技术机制有关)。

重要的是你的JS是如何执行的

我之前参考了这个最近的研究。在其中,作者发现:

内联与外部与捆绑的JavaScript对Googlebot产生巨大影响

最后的图表显示了流行的JavaScript框架在多大程度上取决于它们的调用方式,具有从将每个测试传递到几乎每个测试失败的一系列性能。例如,这是Angular的图表:

绝对值得阅读整篇文章并回顾不同框架的表现。有更多证据表明Google在某些领域节省了计算资源,并且不同框架之间的结果令人惊讶。

CRO测试正在编制索引

当我们第一次看到基于JavaScript的拆分测试平台,旨在测试旨在提高转换率(CRO =转换率优化)的更改时,他们对各个页面的内联更改对于搜索引擎是不可见的。特别是谷歌通过在外部文件中执行简单的内联JS到更复杂的JS,提升了JavaScript能力阶梯,我们现在看到一些CRO平台创建的更改被编入索引。正在发生的事情的简化版本是:

  1. 对于用户:
    • CRO平台通常将访问者带到页面,检查是否存在cookie,如果没有,则将访问者随机分配给A组或B组
    • 基于cookie值或新分配,用户可以不变地为页面提供服务,或者通过从CRO平台的CDN(内容传送网络)加载的JavaScript看到在其浏览器中修改的版本
    • 然后设置cookie以确保用户在稍后重新访问该页面时看到相同的版本
  2. 对于Googlebot:
    • 依赖于外部JavaScript用于防止分段内联更改被索引
    • 现在正在加载外部JavaScript,并且使用标准库(例如JQuery)进行了许多这些内联更改,Google能够为变体编制索引,因此我们看到CRO实验有时会被编入索引

我可能期望平台用robots.txt阻止他们的JS,但至少我看过的主要平台不这样做。然而,谷歌对测试表示同情,这不应该成为一个主要问题 - 在构建面向用户的CRO测试时需要注意的事项。您的UX和SEO团队密切合作并进行良好沟通的更多原因。

拆分测试表明,通过消除对JS的依赖,改进了SEO

虽然我们希望做更多的事情来测试依赖JavaScript的实际真实影响,但我们确实有一些早期的结果。在上周末,我发布了一篇文章,概述了我们从删除网站依赖JS在类别页面上显示内容和链接所看到的提升。

一项简单的测试消除了50%页面上对JavaScript的需求,显示有机流量增加了6%以上 - 每月价值数千次额外会话。虽然我们还没有证明JavaScript总是很糟糕,也没有理解这里的确切机制,但我们已经开辟了一条新的探索途径,至少表明它不是一个固定的问题。在我看来,它强调了测试的重要性。显然我们相信SEO分裂测试的重要性导致我们在过去18个月左右的时间里投入了大量的ODN平台开发。

结论:JavaScript索引如何从系统角度起作用

基于我们可以从搜索结果的外部行为,Google员工的公开评论,测试和实验以及第一原则拼凑起来的所有信息,以下是我认为JavaScript索引目前在Google上的工作方式:我认为有一个单独的队列,用于启用JS的渲染,因为尝试在整个Web上运行JavaScript的计算成本是不必要的,因为在许多页面上不需要它。详细地说,我认为:

  1. Googlebot会定期抓取并缓存HTML和核心资源
  2. 启发式(以及可能的机器学习)用于为每个页面优先处理JavaScript呈现:
    • 有些页面的索引没有JS执行。有许多页面可能很容易被识别为不需要渲染,而其他页面的优先级较低,因此不值得使用计算资源。
    • 有些页面会立即呈现 - 或者可能立即进行基本/常规索引,以及高优先级呈现。这将使新闻结果或其他QDF结果中的页面立即索引,但也允许在渲染完成时严重依赖JS的页面获得更新的索引。
    • 许多页面在爬行和常规索引的单独进程/队列中呈现为异步,从而将页面添加到索引中,以便在呈现完成时仅在JS呈现的版本中找到的新单词和短语,以及找到的单词和短语在最初索引的未呈现版本中。
  3. 除了向索引添加页面之外,JS渲染还包括:
    • 可以修改链接图
    • 可以为Googlebot的发现/抓取队列添加新网址

将JavaScript渲染作为索引管道的独特部分的想法得到了KMag的这个引用的支持,我之前提到过他对这个HN线程的贡献(直接链接)[强调我的]:

“我正在开发轻量级的高性能JavaScript解释系统,它几乎只是一个JS引擎和一个DOM实现,我们可以在索引的每个网页上运行。我的大部分工作都是试图提高系统的保真度。我的代码分析了索引中的每个网页。

在我那个时代的末期,Mountain View中有人正在研究一个更重,更高保真的系统,该系统更多地浏览了沙盒,他们试图提高性能,以便他们可以在更高的索引百分比上使用它“。

这就是2010年的情况。在所有情况下,他们似乎已经向无头浏览器迈进了很长一段路,但我怀疑是否值得花时间使用JavaScript来渲染他们抓取的每个页面。这样做以及大部分页面在您执行时不会发生实质性变化的事实。

我最好的猜测是,他们正在尝试找出在给定页面上执行JavaScript 的需要,再加上信任/权限指标来决定是否(以及具有什么优先级)使用JS呈现页面。

进行测试,获得宣传

我有一个假设,我希望看到有人测试:有可能得到一个页面索引和排名的服务HTML中包含的无意义的单词,但最初没有排名通过JavaScript添加一个不同的废话单词; 然后,看到JS在一段时间后被索引,并为两个无意义的单词排名。如果您想进行该测试,请告诉我结果 - 我很乐意宣传它们。

所有文章
×

还剩一步!

确认邮件已发至你的邮箱。 请点击邮件中的确认链接,完成订阅。

好的