2019 年 3 月 8 日 - Google 帮助环聊笔记

本周，John 回答了一些关于 Page Speed、Anchor Text、Java Script 的好问题。 与往常一样，可以在下面找到完整的视频和成绩单！

如何处理翻译的内容？

0:33

我认为有一个这样的组合网站很好。 我认为对用户来说，让它易于阅读是有意义的，这样如果你是一个说英语的人并且你访问你的网站，它就不像俄罗斯、乌克兰和英语内容的混合体，而是所有的英文内容。 可能不是您拥有不同语言的所有内容，但没关系。 从 SEO 的角度来看，将翻译转化为高质量的内容确实很有意义。 所以不仅仅是使用谷歌翻译。 翻译工具在这方面仍然越来越好，但如果你手动翻译或使用谷歌翻译版本并将其清理并使其更具可读性，那就更好了。 这是用户注意到的，也是我们从算法的角度注意到的。 如果我们能分辨出这是真正高质量的内容，那么我们会在搜索结果中更好地对待它。

摘要：确保您的翻译内容可以用其他语言阅读，而不仅仅是通过 Google 翻译自动翻译。 还要确保翻译质量高，对用户有价值。

如果我的网站在 Javascript 上运行并且索引时间对内容至关重要，我怎么知道它需要被索引？

3:10

所以总的来说，第一部分是正确的。 在这种情况下，我们尝试尽可能快地索引内容，如果我们有一个静态 HTML 版本，我们可以这样做，然后下一步是我们尝试像浏览器一样呈现页面，我们也会选择该内容，并且将其用于索引。 这两件事结合在一起通常可以协同工作，但静态 HTML 版本不会被延迟（人为）直到 javascript 版本准备好。 所以从这个角度来看，对于大多数网站来说，存在这种差异并不重要，而且我们没有任何明确的时间适用于开始呈现页面所需的时间。 这可能会因页面类型、我们何时找到它、我们如何找到它以及该页面周围发生的事情而有所不同。 例如，如果我们认为这是非常快速地在搜索中显示的东西，那么我们将尝试立即渲染它。 所以有点难以考虑。 那里没有固定的数字。 一般来说，我会将此作为粗略的指导来确定您是否需要对客户端 javascript 内容进行处理。 例如，如果您有需要快速索引的新闻内容，那么我会确保 Google 可以尽快提取该内容，而无需单独呈现该内容。 对于新闻站点，尤其是在链接到所有新文章的新闻站点的翻页上，我真的会确保这些页面完全与提供给搜索引擎的静态 HTML 一起工作。 所以这就是我的想法，想想我的内容被立即编入索引有多重要，而不是需要多少分钟，因为没有固定的时间来确定需要多长时间。

摘要：对于 javascript 网站，Google Firsts 索引页面，然后需要时间来处理 javascript。 至于需要多长时间，没有固定的时间。 因此，如果您的内容需要经常更新，最好提供页面的静态 HTML 版本。

如果 url 检查工具和移动友好测试都从实时服务器中获取页面，它们的主要区别是什么？

9:16

所以移动友好测试的想法只是测试这个版本是否是移动友好的，所以这是主要的焦点。 而 url 检查工具，实时测试工具，更多地是为了查看“这个页面在索引中的表现如何？”，我认为它会检查一些事情，比如没有索引响应代码，那种通常会适用的事情对于我们是否获取此页面并将其放入我们的索引中。 移动友好的测试主要集中在移动端，inspect url 工具就像一把大折刀，具有不同的功能，您可以将其用于不同的事情。

摘要：移动友好测试是查看网站在移动设备上的表现如何，而 url 检查工具检查索引是否正常工作，例如没有索引响应代码。

我正在考虑在我的电子商务网站上拆分我的产品页面。 目前，它们可以在一个页面上配置，并显示多种变体。 你有什么建议？

18:00

我认为我会更多关注的方面是将这些产品拆分为单独的页面是否真的有意义，因为您所交易的是一个产品页面，该页面对该产品和所有变体都相当强大，而不是多个页面有点必须自己工作并得到自己的支持。 因此，与其为“跑鞋”提供一个非常强大的页面，不如为“蓝色跑鞋”“红色跑鞋”“绿色跑鞋”等多个页面进行竞争。 因此，如果有人在搜索“跑鞋”，那么这些小页面确实不如您为该主要产品拥有的那个产品页面那么强大。 所以我的一般建议是，如果你认为这些变化只是主要产品的属性，因为人们倾向于搜索主要内容然后说“哦，我想要哪种颜色，就像我找到了产品一样我想要，但我只需要选择我想要的颜色。” 然后我会把它们放在一个共享页面上。 然而，如果人们明确地在寻找这种变化，而这种变化真的很独特，而且它本身就很突出，人们来到你的网站时不会只是说“我想要跑鞋”而是“我想要这种特定类型的跑步”这种颜色的鞋子”那么这可能值得作为一个单独的产品拿出来。

摘要：除非产品变体单独突出并且人们会搜索该特定变体，否则最好将它们全部放在一个强大的页面上。 这样，产品页面的不同变体就不会相互竞争。

速度对于您网站的移动版本重要吗？

21:00

所以好的部分是我们有很多排名因素，所以你不必总是把所有事情都做到完美。 但这也意味着你会遇到这样的情况，你会说“谷歌说速度很重要，但这里的顶级站点没有那么快，所以它一定不重要”。 对我们来说，这绝对是重要的，但这并不意味着它凌驾于其他一切之上。 你可以想象你能想到的最快的页面可能是一个空页面。 但是，如果您正在搜索非常具体的内容，那么空白页面将是一个非常糟糕的搜索结果。 它真的很快，但那里没有内容，所以用户不会高兴。 所以我们必须平衡所有这些因素、内容、链接和所有这些信号，并尝试找出如何根据我们拥有的不同因素的组合来进行排名。 它也会随着时间的推移而改变，它可以很快改变。 例如，如果某件事目前确实具有新闻价值，那么我们可能会选择向稍微不同的网站展示更多是研究的、常青的话题。

摘要：速度只是 Google 使用的排名因素之一。 仅仅因为热门网站可能不快并不意味着它对您的网站不重要。

如果我们使用 JSON 或微数据、微格式，哪种类型的模式标记更适合 Google。 哪个更可取？

22:30

我们目前更喜欢 JSON-LD 标记。 我认为大多数新类型的结构化数据首先出现在 JSON-LD 中，所以这是我们更喜欢的。

摘要： JSON-LD 是 Google 的首选。

锚文本有多重要？

25:10

所以我认为首先，我不会太担心谷歌的专利，我们申请了很多不一定适用于网络大师需要做的事情。 所以我认为看到我们的工程师正在努力很有趣，但这并不一定意味着我们会立即受到影响。 关于一般的锚文本，我们确实将它用于文本。 这是我们确实接受的东西。 这是为我们提供有关链接的上下文的好方法。 特别是在您的网站中，如果您的链接仅显示“单击此处获取更多信息”，这对我们来说不是很有用。 你在哪里有一个链接，上面写着“你可以在这个产品页面上找到更多信息”，并用那个产品的名称链接到那个页面，那么这告诉我们这个页面可能真的是关于这个产品的。 因此，我肯定会继续查看您使用的锚文本，尤其是在您的网站内部，并尝试确保您提供的锚文本非常有用，并为页面上链接的内容提供上下文。

摘要：锚文本非常重要，因为它为 Google 提供了有关页面内容的上下文。 诸如“单击此处获取更多信息”之类的锚文本不会为 Google 提供太多信息，但诸如“您可以找到有关此产品页面的更多信息”之类的锚文本告诉 google，此页面是关于此产品页面的。

我们的注意事项：如果您正在制作自己的链接，如果您获得人工审核，那么有太多的关键字链接可能会提示垃圾邮件团队。

Google 如何直观地看到您的页面？

39:00

我们确实尝试从视觉上查看页面，但主要是关于首屏上方的实际内容还是首屏空间只是一个巨大的广告。 这就是我们所关注的，同样关于移动友好性，我们尝试对页面进行可视化映射，看看这个页面是否可以在移动设备上运行良好。 为此，我们必须绘制页面，如果某些元素不可读，只要它们在移动设备上工作，就可以了。 如果这些链接在那里，它们的大小合适，人们可以点击它们，那很好。 如果你正在做一些花哨的 css 转换来把它变成 3d 文本，那完全取决于你。 重要的部分是文本本身在页面上是可见的，并且您没有做太多花哨的标记来拆分该文本。 举个例子，如果你在旧系统中有一个标题，你有一个基于表格的布局，并且你想在顶部拆分治疗，我似乎人们将单独的字母放入单独的表格单元格中，从我们的角度来看，这使得几乎不可能看到这实际上是一个词，因为您使用标记将其拆分为不连贯的块。 从解析页面的角度来看，这真的很棘手。

摘要： Google 主要尝试查看实际内容是否在首屏，而不仅仅是一个巨大的广告。 就移动友好性而言，谷歌试图了解是否存在相同的链接、所有内容的大小是否正确以及人们是否可以点击这些链接。 最重要的是文本本身是否在页面上可见。

你能用 Javascript 换掉一个 URL 吗？

43:00

是的，我们可以把它捡起来。 我认为重要的部分是在页面加载后需要换掉 URL。 当用户执行特定操作时，不应将其换出。 因此，例如，如果用户将鼠标悬停在链接上，然后您使用 JavaScript 换出我们不会注意到的 URL，或者如果用户单击链接，然后您使用 JavaScript 换出 URL，那么也不会是我们会注意到的。 但是，如果页面加载，然后您执行一些 JavaScript 来清理 URL，以便它们链接到正确的规范版本，这非常好，就像我们在开始时谈到渲染时谈到的那样，有时这需要一些时间时间。 因此，我们不会立即选择我们可能会选择的东西，或者我们很可能会选择这两个版本，包括您在那里拥有的原始链接以及 JavaScript 版本。 因此，旧版本不会完全退出。

摘要：如果在页面加载后换出 URL，Google 可以获取。 唯一需要注意的是确保当用户执行特定操作时 URL 不会被换出。

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

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

问题 0:33 - 关于翻译的问题。 我知道，如果我将英语内容翻译成俄语或乌克兰语，大多数人只使用谷歌翻译并输入内容。 但是，如果您以母语人士的身份阅读，则其中 90% 的内容需要更正。 我对两点感兴趣。 如果我想为我的网站制作其他版本或其他语言，例如英语、俄语或乌克兰语，可以吗？ 第二个，我发现一篇关于我的利基的有趣文章，我想翻译它，这好还是不好？ 我需要让它适应国内读者吗？

回答 1:38 - 我认为有一个这样的组合网站很好。 我认为对用户来说，让它易于阅读是有意义的，这样如果你是一个说英语的人并且你访问你的网站，它就不像俄罗斯、乌克兰和英语内容的混合体，而是所有的英文内容。 可能不是您拥有不同语言的所有内容，但没关系。 从 SEO 的角度来看，将翻译转化为高质量的内容确实很有意义。 所以不仅仅是使用谷歌翻译。 翻译工具在这方面仍然越来越好，但如果你手动翻译或使用谷歌翻译版本并将其清理并使其更具可读性，那就更好了。 这是用户注意到的，也是我们从算法的角度注意到的。 如果我们能分辨出这是真正高质量的内容，那么我们会在搜索结果中更好地对待它。

问题 3:10 - Google 分两步抓取和索引内容。 首先是服务器端渲染，其次是客户端渲染，根据之前的说法，这个过程可能需要几天或几周才能完成。 对于使用 Javascript 的网站，如果索引时间紧迫，他们可能会遇到严重的问题。 我怎么知道需要多长时间？

回答 3:46 - 所以总的来说，第一部分是正确的。 在这种情况下，我们尝试尽可能快地索引内容，如果我们有一个静态 HTML 版本，我们可以这样做，然后下一步是我们尝试像浏览器一样呈现页面，我们也会选择该内容，并且将其用于索引。 这两件事结合在一起通常可以协同工作，但静态 HTML 版本不会被延迟（人为）直到 javascript 版本准备好。 所以从这个角度来看，对于大多数网站来说，存在这种差异并不重要，而且我们没有任何明确的时间适用于开始呈现页面所需的时间。 这可能会因页面类型、我们何时找到它、我们如何找到它以及该页面周围发生的事情而有所不同。 例如，如果我们认为这是非常快速地在搜索中显示的东西，那么我们将尝试立即渲染它。 所以有点难以考虑。 那里没有固定的数字。 一般来说，我会将此作为粗略的指导来确定您是否需要对客户端 javascript 内容进行处理。 例如，如果您有需要快速索引的新闻内容，那么我会确保 Google 可以尽快提取该内容，而无需单独呈现该内容。 对于新闻站点，尤其是在链接到所有新文章的新闻站点的翻页上，我真的会确保这些页面完全与提供给搜索引擎的静态 HTML 一起工作。 所以这就是我的想法，想想我的内容被立即编入索引有多重要，而不是需要多少分钟，因为没有固定的时间来确定需要多长时间。

问题 6:17 - 现在我们有一个很长的问题，关于理解搜索控制台中的标记类型，例如当我们将某些内容标记为“重复 Google 选择与用户不同的规范”或“重复提交的 URL 并且未选择为规范问题”时.

[用户提示] 这是一个 Javascript 页面。 它是预渲染的，所有内容都在静态 HTML 中，但谷歌仍在尝试执行该页面。 我们在这个电子商务环境中发现，这些具有独特描述和有意义内容的独特产品页面被标记为 Google 重复内容。 我们假设这归结为某种 JavaScript 渲染失败，Googlebot 一直看到相同的错误页面或类似的东西，因此认为它们是重复的 - 我们如何理解 Web 渲染服务最终是什么可能会导致内容看起来与 Google bot 重复。

回答 7:43 - 我将不得不看一些实际的例子，所以如果你能给我一些非常有用的例子。

问题 8:00 - Google 是否意识到一个持续存在的问题？

回答 8:00 - 不……我从一些网站那里听到的抱怨比其他网站更多，所以如果您发送一些有用的示例。

问题 8:24 - 如果一个 url 被标记，是否有任何关于在分析时发生的渲染的信息。 无论如何，是否可以查看索引中发生的资源加载错误？ 您在搜索控制台中没有该 UI，或者至少我无法使用它。 或者是否有任何地方可以让我们在索引器和/或重复检测查找器查看内容时看到内容的实际样子

回答 8:41 - 目前没有。 这是一件很有意义的事情。 对于大多数站点来说，这并不重要。 但在这种情况下，这将是有用的。

问题 9.16 - 下一个问题。 移动友好测试。 在理解索引器如何查看内容方面，您已经引用了几次。 但是，我们发现在加载资源时标记了许多其他错误，并且这些错误发生的速度似乎因域而异。 所以第一个问题，我们在移动友好测试中看到的错误是否代表了服务在索引期间会遇到的错误？ 或者 MF 测试是否有不同的资源分配？

回答 10:04 - 所以我认为您专门指的是为测试而引入的嵌入式资源，对吗？ 像JS文件CSS不同响应之类的东西？ 我认为目前有点复杂的方面之一是，与普通的谷歌机器人相比，我们对移动友好测试有不同的优先级。 我们尝试尽快从实时服务器中提取资源，并且在索引期间我们缓存了大量资源并仅获取页面的缓存版本。 因此，您在移动友好测试中可能会看到，我们尝试尽可能快地呈现此页面，并且我们可以获得大量此类资源，但对于其中一些资源，我们基本上会超时，基本上有能力从中提取此内容服务器。 这在很大程度上是您在移动友好测试中看到的一些错误。 我也相信，在检查 url 工具中，如果您使用实时测试，我们会尝试实时提取所有内容，有时这只是无法实时进行。 对于索引，我们有更多、更长一点的时间可供使用。 因此，如果我们看到需要这些资源，我们将拉取它们，缓存它们，并在尝试进行渲染时尝试使它们可用。 所以这是我们不需要做 iot live 的事情，所以如果需要更长的时间来做这件事，我们会耐心等待所有这些都在一起。 仍然存在时间的一个方面，即这些资源都无法缓存它们（例如会话 ID 和所有 JS URL），这使得我们真正需要保留缓存的版本和稍后重用它，那么那些我们可能，我不知道，出于某种原因，无法获取索引。 简而言之，我认为很难诊断出这样的问题，尤其是在您拥有大量嵌入式资源的情况下。 我通常从工程团队那里得到的指导方针是，我们应该告诉人们拥有更少的嵌入式资源，他们往往不会遇到这个问题。 这并不总是那么容易，所以，但总的来说，我会做的是将移动友好测试作为一个粗略的指导，所以如果它在 MTF 中有效，那么你肯定是安全的。 如果您确实看到其他一些事情因其他错误而超时，那么在大多数情况下，我们仍然可以将其用于索引。

问题 12:57 - 我猜你已经触及了它，切线地，我们是否应该知道 Web 渲染服务渲染的任何硬超时或任意超时。 如果 Googlebot 在渲染服务中渲染页面需要很长时间，是否有明确的实际使用内容。 它是否只是放弃并使用最初存在的页面html内容？ 我们是否清楚您最终可以在渲染过程中走多远？

回答 13:45 - 大多数情况下，如果出现问题或超时，我们只是在当时和那里拍摄快照。 所以是的......我认为在你的情况下，如果你正在预渲染内容，那么那里不应该有问题，因为内容就在那里。 我们有时在电子商务网站或使用非常模板化框架的网站中看到的是，在实际测试 URL 之前，我们会遇到假设存在重复内容的情况。 例如，如果我们看到一个 url 模式，就会发生这种情况。 例如，如果我们访问一堆具有不同模式或不同参数的 url，并且我们看到所有这些 url 都指向相同的内容，那么我们的系统可能会说“好吧，这个参数与网站不那么相关”全部”，然后我们倾向于删除这些 url，我们会说“这组 url 可能与我们已经抓取的另一组 url 相同。 所以特别是如果你有东西让我们看看，我见过很多的一个例子是，如果你有很多不同的电子商务网站并且它们都销售相同的产品 - 所以整个路径在产品部分之后大量域中的 url 是相同的 - 然后我们的系统会说“所有这些 url 都是相同的，它们都指向相同的产品”，因此我们不妨只索引这些域中的一个而不是全部这些域中。 我不知道这是否适用于您的情况，所以我不知道这是否有用，但这是我们的系统尝试针对我们在网络上找到的内容进行优化的事情之一，我们假设其他人在网络上也犯错误，我们试图解决这个问题。 我们看到“所有这些人都在创建重复项，但我们不需要抓取所有这些重复项”，因此我们可以专注于我们认为的实际网址。

问题 16:22 - 了解移动友好测试和 url 检查工具上的实时测试。 在移动友好测试中，Googlebot 尝试从实时服务器中获取页面，那么它与具有此功能的 url 检查工具有何不同？ 明智的渲染或获取页面和资源有何不同

回答 17:04 - 所以移动友好测试的想法只是测试这个版本是否是移动朋友，所以这是主要关注点。 而 url 检查工具，实时测试工具，更多地是为了查看“这个页面在索引中的表现如何？”，我认为它会检查一些事情，比如没有索引响应代码，那种通常会适用的事情对于我们是否获取此页面并将其放入我们的索引中。 移动友好测试主要集中在移动端，inspect url 工具就像一把大折刀，具有不同的功能，您可以将其用于不同的事情。

问题 18:00 - 在我们的客户电子商务网站上，一些产品以可配置的形式出售，这意味着产品的多个不同变体在同一页面上显示和管理。 我们正在考虑拆分这些页面，以便它们每个都有自己独立的产品页面，并带有一个全新的 url。 然后，客户评论将从旧页面移动到新的简单页面。 旧评论的日期早于新创建日期的事实是否可以标记为黑帽 SEO？

回答 18:37 - 所以，我认为评论没有任何问题，只要您可以继续向这些产品页面添加新评论。 我认为我会更多关注的方面是将这些产品拆分为单独的页面是否真的有意义，因为您所交易的是一个产品页面，该页面对该产品和所有变体都相当强大，而不是多个页面有点必须自己工作并得到自己的支持。 因此，与其为“跑鞋”提供一个非常强大的页面，不如为“蓝色跑鞋”“红色跑鞋”“绿色跑鞋”等多个页面进行竞争。 因此，如果有人在搜索“跑鞋”，那么这些小页面确实不如您为该主要产品拥有的那个产品页面那么强大。 所以我的一般建议是，如果你认为这些变化只是主要产品的属性，因为人们倾向于搜索主要内容然后说“哦，我想要哪种颜色，就像我找到了产品一样我想要，但我只需要选择我想要的颜色。” 然后我会把它们放在一个共享页面上。 然而，如果人们明确地在寻找这种变化，而这种变化真的很独特，而且它本身就很突出，人们来到你的网站时不会只是说“我想要跑鞋”而是“我想要这种特定类型的跑步”这种颜色的鞋子”那么这可能值得作为一个单独的产品拿出来。 所以这就是我可能会担心的区别——我不会太担心评论部分。

问题 20:36 新的 Search Console 标记架构功能是否与旧版本相同？

回答 20:50 我不知道新搜索控制台在结构化数据功能方面的确切计划是什么，但我们确实计划支持所有这些结构化数据功能。 所以可能会发生的是这些功能最终以稍微不同的方式出现在搜索控制台中。

问题 21:00 移动版速度怎么样，绿区速度很重要吗？如果是，为什么很多顶级网站仍然这么慢？

回答 21:20：所以好的部分是我们有很多排名因素，所以你不必总是把每件事都做到完美。 但这也意味着你会遇到这样的情况，你会说“谷歌说速度很重要，但这里的顶级站点没有那么快，所以它一定不重要”。 对我们来说，这绝对是重要的，但这并不意味着它凌驾于其他一切之上。 你可以想象你能想到的最快的页面可能是一个空页面。 但是，如果您正在搜索非常具体的内容，那么空白页面将是一个非常糟糕的搜索结果。 它真的很快，但那里没有内容，所以用户不会高兴。 所以我们必须平衡所有这些因素、内容、链接和所有这些信号，并尝试找出如何根据我们拥有的不同因素的组合来进行排名。 它也会随着时间的推移而改变，它可以很快改变。 例如，如果某件事目前确实具有新闻价值，那么我们可能会选择向稍微不同的网站展示更多是研究的、常青的话题。

问题 22:30 哪种类型的模式标记更适合 Google，我们应该使用 JSON 还是微数据、微格式。 哪个更可取？

回答 22:48 我们目前更喜欢 JSON-LD 标记。 我认为大多数新类型的结构化数据首先出现在 JSON-LD 中，所以这是我们更喜欢的。

问题 23:00 谷歌在 2 月或 3 月有没有进行重大更新？

答：23:15 我不知道，我的意思是我们一直在更新。 我不知道你会认为什么很重。 这可能取决于您的网站。 如果您的网站受到这些更新之一的强烈影响，您可能认为它非常沉重。 如果我们从整体上看网络，也许它就像经常发生的变化一样。

问题 23:24。 精简内容对附属网站意味着什么？

回答 23:34 与任何其他网站相比，附属网站的精简内容并不意味着任何不同。 我们已经看到，特别是在附属网站上，有一种只从提要中获取内容的趋势，因为它真的很容易做到。 您可以相当快地获得脚本来为您执行此操作，这很容易，您不需要两个来做很多工作，它会创建很多 URL。 但是，对于用户和我们来说，这当然不是那么有趣，因为您提供的东西与其他人已经拥有的东西一样。

问题 24:40 选项卡中隐藏的内容是否会成为索引问题？

回答 24:50 一般情况下索引是没有问题的。 这对用户来说可能是个问题，所以如果那里有您认为用户真正需要看到才能进行转换的内容，那么从您的角度来看，这将是一个问题。 关于索引，我们可以获取该内容并显示它，所以这不是问题。

问题25:10 2019年锚文本仍然是重要的排名因素吗？ 许多公司进行了研究，他们指出没有相关性。 然后是谷歌专利的链接。

回答 25:30 所以我想首先，我不会太担心谷歌的专利，我们申请了很多专利，不一定适用于网站大师需要做的事情。 所以我认为看到我们的工程师正在努力很有趣，但这并不一定意味着我们会立即受到影响。 关于一般的锚文本，我们确实将它用于文本。 这是我们确实接受的东西。 这是为我们提供有关链接的上下文的好方法。 特别是在您的网站中，如果您的链接仅显示“单击此处获取更多信息”，这对我们来说不是很有用。 你在哪里有一个链接，上面写着“你可以在这个产品页面上找到更多信息”，并用那个产品的名称链接到那个页面，那么这告诉我们这个页面可能真的是关于这个产品的。 因此，我当然会继续查看您使用的锚文本，尤其是在您的网站内部，并尝试确保您提供的锚文本非常有用，并为页面上链接的内容提供上下文。

问题 27:00 你能告诉我们 DMCA 流程是如何运作的吗？

回答 27:01 我不能告诉你这是如何运作的，因为我不知道这方面的细节，而且这也是一个法律程序，我不能给你法律建议。

Question 27:30 How does a content platform like medium get its status as content provider? When I check the transparency report for medium the status is, check a specific URL, it's hard to provide a specific status for a site like medium that has a lot of content. We're also a content provider, hosting supermarket catalogs and other PDF publications online, generated by users. So I guess the questions is how do we get that status?

More context from the person who asked the question. Basically the problem we're trying to solve is, our platform allows adding outgoing links in the catalogue and if one specific Url is flagged for going to a bad site, our entire domain is at risk and we have been blacklisted before. Basically it fits the bill because we have a large number of content and all of that is user generated, so how does one go about being in this standing?

Answer 28:48 Um, I don't know. Is it mostly in regards to the transparency report with regards to phishing or maybe malware? It sounded like originally you just want the status that's provided in the transparency report but with regards to link and the content that's provided that sounds more like it's towards phishing or spam?

We're trying to solve for the issue where the domain is blacklisted for phishing and spam. Under the hood we are solving that problem but the generic solution seems to be something like this because even if individual long-tail domains are blacklisted for a period of time our main commercial domain is sage, is that even a good assumption?

Answer 29:50 I don't know how to best attack that. So I think from my point of view, there's one thing that you could do. I don't know your website so its hard for me to say already. Make it so it's easier for us to understand which parts of our website belong together. So for example, if you have different subdomains per user then its easy for us to say, well this problem is isolated on this specific subdomain or subdirectory and then our algorithms can then focus on that on a subdomain level. Where as if all the content is within the main domain and the URL structure is a slash and then a number then its really have for our algorithms to say everything that matches this pattern is maybe phishing or spam that wasn't caught in time. The easier you can make it for us for figure out which parts belong together, which could be by user, or could be by type of content depending on how you group the content then the easier it is for us to kind of match an action that applies just to this part of the website.

Question Continued 31:33 There is no process that your aware of that you can apply or get the status of content provider? And does it actually link to having decreased risk for whole domain blacklisting?

Answer 31:46 I don't think the two side are connected, so I think that content provider status in the transparency report is something that's specific to the transparency report and wouldn't apply to the spam handling. We do have some fold here who are working on something specific for hostess or CMS providers, which I think is kind of what you fall into here. To try to give them more information on where we see spam and to better understand the grouping of content in regards to individual websites.

Question 37:00 Is it necessary to Hreflang links to paginated pages beyond page one?

Answer 37:18 So it's never necessary to add Hreflang links, that's kind of the first thing there. It's not like you will be penalized for having those links on all pages across your website, those links do help us better understand which pages belong together. HReflang links work on a per page basis so if links work well between the homepage version of your site and not between the product pages on your website that's perfectly fine. Use them for the URLs that you think need to have that connection for the language and country versions, you don't need to do that for everything. The other thing, sometimes doing Hreflang links properly is really complicated, especially if your mixing things like pagination and maybe filtering then that feels like something where you're adding so much complexity that it's unlikely you will end up with a useful result and I would just drop the hreflang links so that you don't have extra noise in search console. That's kind of the pragmatic approach that I would take there. Use Hreflang where you see that you have problems and if you don't have any problems in regards to localization then don't worry about the hreflang part.

Question 39:00 Does Google determine a page is low quality by taking into account what the pages looks like visually? I have a site that has elements that get 3D rotated when a user taps on them, when I look at this page as Googlebot, it see's these elements with the ext backwards and looks weird. Is that a problem or not?

Answer 39:20 From my point of view, that's no problem. We do try to look at the page visually but mostly with regards to, is the actual content above the fold or is the above the fold space just one giant ad. That's kind of what we focus on, also with regards to mobile friendliness we try to visual map a page and see, is this a page that would work well on a mobile device. And for that we kind of have to map out the page, its ok if some elements are unreadable as long as they work on a mobile device. If those links are there, they're the right size and people can click on them, then that's perfectly fine. If you're doing some fancy css transformation to turn this into 3d text, that's totally up to you. The important part is that the text itself is visible on the page and that you're not doing too much fancy markup to split that text up. So as an example if you have a headline in the old system where you have a table based layout and you wanted to split the healing on top, I've seem people put individual letters into individual table cells and from our point of view that makes it pretty much impossible to see that this is actually one word because you're using markup to split it up into disconnected chunks. From a parsing the page point of view that's really tricky.

Question 41:26 - I've heard that changing a title tag for page will drop in ranking temporarily is that true what if I have a number that has just changed on the page title?

Answer 41:47 - So it's not true that changing a title will automatically drop a page in ranking I don't think that would make sense. However if you change a title and you put new keywords in there then we obviously need to figure out like how we should rank that page based on that title. Where the title is is one of the things that we do look at. We do look at a lot of other things on a page as well a lot of other signals that are involved with ranking so just changing a title on its own should have a big effect over all but if you're adding something new there that wasn't there before and you want to rank for that new piece of thing there then obviously that does take a little bit of time. So if you're just changing numbers in the title then if people were searching for those old numbers or those new numbers that might be an effect that you would see. In practice people are not going to search for like number three or number five and expect your page to show up. I mean maybe there are exceptions but for the most part that's not going to be something that would affect your your pages ranking. So if you're changing numbers in a title over time I think that's perfectly fine if users are okay with that if that works for everyone.

Question 43:00 - Can Google crawl hyperlinks that we've swapped out the URL with JavaScript we do this as a workaround with our client due to CMS limitations.

Answer 43:08 - Yes we can pick that up. The important part I think is that the URL needs to be swapped out after the page is loaded. It shouldn't be swapped out when a user does a specific action. So for example if a user hovers over a link and then you use JavaScript to swap out the URL that wouldn't be something that we would notice or if a user clicks on a link and then you use JavaScript to swap out the URL then that also wouldn't be something that we would notice. But if the page loads and then you execute some JavaScript that cleans up the URL so that they link to the proper canonical versions that's perfectly fine and kind of like like we talked about in the beginning when it comes to rendering sometimes this takes a bit of time. So it's not an immediate thing that we would pick up we might or it's likely that we would pick up both of these versions both the original link that you had there as well as the JavaScript version. So it wouldn't be that the old versions would drop out completely.

Question 44:20 - Does Google understand related topics for example if I create a page about pets but I don't mention cats and dogs will that make it harder for Google to rank me?

Answer 44:35 - No I don't think that would be problematic. So it would of course make it harder to rank this page if someone searches for cats or dogs but you can create a page about pets that doesn't include all of those different types and I think that's that's pretty normal. Like there's a lot of variation of content out there and some content focuses more on on this side of the topic and some focuses more on a different part of the topic that's completely normal.

Question 45:09 - How does Google understand the quotes page given that they're technically duplicate content. Can Google tell that these are quotes pages and lots of content is also on other websites is that a bad thing or not? How does Google know?

Answer 45:30 - We do recognize when there are kind of parts of a page that are shared across other pages. So a really common situation is you have a footer on your web page that you share across a lot of pages. We can tell that this this part of text is the same as you have across other parts of your website. So what generally happens there is if someone searches for something that's in the shared piece of content we'll will try to pick the most matching page for that. If someone searches for something that's a combination of that content and something else on a page that will try to pull that best matching page. So that's the same as what would happen with these quotes pages and that if someone searches for a specific quote that you have on this page then we'll try to pick one of the many quotes pages that we have that has the same quote on it. It might be yours it might be like hundred other people, a lot of people have these quotes, and we'lll try to show that one in the search results. It's not that we would see this page as being lower quality it's just that you're competing with a lot of other sites that have the exact same quotes on it so if there is something unique that you're providing on these pages then I would make sure that that is also very visible there. So that it's easy for us to tell that well pages about this quote but also has a lot of information about other I don't know, Russian quotes or other German quotes, and we can tell this user is used to searching in Russian or German so we'll bring them to your site rather than to a generic site that has just all kinds of quotes. So the more you can bring unique value into those kind of pages more likely we'll be able to show that in the search results. But it's not necessarily something that you have to hide, we recognize these quotes we we understand that as sometimes are shared across lots of websites that's completely normal.

Question 47:40 - Suppose I started a blog the most following methodology is connecting your site map to the webmaster site from day one but what if I write 50 posts and then add a sitemap file is there any difference

回答 47:54 - 这两种方法都有效。 因此，站点地图文件可以帮助我们更好地了解网站上的新页面和更改页面。 这不是排名因素，因此您不会仅仅因为您拥有站点地图文件而排名更高同样，如果我们可以正常抓取站点或使用站点地图文件抓取站点，则站点在搜索中的显示方式没有太大区别。 因此，如果您要更改站点中有时稍微低一些的内容，站点地图文件对于较大的站点绝对不是关键，那么站点地图文件显然可以帮助我们更快地找到这些更改，但如果您刚刚开始您不一定需要有站点地图文件的博客。

问题 48:50 - 我们通过我们的网站转售希腊的酒店，我们为酒店开发了一个非常友好的部分，但是当我们嵌入这些酒店的 YouTube 视频时，我们也会复制这些酒店的内容和标题。 这对我们有害吗？

回答 49:10 - 我认为这可以追溯到我们对重复内容的其他问题。 重复的内容，如果你真的只是在许多不同的网站上提供相同的东西，那么你真的需要专注于确保你的网站上有一些独特的东西，那么这让我们很难说好这是实际上是我们需要显示搜索结果的网站。 因此，我建议您退后一步，思考您可以做些什么来确保您的网站真正独特且具有吸引力，而不仅仅是与所有其他网站相同。

问题 50:00 - 如果一个故事因为内容稀少且年代久远而被重定向，文章的负面影响是否会随着重定向而被转发？

答案 50:12 - 不一定。 因此，特别是在内容方面，我们会查看在我们登陆的最终页面上找到的内容。 所以如果你删除了内容，如果你清理了一些东西，我猜这会自动发生。 如果您重定向该页面并且旧内容不再存在并且我们只有新内容，那很好。 所以这不会是任何可以进行的事情。

问题 50:45 - 当我们将页面的移动友好版本与链接 rel alternate' 行为相关联时，如果搜索控制台报告移动友好错误是在页面的测试颠覆中是否自然？

回答 50:57 - 所以通常这意味着我们并不清楚这些页面中的哪些属于同一类。 因此，出于某种原因，我们将这些页面单独编入索引，而不是作为我们知道该桌面页面属于该移动页面的一对。 因此，这可能与您在这些页面上设置备用链接或 rel 规范链接的方式不匹配。 所以我也会对此进行研究，当然另一件事是我也会研究转向响应式设计需要什么，因为特别是在移动优先索引的情况下，所有这些问题我们都有单独的移动URL 他们只是让一切变得不必要的复杂。 而如果您可以迁移到响应式设计或仅对桌面版和移动版使用相同 URL 的设计。 比你省了这么多麻烦，所以与其跟进这类问题，不如花时间说，好吧，我应该投资一个计划来转向响应式设计，这样我就不必专注于这些以后还有什么问题。

问题 1:01:01- 像其他外部链接一样向维基百科链接和谷歌帮助文章添加 nofollow 是个好主意吗？ 好的数据荧光笔需要多长时间才能在搜索中生效？

回答 1:01:16 - Skay 所以将 nofollow 添加到 Wikipedia 链接。 我认为这没有多大意义，除非维基百科付钱给你放置这些链接。 因此，II 会为您不想与您的网站关联的链接添加一个 nofollow。 但否则，如果它是内容中的正常链接，我会看起来很正常，所以除非维基百科为这些链接付费，否则我会认为正常。 对于数据荧光笔来说，发生的事情是一种算法过程，可能需要一些时间，因为它基于它从您网站上的索引页面中学习的缓存页面，并且显然基于您处理数据的标记荧光笔，然后当我们在您的网站上重新抓取和重新索引它们时，它会将其应用于新页面。 因此，当我们在您的网站上重新抓取和重新索引内容时，这需要一段时间才能应用于内容。 所以没有固定的时间线，有时对于很多页面来说相当快，有时可能需要几个月的时间才能看到。 因此，没有那种即时按钮，它需要时间，就像您手动添加到页面的任何其他结构化数据一样。

问题 1:02:58 - Google 是否意识到并宣布在去年 11 月底 12 月初左右开始处理重复内容的方式发生重大变化？ 或者在那个时期，网络渲染服务开展业务的方式或网络渲染和索引与爬网索引之间的关系是否发生了重大变化，因为我们的系统没有任何变化，正如我所说的那样，我们已经看到了从那时开始的实质性问题特别是不仅对我们自己，而且我们还注意到同一时期对此类问题的许多其他观察？

答案 - 1:03:47 - 那里发生了实质性的变化。 我认为大约在秋天左右发生的唯一一件事是，我们开始将此功能添加到搜索控制台以突出这些问题，我认为这也是我开始看到更多此类报告的地方，一旦我们将其突出显示为用户，嘿，我们是否正在删除这些 URL 并且喜欢它们的图表，因为我们认为它们都是重复的，当然每个人都喜欢，哦，这是一个新问题，但在很大程度上，它基本上一直是这样的我们只是从未在搜索控制台中谈论过它。 所以我不知道我们何时开始在搜索控制台中推出该功能，但可能就像去年下半年一样。