您可以在您的网站上使用 Web 组件吗？
3:08 “使用 Web 组件进行 SEO 有什么问题吗？”
John 回答说：“[…] 在 SEO 方面，[…] Web 组件是使用各种形式的 JavaScript 实现的，而在涉及 Google 搜索时，我们几乎可以处理大多数 JavaScript。虽然我想说只是盲目地支持一切，但你可以测试它，你应该测试它。
对此进行测试的最佳方法是在 Search Console 中 – 有URL 检查工具。在那里，您可以插入您的 URL，您将看到 Google 将为该页面呈现的内容，即 HTML。首先，您可以在屏幕截图上看到它，然后也可以在您也可以查看的呈现的 HTML 中看到它。您可以仔细检查 Google 能够从您的 Web 组件中获取的内容。
如果您认为重要信息在那里，那么您可能已经准备就绪。如果您认为缺少某些重要信息，那么您可以深入研究并尝试找出卡在那里的原因是什么？现在我们有很多关于 JavaScript 网站和网络搜索的文档，所以我会仔细检查一下。[…]”
是否可以在页面的不同部分使用常见问题解答模式？
5:18 “是否可以使用常见问题解答模式来标记出现在博客文章不同部分中的问题和答案，这些问题和答案未格式化为传统常见问题解答列表？”
约翰回答说：“我仔细检查了官方文档[…]，看起来没问题。
一般来说，关于常见问题解答片段和结构化数据的重要部分是内容应该在页面上可见。因此，当有人访问该页面时，问题和答案都应该是可见的，而不是隐藏在页面的某个部分中。但是，如果问题和答案在页面上可见，即使它们位于页面上的不同位置，那也很好。
要记住的另一件事是，与所有结构化数据一样，FAQ 片段不能保证显示在搜索结果中。从本质上讲，您使您的网页有资格显示这些常见问题解答片段，但不能保证它们会显示。
因此，您可以使用测试工具来确保一切都正确实施。如果测试工具说没问题，那么您可能走在正确的轨道上。但是您可能仍然需要等待，看看 Google 如何解释您的页面并处理它们以查看搜索结果中显示的内容。
对于结构化数据，我认为常见问题解答就是这种情况，但至少对于其他一些类型，Search Console 中也有特定的报告，可为您提供有关已找到的结构化数据和显示的结构化数据的信息搜索结果，以便您可以粗略地衡量，它是按您希望的方式工作，还是按您希望的方式工作？
对于这样的事情，我建议您尝试一下并在您的网站上制作一个测试页面，看看搜索结果中的结果如何，仔细检查它是否是您想要做的，然后开始实施它您网站的其余部分。”
如果您对常见问题解答架构有更多疑问，请阅读我们博客上的文章，其中包含有关常见问题解答丰富网页摘要（也称为丰富搜索结果）的常见问题。
是否可以抄袭您的内容？
7:37 “Google 同意出版商抄袭自己的内容吗？”
根据约翰的说法，“[…] 看起来如果你在重复使用自己的内容，这并不是抄袭。[…]
从 Google 的角度来看，如果您从自己的网站中获取内容并在页面的某些元素发生更改的情况下再次发布，这基本上取决于您。这就是 […] 只是复制现有文章并更改其中的一些文字并没有提供很多价值的地方。
所以 […] 从战略的角度来看，你可能更适合为这些主题写一些独特且引人注目的东西，或者创建一篇涵盖这些不同变化的文章。但是 […] 从政策的角度来看，我认为没有什么特别的方式可以让您获取个别文章然后复制一些文章。[…] 但我的建议是 [to]少写一些实际上非常好的文章。
如果您 […] 强烈复制自己的内容，可能会出现的一种极端情况是，您最终会创建门口页面。这本质上就是取一个内容，然后用不同的词创造出很多很多的变化。这违反了我们的网站站长指南。
[…] 这也是您为您的网站创建大量 […] 垃圾页面的地方，而这些页面基本上 […] 总体上并没有提供任何独特的价值。而不是像那样稀释您网站的内容，我建议您专注于使您网站的主要内容更加强大。[…]”
如果您的网站在关闭 JavaScript 后对用户不友好怎么办？
10:24 “如果关闭 JavaScript，我们的网站就不是很友好。大多数图像未加载。我们的弹出菜单无法打开。但是，其所有菜单链接中的 Chrome 检查功能位于源代码中。我们对 JavaScript 的依赖可能仍然是 Googlebot 的问题吗？”
约翰：“从我的角度来看，[…] 我会测试它。[…] 而且，我可能会假设如果您以合理的方式使用 JavaScript，如果您没有做任何特别的事情来阻止页面上的 JavaScript，那么它可能会起作用。但是你最好不要相信我，而是使用测试工具来尝试一下。[…] 因此，我会仔细检查我们关于 JavaScript 和 SEO 的指南，并考虑尝试一下，确保它们以您想要的方式工作，然后将其用于整体改进您的网站。
你提到了关于 JavaScript 的用户友好性。因此，从我们的角度来看，我们拥有的指导本质上是非常技术性的，从某种意义上说，我们需要确保 Googlebot 可以从技术角度查看内容，并且它可以从技术角度。它主要不关心用户友好性。
但是，当然，您的用户关心用户友好性。这就是做更多的事情是有意义的，这样您的用户确实可以确保在您的页面上获得良好的体验。
这通常不仅仅是一个简单的测试工具的问题，而是你可能需要做一个小的用户研究，或者采访一些用户，或者至少在你的网站上做一个调查来了解在哪里做他们卡住了？他们面临着什么样的问题？[…] 可能是文本太小，或者他们不能正确点击按钮，那些不符合技术问题但更多的是用户端的东西。
[…] 如果你能改进这些，如果你能让你的用户更快乐，他们会留下来，他们会回来，他们也会邀请更多的人访问你的网站。”
单击此处进一步阅读我们博客上的 JavaScript SEO。
索引问题是否取决于所使用的网站技术类型？
13:08 “我们的静态页面是用 HTML 构建的，我们的博客是用 WordPress 构建的。我们的大多数博客文章都在 Google 中遇到索引问题。我该如何解决？”
约翰：“首先，重要的是要知道这些只是不同的平台。本质上，使用所有这些平台，您正在创建 HTML 页面。以及最终创建这些 HTML 页面的网站的背景或后端，这是 Googlebot 不会查看的内容。或者至少，这是 Googlebot 不会尝试评估的东西。
因此，如果您的页面是用 HTML 编写的，并且您在编辑器中编写它们，然后将它们加载到您的服务器上，并且它们就是这样服务的，那么我们可以看到它们是 HTML 页面。如果它们是基于 WordPress 或您正在使用的其他平台中的数据库在您的服务器上动态创建的，然后它会创建 HTML 页面，我们会看到这些最终的 HTML 页面，我们基本上会使用这些页面。
因此，如果您在抓取、索引或排名等方面发现网站整体存在问题，并且您可以排除其中的技术元素，即 Googlebot 能够看到内容，那么通常剩下的就是事物的质量方面。
这并不依赖于您用于创建这些页面的基础架构，而更多的是关于您在那里提供的内容以及您在网站上提供的整体体验。因此，如果您看到某些内容，例如，您的博客文章没有被 Google 收录或在 Google 中排名不佳，而您的静态 HTML 页面在 Google 上表现良好，那并不是因为它们是静态 HTML 页面他们在谷歌上表现不错，而是因为谷歌认为这些是它应该推荐给其他用户的好内容。
在那个层面上，这就是我要看的地方，而不是过多地关注基础设施，而是关注您提供的实际内容。
在内容方面，不仅仅是页面的主要部分的文本。就像整个网站周围的一切都在发挥作用。所以这就是我会尝试退后一步，看看更大的图景的地方。如果您没有从大局的角度看一些质量问题可能存在或您可以改进的地方，我强烈建议您进行用户研究。
为此，可能会邀请少数与您的网站没有直接关联的人，让他们在您的网站上执行一些任务。然后问他们一些棘手的问题，比如他们认为本网站可能存在问题的地方，或者他们是否会信任本网站，或者关于了解网站质量的任何其他问题。我们的一些博客文章中有很多这样的问题，您也可以从中获得灵感。[…] 将他们的答案铭记于心，并思考如何整体改善您的网站。”
为什么 Google 不尊重规范标签？
17:12 “我在五个页面上设置了规范 URL，但谷歌也在第三页上显示它。为什么它不仅显示我为其设置了规范的 URL？”
约翰说，“[…] 释义，听起来你在网站的五个页面上设置了一个 rel=”canonical”。您网站上的其他页面还没有设置 rel=”canonical”。谷歌正在展示所有这些页面，这些页面基本上以各种方式被索引。
我认为要记住的是rel=”canonical” 是一种指定一组重复页面中的哪些页面要像这样索引的方式。或者本质上，您想使用哪个地址。因此，特别是，如果您有一页，文件名可能是大写的，而一页的文件名是小写的，那么在某些情况下，您的服务器可能会显示相同的内容，从技术上讲，它们是不同的地址。[…] 但是从实际的角度来看，您的服务器显示的是同样的东西。
而谷歌，当它看到这一点时，它说，好吧，索引两个具有相同内容的地址是不值得的。相反，我将选择其中一个地址并使用它来索引该内容。使用 rel=”canonical”，您可以向 Google 发出信号并告诉它，嘿，Google，我希望您在索引此内容时使用地址的小写版本。您可能已经看过大写版本，但我希望您使用小写版本。这基本上就是 rel=”canonical” 所做的。
这不能保证我们会使用您在此处指定的版本，但这对我们来说是一个信号。它可以帮助我们找出所有其他条件相同的情况，您真的更喜欢这个地址，所以我们将尝试使用该地址。[…]
当我们认识到您的网站上有同一内容的多个副本时，它就会发挥作用。对于其他所有内容，我们将尽力将其编入索引。这也意味着对于您有 rel=”canonical” 的页面，有时它会遵循您给我们的建议。有时我们的系统可能会说，我想你可能搞错了。您应该使用其他地址作为规范。这可能会发生。这并不意味着它的排名会有所不同，或者它会在搜索中变得更糟。只是，谷歌系统正在选择一个不同的系统。
对于您网站上的其他页面，您可能根本没有设置 rel=”canonical”。对于那些，我们将尝试自己挑选一个。这也很好。在所有这些情况下，排名都会很好。索引会很好。只是搜索结果中显示的地址有所不同。
因此，如果您在某些页面上设置了规范集，但在其他页面上没有，我们仍会尝试为这些页面编制索引，并在搜索中显示这些页面时找到用于这些页面的正确地址。因此，在您的页面上使用 rel=”canonical” 是一个很好的做法，因为您试图控制这种可能会显示不同地址的模糊可能性。但是，rel =“canonical”并不是绝对必要的。
如何摆脱垃圾邮件反向链接？
20:56 “如果我们有数千个垃圾链接不断作为反向链接放置在恶意域上，我们该怎么办？它们包含垃圾关键字并在我们的域上导致 404。我们发现这些垃圾链接与我们在 2021 年垃圾邮件更新后受到的惩罚之间存在很强的相关性。我们否认了所有垃圾链接，并报告了被列为垃圾链接来源的域。我们还能做什么？”
约翰回答说：“[…] 在这个特殊情况下，我认为有两件事很重要。一方面，如果这些链接指向您网站上返回 404 的页面，那么它们实际上是链接到不存在的页面，那么我们不会考虑这些链接，因为没有任何关联它们在您的网站上。从本质上讲，人们正在链接到一个缺失的位置。然后我们会说，好吧，我们可以用这个链接做什么？我们无法将它连接到任何东西，所以我们将删除它 […] 就像其中很多可能已经被删除一样。
第二部分是您提到您否认了那些垃圾邮件反向链接。尤其是如果您提到这些来自少数域，那么您可以使用拒绝反向链接工具中的域条目来做到这一点。这基本上也将它们从我们的系统中取出。所以我们仍然会在 Search Console 中列出它们，你可能仍然会在那里找到它们并且对此有点困惑。但本质上，它们根本没有任何作用。如果他们被拒绝，那么我们告诉我们的系统，不应该以积极或消极的方式考虑这些。因此，从实际的角度来看，无论是从 404 方面还是从拒绝方面来看，这些链接可能对您的网站没有任何负面影响。
如果您在 Google 搜索中看到您的网站发生了重大变化，我不会关注这些链接，而是更进一步。这可以在您自己的网站内更好地了解您在那里提供的价值。就您为用户提供的巨大价值而言，您能做些什么来超越所有其他网站？您如何使搜索引擎尽可能清楚？[…] 你可以否认他们来自的整个域，然后继续前进。在那里你绝对不需要做任何事情。尤其是如果它们已经链接到 404 页面，它们就已经被忽略了。”
如何在没有 App Indexing 的情况下让您的应用被索引？
26:51 “ […] 如果 App Indexing 不再有效，如何让您的应用在 Google 上排名？”
John 回答说：“[…] 对于任何应用程序，您可以做的一件事是，[…]您可以为其创建主页。 这就是可以像其他任何东西一样在搜索中显示的东西。而对于很多智能手机应用程序，Play Store 或 App Store 上也会有一个页面。[…] 但通常，它们就像也存在的登录页面，它们是也可以出现在搜索中的普通网页。当人们在您的应用周围搜索某些内容时，这些内容可能会出现在“搜索”中。
[…] 尤其是当涉及到您自己的网站时，您可以为您自己的网站做我们谈论的所有关于 SEO 的事情。所以我不会说应用索引不再像 10 年前一样。[…] 相反，您有很多机会以不同的方式在搜索中可见。你不需要只依赖一个特定的方面。”
