SEO 办公时间，2022 年 3 月 4 日

这是2022 年 3 月 4 日Google SEO Office Hours与John Mueller的最有趣问题和答案的摘要。

在 schema.org 验证器与 Google Search Console 中测试架构标记

7:41 “约翰，所以我的第一个问题是，Google Search Console 在所需的结构化数据元素中抛出错误 [...]。 但是当我在validator.schema.org 上检查相同的内容时，它没有显示任何警告或任何错误。 所以第一个问题是，它是检查网页的 AMP 实现的正确网站吗？ […]“

约翰回答说：“是的，所以这些测试工具的用途略有不同。 这可能就是您看到这种差异的原因。 schema.org 中的测试工具更多的是基于 schema.org 的要求来理解 schema.org 标记，例如总体上。 Search Console 中的测试工具完全专注于我们可以从结构化数据中提取并用于在搜索功能中显示的内容。 所以它真的专注于那个故事的搜索部分。 在搜索中，我们只使用了 schema.org 标记的一小部分。 有时，我们的要求略有不同，可能我们需要的特定元素比基本 schema.org 标记所需的要多。 这就是为什么你经常看到这种差异的原因。 schema.org 验证器用于理论标记，而 Google 验证器实际上用于实际的 Google 搜索方面。 “

9:20 “[...]基本上，这不是错误。 这是 Search Console 中的警告。 当我在 Search Console 中查看详细信息时，它只是说你做得不对。 那么是否有可能的方法[解决问题]，还是我的开发团队应该解决这个问题？

约翰解释说：“是的，如果这是一个警告，那我就不用担心了。 它基本上只是说你可以做一些不同的事情。 […]。 如果您想知道到底有什么区别，我会做的是仔细检查developers.google.com上的搜索文档，我们在其中记录了所有结构化数据以及所有必需和推荐的字段。 可能是推荐或可选字段之一是触发此警告的原因。”

页面可能被抓取但未编入索引的原因

14:11 “ [...] 某些页面没有被索引的可能原因是什么，即使它们被多次抓取？ ”

约翰回答说： “这可能发生。 我认为这不是那么频繁，因为通常，当我们决定抓取某些东西时，我们也很乐意去索引它。 但是可能会发生这样的情况：我们抓取一个页面，然后最终决定，实际上，我们不需要索引它。

[...] 可能发生这种情况的一些常见情况（可能不适用于您的情况）是页面上是否有错误代码。 我们得先爬取，然后才能看到错误码。 如果页面上有noindex ，我们也得先爬取，然后才能看到noindex。 如果页面是我们已经看到的其他内容的完整副本，那么我们抓取它，我们看到它是重复的，但我们再次关注主页面。 所以这些是我们会抓取一些东西而不是索引它的正常情况。 但也有可能我们抓取了一些东西，然后，当我们开始索引时，我们决定，哦，实际上，我们想从网站上获取其他东西。 ”

15:41 “[...] 还有哪些其他因素 [除了已经提到的] 可能会导致 Googlebot 做出决定，哦，我们最后不想将其编入索引？”

约翰说：“我不知道。 我认为整体网站质量肯定在那里发挥作用，但通常，如果我们不相信网站质量，那么我们可能不会首先抓取页面。 所以，我认为，这是一个棘手的情况。 而且，如果您查看 Search Console，我认为，对于每个站点，您几乎都会有已发现但未编入索引的分组，以及已抓取但未编入索引的分组。 我认为，这在各个网站上都很常见。”

问这个问题的人想知道除了页面质量和技术问题之外，他们是否应该考虑其他一些问题。 John 建议他们不要过分关注某一页，“我也认为不要过度关注那个特定的页面，这一点很重要。 因此，如果您确定，从技术角度来看，一切正常，我不会认为该特定页面的质量是一个问题，而是网站该部分的感知质量或整个网站本身。 在这种情况下，我会尝试查看您可以做些什么来改进事情，不仅仅是没有被索引的单个页面，而是该页面周围的更大图景。 ”

删除电子商务网站上的产品列表会让您处于劣势吗？

21:48 “所以我们运营一个电子商务网站，我们现在正处于一个阶段，我们希望对我们的类别页面进行重大更新。 […] 在一份草案中，我们希望摆脱产品列表。 因此，您拥有带有分面搜索的产品列表，您可以在其中过滤您正在寻找的产品。 [...] 当我们删除类别页面的整个产品列表时，我们是否会在排名中处于劣势，因为首先，所有其他竞争对手都有这些类型的产品列表？ 其次，我猜这是电子商务页面的一个既定元素，用户希望 [...] 对所有产品有某种概述，过滤器让他们搜索他们想要的产品。 ”

约翰回答说：“从 SEO 的角度来看，我不会看到任何问题。 我认为您需要注意不同的事情，[...] 这样我们仍然可以找到我们在那里有干净链接的所有单个产品。 但是，如果您只是重新设计此类别页面并使其看起来更像是一个信息页面，那么我预计不会有任何问题。 我也不认为我们对搜索中的那些类别页面做任何特别的事情，所以从这个角度来看，你只是在改变设计，本质上。  

我认为如果它是一个产品页面会有所不同，而您要完全改变它，因为我们确实会尝试识别产品页面并找出价格在哪里，可用性在哪里，诸如此类。 如果你让它看起来完全不同 [...]，那么我可以想象这会影响我们如何选择产品页面，以及我们是否可以在产品搜索结果中显示它。 但是，据我所知，类别页面并没有对它们做任何特别的事情。 因此，如果您基本上隐藏它们，并确保我们仍然可以找到产品的链接[...]，您可以这样做。 但如果你想通过提供更多关于它们的信息来使它们更有用，我认为这是一个好主意。”

在问题的最后，John 补充说，从用户的角度检查变化很重要：“[...] 你提到'用户会感到困惑'。 我会仔细检查。 因此，从 SEO 方面来看，我认为这非常好，但从用户方面来说，这可能是你首先要测试的东西。”

内部链接结构的重要性

25:18 “如果您有用于面包屑设置的结构化数据，内部链接对 SEO 仍然很重要吗？”

约翰回答说：“是的，当然。 这是内部链接对搜索引擎优化至关重要的地方。 我认为这是您在网站上可以做的最重要的事情之一，以引导 Google 并引导访问者访问您认为重要的页面。 而你认为重要的是完全取决于你。 你可以决定让你赚最多钱​​的事情变得重要，或者你可以让你成为最强竞争对手的事情变得重要，或者你可能是最弱的竞争对手。 通过内部链接，您可以真正将注意力集中在这些方向和网站的那些部分上。 这不是您可以用结构化数据代替的东西。

因此，仅仅因为某个页面上有结构化数据，我不会将其视为正常内部链接的替代品。 即使在结构化数据中，您还提供了 URL，我们使用这些 URL 的方式与我们在页面上使用普通内部链接的方式不同。 所以绝对不是hreflang注释代替国家版本之间的链接，或者面包屑注释代替网站不同级别之间的链接的情况。 您确实应该在网站的不同部分之间拥有正常的 HTML 链接。 而且，理想情况下，您不应该只拥有一组基本链接，而是应该以战略性的方式看待它，并思考您最关心什么，以及如何通过内部链接突出它？ ”

产品列表页面上的多个产品架构

29:50 “对于一个产品listing页面，我们可以在产品listing页面上实现多个产品schema吗？ ”

John 说：“从我们的政策的角度来看，我认为您不应该这样做，至少在我上次检查有关结构化数据的政策时，因为对于产品结构化数据，我们真的希望将其应用于主要页面的元素。 如果您在一个页面上有多个产品，那么其中一个并不是页面的主要元素。 因此，从这个角度来看，您不应该在一个类别页面上使用多个产品结构化数据元素 [...]。 ”

如果您创建混合语言页面，您的排名会受到影响吗？

30:30 “对于使用混合语言的页面是否有最佳实践？ 例如，我们在日本的国际学校为日本和非日本家庭提供服务，但我们将主页上的大部分信息保留为英文。 我们也在日语页面上添加了支持。 […] 因为我们在现实生活中的交流是混合语言，所以让主页反映这种感觉更自然。 如果页面是故意混合的语言，我们会在搜索中受到惩罚吗？”

约翰回答说：“我不一定会说在这种情况下会受到惩罚。 但我们确实尝试了解页面的主要语言是什么，这有助于我们了解我们能够显示该页面的查询类型。 所以，我认为，在这样的情况下有点棘手。

我们也可以理解页面上何时有多种语言。 它只是让我们更容易真正清楚的是，如果有人用英语搜索，这是向他们显示的正确页面。 所以我可以想象像主页这样的东西，也许混合或轻微混合是有意义的。 如果您有一个主页作为初级英语，那么可能包含一些日语元素。 如果您有另一个主要是日语的版本，并且有一些英语元素，那很好。 但这有助于我们真正理解，在大多数情况下，这是一个英文页面。 如果有人在用英语搜索日本的特定类型的国际学校，那么我们可以说，好吧，这里有一段英语内容，我们知道它符合您的需求，并且与您给我们的查询相匹配。 因此，从这个角度来看，我不一定会说该页面受到了惩罚，但它使我们的系统更难弄清楚如何正确地对该页面进行排名。

您可以在这里考虑的一件事是在 Search Console 中查看哪些查询将访问您的网站或您的主页。 想想如果 Google 不能正确理解语言，哪些查询可能会受到影响。 很可能，如果大多数人都在搜索您的名字或您学校的品牌，基本上，那可能根本不会受到影响。 另一方面，如果大多数人正在搜索更广泛的查询，更通用的查询，几乎就像一个与您主页上的内容相匹配的句子，那么我可以想象您在搜索结果中出现的难度会更大一些，只是因为我们不确定您的主页是否实际上是该查询的那种语言 [...]。

您还可以做的一件事，[...] 是让您的主页成为这种双语版本 [...]，但另外为单个语言创建单独的页面，以便如果有人正在寻找有关国际学校的长格式信息，例如这样，他们仍然可以找到那些纯英文或主要是英文的页面，然后从那里过渡到您网站的其余部分 [...]。

移动版和桌面版的内容差异

34:20 “如果手机版和桌面版的内容有差异，是谷歌会惩罚网站，影响网站排名，还是说谷歌bot在手机版能找到，但赢了'不能排名？ ”

John 说：“因此，在大多数情况下，我们将大部分索引转移到移动优先索引，这意味着我们只会在这种情况下查看网站的移动版本。 因此，从本质上讲，如果网站的桌面版本有一些细微的不同，我们在大多数情况下甚至不会将其用于搜索。 所以我们并不是因为不同而惩罚一个网站，而是，就像，我们只看网站的一个版本，我们甚至不知道另一个版本上有什么不同的对待它.  

而对于少数仍在桌面索引中的网站，情况正好相反。 当然，如果移动版本中有 [...] 某些东西不在桌面版本上，并且您正在被桌面爬虫索引，那么我们就不会真正看到。 我们会不时抓取备用版本，但我们不会抓取它来获取更多信息，而只是为了确认桌面 URL 和移动 URL 之间存在这种联系。 ”

您可以在云中托管您的站点地图吗？

46:20 “我们有一个非常大的页面，其中包含数百万个 URL，并且 [...]站点地图目前正在翻新。 我们的 IT 团队正在考虑将 [...] 新站点地图文件存储在我们的云服务中。 这意味着从 example.com/sitemaps 到 cloud.com/sitemaps。 我们想知道，如果我们将站点地图存储在云中会不会有问题？ 如果这不是问题，我们是否还应该为这个 example.com/sitemap 的旧 URL创建一个永久重定向，或者我们应该如何计划移动？ ”

John 说：“绝对可以将站点地图文件托管在其他地方。 有两种方法可以做到这一点。 一种是，如果您在 Search Console 中验证了这两个域，那么就可以了。 另一种方法是，如果您使用 robots.txt 文件提交它，您可以在其中指定“站点地图：”，然后指定站点地图的 URL。 这也可以转到不同的域。 [...] 我也会将旧站点地图文件重定向到新位置以保持干净，但可能即使您只是删除旧站点地图 URL 并确保正确提交新的，那么这应该可以正常工作。  

可能有点棘手的是我不知道 Search Console 将如何直接在 UI中显示，特别是如果站点地图文件位于不同的位置，如果 Search Console 会在索引报告中显示站点地图信息，例如。 但这是一个报告问题。 这不依赖于站点地图文件的功能。 这实际上只是 Search Console 没有正确显示它。 而且，也许它确实如此。 我只是不是 100% 确定。 ”

域的历史会影响您的网站吗？

49:40 “[…]所以 [在之前的 SEO 办公时间] 我们提出了关于具有护送服务提供商历史的域的问题。 [...] 该域历史悠久，因为该网站的第一个快照是从 1997 年开始的。[...] 我们于去年 6 月重新启动了我们的网站 [...]。 我们遇到的主要问题是 [...] 我们仍然被标记为 [作为成人内容]。 此外，我们有这个问题 […] – 已爬网，目前未编入索引。 我们正在尝试了解域的历史是否真的会影响我们在索引方面遇到的问题。 [...] 我们确实相信我们发布的内容质量很好。 它是内部链接的，我们尝试建立一个高质量的网站。 我们目前挣扎的地方是页面性能，因此目前正在为此进行优化。 但是我们使用prerender.io ，所以我们为 Google 展示的已经是预渲染版本。 所以当谈到我们的灯塔分数时，一切都很好。 [...] 我们可以改进或寻找什么来理解为什么我们没有被索引？ 我也很高兴分享 URL。 “

约翰表示他可以稍后再看一下这个网址，然后他回答说：“通常情况下，事物的索引方面与之前网站上是否存在成人内容无关。

如果之前的内容非常垃圾，索引方面可能会受到影响。 因此，从索引的角度来看，这可能需要一段时间才能弄清楚，哦，这个新网站实际上根本不是垃圾邮件。

但如果纯粹是以前那里有成人内容，那么我可以想象我们的安全搜索过滤器在识别这一点方面可能有点慢。 我确实知道我们已经采取了一些措施来加快速度 [...]，或者安全搜索上可能还有其他一些东西有点坚持。

如果您进行站点查询，然后打开和关闭安全搜索，您可以检查安全搜索端。 您应该能够看到 SafeSearch 是否发生了某些事情。 但是，您在索引方面看不到这一点。 但我可以稍后再看一下，我们可以看看是否有一些非常明显的事情我可以让你知道。 ”