2019 年 1 月 22 日 - Google 帮助环聊笔记

本周约翰在纽约的大苹果。 加入 IRL，从左到右，来自 Google 的 Java 脚本团队的 Martin Splitt、Chris Love、Lily Ray、Marie Haynes、Dave Minchala 和 Quason Carter。 本周有一些关于 Cloudfare、QRG 和新页面速度工具的好问题。 视频链接和完整的成绩单可以在下面找到！

Cloudflare 有时会阻止 Googlebot 吗？

7:58

“是的，我现在不知道 Cloudflare 是如何设置的，但我知道过去他们曾经阻止过伪造 Googlebot 的人。所以如果你使用，比如你自己的，我不知道，Screaming青蛙之类的——你说，我正在使用 Googlebot 用户代理，然后他们会阻止它，因为他们可以判断，例如，这不是一个合法的 Googlebot。我们可以阻止它。但在大多数情况下，我认为他们有足够的练习来识别正常的 Googlebot 并让它正常爬行。”

摘要：有时，在测试时，Cloudflare 可能会阻止 Googlebot。 这里可能发生的情况是 Cloudflare 正在阻止伪装成 Googlebot 的人。 因此，如果您使用 Screaming Frog 之类的工具并选择 Googlebot 作为您的用户代理，您可能无法使用 Cloudflare 抓取网站。

不自然的链接仍然会在算法上伤害网站吗？ 如果是这样，可以使用拒绝工具帮助吗？

14:01

“我认为这是一个很好的问题。所以从我的角度来看，我会看到，一方面，肯定是有手动操作的情况。而且，你也想要的情况看到很多手动操作会说，好吧，如果网络垃圾邮件团队现在看到这个，他们会给你一个手动操作。你会说，手动操作更多的是时间，而不是有点像它基于已经完成的事情——我不知道——它显然是在几年前完成的，而且它有点不是边界。但是你看到的那种东西并且说，如果网络垃圾邮件团队的某个人得到了这个提示，他们会采取手动操作，这绝对是我会清理它并为此拒绝的那种事情。是的，我想很难说是否有具体的时间表。但总的来说，如果网络垃圾邮件团队看到这个并说，就像，事情已经发生了。这显然是 d 几年前的一个。 这并不完全是恶意的。 那么他们可能不会为此采取手动操作。 "

我假设您可能无法回答这个问题，但有什么办法——比如，假设我们没有得到手动操作，或者他们没有得到手动操作。 这些链接会在算法上伤害它们吗？ 因为我们觉得我们在一些网站上看到了一些改进，你知道，在拒绝之后。 所以，再一次，我知道它总是——它从来都不是非黑即白的。

绝对可以这样。 所以这是我们的算法，当我们查看它时，他们会看到，哦，它们是一堆非常糟糕的链接，那么也许他们会对网站的一般链接更加谨慎。 所以如果你把它清理干净，那么算法会看着它说，哦，有--有点--没关系。 不算太差。

总结：如果您有专门为 SEO 制作的链接，并且有很多链接，它们可能会导致 Google 的算法不信任您的所有链接。 最好拒绝这种情况。

Google 的算法如何衡量出版商的 EAT？

33:40

“我不知道。我认为这可能很难通过算法计算出来。如果你应该做任何技术上的事情，那么我们会让你知道。所以如果有像作者标记这样的事情，我们在某些时候我们认为对这样的事情有用，我们肯定会把它带到那里。但是很多事情实际上是我们试图弄清楚的更多的软质量因素，这不是技术性的东西'要么在做，要么不做。更像是试图弄清楚用户可能会如何看待它。所以我不能指出任何具体的东西。“

总结： Google 关注了很多“软质量因素”。 从用户的角度看待事物。 此外，作者身份标记可以帮助 Google 更好地理解事物。

如果质量评估者指南中有某些内容，那么假设 Google 希望将其反映在他们的算法中是否合理？

34:44

我认为，总的来说，以此为目标可能是一种好习惯。 我避免过多地关注谷歌可能使用的算法因素，而是更多地看待它——我们认为这对网络有好处，因此，我们将尝试朝着这个方向前进并做这些之类的东西。 所以与其说我在做一个好的网站只是为了让我排名更高，但我做一个好的网站是因为当我出现在搜索中时，我希望人们有好的体验。 然后他们会回到我的网站，也许他们会买点东西。 所以这就是我会看到的方向，不是为了排名，而是为了在网络上建立健康、长期的关系。

总结：想想什么对用户最好。 尽管目前 QRG 中的所有内容并未反映在 Google 的算法中，但这些都是朝着提高整体质量迈出的重要一步。

是否有模式可以帮助网站在语音搜索结果中显示得更高？

36:10

我不知道。 我什么都想不出来。 因此，您可以使用可朗读的标记，这可能是合理的——看看它在页面上的哪些地方有意义。 我认为我们不会在所有地方都使用它。

总结：可口语标记尚未在所有地理位置使用。 但是，这是一个很好的起点。

赢得精选片段的一些技巧

38:03

但特别是精选片段，我认为我们没有任何类型的特定标记。 因此，如果您在页面上有清晰的结构，这对我们有很大帮助。 如果我们可以识别页面上的类似表格，那么我们可以更容易地将其拉出来。 而如果你使用花哨的 HTML 和 CSS 让它看起来像一个表格，但它实际上不是一个表格，那么我们很难把它拉出来。

摘要：您无法添加任何标记来赢得精选片段。 但是，很好地使用 h 标签和普通的 HTML 表格真的很有帮助。

是否应将位置模式添加到所有页面？

50:47

回答 51:42 - 据我所知，它只是主页。 我不知道。 你们有谁知道吗？

Liz 的回答 51:4 7 - 通常应该只有一页，包含组织和公司。 这通常是建议。

MARTIN SPLITT 52:00 - 我想哪一页都没有关系——就像不要把它放在你所拥有的每一页上一样，我猜是更重要的一点。 我认为这取决于——如果你是一个新闻网站，把它放在联系页面、关于页面或其他东西中可能是有意义的。 而在商店或餐厅网站中，将其放在主页上可能是可以的。

JOHN 52:20 - 我也认为，在这种情况下，这对我们来说并不重要，因为我们需要能够在主页或联系页面之类的地方找到它。 但是，如果我们在其他地方拥有它，它不会改变我们的任何东西。 因此，不能与之相比的最重要的事情是评论标记，我们有时会看到人们在网站的所有页面上放置公司评论，希望获得星星和他们网站上每个页面的搜索结果。 这对我们不利。 但是联系信息，如果你已经标记了，那是 - 我认为这没有问题。

总结：其实无所谓。 它应该在联系页面上，可能在您的关于页面和主页上。 拥有跨站点的位置模式不是问题，但也可能没有必要。

为什么基于 Lighthouse 的新 PageSpeed Insights 工具在对网站进行评分时会如此苛刻？

53:05

Marie Haynes：这不是我的问题，但为了提供一些背景信息，新的 Lighthouse 页面速度数据比 Page Speed Insights 过去更加苛刻。 因此，在 Page Speed Insights 上得分为 80 分的东西在 Lighthouse 上可能是红色的 29 分。 所以这是一个很好的问题。 这可能会导致 - 因为我们知道在移动设备中，速度非常慢的网站可能会被降级。 那么，如果我们说，你知道，如果你在灯塔测试中处于亏损状态，我们真的应该改进一些东西，因为它可能会导致降级，或者是否有截止日期？

回答 54:07 - 所以我们没有对外部工具和我们用于社交的所有工具进行一对一的映射。 是的，这很难说，但是在搜索中，我们尝试使用实际的，它是什么，实验室测试数据，有点像 Lighthouse 测试，以及 Chrome UX 报告数据，其中本质上是什么我们正在衡量的是网站的用户会看到什么。

MARTIN SPLITT 55:37 - 同样重要的是要看到 Lighthouse，例如，专门测量中端的 3G 连接——或者像中等性能的手机，是的。 所以，基本上，如果你在最近的 Apple McIntosh 或最近的快速 Windows 计算机上使用非常好的有线连接或非常好的 Wi-Fi 连接在你的办公室，当然，你会看到两秒的加载时间，但是在野外使用手机的真实用户可能看不到这一点。 所以这是其中一种情况，就像让您的网站更快永远不会受到伤害，但这真的，真的很难说从内部的角度来看它会是什么样子，因为我们使用的是非常具体的指标，不一定将一个映射到一个工具所暴露的内容....当然，解决这个问题很重要，因为您不希望您的用户永远等待您的网站。 那会伤害你的。 这会伤害你的用户。 这只会伤害你的搜索。 但我不付钱——我会说只是看看工具。 如果工具告诉你你做得很好，那么你不应该太担心它。 如果工具告诉你你做得不好，那么我认为花在弄清楚它为什么说上的时间——比如，如果它说的是相关的，那就浪费了。 您应该着眼于使网站更快。

移动性能对于您的用户以及其他一切都是一个非常重要的因素。 所以我想说确保您的网站在现实条件下表现良好。 甚至可以买一部便宜的手机，时不时地尝试一下这个网站，如果——那是我喜欢做的事情，而且在我加入谷歌之前，我曾经和我一起工作的开发团队一起做。 我想，看，你想在这部手机上使用这个网站吗？ 就像，哦，这太可怕了。 我想，嗯，是的，所以也许我们应该做点什么。

JOHN - 在 Chrome 中，您可以设置它并尝试不同的连接速度。 移动模拟器。 我认为这是非常值得一看的东西，而且，看看你的用户群。 如果您发现人们只使用高端 iPhone 使用您的网站，请查看您的分析数据，那么与您看到人们从随机的农村连接连接到您的网站相比，这可能不是问题，这是慢，而且他们有低端设备，那么也许更多。

总结： Lighthouse 测量 3G 连接的速度，因此对于大多数会话来说，大多数站点的运行速度比此处显示的要快得多。 注意：在本次视频群聊结束后，Martin 继续说，对于潜在的排名降级而言，这是最重要的“第一次有内容的绘画”。

如果你喜欢这样的东西，你会喜欢我的时事通讯！

我和我的团队每周都会报告最新的 Google 算法更新、新闻和 SEO 技巧。

视频和完整成绩单

问题 1:32 - 我想知道您是否有任何更多的指导或更多的观点来测试 SEO 可以用来更精确和更有信心向业务报告的方式。 我们尝试了这个东西，它产生了影响。 我们以一种肯定的方式做到了，就像谷歌推荐的那样。

回答 3:20 -所以从我的角度来看，我尝试将更多技术类型的东西与质量类型的变化分开。 因此，任何真正明确的技术事物，您几乎可以测试它是否有效或无效。 这不是一种工作或不起作用的问题，而是很多这些技术性的东西，尤其是当你在看渲染时，或者当你在看 Google 是否真的可以索引这些内容时，那就是一些有效或无效的东西。 它变得棘手的地方是它所涉及的一切——它被编入索引，但它是如何出现在排名中的呢？ 而且我认为在很多方面，没有绝对的方法可以真正测试它。 因为如果您在孤立的情况下进行测试，例如创建一个测试站点，并根据您的建议进行设置，您不能真正假设测试站点的运行方式与普通网站相同。 有时有一些简单的事情，比如如果它是一个测试站点，那么也许我们不会进行完整的渲染，因为我们认为在这个和这个上花费这么多时间是没有意义的，因为就像没有人看它一样。 它从来没有出现在搜索结果中，我们为什么要费心把这么多资源放在后面呢？ 然而，如果你在一个普通的网站上这样做，那将有很大的不同。 所以我对你应该做什么或不应该做什么没有任何明确的指导。 它看起来更像是您查看您看到该网站出现的总体趋势，您看到这些查询的排名变化，并尝试在那里应用最佳实践的那种事情。

问题 5:21 -所以也许如果—— 一个具体的例子，你可以用它来—— 也许这会有所帮助，比如标题标签测试，对吧？ 如果你这样做——如果有的话，我们应该寻找什么？ 或者有什么可以解开的——这是由于我们的测试，还是由于服务器、算法、竞争动态的某些变化？ [笑声] 假设我们正在做其他事情来看待这些外部性。

回答 5:56 -我认为标题标签更改实际上对我们来说非常复杂，因为 Google 是否使用您实际提供的标题标签，一方面，用于排名，另一方面，用于显示在搜索结果中。 就像桌面和移动一样，我们有不同的空间，所以我们可能会显示略有不同的标题标签。 用户可能会以不同的方式对此做出回应。 因此，您可能会以相同的方式进行排名，但用户可能会认为，哦，这是一个很棒的页面。 我会把它显示得更高——或者我会在搜索结果中点击它，因为它看起来像一个很棒的页面。 然后你有更多的流量。 但排名其实是一样的。 那么这是一件好事吗？ 大概吧，我猜。 如果你只是看排名，那么看起来，你没有改变任何东西，我们只是获得了更多的流量。

但这就是其中有很多不同方面的地方。 所以我认为，作为一名 SEO，一方面，对发生的事情有技术上的理解是有用的，而且对用户如何对变化做出反应有更多的营销和质量理解，什么是我们可能会影响用户的长期变化，您如何推动它以确保在人们搜索与之相关的内容的情况下我们的网站被视为最相关的网站。 我认为这真的很难测试。 就像，即使在他们已经进行了多年实践的传统营销中，也很难测试，例如，这是否真的有很大的影响？ 这是他们最终着眼于大局或进行用户研究的事情，您也可以作为 SEO 来做这些事情。 对不起。 [笑声]

问题 7:58 - 我有一个更直接的问题。 因此，您知道，我们的许多网站都在使用 Cloudflare，我们注意到它们直接阻止了 Googlebot，对吧？ 但这对我们的排名、知名度等并没有太大影响。 所以想弄清楚你们是如何使用另一个机器人直接在 Googlebot 之外抓取索引的，当 CDN 竭尽全力阻止机器人时，我们应该如何考虑这一点？

回答 8:33 -是的，我目前不知道 Cloudflare 是如何设置的，但我知道过去他们曾经阻止过伪造 Googlebot 的人。 所以如果你使用，比如，你自己的，我不知道，Screaming Frog 什么的——你说，我在使用 Googlebot 用户代理，那么他们会阻止它，因为他们可以告诉，比如，这不是合法的谷歌机器人。 我们可以阻止它。 但在大多数情况下，我认为他们有足够的练习来识别普通的 Googlebot 并让它正常爬行。

问题 9:02 - 是的，这很有趣。 因为联系了其他机构的一群同事，他们甚至在自己的网站上也复制了类似的情况。 就像，Cloudflare 中有一张支持票，当我试图直接从 Googlebot 或 Googlebot 智能手机进行渲染时，它也被阻止了。

回答 9:21 - 好的，是的。 好吧，我们没有任何变通办法。 就像，如果网站阻止了我们，我们就会陷入困境。 但通常如果像 Cloudflare 这样的服务默认阻止我们，那么这会影响很多网站。 我们会注意到这一点。 我们可能会就类似的事情联系 Cloudflare。 可能是他们有不同的服务层。 因此，如果您处于较低级别，那么它就像一项免费服务，但我们对流量有限制。 我不知道他们有没有类似的东西。 这是我在其他一些主机上看到的情况，如果你设置了免费的默认主机，那么有时他们只是有流量上限，他们会阻止事情。

MARTIN SPLITT：您可能不会立即从您的排名等统计数据中看到这一点。 因为基本上，如果我们有您的内容，并且基本上，该网站不是-- 取决于被阻止的内容，在这种情况下，意味着因为我没有看到那个。 我在 Cloudflare 后面运行了几个网站，我没有遇到任何问题。 但话又说回来，我没有庞大的网站或喜欢大量的流量，因为我是免费计划的。 那是 - 但如果您没有在我们这边遇到错误，它 - 可能只是我们保留了我们上次看到的内容。 这只是排名很好，没关系。

回答 12:09 - 是的，所以我认为在像你这样的情况下会发生什么，我们会减慢爬行速度。 我们会尝试保留我们可以在索引上获取更多内容的内容，并且我们会重新抓取更长的时间。 但这也意味着，如果您在您的网站上进行更改，我们将需要更长的时间来处理。 如果我们必须重新抓取大量内容，例如，我不知道，AMP，或者您在整个网站上添加一些这样或那样的内容，那么这一切都需要更长的时间。 因此，如果您确实经常看到我们无法使用普通的 Googlebot 进行抓取，那么我会与主机商联系，以便我们查看。

问题 14:01 - 太好了。 所以我有一个关于拒绝工具的问题。 因此，我们一直都有希望我们进行链接审核的人。 自从 Penguin 4.0 以来，2016 年 9 月，Gary Illyes 说过，我想你也说过，就像，谷歌非常擅长忽略不自然的链接。 所以我当时的想法是，好吧，我们不应该使用拒绝工具来要求 Google 忽略他们已经忽略的链接，除非您对非自然链接进行了手动操作。 因此，我们只向那些积极建立链接、试图操纵事物、非自然链接的网站推荐它。 但我认为网站管理员之间存在很多困惑，因为我一直看到人们，你知道，收取大量资金进行审计——否认那些只是——我知道他们被忽略的链接。 因此，如果我们能再澄清一点，我会很高兴。 所以也许我可以给你举个例子，比如，如果有一个企业主，几年前，聘请了一家 SEO 公司，而那家 SEO 公司为链接做了一堆客人发帖，你知道的，是一种中等质量，如果你知道我的意思，不是超级垃圾邮件，我们可以确信谷歌忽略了这些链接吗？ 还是我们应该进去否认？

回答 15:22 - 我认为这是一个很好的问题。 因此，从我的角度来看，一方面，我所看到的绝对是手动操作的情况。 但是，如果您还希望看到很多手动操作，那么如果网络垃圾邮件团队现在看到这个，他们会给您手动操作。 在某些情况下，您会说，手动操作更多是时间问题，而不是基于已经完成的事情-我不知道-显然是在几年内完成的以前，这是一种边界不是。 但是，如果你看到它并说，如果网络垃圾邮件团队的某个人得到这个作为提示，他们会采取手动操作，而这绝对是我会清理并做的那种事情就像对此的否认。 是的，我认为很难说是否有特定的时间表。 但总的来说，如果网络垃圾邮件团队看到这个并说，事情已经发生了变化。 这显然是在几年前完成的。 这并不完全是恶意的。 那么他们可能不会为此采取手动操作。

问题 16:43 -我假设您可能无法回答这个问题，但有什么方法可以 - 比如，假设我们没有获得手动操作，或者他们没有获得手动操作。 这些链接会在算法上伤害它们吗？ 因为我们觉得我们在一些网站上看到了一些改进，你知道，在拒绝之后。 所以，再一次，我知道它总是——它从来都不是非黑即白的。

回答 17:03 - 绝对可以。 所以这是我们的算法，当我们查看它时，他们会看到，哦，它们是一堆非常糟糕的链接，那么也许他们会对网站的一般链接更加谨慎。 所以如果你把它清理干净，那么算法会看着它说，哦，有--有点--没关系。 不算太差。

问题 17:24 - 基本上拒绝只是为了防止手动操作仍然很好，对吗？

回答 17:29 - 我认为，如果您确实很清楚网络垃圾邮件小组会根据当前情况为您提供手动操作，那么我会拒绝这样做。

问题 17:37 - 所以，像在 Google 那样思考是件好事——就像 Google 垃圾邮件小组中的某个人只是想，你知道，如果他们看到这个，他们会怎么做？

回答 17:47 - 是的。

问题 17:48 - 但问题是，大多数人不知道。 我的意思是，一般企业主不知道网络垃圾邮件团队会使用哪些链接——我的意思是，有指导方针，但它非常——你知道，很难解释这些。 所以我认为——我的意思是，我有几个担忧，但我主要担心的是有人在我认为不值得的链接审计上花费大量资金。 另一方面，我们可能不会进行链接审核并拒绝某些可能从中受益的网站。 所以我很乐意，你知道，我认为你所说的帮助很大，所以我们会 - 你知道，这很好。

回答 18:22 - 是的，我认为对于绝大多数网站来说，这些网站都有正常的组合，就像你过去听了一些不好的建议，就像你继续前进，现在事情很自然，那么他们真的不必那样做。 这就是所有这些的目标，这就是为什么拒绝工具不像 Search Console 中的主要功能。 你有点明确地寻找它。 这一切都是故意的，因为对于大多数网站，您真的不需要那么关注链接。 不过，我喜欢拒绝工具的一点是，如果您对此感到担心，您仍然可以去那里并说，好吧，我知道我们做了几年的一些事情以前，我真的很担心。 然后，在我看来，否认它们不是问题。 我不会出去专门搜索所有这些东西。 但是，如果您知道它，并且您真的很担心它，那么您可以照顾它。

问题 19:27 - 我对我们的一个客户网站有疑问。 所以他们有俱乐部——他们在新南威尔士州的三个城市都有俱乐部。 每个俱乐部在网站上都有一个子域。 现在，当他们将任何页面添加到他们的网站时，他们会为每个子域创建页面。 所以最近，他们添加了一个关于他们的俱乐部活动的页面，并且他们已将此页面添加到他们的所有子域中。 所以这意味着所有的子域都有相同的内容，除了页面的标题不同。 因为当他们添加到悉尼时，他们会在标题标签中添加他们的位置名称。 当他们为纽卡斯尔添加它时，他们在标题标签中添加了纽卡斯尔，但页面上的其余内容是相同的。 那么会不会有问题，因为他们有 50 个子域，并且他们创建了 50 个页面，除了标题之外的内容相同吗？

回答 20:36 - 我猜这听起来有点低效。 所以我的意思是，你已经提出来了，有点像是说，这似乎可以用不同的方式来做。 我认为，如果您有 50 个子域都具有相同的内容，而您只是更改标题标签，那么您可能没有为我们提供很多真正有用的内容。 所以这就是我要说的情况，结合事物并制作真正强大的页面而不是在更多子域中稀释事物更有意义。

问题 21:44 - 创建一个页面然后使用规范 URL 到其他位置页面怎么样。 我只想创建一个页面，我们将讨论他们的活动，我将使用该链接作为其他位置页面的规范 URL。

回答 22:10 - 位置 - 是的。 我认为这可能是有道理的，因为那时你又将事物结合起来了。 然后你正在制作一个强大的页面，而不是一堆稀释的页面。

问题 22:20 - 因为当有人访问该网站时会发生什么，并且他们选择了他们的位置，他们会自动将该人重定向到他们指定其特定位置的子域。 这就是他们需要该子域上的页面的原因。 因此，我认为这就是为什么如果我们保留一个页面并添加规范 URL，那么这就是我们目前唯一的选择。

回答 23:08 - 好的，但我认为如果您有单独的页面，出于某种技术原因需要在网站上拥有它们，并且您放置规范，这是一个好方法。

问题 23:21 - 会不会像 - 一家在不同地点拥有多个特许经营权且每个特许经营权本质上具有相同内容的企业会位于不同的城市或乡镇，或者其他任何地方，并且从您的点回单页？

回答 23:34 - 我认为这总是有点棘手，因为您要平衡在特定位置寻找此类业务的人与直接围绕该业务的信息页面。 因此，有时将业务分开是有意义的。 有时，在一个中心位置拥有某种一般信息并拥有类似的位置登录页面是有意义的，这些页面更侧重于地址、开放时间等。

问题 24:12 - 是的，我有一个关于你提出的规范点的相关问题。 这是我和我的团队多年来一直存在的问题。 而且我们仍然不完全知道解决方案。 因此，如果您正在处理一个包含许多产品和许多类别的大型电子商务网站。 假设您在一个类别页面上，该页面具有许多不同的过滤器和方面以及性质稍有变化的页面内容，但可能不足以证明拥有自己的 URL 是合理的。 但也许在某些情况下使用某些过滤器，它确实证明拥有站点 URL 是合理的。 那么在这种情况下你如何处理爬行呢？ 像规范标签一样有效吗？ 仅创建一个已编入索引的页面是否是一揽子解决方案？ 或者你应该看看，你知道，不索引某些方面和过滤器，或者使用机器人，或者你如何控制大型电子商务网站？

回答 24:57 - 这很棘手。 我认为我们目前对此没有真正明确的指导。 所以这就是所有这些不同类型的方法都有意义的地方。 一般来说，我尽量避免为此使用 robots.txt，因为我们可能会找到 URL。 我们只是不知道那里有什么。 因此，除非您真的看到导致服务器负载过大的问题，否则我会尝试使用无索引之类的东西，使用 rel canonical。 也许您使用带有内部链接的 rel no-follow 来指向某种漏斗事物，以便更清楚地了解我们应该抓取索引的内容，而不是使用 robots.txt。 但是，关于何时将内容组合到索引级页面以及何时阻止其编入索引，何时将其温和地引导至一个规范 URL 的决定，有时真的很棘手。

问题 25:53 - 因为有时如果页面内容差异太大，规范会被忽略。

回答 25:57 - 没错。 如果内容不同，那么我们可能会说，嗯，这些是不同的页面。 我们不应该使用规范。 而你可能会说，嗯，这真的是我不想索引的东西。 也许无索引比规范更有意义。 您也可以将两者结合起来。 我们不建议将它们结合起来，因为我们很难说，嗯，你是什么意思？ 你是说这些是一样的，但是一个是可索引的，一个是不可索引的，那么它们就不一样了。 但我想，在这一年里，这将是一些关于在那里可行的明确指导。 但尤其是对于非常大的电子商务网站，抓取方面可能非常具有挑战性。

问题 26:46 - 所以最近我一直在尝试与我的几个客户一起弄清楚一个场景。 我们正试图弄清楚为什么我们无法从本质上删除仍在使用 HTTP 且或多或少看起来已被废弃的网站，因为该页面已经有一段时间没有更新了，而且内容又旧又过时，而且通常有点薄，所以我有一些关于它的理论。 部分原因是，我认为，也许它在指数中的时间太长了，以至于你们都对它们建立了信任因素。 而且很难让他们下台。 That's part of my theory on that. So I'm just trying to figure out what's going on because I know HTTPS is a factor. I don't know how much of a factor it can be, but I also think the age might be part of the problem of trying to provide that newer, fresher content that-- in most cases, what we have done over last year is a lot more thorough than what was written, say 10, 12 years ago. So we're trying to figure out why is it taking so long to essentially move ahead of those pages in a lot of cases.

Answer 27:46 - So HTTPS is a ranking factor for us. But it's really kind of a soft ranking factor. It's really a small thing.

Question 27:55 - One of the things I've noticed about when I encounter sites that are still using HTTP is they haven't really-- they haven't been updated, in general, in two or three years, usually. So to me, it's kind of like they've almost been abandoned. To me I'm looking at it as a signal of freshness and stuff like that.

Answer 28:10 - Yeah, I mean, freshness is always an interesting one, because it's something that we don't always use. Because sometimes it makes sense to show people content that has been established. If they're looking at kind of long-term research, then like some of this stuff just hasn't changed for 10, 20 years.

Question 28:30 - I'll give you a pragmatic examples since I'm a web developer. I see pages that were written, say in 2006 or 2007. They haven't actually been changed, but the web standards, web specifications, or just the general way of handling those things has evolved. But that page is still written as if it's 2006. And yet I've got something that's fresher, you know, that's more in depth and things like that, and I'm like at number 11. They're sitting at number four, for example, like, why are they still up there, you know?

Answer 28:59 - Yeah. It's hard to say without looking at the specific cases. But it can really be the case that sometimes we just have content that looks to us like it remains to be relevant. And sometimes this content is relevant for a longer time. I think it's tricky when things have actually moved on, and these pages just have built up so much kind of trust, and links, and all of the kind of other signals over the years, where like, well, it seems like a good reference page. But we don't realize that, actually, other pages have kind of moved on and become kind of more relevant. So I think long-term, we would probably pick that up. But it might take a while.

I don't know if we call it trust or anything crazy like that. It's more-- it feels more like we just have so many signals associated with these pages, and it's not that-- like, if they were to change, they would disappear from rankings. It's more, well, they've been around. They're not doing things clearly wrong or for as long time, and people are maybe still referring to them, still linking to them. Maybe they're kind of misled in kind of linking to them because they don't realize that, actually, the web has moved on. Or maybe, I don't know, a new PHP version came out, and the old content isn't as relevant anymore. But everyone is still linking to, I don't know, version 3 or whatever.

Question 30:42 - But I've also seen that kind of in the health and fitness space as well, you know, like workout types were more popular 10 years ago, but the particular, you know, approach to it isn't necessarily as popular now or been kind of proven to not necessarily be as good. You know, it's just some other general observations I've made too.

Answer 31:06 - Yeah, I think it's always tricky because we do try to find a balance between kind of showing evergreen content that's been around and kind of being seeing more as reference content and kind of the fresher content and especially when we can tell that people are looking for the fresher content. But we'll try to shift that as well. So it's not something that would always be the same.

Question 32:20 - "We have a large e-commerce site that's not in the mobile-first index yet. We know we serve different HTML for the same URL, depending on the user agent. Could this harm us?

Answer 32:38 - So you don't have a ranking bonus for being in the mobile-first index. So it's not that you need to be in there. But it's more a matter of when we can tell that a site is ready for the mobile-first index, then we'll try to shift it over. And at the moment, it's not at the stage where we'd say, we're like flagging sites with problems and telling them to fix things. But more where we're just trying to get up to the current status and say, OK, we've moved all of the sites over that we think are ready for mobile-first indexing. And kind of as a next step, we'll trying to figure out the problems that people are still having and let them know about these issues so that they can resolve them for mobile-first indexing. So it's not that there is any kind of mobile-first indexing bonus that's out there. It's more that we're, step by step, trying to figure out what the actual good criteria should be.

Question 33:40 - Given that the search quality guidelines are an indication of where Google wants its algorithm to go, how does the current algorithm handle measuring the expertise and credibility of publishers?

Answer 33:59 - I don't know. I think that's probably hard to kind of figure out algorithmically. And if there were any kind of technical things that you should do, then we would let you know. So if there are things like authorship markup that we had at some points that we think would be useful for something like this, we would definitely bring that out there. But a lot of things are really more kind of soft quality factors that we try to figure out, and it's not something technical that you're either doing or not doing. It's more, like, trying to figure it out how a user might look at this. So not anything specific that I could point at.

Question 34:44 - Is that reasonable to assume that if something is in the Quality Raters' Guidelines that Google-- I mean, that's what Ben Gomes said, right? That's where the Google wants the algorithm to go. So I mean, we may be guilty putting too much emphasis on the Quality Raters' Guidelines, but it's all good stuff in there, right? So is it reasonable to make that assumption? Like, if it's in there, we should aim for that sort of standard of quality?

Answer 35:09 - I think, in general, it's probably good practice to aim for that. I avoid trying to focus too much on what Google might use as an algorithmic factor and look at it more as-- we think this is good for the web, and, therefore, we will try to kind of go in that direction and do these kind of things. So not so much it's like I'm making a good website just so that I can rank better, but I'm making a good website because when I do show up in search, I want people to have a good experience. And then they'll come back to my website, and maybe they'll buy something. So that's kind of the direction I would see that, not as, like, do this in order to rank, but do this in order to kind of have a healthy, long-term relationship on the web.

Question 36:10 - Is there a particular type of schema that is more likely to obtain featured snippets of voice search results?

Answer 36:18 - I don't know. I can't think of anything offhand. So there is the speakable markup that you can use, which is probably reasonable to-- kind of look into to see where it could make sense on a page. I don't think we'll use that in all locations yet.

Question 36:41 - Is that the goal to us it in more locations?

Answer 36:47 - I believe-- I guess. I mean, it's always a bit tricky because, sometimes, we try them out in one location, and we try to refine it over time. And usually, that means we roll it out in the US, and where we can kind of process the feedback fairly quickly, we can look to see how it works, how sites start implementing it or not. And based on that, we can refine things and say, OK, we're doing this in other countries, and other languages, and taking it from there. But it's not always the case that that happens. Sometimes it happens that we keep it in the US for a couple of years, and then we just said, oh, actually, this didn't pan out the way that we wanted it. So we'll try something new, or we'll give it up. Yeah. But a lot of the structured data types, we do try to roll out in other countries, other languages. I imagine the speakable markup is tricky with regards to the language. So that's something more where we'd say, well, Google Assistant isn't available in these languages. So, like, why do we care what markup is actually used there.

I don't know how many places this system is available yet. Maybe that's everywhere now. But featured snippets, in particular, I don't think we have any type of markup that's specific to that. So that's something where if you have clear kind of structure on the page, that helps us a lot. If we can recognize like tables on a page, then we can pull that out a lot easier. Whereas if you use fancy HTML and CSS to make it look like a table, but it's not actually a table, then that's a lot harder for us to pull out.

Question 38:37 - John, do internal links help with featured snippets if you have an anchor? Sorry, not an internal, like, an anchor like-- do you think that that would help?

Answer 38:48 - I don't know. I do know we sometimes show those anchor links in search as a sub site link-type thing. But I don't know if that would work for featured snippets.

Question 39:04 - Does cross domain site map submissions still work when 301 redirecting to an external sitemap file URL?

Answer 39:16 - Hopefully.

Question 39:17 - What about using meta-refresh? This was something that was recommended by a video hosting company. People said, we'll host the site map on our site, but, you know, the XML file will metarefresh over to our site where all the links are located.

Answer 39:33 - I don't think that would work. So sitemap files are XML files, and we process those kind of directly.

So if you do something that's more like a JavaScript redirect or that uses JavaScript to get us the sitemap content, then that would work. It would really need to be a server-side redirect. What you can also do is use the robots.txt file to specify a sitemap file on a different host. That also confirms to us that actually you told us specifically to use a sitemap file from there. So I probably use something like that more than any kind of a redirect. I imagine the 301 server-side redirect would work. But, no, I don't know, you should be able to see some of that in Search Console too, like, if we're picking the sitemap up in the index composition tool, you can pick the sitemap file, then that's a pretty clear sign that we can process that.

问题 42:29 -关于旅行的旅行社网站。 我们选择内部搜索来显示动态内容，比如搜索城市中最便宜的 10 家酒店，好吗？ 所以页面框架会立即加载。 但是最便宜的前 10 家酒店结果在搜索执行后大约 30 秒内动态加载，因为网站必须在后面执行此搜索，然后比较和优化结果，以便为搜索者列出便宜的前 10 名酒店酒店。 所以列出它们需要一点时间。 所以现在，Googlebot 只能看到页面的背景。 然后，这 10 个空占位符是执行内部搜索后稍后加载结果的位置。 因此，既然这是旅游网站带来尽可能新鲜和准确的信息的趋势，我在想，谷歌正在为此做些什么。 当然，我们可以在这些页面上列出一些静态内容，就像现在所有其他网站为 Google 所做的一样，如果我可以这么说的话。 但这违背了大多数用户现在想要看到的新鲜和便宜的目的。

回答 44:00 - 所以如果它没有在那里加载，那么我们就不能索引它。 但通常，这更多是因为我们无法处理 JavaScript，或者可能被阻止实际访问那里的内容。 所以这是你可以用一种可行的方式来做的事情。 这不是设计使然，它永远不会起作用。 因此，您可以使用诸如移动友好测试之类的东西来挖掘细节，以查看是否涉及 JavaScript 错误、是否被阻止，并从那里进行改进。 所以这不是不可能的，但需要一些工作。

问题 44:42 - John，我对此进行了深入研究，确保没有任何内容被 Google 屏蔽。 我们希望谷歌做的唯一一件事就是等待动态内容加载到页面上，你知道吗？ 这是下一步，如果我可以这样说的话，因为虽然这个页面不像一个无尽的滚动，比如说 Facebook，它是一个有限的 10 个结果页面。 所以它是有限的。 它是有限的。 问题是谷歌应该等待一些动态内容。 我只是给你一个例子。 但我敢肯定还有很多其他的例子。 并且因为这是人们看到动态内容的趋势，因为他们以某种方式对事物进行排序并且他们花费的时间越来越少——人们在网站上花费的时间越来越少，他们希望尽快找到完美的结果，如果我可以这么说的话。 我想知道你们是否正在寻找这种增强功能。

回答 45:55 - 所以我们等待渲染。 但是，如果人们不耐烦，那么这表明您无论如何都应该更快。 所以无论如何我都会对此进行研究。 但我认为看截图，所有的项目都被封锁在灰色的盒子里。 所以这感觉更像是一个技术问题，而不仅仅是一个超时。

马丁·斯普利特：是的。 我正要说，我们确实看到很多动态内容可以毫无问题地被编入索引，即使它使用 JavaScript 之类的东西。 因此，如果我们超时，那么您可能会在搜索需要多长时间方面遇到问题，这实际上也可能反映在其他地方。 我们等了很长时间才能完成内容。

问题 46:48 - 你能给我一个时间框架吗？ 你等多少？

MARTIN SPLITT ：这真的非常非常棘手，因为基本上——问题是，我们不能给你一个时间框架的原因是因为时间——这听起来真的很奇怪，请耐心等待我一秒钟. Googlebots 渲染的时间很特殊，不一定遵循爱因斯坦的原则。 [笑声] 所以我真的不能说太多。 我能说的是，如果网络繁忙，网络是瓶颈，我们可能正在等待，但我们只等了这么久。 因此，如果您花费 1 分钟或 30 秒，那么我们可能会在两者之间超时。 但没有什么难的——如果我告诉你 10 秒，那可能有效，也可能无效。 如果我告诉你 30 秒，那可能行得通，也可能行不通。 所以我宁愿不说一个数字。 我想说的是，尽可能快地把它放进去。 如果你不能快速获得它，那么尝试像缓存搜索结果这样的东西，以便搜索或多或少地在页面上产生 - 或者在页面上产生的结果变得越来越多 - 或多或少是即时的。 或者尝试在您身边进行动态渲染，这可能是一种解决方法。 您还可以尝试的是，您可以尝试将其放在服务器端，并且基本上尝试在第一遍中生成尽可能多的内容。 这也有利于您的用户，尤其是当他们使用慢速网络时。 是的。 抱歉，我没有任何简单的答案，但 Googlebot 的时间很时髦。

回答 49:29 - 我认为这可能取决于网站的实际用途。 渲染速度的棘手问题之一是我们可以缓存从服务器发送的大量内容，而不是在浏览器中，因为我们可以将索引用于很多这些内容。 因此，有时如果 JavaScript 缓存在我们这边，我们就不必获取它。 然后，如果您再次比较时间，那么它将与用户看到的不匹配。 它与您在webpagetest.org 中看到的不匹配。 所以这真的有点棘手，对于我们确实知道需要更长时间的部分，我们会更有耐心。 但这使得测试变得棘手。 这就是为什么我们现在拥有所有这些测试工具，它们会显示尽可能多的错误，以便能够弄清楚，例如，它根本不起作用吗？ 它有时会起作用吗？有时会出现什么问题？

问题 50:29 - 对于非常大的网站，XML 站点地图中 URL 的顺序是否重要？

回答 50:34 - 不，我们不在乎。 这是一个 XML 文件。 我们提取所有数据。 我们一次处理所有这些。

问题 50:44 - 那么站点地图中的优先级参数呢？

回答 50:47 - 我们根本不使用它。 所以一开始，我们想，哦，这可能有助于确定我们应该多久抓取一次页面。 但事实证明，如果你问网站管理员，他们会说，一切都是优先事项。 这是最重要的。 与我认为站点地图中的更改频率类似，我们还注意到，就像人们告诉我们，事情一直在变化，但它最后一次更新是在去年。 因此，如果您有更改频率和日期，那么无论如何我们都会从日期中获取该信息。 所以我们忽略了变化频率。
问题 51:35 - 是否应该将公司模式仅添加到主页、联系页面或所有页面？

回答 51:42 - 据我所知，它只是主页。 我不知道。 你们有谁知道吗？

Liz 的回答 51:4 7 - 通常应该只有一页，包含组织和公司。 这通常是建议。

MARTIN SPLITT 52:00 - 我想哪一页都没有关系——就像不要把它放在你所拥有的每一页上一样，我猜是更重要的一点。 我认为这取决于——如果你是一个新闻网站，把它放在联系页面、关于页面或其他东西中可能是有意义的。 而在商店或餐厅网站中，将其放在主页上可能是可以的。

JOHN 52:20 - 我也认为，在这种情况下，这对我们来说并不重要，因为我们需要能够在主页或联系页面之类的地方找到它。 但是，如果我们在其他地方拥有它，它不会改变我们的任何东西。 因此，不能与之相比的最重要的事情是评论标记，我们有时会看到人们在网站的所有页面上放置公司评论，希望获得星星和他们网站上每个页面的搜索结果。 这对我们不利。 但是联系信息，如果你已经标记了，那是 - 我认为这没有问题。
问题 53:05 - 我们一直在使用的 Google 网站速度测试记录的页面加载时间非常慢，但我们与海外同事进行的独立测试显示页面加载时间非常快。 这种虚假记录 Google 措施是否会影响我们的网站在 Google 算法中的排名？

Marie Haynes：这不是我的问题，但为了提供一些背景信息，新的 Lighthouse 页面速度数据比 Page Speed Insights 过去更加苛刻。 因此，在 Page Speed Insights 上得分为 80 分的东西在 Lighthouse 上可能是红色的 29 分。 所以这是一个很好的问题。 这可能会导致 - 因为我们知道在移动设备中，速度非常慢的网站可能会被降级。 那么，如果我们说，你知道，如果你在灯塔测试中处于亏损状态，我们真的应该改进一些东西，因为它可能会导致降级，或者是否有截止日期？

回答 54:07 - 所以我们没有对外部工具和我们用于社交的所有工具进行一对一的映射。 是的，这很难说，但是在搜索中，我们尝试使用实际的，它是什么，实验室测试数据，有点像 Lighthouse 测试，以及 Chrome UX 报告数据，其中本质上是什么我们正在衡量的是网站的用户会看到什么。

MARTIN SPLITT 55:37 - 同样重要的是要看到 Lighthouse，例如，专门测量中端的 3G 连接——或者像中等性能的手机，是的。 所以，基本上，如果你在最近的 Apple McIntosh 或最近的快速 Windows 计算机上使用非常好的有线连接或非常好的 Wi-Fi 连接在你的办公室，当然，你会看到两秒的加载时间，但是在野外使用手机的真实用户可能看不到这一点。 所以这是其中一种情况，就像让您的网站更快永远不会受到伤害，但这真的，真的很难说从内部的角度来看它会是什么样子，因为我们使用的是非常具体的指标，不一定将一个映射到一个工具所暴露的内容....当然，解决这个问题很重要，因为您不希望您的用户永远等待您的网站。 那会伤害你的。 这会伤害你的用户。 这只会伤害你的搜索。 但我不付钱——我会说只是看看工具。 如果工具告诉你你做得很好，那么你不应该太担心它。 如果工具告诉你你做得不好，那么我认为花在弄清楚它为什么说上的时间——比如，如果它说的是相关的，那就浪费了。 您应该着眼于使网站更快。

移动性能对于您的用户以及其他一切都是一个非常重要的因素。 所以我想说确保您的网站在现实条件下表现良好。 甚至可以买一部便宜的手机，时不时地尝试一下这个网站，如果——那是我喜欢做的事情，而且在我加入谷歌之前，我曾经和我一起工作的开发团队一起做。 我想，看，你想在这部手机上使用这个网站吗？ 就像，哦，这太可怕了。 我想，嗯，是的，所以也许我们应该做点什么。

JOHN - 在 Chrome 中，您可以设置它并尝试不同的连接速度。 移动模拟器。 我认为这是非常值得一看的东西，而且，看看你的用户群。 如果您发现人们只使用高端 iPhone 使用您的网站，请查看您的分析数据，那么与您看到人们从随机的农村连接连接到您的网站相比，这可能不是问题，这是慢，而且他们有低端设备，那么也许更多。